STM32 UART DMA, как организовать прием по уму Опции

[Golikov A.]

Всем привет!

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

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

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

[Golikov A.]

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

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

[anpaza]

Описание протокола здесь:
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, но мало ли что...

Сообщение отредактировал anpaza - Jan 10 2015, 12:11