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

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

Судя по приведенной функции у Вас совершенно искаженное представление об USART. Это устройство байтового типа, а "пакетом" для USART является последовательность бит. Как только предопределенный пакет бит принят, USART предоставляет байт для считывания. Боюсь, прежде, чем начать разбирать GPS (NMEA) пакеты, Вам придется основательно изучить принципы буферизируемого приема (и передачи) потока данный через байтное устройство.

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

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

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

Любая NMEA-строка начинается с $ и заканчивается \r\n. Да ещё и контрольную сумму содержит.
Сделайте как это делают везде и повсюду - разделите процесс приёма байтов по UART и складывания их в буффер FIFO и процесс извлечения байт из FIFO UART поиска ключевых символов ($ - начало строки, \r или \n - завершение строки) и последующей обработки NMEA-строк.
На форуме есть примеры организации FIFO и методы работы с ней.
Если нет желания городить FIFO, можете прямо в прерывании отлавливать ключевые символы и по ним определять начало/завершение строки и устанавливать какой-либо флаг что принята полная NMEA-строка.

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

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

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

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

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

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

Вам код дать?

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





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

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

Ну так Вы все знаете. А неполно поставленный вопрос вначале наводил на иную оценку. Извините.


Думаю, при такой постановке вопроса и условии, что токенов мало (остальные отфильтрованы), а период составляет, скажем, 1 секунду, можно пойти по пути определения окончания пачки токенов путем таймаута. USART это вряд ли обеспечит: IDLE срабатывает, если прошло пару битов со времени последнего STOP. Никто, однако, не может гарантировать, что GPS сыплет байтами плотно друг за дружкой. Поэтому об IDLE можете тоже забыть. Остается только внешний таймер, перезапускаемый приемом байта USART и срабатывающий, скажем, после неприема трех-четырех байт - это надо заценить опытно.

Тем не менее, я не понимаю проблемы вложиться с обработкой токена в какие-то жесткие временные рамки: их просто нет, т.к. обработка токена (читай - строки) может происходить, пока принимается другой токен, а это - куча байт, а значит - и времени. То же касается и требуемой памяти: токены не такие уж и длинные (байт 50-60, думаю). Неужели напряг с этим? Вы же в форуме ARM - тут речь о множестве килобайт в микроконтроллерах или мегабайт, кто там с внешней памятью играется....

Думаю все тянется со старого пика, который работает без нареканий.

у вас есть определенное количество действий которое надо совершить с символами. Это занимает сколько-то тактов процессора. И это будет всегда занимать столько тактов (с точностью до оптимизации) не важно как вы будете их обрабатывать, сначала все сложите, а потом проверите, или будете складывать попутно проверяя.

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

Тогда вам надо самим определить критерий прихода всего пакета (его нет в описании протокола и остается только придумать), и реализовать. У уарта есть флаги что начался прием, и прием закончен. Можете мерить паузу между ними. Но будет ли это все дальше работать без нареканий никто вам не скажет...


П.С, Если уж быть совсем взрослыми мальчиками, то я бы подключил ДМА контроллер, который бы пихал уарт символы в буфер заведомо большей длины, так процессор вообще не тратит ресурсов на сбор сообщения. Проблема лишь в критерии когда проверять буфер...

Ну так что я в прерывании складываю, что ДМА заставлю. Упор опять же в одно "критерии когда проверять буфер". В общем тенденции я понял. И понял главное, в UART надёжного механизма определения того что данные прекратились приходить нет.

А это зависит от самих данных, соглашения об их организации.
Это в народе кличут "протоколом обмена", в котором строго оговаривается разделение данных.
Вот Вам и объясняют, что в NMEA имеет строго определенный "маркер начала" и "маркер конца".

P.S. То что разделение по времени работает на сотнях устройств c PICами, не является доказательством
правильной реализации. Есть ли в том, PIcовском, драйвере диагностика того сколько было "ошибочных" пакетов?
В чем заключается "ошибочность" пакета?

СRC пакетов проверяется, в случае несовпадения CRC все NMEA по этой точке бракуются. Длительные тесты с частотой точек раз в 1 сек, пропусков не давали , можно делать вывод что все в порядке.

