Всем привет.

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

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

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

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

DMA ничего не знает про программное FIFO, это автомат, раскладывает байты как приказали, вызывает прерывания, если настроили.
По USART обратить на флаг IDLE

На практике, у STM32F10x DMA работают вполне адекватно, описание в даташите "несколько странное".
в одном из устройств интенсивно использую 5 каналов DMA, причем транзакции по некоторым запускаются синхронно, все нормально.

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

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

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

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

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

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

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





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

Есть. Я здесь кидал рабочий пример. (или во freertos ветке).
Смысл простой:
1. ДМА настраивается в режиме кольца
2. Прерывания ДМА - заоплнение буфера и половина буфера.
3. Прерывание УАРТА одно - line IDLE.

Собствено любое прерывание из этих должно разблокировать операцию чтения данных. Данные читаются до тех пор, пока не прочитаны все.

Есть недостаточек - если какие-то данные не прочитались, то они могут быть перезаписаны новыми.

Спасибо.

Поделюсь одним "болтом" на хитрую "гайку" организации 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

krdmitry, поясните, а то из референс мануала не вполне ясно:
IDLE прерывание это когда контроллер фиксирует паузы между байтами?

- IDLE прерывание это когда контроллер фиксирует паузы между байтами?

да, более, кажется, 1.5 байта

Похоже, что так. Вопрос, видимо, адресован diwill? В референс-мануале не нашел конкретного ответа, сколько битовых интервалов нужно для генерации прерывания IDLE. Видимо, это что-то из области LIN или smartcard протоколов, но подойдет и под нашу задачу.

ой, да, diwill
krdmitry, спасибо за ответ
Я вот тоже в референсе по-быстрому не нашел ответа.

Как-то сложновато...
Если отказаться от счётчика (а зачем он нужен?) и оперировать только указателями на "голову" и "хвост" буфера, то и флаг не понадобиться, и прерывания можно не трогать, один раз только разрешить при инициализации и всё.