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

Поверю!

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

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

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

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

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


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

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

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

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

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

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

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


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


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

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

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

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


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

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

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


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


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


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

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

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

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


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

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


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


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

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

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

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