Форум программистов, компьютерный форум, киберфорум
Наши страницы
Микроконтроллеры ARM, Cortex, STM32
Войти
Регистрация
Восстановить пароль
 
Рейтинг 4.89/38: Рейтинг темы: голосов - 38, средняя оценка - 4.89
TomityWotf
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 553
1

Подскажите по USART IDLE (РЕШЕНО)

10.04.2015, 19:55. Просмотров 7758. Ответов 12
Метки нет (Все метки)

Имеется GPS приемник, подключенный к USORT STM32T151. Прием данных реализован через кольцевой буфер DMA. Поскольку размер каждой посылки от приемника - величина непостоянная, то окончание посылки ловил через таймаут по таймеру (если с предыдущего срабатывания количество принятых из USORT данных не изменилось, то это конец посылки). Для этих же целей раньше пробовал прерывание USORT IDLE, но получалась всякая фигня, не помню уже подробностей. Сейчас решил попробовать еще раз.
На скорости 9600 все работает замечательно. IDLE четко ловится по окончании посылки из нескольких текстовых строчек. Решил увеличить скорость до максимума. Шлю приемнику команду перейти на скорость 115200 и переключаю USORT проца на такую же скорость. И вот тут начинается веселье. Первая посылка приходит полностью, дальше IDLE начинает срабатывать через каждые принятые 16 байт и по окончанию посылки. Хотя интервал в 16 байт не всегда такой, иногда бывает больше.
Пробовал перед изменением скорости USORT выключать USORT receiver (бит USORT_CR1_RE) - не помогло. Экспериментировал со скоростями - 9600..38400 нормально, на 57600 и 115200 IDLE определяется неверно.
На любых скоростях байты принимаются идеально и без ошибок. Насколько я понимаю, IDLE - это просто подряд идущие единички, т.е. линия находится в состоянии High в пределах одного фрейма. Почему колбасит IDLE? Подскажите, куда копать?
Подозреваю, что я либо что-то не учел в настройках USORT, либо чего-то не понимаю.
0
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
10.04.2015, 19:55
Ответы с готовыми решениями:

STM32F103 USART+DMA не выходит из прерывания Idle
Настроил получение данных через USORT с использованием DMA. RCC->APB1ENR |= RCC_APB1ENR_USORT2EN; ...

[РЕШЕНО] Проблемы с инициализацией USART
Доброго времени суток всем. Столкнулся с совсем простой проблемой, но никак не пойму что же не...

[РЕШЕНО] STM32F30x USART Irq
Добрый день! Перешёл с STM32F4 на F3. Обработка прерываний USORT Irq отказалась напрочь работать....

[решено]usart на stm32f4-discovery
портирую rtems на сабжевую платку. накидал драйвер pottyng усарта, консолька работает, prymtf в...

[Решено]Непонятная работа USART в STM32F105
Привет всем. Столкнулся со странной проблемой с UART на STM32F105RCT6. Приём работает вроде...

12
ovtomiru
0 / 0 / 0
Регистрация: 03.11.2014
Сообщений: 153
10.04.2015, 20:25 2
Не совет, а так - мысли от себя. Нецелесообразно применять DMA, когда заранее неизвестен размер пакета приходящих данных. В случае непрерывного потока входных данных - DMA эффективен. В случае, если размер "посылки" заранее неизвестен - эффективнее обрабатывать через обычные прерывания. Вы же создаете дополнительное звено "нет данных", т.е. сначала создали проблему (пауза в DMA), а потом с ней боретесь ... ИМХО
0
TomityWotf
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 553
10.04.2015, 21:30 3
Дергатся в прерывание на каждый символ посылки, которая порой до килобайта до ходит? И так каждую секунду... не нравится мне такое решение. Проц спит или занимается другими делами, а данные из UART посредством DMA заливаются в память. Ну и, когда сработало IDLE, обрабатывается весь принятый пакет.

Просто уж очень странное поведение прерывания IDLE на высоких скоростях, хотя 115200 для данного проца далеко не пограничное значение - он у меня отлично принимал/передавал данные на 1382400bps. Почему IDLE начинает срабатывать каждые 16 байт? Не спроста же эта цифирь взялась...

