SIM900. Прием команд от TCP сервера., Как исключить коллизии в порту при приеме внешних команд? Опции

[Иван Плетнев]

Здравствуйте!

Разрабатываю устройство, которое собирает различные данные с датчиков и с периодичностью в одну минуту отправляет их на сервер посредством SIM900. Использую обычный режим AT-команд, не transparent, то есть команда AT+CIPSEND, приходит приглашение ">", отсылаю в порт строку, дожидаюсь SEND OK, всё. В данный момент добился надежной отсылки данных. Встал вопрос приёма команд от сервера. Все в общем, работает, за исключением случая, когда микроконтроллер ждет ответа от SIM900 и в этот момент приходит команда от сервера. Аппаратное управление потоком в этом случае вряд ли подойдет..
Подскажите, пожалуйста, кто как справился с этой проблемой?

[zebrox]

И почему конец сообщения определяется таймаутом?
Почему не использовать последовательность CR LF?

[Иван Плетнев]

И почему конец сообщения определяется таймаутом?
Почему не использовать последовательность CR LF?

Потому что встречаются ответы модема, в которых есть и две последовательности CR LF, и три.

[Alechek]

Потому что встречаются ответы модема, в которых есть и две последовательности CR LF, и три.

Самое первое правило - обрабатывать ВСЕ!!! последовательности от модема.

Второе - последовательность AT команд четко регламетирована (см GSM 07.07 раздел 4).
Заметьте, у всех команд стандарта есть final result code (чего не скажешь творчестве собственных расширений производителей модемов)
Все что между - результат выполения команды.

И еще есть ансинхронные ответы. Могут влезть куда угодно. либо пропускайте их, либо применяйте. НО РАСПОЗНАТЬ их надо!!

[tdocs.su]

Самое первое правило - обрабатывать ВСЕ!!! последовательности от модема.

Второе - последовательность AT команд четко регламетирована (см GSM 07.07 раздел 4).
Заметьте, у всех команд стандарта есть final result code (чего не скажешь творчестве собственных расширений производителей модемов)
Все что между - результат выполения команды.

И еще есть ансинхронные ответы. Могут влезть куда угодно. либо пропускайте их, либо применяйте. НО РАСПОЗНАТЬ их надо!!

Однозначно! Все прочее (кроме автомата) - просто мертвому припарки. Выкрутиться не получится.
Кстати, у оператора case в любом "языковом исполнении" всегда имеется свой else, позволяющий пропустить что-угодно как с распознаванием, так и без, если со стороны пришел некий "невнятный" и не вписывающийся в рамки протокола ответ - команда вместо данных и в таком духе.

[Иван Плетнев]

Однозначно! Все прочее (кроме автомата) - просто мертвому припарки. Выкрутиться не получится.
Кстати, у оператора case в любом "языковом исполнении" всегда имеется свой else, позволяющий пропустить что-угодно как с распознаванием, так и без, если со стороны пришел некий "невнятный" и не вписывающийся в рамки протокола ответ - команда вместо данных и в таком духе.

Немного не понял про else. Что Вы имеете ввиду?

Тоже сначала делал обработку по таймауту.
Все было очень плохо.

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

Кстати, вот что хотел спросить. Если мы выставляем ртс, и за это время в буфере SIM900 накопится, например, три сообщения, то, когда мы отпустим ртс, они вывалятся все разом, без пауз между ними?

Самое первое правило - обрабатывать ВСЕ!!! последовательности от модема.

Второе - последовательность AT команд четко регламетирована (см GSM 07.07 раздел 4).
Заметьте, у всех команд стандарта есть final result code (чего не скажешь творчестве собственных расширений производителей модемов)
Все что между - результат выполения команды.

И еще есть ансинхронные ответы. Могут влезть куда угодно. либо пропускайте их, либо применяйте. НО РАСПОЗНАТЬ их надо!!

