stm32f4 + Chan's FatFS, работа с большими SD картами Опции

[klen]

Здравсвуйте!
с флехами размером 4 гигабайта работает все хорошою с большими 16/32 и тд начинаются глюки.
при отладке выловил в функции clst2sect что индекс сектора становится выше диапазона и FatFS вываливается с ошибкой FR_INT_ERR
это я что то не так делаю или это не только у меня?

[Genadi Zawidowsk...]

кэши, выравнивание... Все там работает. Версию поновее.
проверял до 64 гиг

[Integro]

Поддерживаю, работал с одной из последних версий, с 16 и 32 проблем нет! Помимо рекомендаций из предыдущего поста стоит также посмотреть на нижний слой, интерфейс карты и проверить адресацию для High Capacity

[klen]

спасибо!
вроде заработало.
тестировался на шести 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

[Genadi Zawidowsk...]

Вот мой конфиг, служит хорошо. За FF_USE_FASTSEEK спасибо, при формировании wav файлов это полезно.

Сообщение отредактировал Genadi Zawidowski - Aug 3 2018, 07:44

Прикрепленные файлы

 ffconf.rar ( 4.09 килобайт ) Кол-во скачиваний: 10

 

[klen]

здрав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]

... теперь будем плавно пробовать прикручивать eMMC микросхему - жизнь показала что sd-сокеты это для "бытовой" аппрптуры, разваливается и не контачит...

Ну не знаю... Все зависит от кривизны рук оператора, и чего он там засовывает(в смысле, чистая карточка или вся измазана в пыли и грязи) За 5и летний срок использования карточек и холдеров проблемы были только в этом.
А вот пайка этих ммэсин, с шагом шаров 0.5мм, причем сгруппированных в один маленький квадрат может привести к боольшим проблемам

[aaarrr]

А вот пайка этих ммэсин, с шагом шаров 0.5мм, причем сгруппированных в один маленький квадрат может привести к боольшим проблемам

Если производство нормальное и платы качественные, то никаких проблем нет.
А вот с SD... ставим массово DM3C от Hirose - в плане механической прочности просто отвратительная дрянь

[klen]

дело в том что платы летают+вибрируют, и иногда с сильно ударяются об земную поверхность. опыт показал что sd-сокет на стационарных приборах допустим, а на перемещающейся в пространстве нет. на вибростенде проверяли - нарушение электрического контакта при вибрации. к тому же все надо покрыть лаком - и что? сокет проливать ? еще качество у сокетов от партии к партии разное....
я сам не видел, но коллеги говорят что часто встречают тупо припаянные sd-карты к платам без сокетов в девайсах подобного толка.

[Arlleex]

я сам не видел, но коллеги говорят что часто встречают тупо припаянные sd-карты к платам без сокетов в девайсах подобного толка.

Изи же.

[Grape]

...
еще нужно обратить внимание, что если не включать опцию 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
( Argument 0200h is byte address 0200h in the SDSC and 0200h block in SDHC and SDXC

[Obam]

Изи же.

Ну, если проволочным хомутиком по слову "Taiwan" прихватить для устранения эффекта "консоли", то... может быть и проканает

[Arlleex]

Ну, если проволочным хомутиком по слову "Taiwan" прихватить для устранения эффекта "консоли", то... может быть и проканает

Да держится прекрасно И тряску прошла...

[haker_fox]

Тоже недавно сделал свой драйвер для SD. Правда для шины SPI. И вот вопрос: в примерах от Чана мультисекторная запись реализована CMD25. Интересно, а есть гарантия, что ФС при записи нескольких секторов подряд запишет именно последоватлеьные сектора. Например, нужно записать 3 сектора. ФС должна записать 128, 129, 130. А не 129, 150, 130.

[AlanDrakes]

Гарантия есть. Она в самой команде 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]

Переводим.

Мне перевод не нужен, читаю английский без перевода
Но вопрос мой был немного в другом. Я знаю, как работает CMD25. Меня интересует: есть ли железобетонная гарантия, что файловая система от Чана при мультисекторной записе (передавая sector_count > 1) выдаст сектора "без дырок". Например, она пишет сектора 10, 11, 12 - это без дырок. Их сразу можно писать на карту. А вот с дырками, но тоже несколько секторов: 10, 20, 12. Есть дырка. Я к чему задаю вопрос: может быть ФС требует записи нескольких секторов, лежащих не линейно, в надежде, что низкоуровневый драйвер сам разгребёт это? Например через кольцевой буфер? Я думаю, что Чан всё делает правильно, т.е. даёт сектора последовательно, пригодные для записи на носитель. Но всё же, а вдруг?

[MrYuran]

Ну, если проволочным хомутиком по слову "Taiwan" прихватить для устранения эффекта "консоли", то... может быть и проканает

Приклеить на компаунд или липучку

[AlanDrakes]

Помнится мне, что вся работа с секторами происходит в файле ff.c, а работа с низкоуровнемыми командами записи - в diskio.c, где уже Вы, по желанию, можете делать запись мультисекторно, или посекторно.

При наличии больших буферов ФС - драйвер технически может вызывать функцию disk_write с параметром "Количество секторов", отличным от единицы.
Фактически, единственный такой вызов я нашёл в функции f_write() в том случае, если ЕСТЬ свободные сектора, куда это поместится, и размер данных больше чем на один сектор.

Так что, весь разбор что и куда писать, находится выше. Драйверу же карты передаются только команды "Пиши вот это, вот сюда, в таком-то количестве".

[Genadi Zawidowsk...]

"Пиши вот это, вот сюда, в таком-то количестве".

Пиши вот это, вот сюда, в таком-то количестве, подряд с указанного места. Я пользуюсь - работяет.
Кстати, очень понравилось extFAT, там как раз нужно 64 битное смещение в seek

Сообщение отредактировал Genadi Zawidowski - Sep 3 2018, 19:32

[haker_fox]

Пиши вот это, вот сюда, в таком-то количестве, подряд с указанного места. Я пользуюсь - работяет.
Кстати, очень понравилось extFAT, там как раз нужно 64 битное смещение в seek

Отлично! Значит библиотека ФС всё сама разруливает. Кстати, я не делал мультисекторную запись пока, но даже посекторная запись идёт со скоростью до 200 кбайт/сек. Что довольно шустро для моих задач)

[AlanDrakes]

Пилил я как-то свой тест скорости карточек. Не оптимальный до ужаса. Тем не менее, результат был таким:

Код

