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]

[uquote="Alex-Elektron",url="/forum/viewtopic.php?p=3235051#p3235051"]А вот как стробить каждый бит - не очень. Есть идеи?[/uquote]
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]

[uquote="arkhnchul",url="/forum/viewtopic.php?p=3239999#p3239999"]В двух словах - клок получается ШИМ-ом с того же таймера, который тактирует DMA.[/uquote]
Чтобы это работало стабильно на больших частотах событий от таймера к DMA, нужно чтобы приоритет арбитража шины для DMA-контроллера был выше чем у других bus-master-ов в МК. Главным образом - выше чем у CPU. А у большинства известных мне МК, как раз у CPU приоритет доступа к шине выше чем у DMA и изменить его нельзя.
Только некоторые МК позволяют менять.
А без этого невозможно гарантировать то, что не будет пропусков обслуживания DMA-контроллером событий от таймера. Да даже когда нет пропусков, из-за того что идёт задержка обслуживания DMA из-за занятости шины, то не будет никакой стабильности во временных диаграммах сигналов данных (будет джиттер). И уж никак нельзя гарантировать синхронность и постоянство фаз между сигналом от таймера на внешней ноге (который генерится без задержек арбитража) и сигналами данных от DMA.
Соответственно: нужно брать МК с возможностью задания наивысшего приоритета DMA-контроллеру. Ну или ложить спать CPU (и остальных bus-master-ов) на время DMA-передачи.
Ну или посмотреть матрицу шин в вашем МК - возможно раскидав массивы данных DMA и рабочие области памяти процессора по разным регионам памяти сидящим на разных шинах, можно добиться независимого доступа к памяти без задержек на арбитраж шины. Хотя тут надо посмотреть.... не факт...

[arkhnchul]

[uquote="jcxz",url="/forum/viewtopic.php?p=3240108#p3240108"]Соответственно: нужно брать МК с возможностью задания наивысшего приоритета DMA-контроллеру.[/uquote]
вот у описываемых в оной методичке 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]

[uquote="dosikus",url="/forum/viewtopic.php?p=3240164#p3240164"]jcxz, по моей ссылке сходите.[/uquote]
Сходил, и что там полезного?

[Alex-Elektron]

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

[jcxz]

[uquote="Alex-Elektron",url="/forum/viewtopic.php?p=3240394#p3240394"]Там довольно неплохой пример от dosikusa именно того, что мне надо (без переделки железа). Там как раз обсуждается рулёжка RGB. 7й пост сверху.[/uquote]
Там нет ничего по указанным мной проблемам. Ни решения ни исследования.
А тот очевидный факт, что DMA-транзакции можно запускать от таймера, обслуживая при этом другую периферию, я думаю не является секретом ни для кого более-менее имеющего опыт реальной работы с МК. Только это никак не поможет при указанной проблеме.

[dosikus]

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

[jcxz]

[uquote="dosikus",url="/forum/viewtopic.php?p=3241107#p3241107"]jcxz, пока вы решаете свою надуманную"проблему", совершенно ни у месту здесь озвученную , другие реализуют.[/uquote]
Всегда так - кто-то думает, прежде чем что-то сделать. А другой сразу быдлокодит, а потом разбирается в той куче, что получил и костыли костылит.
Видимо Вы свой выбор уже сделали.
Если по делу сказать нечего, лучше помолчите.