Я всё понимаю, и стараюсь учесть все возможные ответы от модема. Но если пытаться определять конец посылки по CR/LF, учитывая то, что CR/LF может быть несколько, например \r\nOK\r\nблаблабла\r\n, то нам как минимум нужно знать, сколько \r\n будет в ответе от модема. Посчитать их, конечно, легко, но если асинхронное сообщение появилось, с ним как быть? Направьте меня в нужную сторону. Вообще, конечно, то, что форматы ответов так разнятся от команды к команде, сильно осложняет их обработку и даже немного раздражает.

Что до меня, то пока особых трудностей с определением конца посылки по таймауту не возникало. Работает достаточно надежно. Кстати, снизил длительность таймаута до 1мс., пока полет нормальный.

Кстати, по поводу собственно сабжа. У меня трудности, описанные в первом посте этой темы возникали в основном из-за ошибки переполнения буфера UART, связанной с отключением прерываний в другом, параллельном процессе. Так что проблема, можно сказать, почти решена. Сейчас тестирую прозрачный режим, обсуждение в соседней теме . Буду рад выслушать Ваши мнения.

Это как раз не страшно. У меня идет работа с голосом (прием звонка, дозвон), SMS (прием и отправка) и GPRS (клиент) , плюс полный набор обслуживающих команд и всего в сумме получается не более 60 вариантов заголовков команд/ответов. Если делать не побуквенное сравнение, а более оптимизированный парсер, то получается быстрое автоматическое определение что пришло. Но с GPRS, да, в непрозрачном режиме приходится выкручиваться, а в прозрачном нет мультисокетов. Как вариант - реализовать режим мультиплексирования (CMUX).
Было бы очень удобно, если бы китайцы добавили аналог +CIPRXGET, но не по незапрашиваемому ответу, а по запросу.

Мне как раз мультисокет и не нужен, мне достаточно одного соединения. Значит ли это, что мне лучше воспользоваться прозрачным режимом?
И второе. Намекните, если можно, про устройство Вашего оптимизированного парсера. Как он работает?

[alexdos]

Я всё понимаю, и стараюсь учесть все возможные ответы от модема. Но если пытаться определять конец посылки по CR/LF, учитывая то, что CR/LF может быть несколько, например \r\nOK\r\nблаблабла\r\n, то нам как минимум нужно знать, сколько \r\n будет в ответе от модема. Посчитать их, конечно, легко, но если асинхронное сообщение появилось, с ним как быть? Направьте меня в нужную сторону. Вообще, конечно, то, что форматы ответов так разнятся от команды к команде, сильно осложняет их обработку и даже немного раздражает.

Что до меня, то пока особых трудностей с определением конца посылки по таймауту не возникало. Работает достаточно надежно. Кстати, снизил длительность таймаута до 1мс., пока полет нормальный.

Тоже определял конец строки по таймауту. Работало.
Потом перешел по \r\n. По \r\n оказалось более работоспособно, и нет никакой необходимости в знании сколько их будет в ответе. К примеру посмотрим на строку \r\nOK\r\nблаблабла\r\n, по первому \n мы видим что это начало строки (так как количество принятых байтов равно 2). По второму получаем ответ OK. По третьему получаем ответ блаблабла. Поэтому при разборе ответов, задача сводится к проверке "наборов байтов находящихся между \r\n". Единственное что портит всю картину это приглашение к вводу данных "> ", но и это обходится очень просто.

Сообщение отредактировал alexdos - Apr 28 2014, 07:10

[zebrox]

...Единственное что портит всю картину это приглашение к вводу данных "> "...

Жду 1 сек, и подразумеваю, что пришло приглашение. Не видел ситуации, когда бы приглашение не пришло при отправке смса.
А при передаче данных, мне мой сервер подтверждает получение посылки.

Немного сложно обрабатывать ответы, которые не содержат заголовка (чтение имей).

[alexdos]

Жду 1 сек, и подразумеваю, что пришло приглашение. Не видел ситуации, когда бы приглашение не пришло при отправке смса.
А при передаче данных, мне мой сервер подтверждает получение посылки.

Немного сложно обрабатывать ответы, которые не содержат заголовка (чтение имей).

Аж целую секунду, я не могу позволить себе столько ждать.
В случае с \r\n никаких сложностей.