File created.
Write test...
[0000000030.080] File write done. Total bytes written: 5242880 bytes. Time: 27684 ms. Avg: ~189 kBps
Read test...
[0000000036.114] File read done. Total bytes read: 5242880 bytes. Time: 6033 ms. Avg: ~869 kBps

Здесь кристалл работал на ~96МГц, возможно, меньше. SDIO тактировалось от PLL на 48МГц.
Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно.

Были у меня ещё какие-то весёлые проблемы с записью больших блоков через FatFS, хотя библиотека собиралась с неправильными параметрами, и объём памяти под неё старательно ужимался. В итоге, при записи огромных буферов из памяти (как раз размером в несколько секторов) получал странные зависания в случайных местах. В причинах не разобрался, добавив костыль, заставив код писать мелкими блоками.

[haker_fox]

Если тактирование SDIO было быстрее тактирования ядра - работать с картой памяти было невозможно.

Эх... SDIO это совершенно другой полёт. Как правило, все неприятные нюансы (таймауты, ожидание откликов (R1, R2...)) оно на себя берёт. Да ещё + DMA. С SPI, конечно, тоже можно DMA включить на передачу чисто блоков, но драйвер уж сильно замороченный выходит...

[jcxz]

С SPI, конечно, тоже можно DMA включить на передачу чисто блоков, но драйвер уж сильно замороченный выходит...

Вы не поверите, но и на приём - тоже можно!
SDIO мало где реально нужно в embedded области.

[klen]

Вы не поверите, но и на приём - тоже можно!
SDIO мало где реально нужно в embedded области.

SDIO может эмбеддедуу и ненужен, он нужен заказчику который мне этот эмбеддед заказал!
нужно писать телеметрию изделия, а потом когда что то пекосо....лось в нутри оного изделия и оно со звуком ящика с гвоздямт стукнолось об землю - обосновано назначать виновптого
как я говорил, теперь попробую eMMC микросхемку запустить вместо сокет+карта. так выглядеть поприличнее будет, как мне кажется.

у меня все заработало, но есть один вопрос - я в своем драйвере при выполнении обмена смотрю один блок или более одного нужно протолкнуть, если один то подаю команду одиночного обмена, иначе мультиблочного. пробывал мультиблочным один блок проталкивать - работает, при мультиблочном обмене по завершении необходимо подать команду терминирования обмена, в одноблочном этого не нужно. пробывал в мультиблочном эту команду не подавать, тоже работает. номера команд на память не помню, сорри.Почему оно одинаково работает, и зачем тогда два отдельных отдельных метода?

[aaarrr]

Почему оно одинаково работает, и зачем тогда два отдельных отдельных метода?

Все карты/накопители разные. Некоторые позволяют вольности с протоколом, другие не поймут.

[mantech]

Да держится прекрасно И тряску прошла...

Так-то неплохо, конечно, но пайка карт в печи не гуд - может фирмварь потереться...

[jcxz]

SDIO может эмбеддедуу и ненужен, он нужен заказчику который мне этот эмбеддед заказал!

У Вас как-то видимо неправильно составлено ТЗ. Заказчик должен заказывать функционал, а не способы его реализации. А уж способы реализации должен выбирать инженер исходя из требований ТЗ и здравого смысла. И как подключено некое ЗУ или его тип, объём - это однозначно должен определять инженер, а не заказчик. Заказчик в ТЗ должен только указать: необходима фиксация данных телеметрии в энергонезависимой памяти в течение не менее чем такого-то времени и такие-то и такие-то параметры (как то так). А уж как это делать и куда сохранять - забота инженера (программиста).

нужно писать телеметрию изделия, а потом когда что то пекосо....лось в нутри оного изделия и оно со звуком ящика с гвоздямт стукнолось об землю - обосновано назначать виновптого

Вполне нормально писали текущую телеметрию во FRAM+FLASH по SPI без каких-то проблем.
А писать это дело в FatFS, внутренние операции которой Вы не контролируете - это стрелять себе в ногу. Или заказчику, который не умеет грамотно составить ТЗ. И разработчик занимается натягиванием FatFS, вместо обеспечения хранения потока телеметрии, устойчивого к авариям питания (без всяких FS).

[Arlleex]

Так-то неплохо, конечно, но пайка карт в печи не гуд - может фирмварь потереться...

Они феном паялись
А о каком "фирмварь" идет речь?

[mantech]

Они феном паялись
А о каком "фирмварь" идет речь?

Как-то читал атмеловский даташит по пайке, так там очень не советовали паять в печи запрограммированные МК по причине того, что может произойти искажение в флеш-памяти программы. Тут как-раз такой случай, в каждой карточке есть МК с программой, которая, как правило, находится в первых секторах нанда, и разметка бэд-блоков и пр. тоже там, она и может испортится, по крайне мере на 1 смартбае такое было, после пайки карта работала нестабильно и через непродолжительное время ушла в "рид-онли"...

Конечно есть другое дело - е-ммс - там должно быть предусмотрена печная пайка, но х.з. может там и техпроцесс какой-то другой...

[Axel]

...Заказчик должен заказывать функционал, а не способы его реализации. А уж способы реализации должен выбирать инженер исходя из требований ТЗ и здравого смысла...

В общем случае Вы безусловно правы. Но при наличии повышенных требований к защите информации, Заказчик может позволить себе не заморачиваться формулированием их (требований) в весьма мудреных терминах отрасли, а потребовать использования уважаемых им (Заказчиком) протоколов.

[jcxz]

В общем случае Вы безусловно правы. Но при наличии повышенных требований к защите информации, Заказчик может позволить себе не заморачиваться

А каким образом SDIO выигрывает у SPI в плане "защиты информации"? Защиты от чего/кого?
Или выигрывает FatFS? Так если под "защитой" иметь в виду защиту от несанкционированного доступа, так FatFS наоборот проигрывает самопальному формату хранения.

[haker_fox]

Вы не поверите, но и на приём - тоже можно!

Поверю!

SDIO мало где реально нужно в embedded области.

Как я понимаю, SDIO даёт более высокую скорость, ведь SPI это только 25 МГц максимум + полупрограммные издержки.
Мне пришлось делать на SPI, т.к. дали такое железо. Если бы я имел право выбирать, то настоял бы на SDIO, т.к. придерживаюсь принципа: аппаратный блок справится с задачей лучше, чем софтварная реализация. Хотя, есть исключения.

[aaarrr]

SPI это только 25 МГц максимум