можно делать выводы что вы их не нашли.
Я больше скажу с вашим подходом нет ни одного протокола в мире в котором есть или может быть надежный механизм определения конца прихода данных))

П.С.
- Вот цена 1 руб 15 копеек, хорошо бы чтобы была такая монета 1 руб 15 копеек
- Это очень неудобно
- Почему?
- но вот встретите вы цену 1 руб 45 копеек, что вы будете делать?
- Достану купюру 1 руб 45 копеек.

Это я к тому что странно в Универсальном Асинхронном Приемнике Передатчике требовать наличие спец сигнала определяющего что именно ваш приемник прислал полный пакет данных...

Хых, RS-485 Modbus

но только потому что на каждое сообщение должен быть ответ....

угу, а если устройства нет на шине? кто ответит?
Другое дело, что с GPS-приемником не проходит вариант с тайм-аутом, поскольку не регламентирован в отличие от Modbus.

в этом и фишка, что если устройство ответит то может быть только 1 сообщение в пакете, если не ответит то это 0 сообщений в пакете, но в любом случае по таймауту пакет закончен (в терминах топик стартера)

Причем мод бас бывает РТУ и АСКИ, и в аски символ конца сообщения другой, но опять же в силу максимальной длины пакета = 1 сообщение таймауты помогут.

Любой другой протокол работающий не по запрос- один единственный ответ в терминах топик стартера не имеет надежного механизма определения конца пакета... Причем я так понимаю даже те в которых есть спец сообщение о конце пакета, тоже, ибо разбор и анализ сообщения топик стартер не желает начать до получения надежного признака конца пакета...

Вообще то есть. Break бит называется.

Да готов я разбор и аналазил в любое время делать, лиш бы это не занимало много времени и ресурсов. Мне помимо анализа еще уму дел нужно сделать. Просто предполагал что получив весь пакет данных, я буду иметь уже готовое к анализу, а не части анализируемого. Принять байт и положить в буфер дело не хитрое, и не требует много ресурсов. Ну да ладно, с GPS, там по сути все описано и на крайний случай есть конец строки.
Как быть мне тогда еще с потоком от GPRS модуля, в которого данные идут 0x0D 0x0A DATA 0x0D 0x0A в 98% ответов, 1.5% начального 0x0D 0x0A нет, а в входящих данных которые можно послать на него с сервера нет ничего вообще, что послал то и пришло. (щас сразу шквал пойдёт, что должен позаботится о том что отсылает сервер, но как говорится, что если может прийти без ничего, значит оно обезательно придёт)
Как быть еще с групой датчиков которые делают стороние фирмы, в которых четких правил окончания ответа нет.
"4.3.5 Скорость передачи данных 19200 Бод.
4.3.6 Для передачи байтов пакета используется стандартный UART настроенный на
скорость 19200, с одним стоп битом.
4.3.7 Передача каждого вида данных начинается со старшего бита. При передаче
многобайтных параметров порядок следования байт от младшего к старшему."

и вот как тут прикажете быть? есть четкое задание, работать с этим оборудованием. Вот и был выбран мною способ определения окончания приёма данных по таймауту.

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

При приёме байта можно не только складывать в буфер, но и принимать решение что с ним делать. Тогда строка nmea будет разобрана к моменту приёма символа перевода строки.


Данные, что у вас по одному порту приходят...


В чём проблема, работать с таким оборудованием?

Не тут что-то не так.
Любой протокол на базе УАРТ должен иметь четко обозначенный признак конца сообщения.
Это может быть
1. количество (все сообщения имеют одну длинну)
1.2 внутри сообщения передается параметр с длинной сообщения в четно обозначенном месте

2. Конечные символы, четко определяется какой символ заканчивает сообщение

3. Временные паузы ( четко определяется что если нет передачи заданное время - это конец)

Также хорошим тоном является добавление контрольных сумм

Иначе нет никакой возможности разбирать и работать с такими сообщениями. Потому что любая помеха на линии, пропущенный байт или что-то еще может сойти за сообщение и наделать много бед.

