MiniMax

http://mightyohm.com/blog/2008/11/building...ake-some-noise/

Большие пакеты в моем проекте относятся к TCP/IP. Меньшие пакеты могут относиться к ICMP, ARP. Эти незачем резать.

Я делал так ..... #ifdef UIP_SPLIT_TCP_PACKET uip_split_output(); #else ethernet_send(); #endif .... #define BUF ((uip_tcpip_hdr *)&uip_buf[UIP_LLH_LEN]) /*-----------------------------------------------------------------------------*/ void uip_split_output(void) { u16_t tcplen, len1, len2; /* We only try to split maximum sized TCP segments. */ if(BUF->proto == UIP_PROTO_TCP && (uip_len > MAX_IEEE_LENGTH)) { uip_len -= UIP_LLH_LEN; tcplen = uip_len - UIP_TCPIP_HLEN; /* Split the segment in two. If the original packet length was odd, we make the second packet one byte larger. */ len1 = len2 = tcplen / 2; if(len1 + len2 < tcplen) { ++len2; } /* Create the first packet. This is done by altering the length field of the IP header and updating the checksums. */ uip_len = len1 + UIP_TCPIP_HLEN; BUF->len[0] = (uip_len >> 8); BUF->len[1] = (uip_len & 0xff); /* Recalculate the TCP checksum. */ BUF->tcpchksum = 0; BUF->tcpchksum = ~(uip_tcpchksum()); /* Recalculate the IP checksum. */ BUF->ipchksum = 0; BUF->ipchksum = ~(uip_ipchksum()); /* Transmit the first packet. */ uip_len += UIP_LLH_LEN; ethernet_send(); /* Now, create the second packet. To do this, it is not enough to just alter the length field, but we must also update the TCP sequence number and point the uip_appdata to a new place in memory. This place is detemined by the length of the first packet (len1). */ uip_len = len2 + UIP_TCPIP_HLEN; BUF->len[0] = (uip_len >> 8); BUF->len[1] = (uip_len & 0xff); uip_appdata += len1; uip_add32(BUF->seqno, len1); BUF->seqno[0] = uip_acc32[0]; BUF->seqno[1] = uip_acc32[1]; BUF->seqno[2] = uip_acc32[2]; BUF->seqno[3] = uip_acc32[3]; /* Recalculate the TCP checksum. */ BUF->tcpchksum = 0; BUF->tcpchksum = ~(uip_tcpchksum()); /* Recalculate the IP checksum. */ BUF->ipchksum = 0; BUF->ipchksum = ~(uip_ipchksum()); /* Transmit the second packet. */ uip_len += UIP_LLH_LEN; ethernet_send(); uip_len == UIP_BUFSIZE; } else { ethernet_send(); } }

http://www.bipom.com/products/us/3180265.html MSP Development System includes FREE Version of Micro-IDE. http://www.bipom.com/devsys_free/msp_devsys.exe MSPGCC GNU C Compiler Free Download http://www.bipom.com/devsys_free/mspgcc_setup.exe

Этот компилятор работает нормально. По умолчанию генерятся calla/reta. Проблема возникла только с библиотеками. Подключил ..\msp430\lib\msp5\libc.a ..\lib\gcc-lib\msp430\3.2.3\msp5\libgcc.a Все работает :-)

Установлено 2 чипа SN74AVCB164245VR. 3.3V дисплей подключен к 1.8V SRAM контроллеру ARM9 через эти драйверы. Мануал ( PDF) на плату здесь Кстати, сейчас готовится к выпуску версия 1.03 (Mini-Max/ARM9260, Mini-Max/ARM9G20) Там будет установлен дополнительный микроконтроллер (ATMEGA168) в качестве контроллера питания. Для новых SAM9 чипов последовательность включения питания очень жестко регламентирована. AVR обеспечивает: - контроль входного питания ( 6-26V); - правильную последовательность подачи напряжений; - контроль всех питающих напряжений на плате; - контроль и зарядка 3B батареи (ML621S/ZT); - .... ARM9 может общаться с AVR через I2C.

Это понятно что грузит. Но практически это не влияет на работу других приложений. Конечно-же все работало бы более эффективно при наличии DMA "memory-memory". Но в этом контроллере его нет. И вообще этот конроллер ( 9260) не для мультимедиа. Никто не собирается крутить на нем кино Для простого GUI все работает удовлетворительно

