Grape

еще раз, в приборе вполне себе работали карты и 64 и 128Gb в fat32. сейчас постепенно переход на exFat. Если работать с большим количеством маленьких файлов, то просится кеширование. Если файлы по десятку мегабайт, все ок.

На встраиваем дивайсе все спокойно работает, FatFS, 128Gb, проблем нет. И в виндах читается/пишется весь раздел - больше 32gb. специально сейчас отформатировал SDXC 128Gb в fat32, записал 42Gb архив, все в порядке. (частями по 4g) Ну и в довесок, все, кто форматирует разделы 32Gb+ в fat32 видимо не в курсе, что тратят время зря :)

Насколько я знаю, винды не дают отформатировать раздел больше 32gb в fat32 без танцев, но прекрасно читают/пишут уже отформатированные разделы. По крайней мере у меня проблем не было. https://www.intowindows.com/3-ways-to-format-32gb-usb-drives-to-fat32-in-windows-10/

FAT32 спокойно поддерживает карты больше 32G. проверено на 64 и 128, единственно размер кластера большой, для мелких файлов не оптимально.

а в fat32 может быть файл размером больше UINT32_MAX? 32 бит должно хватать для адресации карт до 2Tb включительно. Умножение требуется для карт SDSC (max 2Gb), там байтная адресация. 4.3.14 Command Functional Difference in Card Capacity Types CCS in the response of ACMD41 determines card capacity types: CCS=0 is SDSC and CCS=1 is SDHC or SDXC. Memory access commands include block read commands (CMD17, CMD18), block write commands (CMD24, CMD25), and block erase commands (CMD32, CMD33). Following are the functional differences of memory access commands between SDSC and SDHC, SDXC: Command Argument SDHC and SDXC use the 32-bit argument of memory access commands as block address format. Block length is fixed to 512 bytes regardless CMD16, SDSC uses the 32-bit argument of memory access commands as byte address format. Block length is determined by CMD16, i.e.: (a) Argument 0001h is byte address 0001h in the SDSC and 0001h block in SDHC and SDXC (B) Argument 0200h is byte address 0200h in the SDSC and 0200h block in SDHC and SDXC

WolfSSL прикручивается к lwip без особых проблем.

Правильно я понимаю, и перед записью и перед чтением есть проверка на состояние "tran"? и все равно - нокаут, если не вставить задержку?

шаманство было, но по поводу быстродействия.

да, и больше двух, но как сервер. /Gr

я бы попробовал 2.0.3 и включил бы статистику. У меня были похожие затыки, в результате нашлась ошибочка в lwip.

а какая версия lwip?

в предыдущем тесте приоритет у main ниже. если у main приоритет выше, то 000000.010 MAIN Run at : 96MHz 000000.010 -- [0] - before wait 000000.010 -- [1] - before wait 000000.010 -- [2] - before wait 000000.509 MAIN before evf set 000000.509 MAIN after evf set 000000.509 -- [0] - after wait 000000.509 -- [1] - after wait 000000.509 -- [2] - after wait tn_event.zip

000000.010 MAIN Run at : 96MHz 000000.010 -- [0] - before wait 000000.010 -- [1] - before wait 000000.010 -- [2] - before wait 000000.509 MAIN before evf set 000000.509 -- [0] - after wait 000000.509 -- [1] - after wait 000000.509 -- [2] - after wait 000000.509 MAIN after evf set да, порт для M3 + правки для удобства и отладки, собранные по форуму..

Все задачи просыпаются.

задержки в тиках сист.таймера. void task(void *p) { int err; for(;;) { unsigned int evflags; err = tn_event_wait(&evftest, 1, TN_EVENT_WCOND_AND, &evflags, TN_WAIT_INFINITE); TRACE("WAIT END %d, %d", (uint32_t)p, err); my_sleep(5); } } void tn_test(void) { //где то в другой задаче tn_event_create(&evftest, TN_EVENT_ATTR_MULTI, 0); // запускаем 4 задачи create_task(task, 1); create_task(task, 2); create_task(task, 3); create_task(task, 4); my_sleep(100); tn_event_set(&evftest, (1<< 0) | (1<< 1) | (1<< 2) | (1<< 3) ); for(;;); }

в 2.7 просыпаются все. только что проверил. /gr

ключевое слово SECTION, указать явно NOROOT /gr

UM10360, rev2, 20100819 Modifications: • UART0/1/2/3: FIFOLVL register removed.

Спасибо! немножко дополнений... diff -urN 2.7/TNKernel/tn.c 2.7_mod/TNKernel/tn.c --- 2.7/TNKernel/tn.c 2013-07-01 10:29:34.000000000 +0400 +++ 2.7_mod/TNKernel/tn.c 2013-07-16 12:42:45.687500000 +0400 @@ -238,12 +238,12 @@ TN_CHECK_NON_INT_CONTEXT - tn_disable_interrupt(); - if(priority <= 0 || priority >= TN_NUM_PRIORITY-1 || value < 0 || value > MAX_TIME_SLICE) return TERR_WRONG_PARAM; + tn_disable_interrupt(); + tn_tslice_ticks[priority] = value; tn_enable_interrupt(); diff -urN 2.7/TNKernel/tn_event.c 2.7_mod/TNKernel/tn_event.c --- 2.7/TNKernel/tn_event.c 2013-07-01 10:30:42.000000000 +0400 +++ 2.7_mod/TNKernel/tn_event.c 2013-07-16 12:43:43.015625000 +0400 @@ -349,10 +349,12 @@ { TN_INTSAVE_DATA +#if TN_CHECK_PARAM if(evf == NULL || pattern == TN_INVALID_VAL) return TERR_WRONG_PARAM; if(evf->id_event != TN_ID_EVENT) return TERR_NOEXS; +#endif TN_CHECK_NON_INT_CONTEXT diff -urN 2.7/TNKernel/tn_mutex.c 2.7_mod/TNKernel/tn_mutex.c --- 2.7/TNKernel/tn_mutex.c 2013-07-01 10:31:54.000000000 +0400 +++ 2.7_mod/TNKernel/tn_mutex.c 2013-07-16 12:44:39.609375000 +0400 @@ -93,7 +93,7 @@ TN_CHECK_NON_INT_CONTEXT - if(tn_curr_run_task != mutex->holder) + if(mutex->holder && (tn_curr_run_task != mutex->holder)) return TERR_ILUSE; //-- Remove all tasks(if any) from mutex's wait queue

На lpc1778 работает и TNnet и LwIP. С dhcp в LwIP проблем не было, все завелось сразу. По ресурсам процессора - примерно одинаково. на Lwip максимальная скорость отдачи по http файла (100мб) из памяти порядка 6 Mb/s. у TNnet точно больше 3 Mb/s. оба стека использовались вместе с TNkernel. некоторый плюс у LwIP - есть обсуждение на сайте разработчиков, есть ipv6 и ppp минус - настройки требуют некоторого шаманства.

KSZ8863MLL http://www.micrel.com/index.php/en/product...ksz8863mll.html

Подтверждаю, все корректно работает на LPC1778, LPC2468. единственно, не стал использовать прерывания и сервисы RTOS - долго. /Gr

Все работает в голой LPC1778, проблем нет.

проблема похоже не в плагине, а в tnkernel. task_set_dormant_state сбрасывает task->create_queue, а после, в tn_task_delete задача удаляется из глобального списка и список портится.

специально проверил, 4 задачи передают данные, суммарный поток ~2MB/c + пятая telnet запущено вчера вечером. на данный момент никаких проблем lwip из git + tnkernel. lpc1778 /gr