[sherr 0]

Дано : STM32F051 48 mhz + RGB светодиодная матрица от светодидного экрана.

Надо раз в 50-400 мкс задвигать 64 байта данных(точнее 64 х6 бит) в сдвиговые регистры.

Можно ли при передаче по DMA после выставления на порту каждого нового байта формировать

импульс CLK(80-100 нс достаточно), или прийдется вешать внешнюю логику ?

ps : Ногодрыг хотелось бы оставить на крайний случай - контроллеру и так будет чем заняться ...

Изменено 10 февраля, 2016 пользователем sherr

[adnega 10]

после выставления на порту каждого нового байта формировать импульс CLK(80-100 нс достаточно),

Точно после каждого байта, а не после каждой пачки из 64 байт?

Опишите какой интерфейс управления матрицей (или хотя бы номер хаба, например, HUB12).

[esaulenka 5]

Что-то кажется мне, что запускаться эта передача должна таймером. Соответственно, пусть таймер и дёргает стробом.

[adnega 10]

Что-то кажется мне, что запускаться эта передача должна таймером. Соответственно, пусть таймер и дёргает стробом.

Там все хитрее - нужно еще переключать мультиплексор и защелкивать данные при выключенном выходе, иначе

будет смаз от соседних диодов. При этом нужно как-то управлять яркостью, не всегда надо 100%.

 

Создается впечатление, что ТС собирает 6-битный SPI...

Если матрица одна, то правильнее воспользоваться на таком чахлике (STM32F051) аппаратным SPI,

при этом замкнув выход матрицы со следующим входом, и задвигать 64 * 6 = 384 байта.

 

[Сергей Борщ 119]

Надо раз в 50-400 мкс задвигать 64 байта данных(точнее 64 х6 бит) в сдвиговые регистры.

Можно ли при передаче по DMA после выставления на порту каждого нового байта формировать

импульс CLK(80-100 нс достаточно), или прийдется вешать внешнюю логику ?

Да, задача не очень понятна. Если я ее правильно понял, то я бы просто завел массив на 64*2 байтов, и этот массив при помощи DMA выпихивал в порт по таймеру. В каждом байте 6 бит под данные, 1 бит под CLK. Желательно, чтобы все сигналы были на одном порту, иначе придется задействовать по одному массиву и каналу DMA на каждый порт. Делал так, выводил одновременно на три порта 16 вообще не связанных между собой последовательных сигналов.

[adnega 10]

и этот массив при помощи DMA выпихивал в порт по таймеру.

Между возникновением DMA-запроса от таймера и самой DMA-транзакцией (запись в GPIO) может пройти около 12 тактов.

Поэтому частота DMA-запросов не может быть высокой. При 4 МГц будут фэйлы в работе, при 2МГц скорее всего нет.

С учетом того, что данные нужно выставить (и сбросить CLK), в следующим такте дать фронт CLK (при установленных данных),

частоту делим еще на 2.

Расход памяти будет 6 бит данных + 1 clk + 1 пустой, т.е. всего 75% полезного использования.

Инициализация такого массива потребует как минимум удвоенные требования к производительности (нужно писать две копии данных).

 

Как правило матрица - это 6 сдвиговых регистров на 512 бит каждый.

Не проще ли сделать из них один сдвиговый регистр на 3072 бита?

При помощи SPI, TIMER и DMA задвигать туда 384 байта и формировать защелку таймером.

При выводе статической картинки из памяти вообще никакого матана - просто натравливай DMA на нужный адрес.

[sherr 0]

Точно после каждого байта, а не после каждой пачки из 64 байт?

Опишите какой интерфейс управления матрицей (или хотя бы номер хаба, например, HUB12).

Номер xаба не помню, матрица RGB 32*64 шаг 3мм (!).

R1-G1-B1...R2-G2-B2 + CLK,EN,STB, A0-A3.

Глубина сдвиговых регистров - 64 бита, мультиплексирование 1/16 .

По поводу сделать массив вдвое больше - уже думал, памяти маловато,при 5 бит/цвет

почти все 8 к и уйдут...

Изменено 10 февраля, 2016 пользователем sherr

[adnega 10]

Номер xаба не помню, матрица RGB 32*64 шаг 3мм (!).

R1-G1-B1...R2-G2-B2 + CLK,EN,STB, A0-A3.

Глубина сдвиговых регистров - 64 бита, мультиплексирование 1/16 .

По поводу сделать массив вдвое больше - уже думал, памяти маловато,при 5 бит/цвет

почти все 8 к и уйдут...

Для 32 * 64 * RGB нужно минимум 32*64*3=6144 бита = 768 байт.

О каких 8К идет речь?

 

Длина регистра 64 бита = 8 байт.

Соединяете R1_OUT c R2_IN, R2_OUT с G1_IN, G1_OUT с G2_IN, G2_OUT с B1_IN, B1_OUT с B2_IN.

Получаете единый сдвиговый регистр на 48 байт.

Передаете эти 48 байт при помощи SPI (SPI_MOSI -> R1_IN, SPI_SCK -> CLK).

По окончанию выключаем вывод (EN=0), чуть-чуть ждем, делаем импульс на STB

(после импульса на STB можно уже начать задвигать следующую строку),

устанавливаем соответствующий A0-A3, включаем вывод (EN=1, если вставить ожидание перед включением,

то можно управлять яркостью).

 

[Сергей Борщ 119]

(после импульса на STB можно уже начать задвигать следующую строку),

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

[sherr 0]

Для 32 * 64 * RGB нужно минимум 32*64*3=6144 бита = 768 байт.

О каких 8К идет речь?

768 x 5(бит/цвет, ВАМ-модляция)x2(как предлагалось выше для получения CLK)=7680 байт.

Соответствие между точками на экране и байтами в памяти там достаточно непростое -

уж очень быстро быстро не сформируешь ...

Сразу признаюсь - задачка учебно-экспериментальная, для STM32 кое-что писал для

себя, но практически без прерываний и DMA.

[adnega 10]

5(бит/цвет, ВАМ-модляция)

Т.е. получается у вас 2^(5*3) = 32768 цветов.

По опыту скажу, что выше 4096 делать смысла нет, ибо не заметишь.

Т.е. при градациях яркости 4 бита на цвет вполне достаточно.

А это 3072 байта на картинку + 768 байт на текущий выводимый буфер.

[VCucumber 0]

В каждом байте 6 бит под данные, 1 бит под CLK

а есть какой-нибудь хак, чтобы пересылка из памяти в порт была строго определена по тактам ? чтобы картинка по экрану не плыла

 

[adnega 10]

а есть какой-нибудь хак, чтобы пересылка из памяти в порт была строго определена по тактам ? чтобы картинка по экрану не плыла

Не хак, а FSMC.

Но у этого МК такого нет.

 

Кста, статическая картинка не должна плыть, т.к. есть STB.

А бегущая строка будет плыть, т.к. строки мультиплексируются.

[VCucumber 0]

Не хак, а FSMC.

Но у этого МК такого нет.

так может всё-таки хак ?