Процессор показывает загрузку 0%. Я это имел ввиду. Т.е. время пересылки очень маленькое и не тормозит другие задачи.

Да, 25 раз в секунду Дисплей имеет 18-bit шину. Процессор пишет 32-bit словами. Старшие 14 разрядов не используются. Организация FB подогнана под железо, чтобы цикл записи был оптимизирован по скорости .... static struct fb_var_screeninfo mmarm9_ili9325_var __devinitdata = { .xres = X_RES, .yres = Y_RES, .xres_virtual = X_RES, .yres_virtual = Y_RES, .height = -1, .width = -1, .activate = FB_ACTIVATE_NOW, .vmode = FB_VMODE_NONINTERLACED, .bits_per_pixel = B_PP, .red = {12, 6, 0 }, .green = { 6, 6, 0 }, .blue = { 0, 6, 0 }, .nonstd = 0, }; ..... static int mmarm9_ili9325_thread(void *param) { int ndx; u32 *videodata; struct mmarm9_ili9325_info *sinfo = (struct mmarm9_ili9325_info *)param; printk(KERN_ALERT "ILI9325 Thread Enter\n"); while(!kthread_should_stop()) { videodata = (u32*)sinfo->buffer; /* X=0,Y=0 */ iowrite32(0x40,sinfo->ir); iowrite32(0x0,sinfo->dr); iowrite32(0x42,sinfo->ir); iowrite32(0x0,sinfo->dr); iowrite32(0x44,sinfo->ir); /* Update LCD VIDEO RAM from FrameBuffer */ for ( ndx=0; ndx< MEM_LEN>>2; ndx++) iowrite32(*videodata++,sinfo->dr); /* Frames Per Second = 25 */ schedule_timeout_interruptible(HZ/25); } printk(KERN_ALERT "ILI9325 Thread Exit\n"); return 0; } ....

Я подключил MTF-TQ24NN731-LB. Дисплей имеет встроенный контроллер. Готового драйвера не нашел. Пришлось написать самому fb драйвер для ILI9325 контроллера. В принципе, не особо сложно. Программная пересылка FrameBuffer из SDRAM в память LCD контроллера 25 раз в секунду. Процессор не нагружается Запускал Minigui Фотографии можно посмотреть здесь

Спасибо за инфу. Попробую новый компилер http://www.innoventis.de/downloads/mspgcc/

MSPGCC может генерить корректный код для MSP430F5437 ? Попробовал void __attribute__((section(".fartext"))) Usage() { uart0_Printf("\n\rUsage EXT"); } int main (void) { // uart0_Init(9600); uart0_Printf("\n\rUsage test"); // Usage(); while(1); } Usage функция не работает. Есть какие-то трюки для памяти > 64K ?

[quote name='demitry' date='Nov 16 2009, 11:53' post='678606' Помогите! -)), рад бы взглянуть на ваши исходники.. Архив (8MB) с исходниками, BIN файлом и т.д. можно скачать отсюда http://www.bipom.com/support/mmarm9260/u-b...2008.10.tar.bz2

Насколько я понимаю, RNDIS это прослойка между TCP/IP и драйвером физического устройства ? http://www.microsoft.com/whdc/device/netwo...dis/rmndis.mspx Но я эту же задачу хочу возложить на AX.25 /KISS ( применяется для пакетной связи). Я посмотрел исходники Kiss драйвера на Linux. Там в принципе все понятно. Есть 2 функции для инкапсуляции/декапсуляции Kiss пакетов. Я так понимаю, что Kiss только делает обертку для IP пакетов. Если у нас есть "broadcast" физический интерфейс, то все в теории должно работать с KISS протоколом. Естественно, что все хосты будут получать все пакеты из RF сети и отфильтровывать по своему IP. Проблема коллизий не должна возникать потому, что mesh сеть решает эту проблему. Или я в чем-то глубоко ошибаюсь ?

А в чем принципиальное отличие ? Главный вопрос даже не в этом. Я имею ввиду транспортный уровень. Главное как сделать TCP/IP на несколько хостов поверх любого протокола. Трафик там не будет очень напряженный. Можно было-бы и без TCP/IP обмениваться. Но очень уж хочется иметь все стандарные linux утилиты для удаленного управления/администрирования