Update: пробовал играться с настройками oversampling и onebit, разницы никакой. Ошибок moysi, framing и overrun не наблюдается. Пробовал инциализировать порт без перестроек скорости, сразу на 115200, ничего не изменилось.
0
itysiy
0 / 0 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
10.04.2015, 22:26 4
Я использую DMA + IDLE для пакетов переменной длины. У меня все работает хорошо на скоростях до 2 мегабод. Выше не пробовал. Может GPS приемник вам с паузами шлет данные, на которые и срабатывает IDLE. Посмотрите осциллографом или анализатором.
0
TomityWotf
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 553
11.04.2015, 00:26 5
itysiy, спасибо за очередной пинок в нужном направлении :)
Дело в том, что подключал другой приемник и имел одинаковое поведение, потому как-то не догадался... Сдул пыль со своей старой STM32VLDISCOVERY с F103 процом, накидал прогу, чтобы слала в порт NMEA мессаги, прикидываясь GPS приемником. Подключил к своей плате вместо GPS и все заработало как часы, даже на 1.5Мбод. IDLE ловятся только там, где они должны быть.

Похоже на то, что приемник тупит с отправкой. Отсюда и нормальный приход первых двух посылок (только стартанул, ничем не занят, потому не тупит). И IDLE через четкие интервалы в 16 байт: видать у него внутри буфер на 16 байт и на высоких скоростях паузы для его заполнения хватает, чтобы STM поймал IDLE. Как осциллограф появится, обязательно посмотрю, что на линии. А вот почему у двух разных GPS приемников одинаковое поведение, вопрос интересный, общего у них только одно: оба на MTK чипсете (MT3339 и MT3329).
0
Vottdimor
0 / 0 / 0
Регистрация: 23.01.2010
Сообщений: 261
11.04.2015, 12:53 6
Вопросик TomityWotf, а зачем такие сложности?
Ведь NMEA0183 предложения ловятся без гемора по признакам начала $ и окончании 0x0d 0x0a.
У меня без проблем работает на скоростях до 115200 (больше GPS приёмник не выдаёт) по вышеизложенному принципу, сбоев в приёме нет. Строку в буфер в обработчике прерывания накопил, маякнул парсеру, и может накапливаться следующее предложение, пока парсер неспешно разберёт сообщение.
0
ptiryks
0 / 0 / 0
Регистрация: 25.09.2014
Сообщений: 201
11.04.2015, 13:58 7
нет там никаких сложностей, настраивается дма и усарт, прерывания на DMA_TC и USORT_IDLE, первое для предотвращения переполнения, второе для отлова пакетов, процу не нужно отвлекаться кучей прерываний на каждый байтик, срабатывает только на последний, конец пакета, да и его обработка может быть отложена, когда процу надо будет, сам обработает, реализации можно сделать разные, под разные задачи, и кольцо и простой буфер
0
itysiy
0 / 0 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
11.04.2015, 18:51 8
Цитата Сообщение от ptiryks
нет там никаких сложностей, настраивается дма и усарт, прерывания на DMA_TC и USORT_IDLE, первое для предотвращения переполнения, второе для отлова пакетов, процу не нужно отвлекаться кучей прерываний на каждый байтик, срабатывает только на последний, конец пакета, да и его обработка может быть отложена, когда процу надо будет, сам обработает, реализации можно сделать разные, под разные задачи, и кольцо и простой буфер
а да, сложностей вообще нет, и решение очень простое. До тех пор пока передатчик не начинает тупить и не втыкать IDLE туда, куда не нужно. Если передатчик собственное устройство и можно его контролировать, то все хорошо.

2TomityWotf, а я почти на 100% уверен, что там паузы в середине пакетов, и тогда от работы по прерываниям не уйти. Да и не так уж много ресурсов это отнимает, времени еще много останется)
0
TomityWotf
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 553
11.04.2015, 19:12 9
Цитата Сообщение от Vottdymor
Вопросик TomityWotf, а зачем такие сложности?
Для того, чтобы пакет от приемника принимался с минимальным вниманием к процессу, так сказать максимально "в фоне". Ловить начало по $ и окончание \r\n это да, можно, но как тогда определять конец посылки? Что бы избежать ситуации, несколько строк принадлежат одной посылке, а несколько строк - другой. И не вижу ничего сложного. DMA с кольцевым буфером (эдакий FIFO для USORT), два прерывания HT и TC, которые из FIFO кидают половинку буфера в основной буфер с данными GPS (только TC проще, но надо успеть скопировать весь буфер, пока не пришел следующий символ, иначе полезут overrunы). И прерывание USORT IDLE, которое докидывает принятый остаток и ставит флаг, что посылка принята и можно парсить. А вот парсить уже можно когда угодно.

