SPI на GPIO+DMA

[Alex-Elektron]

Доброго времени суток! Начну с предыстории (можно не читать). Примерно с год назад передо мной поставили задачу заставить работать RGB-модули, 16х32 точек каждый, всего их два. В связи с краткостью сроков, задачи показывать полноцвет не было, достаточно было 7 цветов, получаемых смешением цвета пикселя, светящегося на полную. Соответствено, над скоростью записи данных в эти модули особо не заморачивался и повесил их на обычные порты ввода - вывода. Всё прекрасно работает и по сей день. Но! Тут возникла неожиданно необходимость выводить полноцвет. Развёртка модулей 1/4, максимальная частота записи данных 150 МГц. Частота обновления (от строки к строке) 1920 Гц, а их 4 штуки. То есть, у нас есть, казалось бы, аж 2 мс (!) чтобы несколько раз перезаписать данные одной строки (применить BAM). МК при этом делает ещё неслабые расчёты помимо вывода инфы и его ресурса перестаёт хватать.

Собсно, возникла идея-вопрос: можно ли как-то реализовать на периферии GPIO+DMA некое подобие шести MOSI + общий CLK?
То есть, на GPIOB у меня болтаются такие выходы:

Как тупо затолкать данные в порт через DMA - понятно. А вот как стробить каждый бит - не очень. Есть идеи?

[arkhnchul]

писать в порт два раза - со сброшенным и установленным битом clk

ЗЫ вам насколько важно clk тоже по dma переключать?

[dosikus]

Alex-Elektron, читай http://forum.easyelectronics.ru/viewtop ... it=dma+spi

[jcxz]

Alex-Elektron писал(а):

А вот как стробить каждый бит - не очень. Есть идеи?

1. Использовать МК имеющий quad-SPI-интерфейсы. Есть в старших LPC, в Tiva, в Infineon и т.д.
2. Либо ещё лучше: имеющий порты McASP или McBSP - там в некоторых вообще до 16-ти сериализаторов на порт. Хотя с фазой CLK надо будет помудрить.
3. Либо ещё лучше: что-нить из LPC43xx, они имеют SGPIO - на нём вообще можно наверное любой последовательный интерфейс эмулировать (с поддержкой DMA) хоть многоканальный SPI, хоть какой-нить свой экзотический.

Зы: Никогда не имел дела с RGB-модулями: а они что - по SPI подключаются? Или вы через SPI пытаетесь какой-то другой интерфейс эмулировать?

[Alex-Elektron]

Спасибо за рекомендации! Буду пробовать.

Зы: Никогда не имел дело с RGB-модулями: а они что - по SPI подключаются? Или вы через SPI пытаетесь какой-то другой интерфейс эмулировать?

В них используются китайские аналоги hc595. А они, как известно, довольно бодро рулятся по SPI.

[arkhnchul]

если забить на clk в самой пачке DMA и дрыгать его таймером, то у ST есть методичка вот прям того, что нужно - http://www.st.com/content/ccc/resource/ ... 169730.pdf . В двух словах - клок получается ШИМ-ом с того же таймера, который тактирует DMA.

[jcxz]

arkhnchul писал(а):

В двух словах - клок получается ШИМ-ом с того же таймера, который тактирует DMA.

Чтобы это работало стабильно на больших частотах событий от таймера к DMA, нужно чтобы приоритет арбитража шины для DMA-контроллера был выше чем у других bus-master-ов в МК. Главным образом - выше чем у CPU. А у большинства известных мне МК, как раз у CPU приоритет доступа к шине выше чем у DMA и изменить его нельзя.
Только некоторые МК позволяют менять.
А без этого невозможно гарантировать то, что не будет пропусков обслуживания DMA-контроллером событий от таймера. Да даже когда нет пропусков, из-за того что идёт задержка обслуживания DMA из-за занятости шины, то не будет никакой стабильности во временных диаграммах сигналов данных (будет джиттер). И уж никак нельзя гарантировать синхронность и постоянство фаз между сигналом от таймера на внешней ноге (который генерится без задержек арбитража) и сигналами данных от DMA.
Соответственно: нужно брать МК с возможностью задания наивысшего приоритета DMA-контроллеру. Ну или ложить спать CPU (и остальных bus-master-ов) на время DMA-передачи.
Ну или посмотреть матрицу шин в вашем МК - возможно раскидав массивы данных DMA и рабочие области памяти процессора по разным регионам памяти сидящим на разных шинах, можно добиться независимого доступа к памяти без задержек на арбитраж шины. Хотя тут надо посмотреть.... не факт...

[arkhnchul]

jcxz писал(а):

Соответственно: нужно брать МК с возможностью задания наивысшего приоритета DMA-контроллеру.

вот у описываемых в оной методичке stm32 как раз так, в случае чего тапки у DMA:

The DMA request may stop the CPU access to the system bus for some bus cycles, when the CPU and DMA are targeting the same destination (memory or peripheral).

[dosikus]

jcxz, по моей ссылке сходите.

[jcxz]

dosikus писал(а):

jcxz, по моей ссылке сходите.

Сходил, и что там полезного?

[Alex-Elektron]

Там довольно неплохой пример от dosikusa именно того, что мне надо (без переделки железа). Там как раз обсуждается рулёжка RGB. 7й пост сверху.

[jcxz]

Alex-Elektron писал(а):

Там довольно неплохой пример от dosikusa именно того, что мне надо (без переделки железа). Там как раз обсуждается рулёжка RGB. 7й пост сверху.

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

[dosikus]

jcxz, пока вы решаете свою надуманную"проблему", совершенно ни у месту здесь озвученную , другие реализуют.
Вы своего "сферического коня в вакууме" приберегите для дурачков, ОК?

[jcxz]

dosikus писал(а):

jcxz, пока вы решаете свою надуманную"проблему", совершенно ни у месту здесь озвученную , другие реализуют.

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