50, hi-speed применим и для режима SPI.

И SD, конечно, а никак не SDIO. Почему-то постоянно встречаю эту ошибку.

[haker_fox]

50, hi-speed применим и для режима SPI.

Я ориентировался только на содержимое регистра, а там для любой из имеющихся у меня карт (в том числе SDXC) стоит 25 МГц. Можно подробнее, видимо я чего-то не знаю.

[jcxz]

Как я понимаю, SDIO даёт более высокую скорость, ведь SPI это только 25 МГц максимум + полупрограммные издержки.

О каких издержках речь?
25МГц - это всего-лишь SCLK. При этом получается скорость передачи около 1МБ/сек. Можете привести пример в каких именно embedded-задачах (на МК из заголовка темы) дальнейшее увеличение скорости передачи выше означенного 1МБ/сек приведёт к заметному увеличению скорости работы прикладной задачи с картой? Не тест скорости, не высосанную из пальца задачу - сферического коня в вакууме, а реальную задачу?
Скажем: чтение конфига-файла и старт устройства по SPI выполнялся за 2 секунды, а та же задача, но по SDIO - 1 секунда?
Могу Вас разочаровать, но при таких скоростях обмена, значительную величину начинает занимать остальная обработка (не собственно задержка связанная с передачей) и низкоуровневого драйвера SD и всего что выше него. Тем более там ещё FatFS болтается. И увеличение в скорости передачи карты даст выигрыш общей производительности прикладной задачи всего несколько % в большинстве embedded-задач.
Если уж есть нужда в увеличении скорости обмена с картой, то первым делом нужно от FS избавляться.

Мне пришлось делать на SPI, т.к. дали такое железо. Если бы я имел право выбирать, то настоял бы на SDIO, т.к. придерживаюсь принципа: аппаратный блок справится с задачей лучше, чем софтварная реализация.

Так SPI-контроллеры обычно тоже в МК аппаратные, не надо ногодрыгать.
Да и правильно что Вам дали, так как "аппаратный блок справится с задачей лучше" - не аргумент. Не блок справляется с задачей, а программист. А при выборе способа решения исходят из того сколько то или иное решение займёт ресурсов (времени МК, количества ног или интерфейсов). И какие из этих ресурсов наиболее важные/дефицитные в данной задаче. А какой-то блок там справится или нет - не аргумент, не справиться может только программист.

[haker_fox]

О каких издержках речь?

Да хотябы циклически ждать (до 64 циклов SCLK) отклик от карты (R0, R1...). Это же надо отправлять по шине 0xff, читать данные, и проверять MSB. По любому нужно либо прерывание каждый принятый байт дёргать (и там проверять), либо в основном цикле. Я не знаю иного способа. Считаю, что это издержки.

Можете привести пример в каких именно embedded-задачах (на МК из заголовка темы) дальнейшее увеличение скорости передачи выше означенного 1МБ/сек приведёт к заметному увеличению скорости работы прикладной задачи с картой? Не тест скорости, не высосанную из пальца задачу - сферического коня в вакууме, а реальную задачу?

К сожалению, нет. Всё вышесказанное является лишь моим мнением.

Так SPI-контроллеры обычно тоже в МК аппаратные, не надо ногодрыгать.

Да, но SPI, на мой взгляд, является "побочным" интерфейсом для SD-карты, идущим из далёкого прошлого. Поэтому, если есть SDIO в МК, его лучше использовать.

Да и правильно что Вам дали

Ну дали не потому, что это правильно. А банально не осталось свободных пинов у МК. Вот на SPI и навесили "остатки". А мне потом ещё пришлось доводить систему на макетке - добавить буфер (т.к. внутреннюю шину просто вывели на улицу, что вносило сбой в работу при установке карты, а также давало возможность подпитывать её паразитным питанием) и сделать некоторые другие доработки.

А какой-то блок там справится или нет - не аргумент, не справиться может только программист.

