STM32F1 vs DMA, part 2. А можно ли махать лапками БЕЗ КОДА?!

[iddqd]

Я неплохо поразвлекся с STM32 DMA и мне это дело понравилось. В голову пришли еще пару идей насчет DMA и стало интересно - а вот так на STM32F1xx прокатит?

- назначаем src некий блок в памяти (RAM/flash), с инкрементом.
- dst -> GPIOx_BSRR.
Далее возможны варианты...
1) Вообще заявить это MEM2MEM. Идея в том что DMA влупит на полной скорости, без эвентов. Результат? Блок в памяти будет описанием как ворочать GPIO с почтенной скоростью без участия процессора. Теоретически. Caveat: не уверен что GPIO успеет отработать тайминги когда DMA в регистр постоянно новые данные толкает - и не факт что адресату эти тайминги понравятся. Но вообще, есть какие-то принципиальные причины по которым это не сработало бы?

2) Для более определенных таймингов можно эвентом от таймера канал DMA дергать, тогда это уже не MEM2MEM транзакция, конечно. Это медленнее, но более предсказуемо. И по прежнему не треубет внимания проца к этому занятию. Позволяя что-нибудь этакое, от супер-многоканального PWM железно (совсем-железно если CIRC сделать) до синтеза всяких хитрых паттернов без участия в этом софта.

Пример практического применения, один из: допустим я повешу на Port B (или любой иной) 8080/6800 LCD (параллельный mipi, которые в "простых" мобилах) и согласен подарить LCD весь port B (или иной). У LCD есть 8 линий данных + несколько линий управления (CS, RD, WR... обычные сигналы шины). Это естественно в допущении что контроллера внешней шины нет - камни с шиной очень уж разлапистые и/или дорогие и избыточные. Если контроллер есть, все это конечно ни к чему. А тут идея в том чтобы заранее подготовить буфер и пульнуть целый блок без участия проца. В данном случае - ну вот сэмулировав контроллер шины, дескать. Так что даже малолапый камень сможет не очень медленно в графический LCD что-то пульнуть, да еще и без участия софта.

Кто что думает? Это бред? Или работоспособно? И если второе - какие подводные камни в этих комбо? Ну, кроме диких таймингов в первом случае

[Reflector]

[uquote="iddqd",url="/forum/viewtopic.php?p=3947683#p3947683"]Кто что думает? Это бред? Или работоспособно?[/uquote]
Это работоспособно и достаточно банально. Работает в том числе с дисплеями, один канал таймера пинает DMA, а второй формирует строб. Насколько помню по времени для F1 получалось 14 тактов на байт. Так можно и 16-ти битный дисплей подключить, а если строб генерить не таймером, то только 8-ми битный и буфер придется увеличивать в 2 или 4 раза... Правда на F1 в половинки порта писать нельзя, так что для него разница не настолько большая.

[Мурик]

https://www.cyberforum.ru/blogs/204791/blog5169.html
https://www.cyberforum.ru/blogs/204791/blog5170.html

[iddqd]

Лобовая идея которая возникла - с 1 таймером/каналом, от которого только DMA event надо. Как я понимаю, по максимуму это что-то типа (APB/2) dma event'ов в секунду? (без прескалера и счет до 1?). А DMA столько вообще переварит?

По оному эвенту нечто типа u32 за раз, кодирующий и данные и стробы, поэтому и все на 1 порт -> BSRR. Можно даже несколько лап в AFIO заюзать под что-то еще, если при подготовке данных учесть что они no-op. Очевидный минус - u32 память кушает, но если это partial отрисовка или нечто типа "PWM на весь порт" - не выглядит большой проблемой вроде. Из плюсов - BSRR позволяет "latch". Можно напрямую ODR, тогда вроде хватит u16 но latch прошлого состояния не будет, каждый u16 должен описывать целиком все (data+все сигналы).

