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

Вполне достаточно. Тут нужно понять, что подразумевается под "открытой документацией". Например, скачанного из инета SanDisk SD Card Product Manual, в котором аффтары практически полностью пересказали стандарт 1.01, достаточно чтобы сделать универсальный контроллер SD-карты.

Но лучше зайти на FTP и взять полный стандарт.

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

Где не получается - на всех-всех ARM'ах?


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

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

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

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

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

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

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

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

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

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

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

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

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

4) Использовать для синхронного порта SSP подпитываемого байтами за время, пока его FIFO не успеет опустошиться.

Очень инетесно, что там в оставшиеся от эмуляции многомегабитных синхронного порта и SPI, такт-другой сей контроллер "по TЗ" делает? Может вместо него со всем этим пару триггеров (утрирую) справились???

Увы, но "подпитка" занимает 7 тактов, а поскольку подпитывать нужно постоянно, то это равносильно вышеописанному 2-му варианту, т.е. вывод в порт за 9 тактов вместо 5-ти...

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

За 9 тактов подпитываем 16-ю битами, т.е на передачу одного бита информации по SPI тратим 0,56 такта контроллера. Вместо 5*2 = 10 тактов. Так о чем мы это вообще разговариваем?

Не делайте, но зачем при этом и над контроллером, и главное, над собой издеватся?

Что ж, давайте ещё раз напомню, в чём заключалась моя задача. Нужно было делать одновременно 2 вещи:
1) Выводить в порт FIO 16 бит информации;
2) Выводить в SPI по 8 бит данных.
Причём, выводить в порт FIO как можно быстрее (это приоритетная задача). Дык вот, если использовать аппаратный SSP, то пока мы кидаем в него данные, проходит 7 тактов, следовательно, мы не можем слать в порт FIO чаще, чем за 7+2 такта (2 идёт на сам вывод в порт), т.е. за 9 тактов. Если же мы используем программный SPI, то шлём эти биты вручную, да, менее эффективно, чем по SSP, но зато у нас появляется возможность выводить в FIO каждые 3+2 такта, т.е. за 5 тактов. Жертвуем при этом скоростью вывода в SPI (примерно 60 тактов за бит, что в моём случае полностью устраивает). Но куда важнее мне было получить максимальную скорость вывода в FIO, что я и сделал. Именно поэтому я и писал, что существуют те редкие случаи, когда целесообразнее использовать программный SPI, и в этом нет ничего страшного.

Если говорить о скорости передачи по SPI, то, например, программный параллельный 4-битный вывод за 5 тактов вполне окажется быстрее последовательного (и размер буфера можно уж поболее SSP-шного сделать). Нужно ли это автору этой темы - другой вопрос...

Что значит еще раз? Впервые поминаются 16 ПАРАЛЛЕЛЬНО выводимых бит БЕЗ сопровождающего их клока. Впервые озвучивается, что скорость SPI (c БЫСТРОЙ эмуляции которого здесь, вынужден напомнить, все и началось,) значения не имеет. По преждему НИКАК не оговаривается, что делает контроллер, кроме махания ножками за пять тактов, но правда ранее звучало, что есть некие неназванные паузы в этой ногомахалке на подготовку данных. Короче, что имеем - некую вещицу, которая машет 18 ногами по заранее подготовленной порции данных, при этом две из 18 ног изображают некую последовательность совпадающуюю с кастрированным наполовну SPI интефейсом.
Собственно об SPI интерфейсе на самом деле речь и не идет .

Уже обращал внимание - не за 5, а за 5*2, ибо данные на синхронных интерфейсах соопровождаются клоками. Клоки, естественно должны быть сдвинуты по фазе. Посему 5 тактов-записали данные + 5 тактов записали клок. Правда можно (но кривовато) старужи немножко рассыпухи навесить , для сдвига фазы.

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