[Алексей ВМ 0]

Добрый день

Имеется STM32F103, надо как можно быстрее выводить данные на пины проца. Использую связку TIM1 + DMA + GPIO

Таймер (TIM1) настроен на макс частоту - делитель равен 2, период - 1. По таймеру тактируется DMA, который натравлен на GPIO->ODR. Максимальная частота на пинах - 6 МГц, хотя должна быть не менее 36 МГц.

Предделители AHB, APB2, настройки GPIO проверены.

Может быть причиной низкой частоты какие-то аппаратные особенности  TIM1 + DMA + GPIO?

 

[ivan24190 0]

31 minutes ago, Алексей ВМ said:

Добрый день

Имеется STM32F103, надо как можно быстрее выводить данные на пины проца. Использую связку TIM1 + DMA + GPIO

Таймер (TIM1) настроен на макс частоту - делитель равен 2, период - 1. По таймеру тактируется DMA, который натравлен на GPIO->ODR. Максимальная частота на пинах - 6 МГц, хотя должна быть не менее 36 МГц.

Предделители AHB, APB2, настройки GPIO проверены.

Может быть причиной низкой частоты какие-то аппаратные особенности  TIM1 + DMA + GPIO?

 

Попробуйте использовать DMA в режиме MEM2MEM. Хотя 36 МГц получить наверное не удастся, но будет быстрее, чем через таймер. Но учтите, что DMA в этом режиме займет шину целиком. Либо рассмотреть вариант с FSMC.

Изменено 22 апреля, 2019 пользователем ivan24190

[Alex-lab 4]

На коте в одной теме про самодельных осциллограф разбирали общение ДМА и GPIO, по замерам единичный обмен занимает 9 тактов - это предел для F1.

[AVI-crak 0]

В дма есть своё FIFO, использовать порог 1/2 и 4 удара на чтение из памяти для 16 бит данных, или 8 ударов на 8бит данных. Память при этом будет читаться два раза по 32бита.

Арбитр шины допускает работу дма в режиме последовательного чтения без пропусков 2 или 4 полных такта. Два полных такта предпочтительнее, fifo в любом случае заполняется под крышку, порог - это когда количество данных уменьшилось. В этом случае есть ещё два запасных такта на борьбу с арбитром памяти. Можно поиграться с порогом 3/4, но это очень специфично.

И да, дма не может читать данные из памяти быстрее 1/2 частоты шины, чисто физически. Но может стабильно писать на той-же частоте в периферию. 

[Алексей ВМ 0]

https://habr.com/ru/post/437112/

 

10 тактов на копирование... При 72 МГц тактовой и получается около 6-7 МГц.

Изменено 24 апреля, 2019 пользователем Алексей ВМ

[jcxz 245]

6 минут назад, Алексей ВМ сказал:

10 тактов на копирование... При 72 МГц тактовой и получается около 6-7 МГц.

Непонятно с чего Вы решили что GPIO может работать на частоте ядра? Часто частота GPIO как раз и составляет эти самые 6 МГц. И никакой DMA тут не поможет ускориться. Иногда частота GPIO явно указывается в мануале на МК.

[Алексей ВМ 0]

Частота пина конфигурится программно, макс - 50 МГц. Кроме того, без DMA прямое дергание пина занимает 4 такта  - 18 МГц.  Задержку создает латентность работы DMA с шиной.

Изменено 24 апреля, 2019 пользователем Алексей ВМ

[jcxz 245]

Ещё можно попробовать усыпить процессор - может это и даст какой выигрыш на время обмена. Но скорее Вам надо пересматривать архитектуру и искать другое решение. Без ногодрыга. Даже с DMA.

Да и чего вы хотите добиться в результате? Может это вообще недостижимо таким способом...

[Arlleex 190]

4 часа назад, Алексей ВМ сказал:

Частота пина конфигурится программно, макс - 50 МГц.

Там не максимальная частота настраивается программно. От этих настроек зависит скорость нарастания фронтов.

[jcxz 245]

Если ТС осилит асм и сможет написать подряд этак 1000 команд записи в порт GPIO и измерит время их выполнения, то его радужные заблуждения насчёт частоты GPIO быстро рассеятся.  

[aaarrr 69]