А так спасиб за подтверждение что работает. А как именно 14 циклов вышло? Откуда такая математика?

p.s. о, я сделал DMA -> BSRR как MEM2MEM, работает вроде. Некое подобие PWM на весь порт для пробы соорудил, правда это не интересно т.к. MEM2MEM и CIRC вместе не живут. Но как я понимаю отстрелить таким манером "пакет" в дисплей "асинхронно" все же вроде вариант, не? В допущении что нас устроят получившиеся при таком изврате тайминги, конечно.

p.p.s. а по ссылкам из соседнего топика еще http://dimoon.ru/mikrokontrolleryi/dray ... 103c8.html нашлось - там тоже вывод данных в ленту довольно интересно сделан. Как я понял, DMA репрограмит цикл PWM дабы сделать 1 или 0 этой штуке.

[Reflector]

[uquote="iddqd",url="/forum/viewtopic.php?p=3947773#p3947773"]А как именно 14 циклов вышло? Откуда такая математика?[/uquote]
Подобрал опытным путем. Если параллельно еще работают DMA, то может и больше придется делать, особенно на F1 с медленными портами.

[iddqd]

Интересно. А вы это с каким камнем делали? И в чем суть эксперимента была? Смотрели с какого момента дисплей начинает работать стабильно?

[Reflector]

Спектрум на F1 и F3 запускал. Заполнял буфер сразу на всю линию из 256 точек и отрисовывал, там еще второй таймер был который автоматически отключал первый после вывода нужного количества пикселей. Точно не помню, вроде в динамике картинка нормально выглядит и при 12 тактах, по крайней мере на F3, но если по одному кадру отрисовывать то иногда что-то портилось...

[iddqd]

Прикольно. Хоть и не объясняет полностью почему именно столько. А второй таймер зачем? Просто запрограмить нужное число байтов в DMA транзакцию было чем-то плохо? Оно пыталось IRQ от DMA по этому поводу избежать? Или зачем оно?

p.s. в случае дисплея - никогда бы не подумал что dma + gpio можно собезьянить примитивный клон "display controller" gpu, мне все же определенно нравится stm32 своим железом, черт его возьме

[Reflector]

[uquote="iddqd",url="/forum/viewtopic.php?p=3949124#p3949124"]Прикольно. Хоть и не объясняет полностью почему именно столько.[/uquote]
Выбирается достаточно большой период, затем подбирается значение CCR для строба с учетом того, что даже если DMA пинается в начале периода данные в порт могут выводиться с некоторой задержкой из-за конфликтов при доступе к памяти и портам, в конце период уменьшается до минимально возможного при котором наблюдается стабильная работа.

А второй таймер зачем? Просто запрограмить нужное число байтов в DMA транзакцию было чем-то плохо? Оно пыталось IRQ от DMA по этому поводу избежать? Или зачем оно?

Если не отключать таймер, то он будет продолжать генерить строб. Это можно не делать когда управляющие сигналы тоже выводятся через порты, но в таком случае размер буфера будет в 2 или 4 раза больше, соответственно и заполнять его дольше, а мне была важна скорость.

[iddqd]

Ну да, по шине же еще процессор данные гоняет, в дш написано что всегда оставляют хотя-бы 1 цикл для него. И еще другие каналы могут, но там приоритетами можно рулить.

А что до строба - я как-то так себе работу с LCD'шником и увидел - описать вообше "состояния шины", и данные и стробы. Чтобы подготовить пакет, зарядить, а дальше цепочку команд/данных само втолкает, оформив правильными состояниями. И если это какой-нибудь display_init() (команды и константы инициализации) - можно в readonly в флеш, и еще вопрос займет ли оно больше чем софтварная реализация.

Интересно, а есть идеи как проверить теряет DMA -> GPIO что-нибудь или нет при mem2mem? Подстава в том что это быстрое и многоканальное, у меня нет скоростных логичесих анализаторов которым бы что-то такое можно было бы ухватить.