Дано : STM32F051 48 mhz + RGB светодиодная матрица от светодидного экрана.
Надо раз в 50-400 мкс задвигать 64 байта данных(точнее 64 х6 бит) в сдвиговые регистры.
Можно ли при передаче по DMA после выставления на порту каждого нового байта формировать
импульс CLK(80-100 нс достаточно), или прийдется вешать внешнюю логику ?
ps : Ногодрыг хотелось бы оставить на крайний случай - контроллеру и так будет чем заняться ...

Точно после каждого байта, а не после каждой пачки из 64 байт?
Опишите какой интерфейс управления матрицей (или хотя бы номер хаба, например, HUB12).

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

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

Создается впечатление, что ТС собирает 6-битный SPI...
Если матрица одна, то правильнее воспользоваться на таком чахлике (STM32F051) аппаратным SPI,
при этом замкнув выход матрицы со следующим входом, и задвигать 64 * 6 = 384 байта.

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

Между возникновением DMA-запроса от таймера и самой DMA-транзакцией (запись в GPIO) может пройти около 12 тактов.
Поэтому частота DMA-запросов не может быть высокой. При 4 МГц будут фэйлы в работе, при 2МГц скорее всего нет.
С учетом того, что данные нужно выставить (и сбросить CLK), в следующим такте дать фронт CLK (при установленных данных),
частоту делим еще на 2.
Расход памяти будет 6 бит данных + 1 clk + 1 пустой, т.е. всего 75% полезного использования.
Инициализация такого массива потребует как минимум удвоенные требования к производительности (нужно писать две копии данных).

Как правило матрица - это 6 сдвиговых регистров на 512 бит каждый.
Не проще ли сделать из них один сдвиговый регистр на 3072 бита?
При помощи SPI, TIMER и DMA задвигать туда 384 байта и формировать защелку таймером.
При выводе статической картинки из памяти вообще никакого матана - просто натравливай DMA на нужный адрес.

Номер 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, если вставить ожидание перед включением,
то можно управлять яркостью).

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

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

Т.е. получается у вас 2^(5*3) = 32768 цветов.
По опыту скажу, что выше 4096 делать смысла нет, ибо не заметишь.
Т.е. при градациях яркости 4 бита на цвет вполне достаточно.
А это 3072 байта на картинку + 768 байт на текущий выводимый буфер.

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

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

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

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