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

[alexdos]

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

[drum1987]

вы когда байт складываете в буфер попутно проверяйте не символ ли это переноса строки...если нет то ждете дальше, а если да, то значит вы приняли посылку полностью...можно выставить флаг или сразу обрабатывать принятые данные.

[alexdos]

вы когда байт складываете в буфер попутно проверяйте не символ ли это переноса строки...если нет то ждете дальше, а если да, то значит вы приняли посылку полностью...можно выставить флаг или сразу обрабатывать принятые данные.

Я уже писал, что в общем пакете данных находится несколько NMEA, каждый с которых оканчивается символом переноса строки.

[Сергей Борщ]

Я уже писал, что в общем пакете данных находится несколько NMEA, каждый с которых оканчивается символом переноса строки.

Поставьте себя на место процессора. По какому признаку вы опредлелили бы, что пакет закончился? По паузе? Так и спрашивайте - "есть ли механизм обнаружения пауз в посылке?". Специального механизма отслеживания пауз в UART нет. Да, можно городить на дополнительном таймере.

[alexdos]

Сергей Борщ , спасибо за понятный ответ.
Теперь осталось разобратся что ж за прерывание USART_IT_IDLE. Когда оно происходит.

Вам код дать?

Спасибо за предложения кода. Но он мне не нужен. На PIC18F46J50, у меня все реализовано, и работает в сотнях устройств без нареканий. Да, я принудительно оключил ("заглушил") передачу ненужных мне данных с GPS. Да, я знаю про кольцевые буферы, про парсеры и тому подобное. Я следую логике, что приняв весь пакет от GPS за времмя приблизительно 17 милиСек (не более 200 байт) у меня будет времени разобратся с этим пакетом 1 - 0.017 = 0.983 Сек. В случае же к примеру использования методики отлавливания конца строки, и если буфер не достаточной величины (или указатель обнуляется) , мне желательно вложится в время кратное приёму одного байта, для обработки принятого NMEI, а это составляет приблизительно 86 микроСек. Вот поэтому я и хочу принять весь пакет, чтоб потом неспешно, его разобрать.

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

[Сергей Борщ]

Теперь осталось разобратся что ж за прерывание USART_IT_IDLE. Когда оно происходит.

Оно возникает если с момента последнего стопа не возникло нового старта за время 10 битовых интервалов. Вы уверены, что приемник не сделает такую паузу в середине пакета? Я бы не стал на это закладываться. Вы можете, конечно, идти своим путем. Но если в спецификации протокола сказано, что признаком конца посылки является символ перевода строки, я бы не стал придумывать какие-то еще косвенные никем не гарантированные признаки. Откуда вы взяли 86 мкс? У вас буфер. Большой. Пока вы выгребаете-разбираете из него пакет с одной стороны, прерывание складывает в него новые байты с другой. И время обработки определяется размером этого буфера. Никаких проблем. Если вы сделаете размер этого буфера таким же, как и в вашем варианте с приемом всего-всего, то и времени на обработку у вас будет не меньше, а даже больше на время передачи этого пакета сообщений - ведь пока приходит очередное сообщение в пакете вы уже можете обрабатывать предыдущее.
Но вы можете идти своим путем.