Grape
Свой-
Постов
72 -
Зарегистрирован
-
Посещение
-
еще раз, в приборе вполне себе работали карты и 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 без особых проблем.
-
проблемы с SDHC
Grape ответил alexey123_45 тема в ARM
Правильно я понимаю, и перед записью и перед чтением есть проверка на состояние "tran"? и все равно - нокаут, если не вставить задержку? -
Lwip API socket
Grape ответил Kot_Schrodingera тема в ARM
шаманство было, но по поводу быстродействия. -
Lwip API socket
Grape ответил Kot_Schrodingera тема в ARM
да, и больше двух, но как сервер. /Gr -
stm32f7+Lwip+lan8742
Grape ответил Kot_Schrodingera тема в STM
я бы попробовал 2.0.3 и включил бы статистику. У меня были похожие затыки, в результате нашлась ошибочка в 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(;;); }