STM32F UART + DMA на чтение, Как реализовать чтение через DMA для потока данных? Опции

[krdmitry]

Всем привет.

Можно ли на STM32F сделать чтение данных из UART в программный буфер FIFO через DMA? Размер принимаемых данных - произвольный, от 1 байта, поток от модема. Киньте примером пожалуйста, если есть опыт подобной реализации.

[KnightIgor]

Можно ли на STM32F сделать чтение данных из UART в программный буфер FIFO через DMA? Размер принимаемых данных - произвольный, от 1 байта, поток от модема. Киньте примером пожалуйста, если есть опыт подобной реализации.

Можно: см. Circular Mode в мануале. Однако какой-то внешний процесс должен следить за количеством уже принятых байтов, чтобы выбирать их, и вести для этого собственный указатель выборки на область FIFO. Канал DMA содержит (циклический) счетчик записи. По соотношению указателя выборки и счетчика записи можно судить о мере заполнения FIFO. Для проталкивания процесса можно воспользоваться прерыванием от половинного заполнения буфера. На случай, если такое прерывание не сработает, т.к. пришло недостаточно данных, выборку можно еще иницировать неким периодическим процессом.

[krdmitry]

Можно: см. Circular Mode в мануале. Однако какой-то внешний процесс должен следить за количеством уже принятых байтов, чтобы выбирать их, и вести для этого собственный указатель выборки на область FIFO. Канал DMA содержит (циклический) счетчик записи. По соотношению указателя выборки и счетчика записи можно судить о мере заполнения FIFO. Для проталкивания процесса можно воспользоваться прерыванием от половинного заполнения буфера. На случай, если такое прерывание не сработает, т.к. пришло недостаточно данных, выборку можно еще иницировать неким периодическим процессом.

Игорь, в теории так оно и есть. На практике несколько сложнее. Есть RTOS, собственно от ее наличия "ноги и растут". Изначально и планировал сделать, как вы описали, а проверять пришедшие одинокие байты можно в тике от внешнего/системного таймера - если заполнение меньше половины. Хотелось бы увидеть практическую реализацию, т.к. возможно есть подводные камни.

Кстати, по поводу circular mode тоже есть вопрос.
1. Предположим, у нас есть FIFO на 16 байт. При инициализации мы установили размер передаваемых данных = 16 и старт приема на 0-й элемент буфера.
2. Внешний девайс вывалил 9 байт. DMA их принял и выставил прерывание.
3. Основная задача вычитала 4 байта и "задумалась". В это время внешний девайс присылает еще 10 байт. Как быть в этом случае? Куда они запишутся?

[KnightIgor]

Игорь, в теории так оно и есть. На практике несколько сложнее. Есть RTOS, собственно от ее наличия "ноги и растут". Изначально и планировал сделать, как вы описали, а проверять пришедшие одинокие байты можно в тике от внешнего/системного таймера - если заполнение меньше половины. Хотелось бы увидеть практическую реализацию, т.к. возможно есть подводные камни.

Про RTOS - снизошло откровение! Ну, практической готовой реализации у меня нет, т.к. не приходилось что-то решать именно в таком виде. У меня есть прием от UART по принципу FIFO, но в нем всё работает исключительно по прерыванию. Я, честно говоря, не вижу острой необходимости "заморачивать" DMA на буфер длиной 16 байт. Вообще, DMA был бы интересен, если прием велся бы быстрыми большими порциями (хорошее слово bursts), между которыми лежала бы определенная пауза. В этом случае действительно DMA разгрузил бы процессор.

Кстати, по поводу circular mode тоже есть вопрос.
1. Предположим, у нас есть FIFO на 16 байт. При инициализации мы установили размер передаваемых данных = 16 и старт приема на 0-й элемент буфера.
2. Внешний девайс вывалил 9 байт. DMA их принял и выставил прерывание.
3. Основная задача вычитала 4 байта и "задумалась". В это время внешний девайс присылает еще 10 байт. Как быть в этом случае? Куда они запишутся?

DMA пишет в буфер FIFO по кольцу.
В примере DMA принял в общей сложности 19 байт. 4 байта успели "выбраться" целыми и невредимыми, а на бывших их местах с индексами [0], [1] и [2] будут сидеть байты с 17-го по 19-й, при этом байты с 5-го по 16-й будут по индексам с [4] по [15], а FIFO будет иметь место еще для одного байта по индексу [3], и т.д. По-моему, так! (с) Винни Пух.

Сообщение отредактировал KnightIgor - Jul 15 2012, 09:23

[krdmitry]

Про RTOS - снизошло откровение! Ну, практической готовой реализации у меня нет, т.к. не приходилось что-то решать именно в таком виде. У меня есть прием от UART по принципу FIFO, но в нем всё работает исключительно по прерыванию. Я, честно говоря, не вижу острой необходимости "заморачивать" DMA на буфер длиной 16 байт. Вообще, DMA был бы интересен, если прием велся бы быстрыми большими порциями (хорошее слово bursts), между которыми лежала бы определенная пауза. В этом случае действительно DMA разгрузил бы процессор.

