Всем привет!

Собственно не успел я постебать коллег что сидят на STM процах без FIFO на UART. Как достался мне маленький хобби проект на STM32F3Discovery.
В этом проекте мне надо олапачивать несколько UART и крутить несколько ПИД регуляторов. Дергаться за каждым символом в прерывание не хочется, но и определить размер пачки символов нет возможности.

Хочется настроить DMA на прием данных из UART в какой-то буфер, но так чтобы оно качало данные куда-то а я их оттуда забирал время от времени. То есть если есть время забирал каждый байт, а нет пусть там немного накопиться вычитаю их в следующий проход. Есть такой режим ДМА в stm? Чтобы он по кругу какую-то область памяти писал, и всегда можно было понять до куда свежие данные?

Может кто уже делал такой велосипед?

Cube.

Вот тут было.

Там есть такая настройка DMA? или настроить уарт уже считается достаточным номером?


Ага спасибо, примерно такое и искал

блин надо было в поиске писать UART+DMA ))) а я через пробел искал)

Там галочки в нужные места нужно поставить. А потом найти правильную подпрограмму этого самого HAL-драйвера.

Ну так UART+DMA ничем по сути от фифы не отличается, но гораздо гибче.
Я тоже такую шнягу писал, для обмена с компом с минимальным участиям собственно процессора МК (протокол запрос-ответ).
Если интересно, могу дать ссылку на репозиторий (проект опенсорсный, хоть пока в начальной стадии реализации).

Конечно интересно, давайте ссылку.

Присоединяюсь, интересно поглядеть.

Если можно до исходников пояснить в 2 словах. Ваш протокол, надеюсь, не предполагает фиксированную длину запросов и ответов?

Описание протокола здесь:
https://docs.google.com/document/d/1oHtMBnZ...dit?usp=sharing
Если в двух словах, пакеты переменной длины, заголовок 3 байта, данные до 16 байт, 1 байт контрольная сумма (CRC8).

Дерево исходников здесь:
https://code.google.com/p/iwattnick/source/...se/#svn%2Ftrunk
Коментарии местами на русском, местами на инглиш, в зависимости от ожидаемой ширины аудитории .

Несколько коментариев по поводу организации дерева исходников: библиотеки в каталоге libs/, приложения в каталоге apps/, тестовые проги в каталоге tests/, публичный интерфейс библиотек в каталоге include/, система сборки (использует GNU Make и arm-none-eabi-gcc) в каталоге tibs/, утилиты, использующиеся во время сборки в каталоге tools/.
В каждом перечисленном подкаталоге создаётся подкаталог по имени модуля (например, библиотека gears в libs/gears/, приложение iwacon в подкаталоге apps/iwacon, публичный интерфейс библиотеки yagl в каталоге include/yagl и так далее).

Для каждой целевой аппаратной платформы создаётся отдельный файл include/hardware-xxxx.h, в котором описано на каких ногах чего висит. У меня пока всё отрабатывается на STM32VLdiscovery. Название этого файла надо присвоить макросу HARDWARE_H (в командной строке компилятора), в коде стоит просто #include HARDWARE_H.

Библиотека с реализацией протокола (режим single-master, режим multi-master пока теоретический):
https://code.google.com/p/iwattnick/source/...2Flibs%2Fmudbus
Публичный интерфейс библиотеки:
https://code.google.com/p/iwattnick/source/...nclude%2Fmudbus

Библиотеку старался писать аппаратно-независимо, поэтому всё что касается STM32 находится в подкаталоге stm32/.
Основная логика по приёму и посылке - в файлах send.c и recv.c соответственно.
Основная жесть в файле include/mudbus/stm32/drvgen.h. Этот файл включается из основного кода, предварительно макросами задаются номер USART'а, плюс из hardware*.h используются доп. макросы типа какой канал DMA прикреплён к этому USART и т.п.

Тестовое приложение для библиотеки в каталоге tests/tmudbus/.
Приложение на Питоне для общения с устройством через USB-UART в подкаталоге apps/iwacon/.

Низкоуровневая работа с DMA и отчасти USART реализована в библиотеке gears:
https://code.google.com/p/iwattnick/source/...2Fgears%2Fstm32
(в некотором смысле аналог Standard Peripherials Library, от неё меня тошнит).

Ещё из интересного можно посмотреть библиотеку YAGL (Yet Another Graphics Library). Она поддерживает работу с графическими LCD дисплеями, на текущий момент только одного типа - на контроллере ST7567, но достаточно легко добавить поддержку других типов (к тому же они все похожи друг на друга вплоть до кодов команд). Вся работа ведётся с фреймбуффером (1 килобайт для Ч/Б 128x64), периодически буффер выкидывается на экран через SPI/DMA. Трансфер охренительно быстрый, можно обновлять экран более 500 раз в секунду почти не напрягая ЦП, и это при том что я постеснялся выставлять делитель SPI /2, поставил пока /4 - конкретно мой дисплей тянет /2, но мало ли что...

Сделал такой велосипед: Завел DMA RX в циклическом режиме, по IDLE, выделил основной буфер например, например 1 кб, Он будет перезаписываться по кольцу (такая работа DMA). Выделил массив указателей, например 10 штук, которые будут указывать на адреса посылок в основном буфере. Когда срабатывает прерывание IDLE, я записываю адрес начала текущей посылки, которая находится в основном буфере. Таким образом возможно хранить несколько посылок различной длины в одном буфере, а в массиве хранить указатели на их адреса.

Недостаток такого метода является, что при чтении каждого байта посылки нужно проверять не вышел ли за границы основного буфера, т.к. он кольцевой.
Достоинство, что можно сохранить несколько посылок, если вдруг их не успеваешь обработать и не нужно включать, выключать DMA RX, DMA получается всегда включён.

Такое работает на F1 и F4, на др. сериях не пробовал.

Почему решился на такой велосипед, т.к. ловился на не приятном моменте, что дёргая выкл. DMA после принятия посылки
обработал, потом вкл. DMA, DMA не всегда включалось, бывало такое после суток работы например. Но на тот момент, я может не всё изучил и делал, что то не так. Но в таком способе можно работать и на запрос ответ и в асинхронном приёме/передаче данных.
Модбас протокол не использовал.