С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 Передача каждого вида данных начинается со старшего бита. При передаче
многобайтных параметров порядок следования байт от младшего к старшему."

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

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

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

При приёме байта можно не только складывать в буфер, но и принимать решение что с ним делать. Тогда строка 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 разговаривают, но как решается проблема разности протоколов? Ведь если один передает, другие это слышат, и надо чтобы то что слышат не вызвало ошибок, как то это должно решаться...