2 hours ago, jcxz said:

Если ТС осилит асм и сможет написать подряд этак 1000 команд записи в порт...

Для этого нет ни малейшей нужды осиливать асм. Достаточно осилить дизасм.

[Алексей ВМ 0]

12 hours ago, jcxz said:

Если ТС осилит асм и сможет написать подряд этак 1000 команд записи в порт GPIO и измерит время их выполнения, то его радужные заблуждения насчёт частоты GPIO быстро рассеятся.  

В приведенной выше ссылке есть вся информация по поводу времени выполнения. 18 МГц - это если писать без циклов и проверок условий,  линейно Set -> Reset -> ..., в прерывании с наивысшим приоритетом,  то есть максимально достижимая частота,

 

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

Изменено 25 апреля, 2019 пользователем Алексей ВМ

[Алексей ВМ 0]

17 hours ago, jcxz said:

Ещё можно попробовать усыпить процессор - может это и даст какой выигрыш на время обмена. Но скорее Вам надо пересматривать архитектуру и искать другое решение. Без ногодрыга. Даже с DMA.

Да и чего вы хотите добиться в результате? Может это вообще недостижимо таким способом... 

Надо выводить картинку на матрицу 32х32 с последовательным интерфейсом HUB75 (6 сигналов данных и 1 клок) и одновременно управлять яркостью программно, так как аппаратной возможности нет. FSMC в данном чипе нет. Соответственно, если принять частоту кадров 120 Гц, то на линию приходится 520 мкс, за это время надо вывести 8 градаций цвета, то есть на одну линию приходится 65 мкс, за которые надо вывести данные и пошимить яркость. Для достижения макс яркости надо уменьшить время вывода данных, собственно, поэтому и ищется способ с минимальным временем вывода. 

Изменено 25 апреля, 2019 пользователем Алексей ВМ

[jcxz 245]

2 часа назад, Алексей ВМ сказал:

Надо выводить картинку на матрицу 32х32 с последовательным интерфейсом HUB75 (6 сигналов данных и 1 клок) и одновременно управлять яркостью программно, так как аппаратной возможности нет. FSMC в данном чипе нет. Соответственно, если принять частоту кадров 120 Гц, то на линию приходится 520 мкс, за это время надо вывести 8 градаций цвета, то есть на одну линию приходится 65 мкс, за которые надо вывести данные и пошимить яркость. Для достижения макс яркости надо уменьшить время вывода данных, собственно, поэтому и ищется способ с минимальным временем вывода. 

 

Способ с DMA будет сильно зависеть от загрузки шины данных другими bus-master-ами (главным образом - CPU). Т.е. - яркость у вас будет гулять в зависимости от того, что в это время делает фоновая программа. Так как будет меняться временная диаграмма. Самое неприятное, что могут возникать устойчивые интерференции частот обновления картинки и каких-то циклических процессов в фоновой программе (при сравнимых их частотах). Что будет приводить к устойчивым искажениям. Конечно DMA имеет некоторое FIFO, но при таких запросах к времянке как у вас, оно не поможет, имхо.

Так что - или усыплять CPU на время пересылки чтоб не мешал. Или использовать более другой CPU с соответствующей периферией, времянка коей не будет зависеть от загрузки шины.

 

PS: В F103 нет 7-и таймеров с режимом ШИМ и теневыми регистрами для предварительной загрузки?

Такая задача легко реализуема на любом из XMC4500...XMC4800 на 7 таймерах с ШИМ-выходом, работающих синхронно. И загрузка шины будет низкая - никаких лишних массовых пересылок. И яркость будет стабильна.

[Алексей ВМ 0]

17 minutes ago, jcxz said:

PS: В F103 нет 7-и таймеров с режимом ШИМ и теневыми регистрами для предварительной загрузки?

Такая задача легко реализуема на любом из XMC4500...XMC4800 на 7 таймерах с ШИМ-выходом, работающих синхронно. И загрузка шины будет низкая - никаких лишних массовых пересылок. И яркость будет стабильна. 

К сожалению, нет. Да и ШИМ не поможет в данном случае - данные должны быть увязаны с клоком. ШИМ должен работать от момента окончания загрузки данных и до момента начала след загрузки.