DMA пишет в буфер FIFO по кольцу.
В примере DMA принял в общей сложности 19 байт. 4 байта успели "выбраться" целыми и невредимыми, а на бывших их местах с индексами [0], [1] и [2] будут сидеть байты с 17-го по 19-й, при этом байты с 5-го по 16-й будут по индексам с [4] по [15], а FIFO будет иметь место еще для одного байта по индексу [3], и т.д. По-моему, так! (с) Винни Пух.

Да, сейчас сделано так же: UART через прерывание. Работают одновременно 3 UART-а.
Столкнулся с хитростью в ОС:
1. Изначально при чтении из FIFO каждого уарта запрещалось прерывание именно для него. Проблема могла возникнуть в случае, если в момент блокировки FIFO (соответственно и запрета прерывания от UART) возникало переключение контекста, и данные терялись.
2. Сделал вход в критическую секцию при чтении FIFO - проблема до конца не решилась, т.к. запрет переключения контекста в моей ОС сделан как запрет всех прерываний. В результате иногда поток данных с одного UARTа может привести к потере пары байт с другого.

Вопрос: как обычно реализуется работа с UART через прерывания в ОС?

Кстати, у STM нашлась аппнота по теме: http://www.st.com/internet/com/TECHNICAL_R.../CD00256689.pdf

Здесь прерывания на заполнение половины буфера и буфера целиком очень пригодянтся. Таким образом, по таймеру надо вынимать данные из буферов и скалдывать в очередь, при этом блокировать прерывания от ДМА. А при прерываниях по половинкам буферов невычитанные остатки в экстренном порядке выкидывать в очередь.
При этом для таких задач как пассивная обработка NMEA GPS вычитка по таймеру чаще всего вообще не будет нужна.
Я, например обрабатываю GPS приемник по прерыванию и там в секунду около 500 байт вываливается, проц работает на 24МГц и соответственно только на вход и выход из прерывания тратится 500мкс + отправка в очередь - как минимум несколько (может быть десятков даже) мсек в сек тратится на эту хрень...
Что то я вдохновился на написание такого драйвера для своих задач.

Отличная идея
Поделитесь реализацией драйвера с обществом?

[KnightIgor]

Да, сейчас сделано так же: UART через прерывание. Работают одновременно 3 UART-а.
...
Вопрос: как обычно реализуется работа с UART через прерывания в ОС?

Поделюсь одним "болтом" на хитрую "гайку" организации FIFO и работы по прерыванию применительно к приему: во время выборки из FIFO запрещать прерывания... не надо!
Предлагаю (проверенный) алгоритм:

1. Заводится бинарный флаг критической секции.
2. В обработчике прерывания по приему проверяется:
2.1. есть ли место в FIFO положить туда принятый байт. Важно - байт еще НЕ считан с регистра DR!
2.2. не взведен ли флаг критической секции.

Только если эти оба условия выполняются - место есть, флаг не взведен, происходит считывание DR, запись его в FIFO и коррекция счетчика и указателя записи.
Если хотя бы ОДНО из условий выполнилось - нет места или флаг-таки взведён, происходит ЗАПРЕТ своего прерывания и выход из него.

3. Основной процесс выборки с определенной периодичностью проверяет, нет ли в FIFO чем поживиться.
Если да, то:
3.1. установить флаг критической секции.
3.2. выбрать FIFO (или часть его), скорректировать счетчик и указатель выборки.
3.3. сбросить флаг критической секции.
3.4. (Пере)разрешить прерывание от источника (всегда).

Что получается:
- если прерывание возникло вне критической секции, то счетчик и указатель будут модифицированы монопольно в прерывании (если место в FIFO было).
- если прерывание возникло уже внутри критической секции, то прерывание лишь запретит себя само и вернет управление, а процесс выборки будет изменять счетчик и указатель монопольно; как только критическая секция будет пройдена, прерывание будет (пере)разрешено (я пишу "пере-", имея ввиду, что установка уже установленного разрешения прерывания ничего не меняет), и если DR еще не был считан, то тут же возникнет прерывание - см. 2).

Можно спросить, а что будет, если пока прерывание было запрещено, пришел еще один байт? Будет ж...па предыдущему байту. Но весь расклад будет говорить лишь о том, что система не достаточно производительна, либо неудачно распределены приоритеты прерываний.

Для случая RTOS также нужно обрамить выборку критической секцией средствами RTOS, то есть:
- начать RTOS-секцию
- установить флаг
- сделать дело
- сбросить флаг
- закрыть RTOS-секцию

Сообщение отредактировал KnightIgor - Jul 16 2012, 08:16