Ну как посмотреть. Где-то на форуме уважаемый Rst7 лет 10 назад приводил код, который отправляет, и (не очень стабильно) принимает манчестер для 10 Мбит Ethernet. Для этого использовался аппаратный UART. Ну если он справился да ещё и на 8-битной AVR'ке, почему бы в современных "толстых" армах не использовать подобное решение. Не везде ведь нужно 100 или более Мбит. А UART'ов даже в маленьком МК Cortex-M0 как правило не менее двух. И если будет работать неправильно, то - программист плохой. Не смог(((

[jcxz]

Да хотябы циклически ждать (до 64 циклов SCLK) отклик от карты (R0, R1...). Это же надо отправлять по шине 0xff, читать данные, и проверять MSB. По любому нужно либо прерывание каждый принятый байт дёргать (и там проверять), либо в основном цикле. Я не знаю иного способа. Считаю, что это издержки.

Не надо. Драйвер естественно должен использовать DMA. По завершению блока DMA анализировать полученные данные с SD и искать там первый не 0xFF. Программно это очень незначительно по времени, так как в цикл-е про-AND-ить 32-битные данные - ерунда.

Ну дали не потому, что это правильно. А банально не осталось свободных пинов у МК. Вот на SPI и навесили "остатки".

Вот я об этом и говорю: свободные ноги - это как правило очень ценный ресурс в МК и его дефицит был во всех моих проектах. Тем более - на SPI легко можно объединить несколько устройств на одной шине. А с SDIO - придётся пины только под SD отдать. И зачем?
А какое-то там "удобство" - это вопрос больше в компетентности программиста - ну будет немного больше строчек кода и всего-то.

Ну как посмотреть. Где-то на форуме уважаемый Rst7 лет 10 назад приводил код, который отправляет, и (не очень стабильно) принимает манчестер для 10 Мбит Ethernet. Для этого использовался аппаратный UART. Ну если он справился да ещё и на 8-битной AVR'ке, почему бы в современных "толстых" армах не использовать подобное решение. Не везде ведь нужно 100 или более Мбит. А UART'ов даже в маленьком МК Cortex-M0 как правило не менее двух. И если будет работать неправильно, то - программист плохой. Не смог(((

Ну вообще-то - не могу знать о каком Ethernet идёт речь. Есть множество внешних Ethernet-чипов с логикой Ethernet внутри. И если такой Ethernet предполагает подключение по UART - то так и следует подключать. О чём разговор? Мы в каких-то из своих проектов использовали внешний чип Ethernet с подключением по SPI и что? Хотя при этом в МК был аппаратный Ethernet и даже со встроенной физикой. Но по требованиям ТЗ он не походил. Поставили внешний.

[haker_fox]

Не надо. Драйвер естественно должен использовать DMA. По завершению блока DMA анализировать полученные данные с SD и искать там первый не 0xFF. Программно это очень незначительно по времени, так как в цикл-е про-AND-ить 32-битные данные - ерунда.

Т.е. вы предлагаете при ожидании отклика просто вычитать априори 8 байт (64 цикла). Затем, по завершению посылки, найти первый с MSB=0? Я просто не предполагал, что так можно. Я думал, что как только мы встретили первый не 0xff, то следует сразу остановиться, и перевести cs в 1. Гм... если это так, то просто супер!!!

А какое-то там "удобство" - это вопрос больше в компетентности программиста - ну будет немного больше строчек кода и всего-то.

Пока остаюсь при своём мнении. Ведь время программиста тоже денег стоит. И проект ещё сопровождать надо. И исправлять ошибки. И добавлять функции. А так - бухнул сразу чип, подходящий по периферии, и всё.

Ну вообще-то - не могу знать о каком Ethernet идёт речь.

Вот, самый первый пост. Буквально несколько первых предложений. Хотя, давно это было. И при более внимательном чтении вспомнил, что у Rst7 всё-таки не получилось полностью реализовать программно-аппаратный PHY.


Помню, давным давно, на AVR'ках делали программный USB device, HID. Вот мне тут подумалось, что такое можно сделать в одной из недорогих поделок на STM32F051. Правда я хочу 2 CDC (композит). Но, наверно, ничего не получится. Но пока прицениваюсь. Это как раз тот случай, когда аппаратный модуль просто отсутствует.

[aaarrr]

Можно подробнее, видимо я чего-то не знаю.

См. Switch Function Command (CMD6). Описание есть в т.ч. в Physical Layer Simplified Specification Version 2.00.

[jcxz]

Т.е. вы предлагаете при ожидании отклика просто вычитать априори 8 байт (64 цикла). Затем, по завершению посылки, найти первый с MSB=0? Я просто не предполагал, что так можно. Я думал, что как только мы встретили первый не 0xff, то следует сразу остановиться, и перевести cs в 1. Гм... если это так, то просто супер!!!

Нет. Почитайте спецификацию внимательнее - CLK можно гнать сколько угодно. Мой драйвер так и работал. Только не помню - 64 или больше, пока не найдётся !=0xFF.

Пока остаюсь при своём мнении. Ведь время программиста тоже денег стоит. И проект ещё сопровождать надо. И исправлять ошибки. И добавлять функции. А так - бухнул сразу чип, подходящий по периферии, и всё.

Ну да - это время потом понадобится. Когда ног не хватит и придётся всё переделывать.
Да и какая разница по затраченному времени - SPI или SD?

Вот, самый первый пост.

Нет, слишком много буков. Не осилю, после тренировки то.
Да и вообще - там похоже что-то странное, вычурное, нетипичное использование периферии. Делать такое нужно или при реальной нужде или как хобби.
А подключение SD на SPI - это вполне себе штатный способ подключения, прописанный в спецификации. Так что это совсем из другой оперы.

Помню, давным давно, на AVR'ках делали программный USB device, HID. Вот мне тут подумалось, что такое можно сделать в одной из недорогих поделок на STM32F051.

Читал про такое. Тоже имхо - бессмыслица. Ибо - никакого профита на ARM7 в которых как правило есть USB. Во-вторых - там вроде даже не FullSpeed, а LowSpeed да ещё с какими-то ограничениями и косяками (вроде грузит процессор сильно). Т.е. - опять для практического использования бесполезная вещь.
Опять-же - нигде в спецификации USB нет ни слова о реализации через UART. А для SD - SPI есть.

[Сергей Борщ]

Не надо. Драйвер естественно должен использовать DMA. По завершению блока DMA анализировать полученные данные с SD и искать там первый не 0xFF. Программно это очень незначительно по времени, так как в цикл-е про-AND-ить 32-битные данные - ерунда.

Я мимо проходил, протокола не знаю, просто смотреть последний байт блока недостаточно?

[haker_fox]

Почитайте спецификацию внимательнее - CLK можно гнать сколько угодно.

Вернее не просто CLK, а 0xff передавать на карту?!

А для SD - SPI есть.

Я вас понял, из двух разрешённых интерфейсов вы просто предпочитаете использовать тот, который наиболее удобен.

Я мимо проходил, протокола не знаю, просто смотреть последний байт блока недостаточно?

Вроде как нет, отклик на команду появляется однократно в течение 8 байт.

[jcxz]

Я мимо проходил, протокола не знаю, просто смотреть последний байт блока недостаточно?

Я тонкостей уже не помню, но насколько помню байт статуса там передаётся только один раз. По смещению от 0-го до некоторого N-го клока SCLK от конца фрейма. Да и вроде он имеет смещение кратное 8 клокам.

Вернее не просто CLK, а 0xff передавать на карту?!

Естественно. Команды должны отсутствовать.

Я вас понял, из двух разрешённых интерфейсов вы просто предпочитаете использовать тот, который наиболее удобен.

При прочих равных требованиях - всегда предпочитаю использовать тот интерфейс, который требует меньше ресурсов. Так как их всегда не хватает. Чтоб потом не переделывать всё. Сколько тут на форуме уже слышал воплей от новичков "девайс уже сделан, и когда делали не подумали что нужно будет ещё и это и то, а теперь ног/интерфейсов/памяти/... не хватает. И как мне прикостылить ещё и эту плюшку ведь заказчику очень нуно?".
Единственный плюс SDIO в сравнении с SPI - бОльшая низкоуровневая скорость. А как я говорил выше - для embedded это редко реально нужно. Да и низкоуровневая скорость, при использовании кучи довесок сверху в виде ФС и пользовательского кода, в результате скорей всего будет очень мало влиять на общее быстродействие системы. Увеличите low level скорость в 2 раза, а общее быстродействие вырастет на пару %. А цена при этом - значительно бОльший расход пинов.

[haker_fox]

Естественно. Команды должны отсутствовать.

Понятно, я как-то не понял из спецификации, что на карту можно гнать 0xff, и она это нормально пережуёт) Хотя из того, что есть стартовый и стоповый биты в посылке, это как бы следует)

А цена при этом - значительно бОльший расход пинов.

Чтож, я чувствую, что у вас бОльший опыт работы с SD, чем у меня Приму к сведению. Доселе был уверен в обратном (не про опыт, про преимущества SDIO))))))

