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


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

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

Разумеется


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


Гениально.

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


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

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

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

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


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

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


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


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

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

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


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

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

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


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

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

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

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

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

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


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

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

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

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

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