Jump to content

    

STM32F103 Timer + DMA + GPIO

Добрый день

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

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

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

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

 

Share this post


Link to post
Share on other sites
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.

Edited by ivan24190

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
6 минут назад, Алексей ВМ сказал:

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

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

Share this post


Link to post
Share on other sites

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

Edited by Алексей ВМ

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
4 часа назад, Алексей ВМ сказал:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
2 hours ago, jcxz said:

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

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

Share this post


Link to post
Share on other sites
12 hours ago, jcxz said:

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

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

 

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

Edited by Алексей ВМ

Share this post


Link to post
Share on other sites
17 hours ago, jcxz said:

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

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

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

Edited by Алексей ВМ

Share this post


Link to post
Share on other sites
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 таймерах с ШИМ-выходом, работающих синхронно. И загрузка шины будет низкая - никаких лишних массовых пересылок. И яркость будет стабильна.

Share this post


Link to post
Share on other sites
17 minutes ago, jcxz said:

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now