[jcxz]

Чтож, я чувствую, что у вас бОльший опыт работы с SD, чем у меня Приму к сведению. Доселе был уверен в обратном (не про опыт, про преимущества SDIO))))))

Не особо большой. Просто года 3-4 назад делал девайс с SD, писал lowlevel-драйвер (LPC17xx), накатывал поверх него FatFS, тестил скорости. И что-то ещё помню

[V_N]

Единственный плюс SDIO в сравнении с SPI - бОльшая низкоуровневая скорость. А как я говорил выше - для embedded это редко реально нужно.

Вы не правы . Например: автономная система сбора информации с сохранением на SD. 400 раз в секунду измерить напряжение (3 канала по 16 бит) накопить в буфер и переписать в SD. Процессор STM32L476 просыпается на время измерения и записи в SD. Применение SDIO в два раза увеличивает продолжительность автономной работы при заданном источнике питания.

[haker_fox]

Не особо большой.

Кстати! Стоп Отклик R мы ещё можем через DMA "ждать", т.к. оверхед будет не более 8 байт. А вот как тогда ждать Data Response Token Start Block Token и т.п., да ещё и следовать логике их обработке. Честно говоря, у меня в голове уже не укладывается, как тут DMA использовать. Тем более эти "токкены" не приходят в течение 8 байт. Значит издержки будут уже больше.

Процессор STM32L476 просыпается на время измерения и записи в SD.

Возможно всё это зависит от SDIO, а следовательно - от модели микроконтроллера.
И да, всё-таки не процессор

[jcxz]

Вы не правы . Например: автономная система сбора информации с сохранением на SD. 400 раз в секунду измерить напряжение (3 канала по 16 бит) накопить в буфер и переписать в SD. Процессор STM32L476 просыпается на время измерения и записи в SD. Применение SDIO в два раза увеличивает продолжительность автономной работы при заданном источнике питания.

Да ладно! Так уж и в два раза? Как измеряли?
А сколько из всего этого времени что нужно на измерение, обработку, запись (особенно через ФС) составляет собственно пересылка? Сколько %? Я собственно об этом и писал - читайте внимательнее.
А сколько нужно времени на включение и стабилизацию питания карты?
А после записи нужно ещё дождаться статуса "завершение записи", время появления которого вообще никак не связано со скоростью пересылки, а только со скоростью карты. Ну сэкономите целых 10мкс на пересылке, а карта писать/стирать будет ещё 200мс.
И сколько процентов прироста скорости даёт SDIO vs SPI? 1% или целых 2%? Боюсь что даже 1% выигрыша не будет от SDIO.

[aaarrr]

И сколько процентов прироста скорости даёт SDIO vs SPI? 1% или целых 2%? Боюсь что даже 1% выигрыша не будет от SDIO.

На чтении внезапно дает примерно столько, во сколько раз больше линий передачи.

Просто полный набор штампов:
SD - плохо, лучше SPI
FS - плохо, будем колхозить свой велосипед
Скорость больше 1Мбайт/с в эмбеддед не бывает и не нужна

Это для PIC16 актуально, а не для STM32F4.

P.S. SD, не SDIO

[jcxz]

На чтении внезапно дает примерно столько, во сколько раз больше линий передачи.

На чтении чего? Какая прикладная задача? В синтетическом тесте? И кто бы сомневался.
И вообще-то отвечаете Вы на пост о системе сбора информации. На кой там чтение???

Просто полный набор штампов:
SD - плохо, лучше SPI

Вы похоже не умеете читать... Где я писал что "плохо" или "хорошо"? Ещё раз- я писал: в большинстве прикладных задач время передачи данных по интерфейсу карты - не принципиально, так как вносит очень малый вклад в общее быстродействие задачи.
Если есть что сказать по теме - расскажите в каких таких задачах бОльшая скорость чтения по SDIO принесёт заметный плюс?

Это для PIC16 актуально, а не для STM32F4.

Это актуально для чего угодно, пока не изобрели МК с бесконечно большим числом ног.

[aaarrr]

И вообще-то отвечаете Вы на пост о системе сбора информации. На кой там чтение???

Думаете, запись не ускорится? Ускорится, просто не так показательно.

Вы похоже не умеете читать... Где я писал что "плохо" или "хорошо"? Ещё раз- я писал: в большинстве прикладных задач время передачи данных по интерфейсу карты - не принципиально, так как вносит очень малый вклад в общее быстродействие задачи.

Вы писали буквльно следущее:

Если уж есть нужда в увеличении скорости обмена с картой, то первым делом нужно от FS избавляться.

А это, уж извините, бред. Не вносит FS заметного оверхеда, как раз таки единицы процентов.

Это актуально для чего угодно, пока не изобрели МК с бесконечно большим числом ног.

Так используйте однобитный SD для экономии. SPI - это в любом случае костыль, придуманный в мрачные времена.
Да, а ручной подсчет CRC не напрягает?

[haker_fox]

Так используйте однобитный SD для экономии.

Кстати, а это идея!
В проекте, над которым работаю, хоть и получил масштабный опыт руления через один SPI низкоскоростными (сигма-дельта АЦП) и высокоскоростными (NAND, SD) устройствами, переключениями на одни и те же ножки SPIFI прямо по ходу работы, всё же лишний раз такое насильно бы повторять не стал))))

[jcxz]

Думаете, запись не ускорится? Ускорится, просто не так показательно.

Ага, не на 2%, а на 1%
Какой процент времени при записи на карту составляет время пересылки по интерфейсу в общем времени включения карты+пересылки+ожидания_завершения+выключении?

Вы писали буквльно следущее:
А это, уж извините, бред. Не вносит FS заметного оверхеда, как раз таки единицы процентов.

Да ладно - единицы процента?
Вот касательно приведённого выше V_N примера системы сбора данных со сном, предположим что при каждом просыпании система пишет один сектор данных в файл, после чего засыпает. Перед засыпанием закрывает файл, получается - обновляется запись каталога (дата/время файла+размер) и FAT-таблица (размещение). Итого - получаем запись до 3-х секторов вместо одного если бы делали просто на кольцевой цепочке секторов.
И не надо выдёргивать мои слова из контекста. Главный смысл их был в том, что выигрыш по скорости обмена по интерфейсу карты незначителен для большинства прикладных embedded-задач.
"Прикладная задача" к Вашему сведению - это не запись или чтение файла. Или может Вы в руководствах по эксплуатации своих устройств пишете "оно пишет и читает файлы со встроенной SD".
Если карта внутренняя, то заказчику фиолетово - пишет оно файлы или что-то другое, ему важна функция, которую оно реализует.
А вот решение этой функции через ФС очень часто приводит к увеличению оверхеда по чтениям/записям. Поэтому я и говорю, что работа с SD наиболее оптимальным для задачи способом, а не обязательно через ФС, может даст гораздо бОльший выигрыш в плане общей скорости работы.