Цитата Сообщение от itysiy
а я почти на 100% уверен, что там паузы в середине пакетов, и тогда от работы по прерываниям не уйти.
Я уже тоже в этом уверен. А работать по прерываниям не нравится. У девайса батарейное питание, надо экономить, DMA и проц в режиме сна с несколькими пробуждениями для копирования данных из FIFO будет поэкономней, чем просыпаться по приему каждого символа. И таки вопрос: а как при приеме на прерываниях понять, что посылка пришла вся?

Если захочется максимальных скоростей, есть вариант вернуться к первоначальному решению с отслеживанием таймаута по таймеру. Хотя мне он не нравится, IDLE изящней выглядит. Сейчас сделал скорость 38400bps, работает четко, вполне сойдет.
0
itysiy
0 / 0 / 0
Регистрация: 18.01.2012
Сообщений: 1,418
11.04.2015, 20:23 10
Цитата Сообщение от TomityWotf
И таки вопрос: а как при приеме на прерываниях понять, что посылка пришла вся?
ну можно ловить окончание \r\n и затем считать что приняли весь пакет.
0
TomityWotf
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 553
11.04.2015, 21:12 11
Цитата Сообщение от itysiy
ну можно ловить окончание \r\n и затем считать что приняли весь пакет.
Это будет одна NMEA строчка, а как понять, что пришел весь пакет (набор строчек, что выдает приемник за один цикл)?
Например, в одном наборе $GPGSV может быть несколько штук и парсить их надо сразу, иначе в следующей выдаче они могут поменяться.
0
Vottdimor
0 / 0 / 0
Регистрация: 23.01.2010
Сообщений: 261
14.04.2015, 10:02 12
Цитата Сообщение от TomityWotf
Это будет одна NMEA строчка, а как понять, что пришел весь пакет (набор строчек, что выдает приемник за один цикл)?
Например, в одном наборе $GPGSV может быть несколько штук и парсить их надо сразу, иначе в следующей выдаче они могут поменяться.
В парсере GSV ставить флаг, первое ли предложение из нескольких принято, и парсить пока не прмется последнее. Парсится по одному предложению на скоростях до 115200 проблем никогда не наблюдал. Были проблемы на низких скоростях - 9600, когда просто физически на такой скорости не принимается вся инфа, но это уже проблема передатчика, так как теряются некоторые предложения.
0
TomityWotf
0 / 0 / 0
Регистрация: 07.02.2106
Сообщений: 553
15.04.2015, 01:46 13
Посмотрел на осциллографе линию UART - действительно после каждых 16 байт следует пауза фиксированной величины. На скорости 38400 она довольно заметна, но ее уже не хватает для срабатывания IDLE. Вот такую каку подкинул приемник. Спасибо itysiy еще раз за дельную подсказку :)

Цитата Сообщение от Vottdymor
Были проблемы на низких скоростях - 9600, когда просто физически на такой скорости не принимается вся инфа
Да, вот поэтому я и хотел увеличить скорость приемника, т.к. порой его пакеты превышали килобайт (если включить всю выводимую информацию) и 9600 уже не хватало, чтобы прокачать пакет за секунду. На 38400 даже самый большой пакет успеет дойти полностью, так что все работает, как задумано.
0
15.04.2015, 01:46
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
15.04.2015, 01:46

[РЕШЕНО] как получить строку через USART на сам МК?
Не могу найти как правильно получить с компьютера строку по USORT. Через прерывание могу получить...

Подскажите можно ли использовать USART и SPI интерфейсы одновременно?
скажем так: short k=0,g=0; main() { функция инициализации USORT; функция инициализации SPI;...

передача данных с 2 портов can и 1 usart в usart
Доброго времени суток форумчане! Пытаюсь написать код для stm32f4disko с помощью которого можно...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
13
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Рейтинг@Mail.ru