UART STM32F100Rxx и определение окончание приема "пакета" данных Опции

[alexdos]

По какому признаку можно определить что "пакет" данных в буфер по прерыванию принят. Данные идут от GPS приёмника, их количество не фиксировано. Тоесть может быть к примеру 146 байт, а может быть 152 байта.
Пробую через (USART_GetITStatus(USART2,USART_IT_IDLE) != RESET), но неверно определяет окончание приёма, данные не приняты все, а мне уже симафорит что принято.
Или по старинке, использовать таймер для определения окончания приёма?

[uriy]

Тоесть может быть к примеру 146 байт, а может быть 152 байта.

Откуда контроллеру знать сколько байт в вашем пакете?
NMEA пакеты заканчиваются символом переноса строки, что вам мешает использовать этот признак?

[alexdos]

"NMEA пакеты заканчиваются символом переноса строки, что вам мешает использовать этот признак?" все верно, но мне нужно принять весь пакет данных отправляемый GPS приемником. Включающий в себя группу пакетов NMEA, каждый с которых оканчивается символом переноса строки. Вырезать каждый NMEA пакет я не хочу, хочу получить всю пачку, при этом потратив минимум ресурсов, а затем спокойно обработать.
KnightIgor Вы бы по сути сказали, а не высказывали предположения о моих познаниях. Чтото типа "так не делают" , а вот так делают. По приходу каждого байта по прерыванию (USART_GetITStatus(USART2,USART_IT_RXNE) != RESET) я этот байт складываю в буфер. Вот и спрашиваю в опытных, какой признак окончания приёма данных (пауза) будет достаточным, чтоб считать что приём данных окончен. Ежели нет достаточного аппаратного признака, тогда буду использовать таймер, который будет следить за наличием достаточной паузы неактивности работы UART после прихода последнего байта, что и будет означать о окончании передачи GPS пакета данных.

[KnightIgor]

KnightIgor Вы бы по сути сказали, а не высказывали предположения о моих познаниях.

NMEA пакеты представляют собой "читабельные" строки, начинающиеся, как уже отвечали, c $ и заканчивающиеся символами возврата каретки и перевода строки. То есть, "классика" ASCII терминалов эры больших компьютеров 70-х - 80-х годов. GPS модуль, выдающий NMEA пакеты, выдает такие строки разного(!) содержания (различные токены) довольно интенсивно: если посмотреть на терминал, ну просто сплошным потоком! Полагаться на какие-либо паузы между пакетами не приходится: даже если они и есть, они могут быть нерегулярны или вариироваться от производителя к производителю. Вывод - разделять пакеты на основе пауз есть совершенно ненадежное дело, об этом нужно забыть.

Представьте себе три процесса: первый процесс "толкается" прерыванием от приема байта от USART и тупо записывает принятый байт в буфер FIFO.

Второй процесс выбирает побайтно из этого FIFO и тупо складывает ОТОБРАЖАЕМЫЕ символы (то есть, только те, что не меньше 0х20) в еще один линейный буфер (строку) друг за другом, пока не наткнется на символ \n. Если это произошло, процесс дополняет содержимое линейной строки конечным нулем (ASCIIZ) и передает ее копию вышестоящему процессу №3 для синтаксического разбора, а сам начинает нанизывание строки сначала.

Третий процесс получает на вход фактически строку NMEA, которую он должен разчленить на данные с помощью, например, sscanf(). Если принятая строка содержит разумные данные (см. форматы различных сообщений и контрольную сумму), процесс выполняет требуемые действия.

GPS модул выплевывает много разных токенов, содержимое которых может пересекаться. Некторые токены могут быть вообще не нужны. Например, меня интересовали в проекте только время и координаты. Я выбрал токен $GPRMC, а остальные заглушил, то есть передал в GPS модуль управляющие команды фильтрации. Кроме того, я уменьшил частоту передачи сообщений с 0.25с до 1с, т.к. мне чаще не нужно, а процессор разгружается.

Вам код дать?

Сообщение отредактировал KnightIgor - Mar 12 2013, 13:21