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

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

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

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

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

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

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

P.S. SD, не SDIO

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


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


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

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


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

А это, уж извините, бред. Не вносит 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), так как это - шина, и на неё можно повесить несколько слэйвов.

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


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