[Paramedic 0]

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

[GroundCtrl 0]

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

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

[aaarrr 69]

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

[sergeeff 1]

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

[aaarrr 69]

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

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

 

Так что такой вариант 4-проводой реализации протокола обмена с SD - путь в никуда.

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

[account3847 0]

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

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

[zltigo 1]

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

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

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

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

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

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

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

[account3847 0]

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

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

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

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

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

[zltigo 1]

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

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

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

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

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

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

Впрочем, я готов обсудить и другие "случаи".

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

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

[account3847 0]

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

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

1) выводить в порт по таймеру (через FIQ) - мне не удалось и до 2 МГц тактовой добраться, на фоне 7-митактовых команд. В коде всё красиво, да результат не тот...

2) выводить в порт каждые 9 тактов, перемежая код и используя аппаратный SPI-вывод.

3) выводить в порт каждые 5 тактов, перемежая код и используя программно-эмулированный SPI.

 

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

 

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

ИМХО, более широкий спектр инженерных методов, наличие неординарных идей в голове - это залог более эффективного решения нетривиальной задачи. Как бы то ни было, можно много насоветовать в форуме по методологии, но конечный выбор всегда нужно делать самому...

[zltigo 1]

Есть там 3 варианта:

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

...по отношению к данному ТЗ.

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

[account3847 0]

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

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

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

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

[zltigo 1]

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

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

На рассыпухе совсем не хочется такое делать, уж поверьте...

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

[account3847 0]

Так о чем мы это вообще разговариваем?

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

[zltigo 1]

Что ж, давайте ещё раз напомню,

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

Собственно об SPI интерфейсе на самом деле речь и не идет :(.

...программный параллельный 4-битный вывод за 5 тактов ....

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

....вполне окажется быстрее последовательного...

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