Да, а ручной подсчет CRC не напрягает?

Вы вообще о чём? Где я писал про ручной CRC?

[aaarrr]

Ага, не на 2%, а на 1%

На 50%, например.

Да ладно - единицы процента?
Вот касательно приведённого выше V_N примера системы сбора данных со сном, предположим...

Предположим, спит, предположим, выключает при этом питание, предположим, закрывает и не кэширует. Что еще предположим?

"Прикладная задача" к Вашему сведению - это не запись или чтение файла. Или может Вы в руководствах по эксплуатации своих устройств пишете "оно пишет и читает файлы со встроенной SD".

Вы, надо полагать, в руководствах пишете: "для извлечения информации со встроенной SD-карты воспользуйтесь утилитой XXX (протестировано на Windows 7, требует прав администратора)".

Если карта внутренняя, то заказчику фиолетово - пишет оно файлы или что-то другое, ему важна функция, которую оно реализует.

Внутренняя - это как? Как на фото выше, намертво припаянная? Такого вообще не должно быть.

Вы вообще о чём? Где я писал про ручной CRC?

А где я писал про включение-выключение питания?

[jcxz]

Вы, надо полагать, в руководствах пишете: "для извлечения информации со встроенной SD-карты воспользуйтесь утилитой XXX (протестировано на Windows 7, требует прав администратора)".

Я ничего не пишу, так как встроенная карта == неизвлекаемая карта.

Внутренняя - это как? Как на фото выше, намертво припаянная? Такого вообще не должно быть.

Может объясните это Micron-у, что его e.MMC чипов не должно быть? Оне же намертво припаиваются! как можна!
Да и обычная карта может находиться внутри корпуса устройства, без возможности снятия. И не обязательно припаиваться.

А где я писал про включение-выключение питания?

Вы даже не соизволили обратить внимание к чему относился мой пост на который Вы изначально решили ответить? Если бы соизволили, то увидели бы что это был ответ на сообщение системе сбора данных на SD с режимом энергосбережения.
И изначально я спрашивал: приведите реальные примеры где высокая скорость обмена по интерфейсу даст реальный выигрыш. На что и был приведён тот пример.
Стоит хоть немного читать то, на что отвечаешь....

[Aner]

Внутренняя - это как? Как на фото выше, намертво припаянная? Такого вообще не должно быть.

Намертво припаянные регулярно встречаю в серийных изделиях. Далеко ходить не нужно берем DJI и его дроны, Фантомы 3, 4, Мавики ... ; катры 16Gb, 32Gb micro SD внутренние запаяны намертво, + наружные в разъеме. Нехило так, внутри до 4 ARM процов сидит в одном изделии.

[V_N]

Вот касательно приведённого выше V_N примера системы сбора данных со сном, предположим что при каждом просыпании система пишет один сектор данных в файл, после чего засыпает. Перед засыпанием закрывает файл, получается - обновляется запись каталога (дата/время файла+размер) и FAT-таблица (размещение). Итого - получаем запись до 3-х секторов вместо одного если бы делали просто на кольцевой цепочке секторов.

Файл не закрывается, питание с карты не снимается, дописывется 16 кбайт в конец файла( каждые пол часа проводится закрытие файла ). Частота ЦП скорость SDIO оптимизированы с целью увеличения времени непрырывной работы . Конкретно в этом примере переход отSPI к SDIO даловозможность увеличить время автономной работы .

[aaarrr]

Может объясните это Micron-у, что его e.MMC чипов не должно быть? Оне же намертво припаиваются! как можна!

Стесняюсь спросить, а почему, например, не Samsung'у или Toshib'е?

Да и обычная карта может находиться внутри корпуса устройства, без возможности снятия. И не обязательно припаиваться.

Карты превращаются в eMMC, а потом снова в карты. Но в ящике.

Вы даже не соизволили обратить внимание к чему относился мой пост на который Вы изначально решили ответить? Если бы соизволили, то увидели бы что это был ответ на сообщение системе сбора данных на SD с режимом энергосбережения.

Почему же, обратил. И именно в вашем ответе внезапно возникло включение и выключение питания карты.
Но и до этого много прекрасного, не мог пройти мимо:

SDIO мало где реально нужно в embedded области.

А писать это дело в FatFS, внутренние операции которой Вы не контролируете - это стрелять себе в ногу.

25МГц - это всего-лишь SCLK. При этом получается скорость передачи около 1МБ/сек.

Очень сильно постараться надо, чтобы получилось настолько плохо.

значительно бОльший расход пинов

В 1-битном режиме он таки меньше

[jcxz]

Файл не закрывается, питание с карты не снимается,

Тогда о чём разговор? Зачем тогда процессор усыплять если невыключенная карта сожрёт в разы больше энергии?
И если файл не закрывается, то что с этим файлом будет если карту возьмут и выдернут когда этот файл не закрыт?
Или у Вас она - встроенная и её нельзя внезапно выдернуть? Так ув. aaarrr запретил так делать!
И если Вы не послушались aaarrr и она всё-таки встроенная, то зачем тогда там вообще ФС?

Конкретно в этом примере переход отSPI к SDIO даловозможность увеличить время автономной работы .

Ну да - а невыключение карты сократило это время в разы больше чем получили выигрыш от SDIO. Опять экономия на пуговицах.

В 1-битном режиме он таки меньше

И можно обойтись всего одним пином??? Нет? А с SPI - можно (дополнительным CS), так как это - шина, и на неё можно повесить несколько слэйвов.

[aaarrr]

И можно обойтись всего одним пином??? Нет?

Забыли посчитать тот пин, которым выключаете питание

А с SPI - можно, так как это - шина, и на неё можно повесить несколько слэйвов.

Можно. Но если карта не припаяна к плате (а я ведь запретил ), то придется раскошелиться еще и на буфер.

[jcxz]

Забыли посчитать тот пин, которым выключаете питание