Далее надо понимать что УАРТ строго говоря это соединение точка - точка, нельзя его подсоединять одной линией к нескольким устройствам. Это позволяют делать надстройки над уартом, типа РС485, РС422 но они четко определяют как происходить адресация на уровне протокола. И естественно нельзя на одну линию вешать устройства с несколькими протоколами, иначе сообщения от одного могут воздействовать на другие и вызывать ошибки.

Обычно алгоритм действий такой

1. Сбор по символьно сообщения (пихание байт в буфер) и анализ признаков конца(начала) сообщения (либо проверка что пришедший байт стоповый (стартовый), либо запуск таймера на таймаут, либо счетчик числа принятых байт). Это делается с каждым пришедшим байтом, но тут нет никаких вычислений просто 1-2 действия, поверки.

2. По найденному признаку конца сообщения (именно сообщения а не пакета, и признак описанный в протоколе формата данных, а не придуманный) делается пред анализ: проверка адресации если такая есть в протоколе, проверка контрольных сумм, и так далее... Ошибочные сообщения отбрасываются или генерят коды ошибок в зависимости от протокола. Это делается 1 раз на каждое собранное сообщение, это уже требует больше времени, но все равно это сделать необходимо, потому не надо жалеть о потраченных тактах.

3. Разбор, анализ, реакция на сообщение. Это делается 1 раз на каждое годное сообщение. Это самый долгий процесс, но он основной и ничего с ним не сделать.

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



главное все описанные действия вы все равно обязаны сделать. Все равно надо проверить сумму, все равно надо проверить критерий конца сообщения в пакете, отобрать сообщение, все равно надо будет проверить адресацию, и разобрать сообщение. никаких лишних действий алгоритм не делает. ПРосто он делает их в параллель с приемом сообщения и работой прочих функций...

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

P.S. Если совсем по-старинке, то есть четкий признак того, что всё передано, но это только в RS-232C.
Для начала можно почитать тут: http://www.gaw.ru/html.cgi/txt/interface/rs232/index.htm.
Только, думаю что у вашего девайса нет таких сигналов, у передатчика, скорее всего, тоже нет.

разговор ни о чём...

там признак что есть данные для передачи, и признак что есть место для приема. Но строго говоря наличие или отсутствие данных для передачи не означает что все передано или нет. Все же формат определяется протоколом на уровне выше чем определен UARTом или RS232/422/485.


в целом да, просто все нашли возможность потоптать, и увлеклись этим процессом...

Наверное я не так изначально поставил вопрос. Но топтания вокруг да около, дали мне нужный ответ. Все уже чудестным образом работает. Как указал Golikov A.
1. Сбор по символьно сообщения (пихание байт в буфер) и анализ признаков конца(начала) сообщения (либо проверка что пришедший байт стоповый (стартовый), либо запуск таймера на таймаут, либо счетчик числа принятых байт). Это делается с каждым пришедшим байтом, но тут нет никаких вычислений просто 1-2 действия, поверки.
3. Временные паузы ( четко определяется что если нет передачи заданное время - это конец)

После появления признака конца ( Временная пауза), производится разбор полученных данных. Проверка целостности (соответсвию NMEA, CRC этих сообщений.)

"Далее надо понимать что УАРТ строго говоря это соединение точка - точка, нельзя его подсоединять одной линией к нескольким устройствам."
Вы видели как устроена шина MDB в торговых автоматах ? так там можно сказать все соеденено через "монтажное ИЛИ". И все прекрасно уживается, и конец передачи тоже "Временные паузы".
В общем спасибо всем за конструктивную критику.

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

Ну и спросить как же все таки выглядит эта шина, я ее не видел ни разу, я не занимался торговыми автоматами, но мне правда любопытно.
Монтажное или я могу понять, это как в РС485, когда все слушают а 2 разговаривают, но как решается проблема разности протоколов? Ведь если один передает, другие это слышат, и надо чтобы то что слышат не вызвало ошибок, как то это должно решаться...

вот можно почитать.

http://www.autovending.com.ua/mdb_item.php?item=%221%22

весьма познавательно, спасибо. Надо будет где нибудь применить...