klen 1 1 августа, 2018 Опубликовано 1 августа, 2018 · Жалоба Здравсвуйте! с флехами размером 4 гигабайта работает все хорошою с большими 16/32 и тд начинаются глюки. при отладке выловил в функции clst2sect что индекс сектора становится выше диапазона и FatFS вываливается с ошибкой FR_INT_ERR это я что то не так делаю или это не только у меня? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 1 августа, 2018 Опубликовано 1 августа, 2018 · Жалоба кэши, выравнивание... Все там работает. Версию поновее. проверял до 64 гиг Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Integro 0 2 августа, 2018 Опубликовано 2 августа, 2018 · Жалоба Поддерживаю, работал с одной из последних версий, с 16 и 32 проблем нет! Помимо рекомендаций из предыдущего поста стоит также посмотреть на нижний слой, интерфейс карты и проверить адресацию для High Capacity Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 3 августа, 2018 Опубликовано 3 августа, 2018 · Жалоба спасибо! вроде заработало. тестировался на шести 2ГБ файлах на 16ГБ SanDISC uSD, читал начало и конец файла. использую крайний FatFS свой самописный драйвер (SDIO+DMA)->SDCARD как было сказано нужно обращать внимание на адресацию. в моем коде был косяг с умножением индекса блока на размер блока (512), до тех пор пока 32 бит хватало - работает, если файл лежал далеко за 2 ГБ все естественно читалось и писалось в неправильные блоки. еще нужно обратить внимание, что если не включать опцию FF_USE_EXFAT тип аргумента f_lseek - uint32_t и по большому файлу не полазишm даже если он есть. если FF_FS_EXFAT=1 то указатель позиции uint64_t ff.h: ... /* Type of file size variables */ #if FF_FS_EXFAT typedef QWORD FSIZE_t; #else typedef DWORD FSIZE_t; #endif ... настоятельно рекомендую использовать фичу FF_USE_FASTSEEK=1, без карты индексов FatFS итерациями в цикле индексы блокв индексирует. на маленьких файлах это не заметно. на больших все замедляется. http://elm-chan.org/fsw/ff/doc/lseek.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GenaSPB 11 3 августа, 2018 Опубликовано 3 августа, 2018 (изменено) · Жалоба Вот мой конфиг, служит хорошо. За FF_USE_FASTSEEK спасибо, при формировании wav файлов это полезно. ffconf.rar Изменено 3 августа, 2018 пользователем Genadi Zawidowski Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 26 августа, 2018 Опубликовано 26 августа, 2018 · Жалоба здравcтуйте. с помощью такой то матери дописал sdio->sdcard драйвер ( взамен НАL и libopencm3, т.к. использую свой самодельный SDK) попробывал выжать скорость чтения/запись. блоки читаются через DMA до максимального размера позволяющего эти модулем - 256к. stm32f405rgt6 168MHz шина sdio модуля включена на максимальноую скорость - делитель клока = 0 при записи на карту источником является флеш (т.е делается дамп прошивки и кладется на карту с последующей проверкой на большой машине правильности работы записи) с чтением посложнее - нет линейного куска памяти на запись размером 1M поэтому максимальый блок 96k - то что в своей тестовой програмке удалось отжать от системного стека, кучи и статических переменных карта Кингстон 16G class 10 UHS1 RAW WRITE 1M by 256.000k: 9.256 Mbyte/s 0.108s total RAW WRITE 1M by 128.000k: 8.845 Mbyte/s 0.113s total RAW WRITE 1M by 64.000k: 8.125 Mbyte/s 0.123s total RAW WRITE 1M by 48.000k: 7.836 Mbyte/s 0.127s total RAW WRITE 1M by 32.000k: 6.987 Mbyte/s 0.143s total RAW WRITE 1M by 16.000k: 4.285 Mbyte/s 0.233s total RAW WRITE 1M by 8.000k: 3.430 Mbyte/s 0.291s total RAW WRITE 1M by 4.000k: 1.727 Mbyte/s 0.578s total RAW WRITE 1M by 2.000k: 1.025 Mbyte/s 0.975s total RAW WRITE 1M by 1.000k: 0.515 Mbyte/s 1.938s total RAW WRITE 1M by 0.500k: 0.273 Mbyte/s 3.662s total чтение RAW READ 1M by 96.000k: 11.067 Mbyte/s 0.090s total RAW READ 1M by 64.000k: 10.107 Mbyte/s 0.098s total RAW READ 1M by 48.000k: 10.023 Mbyte/s 0.099s total RAW READ 1M by 32.000k: 9.391 Mbyte/s 0.106s total RAW READ 1M by 24.000k: 9.355 Mbyte/s 0.106s total RAW READ 1M by 16.000k: 2.604 Mbyte/s 0.384s total RAW READ 1M by 8.000k: 6.965 Mbyte/s 0.143s total RAW READ 1M by 4.000k: 5.379 Mbyte/s 0.185s total RAW READ 1M by 2.000k: 3.523 Mbyte/s 0.283s total RAW READ 1M by 1.000k: 1.773 Mbyte/s 0.563s total RAW READ 1M by 0.500k: 1.295 Mbyte/s 0.771s total SAMSUN 32G EVO Plus UHS1 RAW WRITE 1M by 256.000k: 10.171 Mbyte/s 0.098s total RAW WRITE 1M by 128.000k: 10.083 Mbyte/s 0.099s total RAW WRITE 1M by 64.000k: 8.279 Mbyte/s 0.120s total RAW WRITE 1M by 48.000k: 8.410 Mbyte/s 0.118s total RAW WRITE 1M by 32.000k: 7.952 Mbyte/s 0.125s total RAW WRITE 1M by 24.000k: 6.836 Mbyte/s 0.146s total RAW WRITE 1M by 16.000k: 7.396 Mbyte/s 0.135s total RAW WRITE 1M by 8.000k: 5.311 Mbyte/s 0.188s total RAW WRITE 1M by 4.000k: 3.837 Mbyte/s 0.260s total RAW WRITE 1M by 2.000k: 1.875 Mbyte/s 0.533s total RAW WRITE 1M by 1.000k: 0.952 Mbyte/s 1.049s total RAW WRITE 1M by 0.500k: 0.486 Mbyte/s 2.057s total RAW READ 1M by 96.000k: 10.830 Mbyte/s 0.092s total RAW READ 1M by 64.000k: 10.054 Mbyte/s 0.099s total RAW READ 1M by 48.000k: 9.697 Mbyte/s 0.103s total RAW READ 1M by 32.000k: 8.490 Mbyte/s 0.117s total RAW READ 1M by 24.000k: 8.581 Mbyte/s 0.116s total RAW READ 1M by 16.000k: 8.955 Mbyte/s 0.111s total RAW READ 1M by 8.000k: 6.206 Mbyte/s 0.161s total RAW READ 1M by 4.000k: 5.819 Mbyte/s 0.171s total RAW READ 1M by 2.000k: 3.707 Mbyte/s 0.269s total RAW READ 1M by 1.000k: 1.809 Mbyte/s 0.552s total RAW READ 1M by 0.500k: 1.720 Mbyte/s 0.581s total какой то noname промаркированный class 4 RAW WRITE 1M by 256.000k: 10.173 Mbyte/s 0.098s total RAW WRITE 1M by 128.000k: 10.063 Mbyte/s 0.099s total RAW WRITE 1M by 64.000k: 8.218 Mbyte/s 0.121s total RAW WRITE 1M by 48.000k: 8.081 Mbyte/s 0.123s total RAW WRITE 1M by 32.000k: 8.082 Mbyte/s 0.123s total RAW WRITE 1M by 16.000k: 8.192 Mbyte/s 0.122s total RAW WRITE 1M by 8.000k: 6.135 Mbyte/s 0.162s total RAW WRITE 1M by 4.000k: 3.267 Mbyte/s 0.306s total RAW WRITE 1M by 2.000k: 1.896 Mbyte/s 0.527s total RAW WRITE 1M by 1.000k: 0.953 Mbyte/s 1.048s total RAW WRITE 1M by 0.500k: 0.486 Mbyte/s 2.056s total RAW READ 1M by 96.000k: 10.830 Mbyte/s 0.092s total RAW READ 1M by 64.000k: 9.985 Mbyte/s 0.100s total RAW READ 1M by 32.000k: 9.767 Mbyte/s 0.102s total RAW READ 1M by 16.000k: 9.243 Mbyte/s 0.108s total RAW READ 1M by 8.000k: 8.047 Mbyte/s 0.124s total RAW READ 1M by 4.000k: 6.397 Mbyte/s 0.156s total RAW READ 1M by 2.000k: 4.469 Mbyte/s 0.223s total RAW READ 1M by 1.000k: 2.473 Mbyte/s 0.404s total RAW READ 1M by 0.500k: 1.810 Mbyte/s 0.552s total выводы которые я сделал пока карячился с написанием драйвера. а) нужно обрабатывать все сотояния SDIO модуля и статусы SD карты, иначе можно залететь в куданибудь и зависнуть. SDIO стейт-машина ... б) как Вы видте при чтении и записи большими кусками все упирается в SDIO модуль - сорт карты не влияет на пиковую скорость, разница возникает толькана маленьких, но тут както нужно отделять время кода драйвера. с) FatFS дробит запросы на чтение и запись кратным 32 блокам(32*512 = 16k) поэтому она тоже ограничивает скорость (это согласовалось с результатами сырых измерений скорости довольно точно соответсвует 16к - тоесть FatFS выдал при линейной записи порядка 7-8Mb/s, а запись 6-7Mb/s) тут также нужно сказать что код самого FatFS при длинных линейных операциях практически не влият на скорость - что хорошо ( но на вид код у Чана - сплjшные макароны.... у нас за такое убили бы, закопали и табличку написали:)) д) FatFS можно поковырять на предмет увеличения батча записи/чтения более 32 блоков - вплоть до 512 ( 256k - то на что способна DMA со своим гребанным 16-битным NDTR недосчетчиком) е) кому надо наипобыстрей - писать руками в сектора без файловых систем - 10Mb/s как бы реальность. ё) провел "грязные игры с клоком" - клок шинного интерфейс sdio модуля тот же что и usb (48MHz) в доке написано что можно до 50.. попробывал потихоньку гнать множителем rcc.q - результат - скорость обмена пропорционально увеличилась, работает свплоть до множителя rcc.q=5 , при таком множетеле и раскачегаренном системном клоке в 240МГц скорость обмена на чтение достигла 20Мb/s, на запись ~15Mb/s. тут еще флешка наверно должна быть хорошей чтобы проканало как у меня. ... теперь будем плавно пробовать прикручивать eMMC микросхему - жизнь показала что sd-сокеты это для "бытовой" аппрптуры, разваливается и не контачит... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 27 августа, 2018 Опубликовано 27 августа, 2018 · Жалоба ... теперь будем плавно пробовать прикручивать eMMC микросхему - жизнь показала что sd-сокеты это для "бытовой" аппрптуры, разваливается и не контачит... Ну не знаю... Все зависит от кривизны рук оператора, и чего он там засовывает(в смысле, чистая карточка или вся измазана в пыли и грязи) За 5и летний срок использования карточек и холдеров проблемы были только в этом. А вот пайка этих ммэсин, с шагом шаров 0.5мм, причем сгруппированных в один маленький квадрат может привести к боольшим проблемам :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 27 августа, 2018 Опубликовано 27 августа, 2018 · Жалоба А вот пайка этих ммэсин, с шагом шаров 0.5мм, причем сгруппированных в один маленький квадрат может привести к боольшим проблемам :laughing: Если производство нормальное и платы качественные, то никаких проблем нет. А вот с SD... ставим массово DM3C от Hirose - в плане механической прочности просто отвратительная дрянь :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 27 августа, 2018 Опубликовано 27 августа, 2018 · Жалоба дело в том что платы летают+вибрируют, и иногда с сильно ударяются об земную поверхность. опыт показал что sd-сокет на стационарных приборах допустим, а на перемещающейся в пространстве нет. на вибростенде проверяли - нарушение электрического контакта при вибрации. к тому же все надо покрыть лаком - и что? сокет проливать ? еще качество у сокетов от партии к партии разное.... я сам не видел, но коллеги говорят что часто встречают тупо припаянные sd-карты к платам без сокетов в девайсах подобного толка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grape 0 27 августа, 2018 Опубликовано 27 августа, 2018 · Жалоба ... еще нужно обратить внимание, что если не включать опцию FF_USE_EXFAT тип аргумента f_lseek - uint32_t и по большому файлу не полазишm даже если он есть. если FF_FS_EXFAT=1 то указатель позиции uint64_t а в fat32 может быть файл размером больше UINT32_MAX? ... как было сказано нужно обращать внимание на адресацию. в моем коде был косяг с умножением индекса блока на размер блока (512), до тех пор пока 32 бит хватало - работает, если файл лежал далеко за 2 ГБ все естественно читалось и писалось в неправильные блоки. 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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Obam 38 27 августа, 2018 Опубликовано 27 августа, 2018 · Жалоба Изи же. Ну, если проволочным хомутиком по слову "Taiwan" прихватить для устранения эффекта "консоли", то... может быть и проканает ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 178 27 августа, 2018 Опубликовано 27 августа, 2018 · Жалоба Ну, если проволочным хомутиком по слову "Taiwan" прихватить для устранения эффекта "консоли", то... может быть и проканает ;) Да держится прекрасно :laughing: И тряску прошла... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба Тоже недавно сделал свой драйвер для SD. Правда для шины SPI. И вот вопрос: в примерах от Чана мультисекторная запись реализована CMD25. Интересно, а есть гарантия, что ФС при записи нескольких секторов подряд запишет именно последоватлеьные сектора. Например, нужно записать 3 сектора. ФС должна записать 128, 129, 130. А не 129, 150, 130. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlanDrakes 1 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба Гарантия есть. Она в самой команде CMD25, которая пишет сектора последовательно, не получая номеров в процессе выполнения. Для её окончания даже есть команда CMD12 - STOP_TRANSMISSION. Документ SD Phisical Layer Specification так же говорит: CMD25: [Address (PTP) data transfer command] Args: [31..0] - Data Address Continuously writes blocks of data until a STOP_TRANSMISSION follows. Block length is specified the same as WRITE_BLOCK command. Переводим. "Последовательно пишет блоки данных до получения команды STOP_TRANSMISSION. Длина блока определяется аналогично команде CMD24 - WRITE_BLOCK" Для карт высокой ёмкости длина блока ВСЕГДА равна 512 (размеру сектора). Для карт обычной ёмкости её можно задавать командой CMD16 - SET_BLOCK_LEN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 31 августа, 2018 Опубликовано 31 августа, 2018 · Жалоба Переводим. Мне перевод не нужен, читаю английский без перевода :rolleyes: Но вопрос мой был немного в другом. Я знаю, как работает CMD25. Меня интересует: есть ли железобетонная гарантия, что файловая система от Чана при мультисекторной записе (передавая sector_count > 1) выдаст сектора "без дырок". Например, она пишет сектора 10, 11, 12 - это без дырок. Их сразу можно писать на карту. А вот с дырками, но тоже несколько секторов: 10, 20, 12. Есть дырка. Я к чему задаю вопрос: может быть ФС требует записи нескольких секторов, лежащих не линейно, в надежде, что низкоуровневый драйвер сам разгребёт это? Например через кольцевой буфер? Я думаю, что Чан всё делает правильно, т.е. даёт сектора последовательно, пригодные для записи на носитель. Но всё же, а вдруг? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться