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


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

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


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

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

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


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


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

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


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


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


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


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

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


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


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

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

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

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


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


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



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

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

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


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


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

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


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

Хммм... а 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. Стоит ли говорить, что так никто не делал за ненадобностью?

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

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

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

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

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