Хммм... а SDIO позволяет выключать без пина?

Можно. Но если карта не припаяна к плате (а я ведь запретил ), то придется раскошелиться еще и на буфер.

Зачем буфер? И что за буфер?

ЗЫ: При большой необходимости, питание можно CS-ом отключать (транзисторный ключ или LDO с фильтром на питание карты). И доп. пин не нужен.

[aaarrr]

Хммм... а SDIO позволяет выключать без пина?

Разумеется

Зачем буфер? И что за буфер?

Предлагаете погладить кота и затем тыкать картой в живую шину?

ЗЫ: При большой необходимости, питание можно CS-ом отключать (транзисторный ключ или LDO с фильтром на питание карты). И доп. пин не нужен.

Гениально.

[jcxz]

Разумеется

И...? Конкретнее.

Предлагаете погладить кота и затем тыкать картой в живую шину?

А по делу? SDIO позволяет гладить кота?

[aaarrr]

А по делу? SDIO позволяет гладить кота?

SDIO позволяет все, да только вот к картам памяти не имеет отношения.

Если Вы допускаете горячее подключение к SPI с несколькими слейвами, то более вопросов не имею.

[haker_fox]

и она всё-таки встроенная, то зачем тогда там вообще ФС?

Я бы от ФС не отказывался. Она всё равно нужна, хоть своя, хоть стандартная. Даже если просто писать сырые данные, то их нужно как-то упорядочивать и привязывать к адресному пространству. Элементарно, чтобы потом найти. А если железка подключается к компу, и необходимо посмотреть данные, то тут точно FAT необходима.

Зачем буфер? И что за буфер?

Буфер необходим, чтобы исключить паразитную подпитку карты, когда шина SPI смотрит наружу в разъём карты. Даже если мы отключим питание карты ключом, то через встроенные в карту защитные диоды по пинам будет происходить подпитка карты. А если стоит конденсатор по питанию, то напряжение на нём будет по-маленьку расти (эффект интегрирующей RC-цепочки), и может достичть почти полной амплитуды питания. Буфер позволяет переводить линии карты в высокоимпедансное состояние, что полностью решает проблему. Если карта - единственное устройство на шине, то буфер не требуется. Можно просто все GPIO перевести на входы.
Кстати, когда по шине идёт обмен данными и мы вставляем карту, то переходные процессы вполне могут нарушить этот обмен, а значит драйвера всех устройств, которые используют шину должны быть готовы к такому поведению.
Я выбрал буферы 74LVC2G125DP. Мы их используем в других разработках. До 25 МГц в нормальных условиях работают. Впереди проверка на отрицательные и положительные (выше нормальной) температуры.

[jcxz]

Я бы от ФС не отказывался. Она всё равно нужна, хоть своя, хоть стандартная. Даже если просто писать сырые данные, то их нужно как-то упорядочивать и привязывать к адресному пространству. Элементарно, чтобы потом найти.

А в чём проблема найти данные в хранилище собственного формата? В чём тут разница с ФС?

А если железка подключается к компу, и необходимо посмотреть данные, то тут точно FAT необходима.

Если карта вынимается и вставляется в комп - то да. Если не вынимается - нет. Так как устройство может интерпретировать и показывать данные по внешнему интерфейсу как угодно как захочет автор программы.
И даже более того: если скажем нужен кольцевой буфер в который что-то иногда пишется и который иногда нужно показать как файл при подключении к компу. Предположим - данные пишутся блоками одинакового размера N байт.
Как Вы это реализуете с ФС? И как без ФС?
А теперь доп. требование: показать такое хранилище через внешний интерфейс как файл с самыми последними данными в его начале (или конце)?
Ещё доп. требование: кроме этого кольцевого буфера, устройство должно хранить некую структуру данных (например - собственную конфигурацию), произвольные члены которой, должны переписываться в произвольные моменты времени. Причём устройство не имеет монитора питания (может быть выключено в произвольный момент времени), но нужно чтобы конфигурационная структура не была разрушена при таком внезапном выключении в любой точке процедуры записи. Как при включении устройства проверить валидность и атомарность конфигурационной структуры? Как сделать так, чтобы исключить ситуации, когда первые N1 байт структуры относятся к случаю после новой записи, а последние N2 байт - к случаю после новой записи? Как это сделать с ФС и без оной? Какой вариант будет сложнее (или потребует расхода бОльшего ресурса флешь)?

Если карта - единственное устройство на шине, то буфер не требуется. Можно просто все GPIO перевести на входы.

Ну так вот - Вы сами и ответили. Что буфер - это не требование собственно SPI, а требование при объединении на одной шине SPI нескольких устройств, когда питание некоторых из этих устройств выключается. И если на одну SDIO также повесить несколько устройств, которые могут отключаться по питанию, то для них также потребуются буфера. Так что разницы тут нет никакой.

[V_N]

Тогда о чём разговор? Зачем тогда процессор усыплять если невыключенная карта сожрёт в разы больше энергии?
И если файл не закрывается, то что с этим файлом будет если карту возьмут и выдернут когда этот файл не закрыт?
Или у Вас она - встроенная и её нельзя внезапно выдернуть?

