SD карта, 4-х битный интерфейс Опции

[Paramedic]

Решил попробовать поработать с SD картой по 4-х битному параллельному интерфейсу, используя GPIO. Кто-нибудь это делал? Достаточно ли инфы из открытых документов? Может где-нибудь есть примеры на эту тему? Подскажите плз.

[sergeeff]

Уже многократно писалось на форуме, что "дерганье" ножками GPIO быстрее 0,9 us (микросекунд) не получается. Так что такой вариант 4-проводой реализации протокола обмена с SD - путь в никуда.

[ГУ-49А]

Уже многократно писалось на форуме, что "дерганье" ножками GPIO быстрее 0,9 us (микросекунд) не получается. Так что такой вариант 4-проводой реализации протокола обмена с SD - путь в никуда.

На быстром GPIO (FIO) очень даже получается дёргать даже каждые 5 тактов. И не просто дёргать, а выводить любые данные из памяти вплоть до 16 бит на сэмпл. И не просто выводить, а ещё и другими делами заниматься параллельно. При частоте процессора в 70 МГц (для некоторых LPC, например, LPC2101/02/03) это даёт тактовую частоту 14 МГц. Всё зависит от типа контроллера и конкретной задачи...

[zltigo]

а ещё и другими делами заниматься параллельно.

Никакими "другими делами" ни "параллельно", ни "перепендикулярно" при махании ножками на максимальной скорости Вы не заниматься будете.
Посему тупое махание четырьмя битами и реальная фоновая пересылка через SPI на максимальной скорости SD карточки ЦЕЛОГО БЛОКА ИНФОРМАЦИИ (даже, если этот блок 8bit, а не 16, как у большиства котроллеров, и SPI не поддерживается ни FIFO ни DMA) совершенно не сопоставимы по эффективности.

Всё зависит от типа контроллера и конкретной задачи...

Да ничего не зависит, при наличии аппаратного SPI - без вариантов.

для некоторых LPC, например, LPC2101/02/03

Для тех-же LPC переключаютесь в 16bit режим, заливаете FIFO под завязку и спокойно реально другими делами занимаетесь, А не пытаетесь изобразить диаграмму работы SD контроллера с данными, клоками и битовыми(не байтовыми!) потоками. Там никакие 14MHz и близко не лежат.

[ГУ-49А]

Никакими "другими делами" ни "параллельно", ни "перепендикулярно" при махании ножками на максимальной скорости Вы заниматься не будете.
...Да ничего не зависит, при наличии аппаратного SPI - без вариантов.

Во-первых, позвольте поблагодарить вас за особую учтивость и толерантность ваших высказываний.
Во-вторых, я лишь указал на практическую возможность подобного подхода, не ставя под сомнение эффективность встроенной периферии.
В то же время, существуют случаи, когда всё же имеет смысл отказаться от аппаратного SPI в пользу его программной реализации (или параллельного доступа). Подобный случай я недавно приводил в ветке про быстрый тайминг FIO (необходимость ждать 7 тактов только для старта пересылки по SSP ведёт к увеличению кванта времени мультизадачности, в отличие от более гибкой программной реализации SPI с квантом в 3 такта).

[zltigo]

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

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

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

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

В то же время, существуют случаи, когда всё же имеет смысл отказаться от аппаратного SPI в пользу его программной реализации (или параллельного доступа).

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

Подобный случай я недавно приводил в ветке про быстрый тайминг FIO (необходимость ждать 7 тактов только для старта пересылки по SSP ведёт к увеличению кванта времени мультизадачности...

7 тактов, для обращения к "обычной переферии" безусловно особой радости не приносит, но и печали тоже. По любому выигрыш 4x тактов с мотивировкой для уменьшения кванта мультизадачности выглядит абсолютно притянутым за уши, поскольку время реакции на прерывание + время шедулера + переключения контекстов имеют даже совсем другой порядок. А если к этому добавить возникающую и требующую, как правило, компенсации неатомарность операции ногомахательства, то все становится еще натянутее.

[ГУ-49А]

7 тактов, для обращения к "обычной переферии" безусловно особой радости не приносит, но и печали тоже. По любому выигрыш 4x тактов с мотивировкой для уменьшения кванта мультизадачности выглядит абсолютно притянутым за уши, поскольку время реакции на прерывание + время шедулера + переключения контекстов имеют даже совсем другой порядок. А если к этому добавить возникающую и требующую, как правило, компенсации неатомарность операции ногомахательства, то все становится еще натянутее.

Мультитаск по таймеру - оно, конечно, так. Но я имел в виду другое: если "мультизадачность" реализована, что называется, вручную, простым перемежанием кода, и надо строго соблюдать тайминг высокоприоритетной задачи ("задача" в этом контексте скорее логическая сущность, в коде-то всё перемешано), то и 1 лишний такт может испортить нам картину. Взять, хотя бы, мой недавний случай - синхронный вывод в порт на фоне вывода в SPI. Есть там 3 варианта:
1) выводить в порт по таймеру (через FIQ) - мне не удалось и до 2 МГц тактовой добраться, на фоне 7-митактовых команд. В коде всё красиво, да результат не тот...
2) выводить в порт каждые 9 тактов, перемежая код и используя аппаратный SPI-вывод.
3) выводить в порт каждые 5 тактов, перемежая код и используя программно-эмулированный SPI.

Вот вам и разница.

Конечно, как уже писалось, идеологически более верным в таких случаях является выбор контроллера (и другого железа) с неким запасом производительности по отношению к данному ТЗ. Но! Это не означает, что все попытки "вопреки" выжать максимум из имеющегося более слабого (и дешевого!) железа подобным способом (пусть, извращённым) надо по-снобистски решительно отвергать.
ИМХО, более широкий спектр инженерных методов, наличие неординарных идей в голове - это залог более эффективного решения нетривиальной задачи. Как бы то ни было, можно много насоветовать в форуме по методологии, но конечный выбор всегда нужно делать самому...