Запитанная карта в состоянии ожидания потребляет не болеее 100 мка ( например http://avr-start.ru/?p=4735). поэтому с учетом издержек на инициализацию и тп было принято решение не снимать питание с карты. Для особо одаренных пользователей ( карта находится в отдельном закрытом отсеке) файл закрывается каждые пол часа потом открывается и дописывается дальше. В случае ошибки пользователя теряются данные за последние пол часа до вскрытия .

[jcxz]

Запитанная карта в состоянии ожидания потребляет не болеее 100 мка ( например http://avr-start.ru/?p=4735).

Как-то странно делать выводы о потреблении на основании того, что кто-то где-то что-то замерил с какой-то неизвестной картой при неизвестных температурных условиях....
Вы уверены что и Ваша карта имеет такое же потребление? И все экземпляры карт во всех ваших устройствах будут иметь такое же потребление? И во всём диапазоне рабочих температур?
Например даже в википедии говорится, что SD-карты могут потреблять до 200мкА в режиме ожидания.

Для особо одаренных пользователей ( карта находится в отдельном закрытом отсеке) файл закрывается каждые пол часа потом открывается и дописывается дальше. В случае ошибки пользователя теряются данные за последние пол часа до вскрытия .

А такие пользователи обязательно найдутся и кто-нить выдернет без предварительной подготовки и потеряет важные данные. И виноваты будете вы, как разработчик, что не предусмотрели защиты от дурака
В нашей практике юзеры умудрялись запихивать SD-карты в разъёмы для SIM-карт, и перевёртывать умудрялись и ещё многое чего. Хотя пользователи были - не люди с улицы.

[Genadi Zawidowsk...]

Для особо одаренных пользователей ( карта находится в отдельном закрытом отсеке) файл закрывается каждые пол часа потом открывается и дописывается дальше

Если что, в Chan's FatFS есть функция f_sync - для файла выполняет нужные в этом случае операции.

[haker_fox]

И виноваты будете вы, как разработчик, что не предусмотрели защиты от дурака

Если не оговорите данный пункт в руководстве по эксплуатации, и не снимите с себя ответственность.

А в чём проблема найти данные в хранилище собственного формата? В чём тут разница с ФС?

Только в удобстве организации.

Так как устройство может интерпретировать и показывать данные по внешнему интерфейсу как угодно как захочет автор программы.

Понятно, но опять же - удобство.

Какой вариант будет сложнее (или потребует расхода бОльшего ресурса флешь)?

На такой вопрос я не могу ответить в силу отсутствия опыта. Но если возможно, расскажите, пожалуйста. Я так понимаю, если вы пишете по блокам 512 байт на карту, но в наихудшем случае у вас 512 байт и потеряется данных вместо разрушения структуры целой ФС.

И если на одну SDIO также повесить несколько устройств

Я думаю, что это более редки случай, чем с SPI.

[aaarrr]

И если на одну SDIO также повесить несколько устройств, которые могут отключаться по питанию, то для них также потребуются буфера.

А ничего, что SD (которую Вы столь упорно обзываете SDIO), вообще не предполагает такого включения?

[jcxz]

А ничего, что SD (которую Вы столь упорно обзываете SDIO), вообще не предполагает такого включения?

Несколько карт на одном интерфейсе? Позволяет. Почитайте внимательнее спецификацию.
PS: Называю так, чтобы не было путаницы с названием самой карты (SD), чтобы было понятно что речь об интерфейсе подключения.

На такой вопрос я не могу ответить в силу отсутствия опыта. Но если возможно, расскажите, пожалуйста. Я так понимаю, если вы пишете по блокам 512 байт на карту, но в наихудшем случае у вас 512 байт и потеряется данных вместо разрушения структуры целой ФС.

Речь не о потере. Потеряется всегда размер одного блока. Чем он меньше - тем меньше потеряется. Можно выбрать какой угодно размер блока.
Я же написал: например - нужно представить структуру хранения в виде файла где самые свежие блоки данных - в самом начале. Всегда.
В этом случае выигрыша от ФС нет никакого - всё равно нужно делать что-то поверх ФС, что будет читать её файлы и представлять их по внешнему интерфейсу совсем не такими, какими они лежат на карте (перемещать блоки внутри). То же самое делается и поверх обычного кольцевого буфера. Без лишней прослойки в виде ФС.
Аналогично и с хранением устойчивой к сбоям питания конфигурации: это элементарно реализуется через тот же кольцевой буфер - каждая новая запись конфигурации просто создаёт новый экземпляр блока данных внутри кольцевого буфера. А при старте просто ищется последняя валидная конфигурация.
Можно писать и не целиком всю структуру конфигурации, а только diff-часть от последнего изменения, чтоб уменьшить объём. И периодически вставлять полные версии структуры.
То же самое можно конечно организовать и внутри одного файла в ФС, но смысла тогда в самой ФС не будет никакого.
Я просто хочу сказать, что сама организационная файловая структура с файлами и папками - она обычно малополезна если только карта не вынимается из девайса.

[V_N]

Как-то странно делать выводы о потреблении на основании того, что кто-то где-то что-то замерил с какой-то неизвестной картой при неизвестных температурных условиях....
Вы уверены что и Ваша карта имеет такое же потребление? И все экземпляры карт во всех ваших устройствах будут иметь такое же потребление? И во всём диапазоне рабочих температур?
Например даже в википедии говорится, что SD-карты могут потреблять до 200мкА в режиме ожидания.

Я вам говорю о том что использование SDIO увеличивает продолжительность автономной работы прибора и поясняю как это сделано ( приборы выпускаются серийно более 2-х лети работают с различными картами и в различных условиях. Я уже писал ”теряетс я последние пол часа до вскрытия” этого достаточно для заказчика .Понятно можно каждый блок закрывать но при этом снижается время автономной работы (думаю понятно почему )

[haker_fox]

Я просто хочу сказать, что сама организационная файловая структура с файлами и папками - она обычно малополезна если только карта не вынимается из девайса.

Я вас понял. Просто "обычно" - это чисто субъективно, и зависит, в первую очередь, от прибора. Например, в наших приборах давно ставятся микросхемы памяти внутри прибора, и всё-равно на них делается ФС. Ну нам так удобнее. Плюс, при подключении к кому - прозрачная трансляция, если память отражается как USB MSC. Естественно, есть опыт хранения данных в виде структур в EEPROM (не важно какая память), и при трансляции для компьютера в представление ФС также не возникало проблем.

[aaarrr]

Несколько карт на одном интерфейсе? Позволяет. Почитайте внимательнее спецификацию.

Когда-то можно было использовать общий CLK. Стоит ли говорить, что так никто не делал за ненадобностью?

Но теперь и этого нельзя:

Because it is not possible to control two cards or more in the case that each of them has a different
timing mode (Default and High-Speed mode) and in order to satisfy severe timing, the host shall drive
only one card. CLK/CMD/DAT signal shall be connected in 1-to-1 between the host and the card.

[Arlleex]

Мне все-таки нужна консультация, чем отличается SD от SDIO, т.к. даже в даташитах иногда пишут SD/SDIO Card interface, что подразумевает, что это все-таки разные шины.
Если не трудно, объясните, пожалуйста, разницу.

[haker_fox]

Если не трудно, объясните, пожалуйста, разницу.

Может быть политика? Атмел в своё време вместо I2C писала TWI в своих даташитах, чтобы не использовать чужую торговую марку.

[aaarrr]

Если не трудно, объясните, пожалуйста, разницу.

SDIO - отдельный стандарт для карт ввода-вывода, электрически и частично механически совместимый с SD.
Поддержка со стороны хоста подразумевает реализацию специфического для SDIO механизма прерываний и
управления потоком.

Сейчас в основном используется для подключения модулей WiFi/BT.