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

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

Так понимаю, что процессор ожидает ответ от сима на какую-либо АТ команду?

Думаю у команды с сервера должен быть заголовок, по которому ее можно отличить от ответа сима.
Выполнить ее, и дальше ждать ответа на АТ?

Ну да, это понятно. У команды действительно есть заголовок, и, кроме этого, по этому признаку я помещаю эти команды в другой буфер для дальнейшего парсинга. Видите ли, у меня конец сообщения от SIM900 определяется по таймауту. То есть, после приема последнего символа ответа, таймер отсчитывает 2мс и поднимается флаг, что ответ готов. Если команда приходит во время ответа, когда SIM900 что-то кидает в порт, или во время этой задержки, то целостность ответа нарушается и, соответственно, парсер ответов не может распознать его. Вот в чем проблема.

Таймаут приема (большой) использую только для защиты от зависаний.
При обычном обмене между процем и GSM-модулем (у меня был SIM700) сообщение разбираю по получении символа ">" (готовность к дальнейшему обмену).

Самостоятельные посылки от SIM700 начинаю разбирать при получении символа ":", далее в зависимости от того, что пришло до двоеточия. Если это "+IPD:" (данные от сервера, работаю только с двоичными (нетекстовыми) посылками), жду прихода длины посылки, после чего завожу счетчик на количество принимаемых байтов)

Автомат конечный писать надо. Были проблемы когда-то давно с коммуникационной программой для двух модемов, только конечный автомат и позволил добиться устойчивой работы. Его ничем из "седла" не вышибить.

Так у меня вся работа с модемом на конечных автоматах. Иначе с ним вообще невозможно работать. В общем, решил проблему "заплатками". Если команда от сервера приходит в неподходящий момент и возникает коллизия с ответом от модема, по таймауту ожидание ответа прекращается и программа выпадает в "диспетчер задач". И если команда не распозналась, сервер не получает подтверждения принятой команды и отсылает её вновь.

Как-то странно... Ведь в автомате после отправки чего-либо в линию вы принудительно переводите его в новое состояние, в котором он ожидает конкретный ответ из линии, и никакой другой. Может, что-то не так делаете? См. личку.

Не принимает ваш ящик личку. См. здесь - http://tdocs.su/4199

Сообщение отредактировал tdocs.su - Apr 23 2014, 06:22

Спасибо, почитаю.

Проблема-то как раз в том, что жду одно, а приходит другое ))

Так вот автомат на другое и реагировать не должен вовсе. Если после перехода в case сразу задать ему новое состояние, он в нем и будет находиться и ждать только то, что надо, все прочее просто игнорировать.

Все-таки не получается у меня в стандартном, командном режиме принимать сообщения от сервера без грабель. Буду пробовать transparent mode.

С утра я чё-та не догнал. А сейчас вспомнил детали той своей давней задачки. Обрисую.

Было 2 компика с зухелом на каждом из них (через COM-порты) и поганейшая линия связи, чуть ли не АТС с шаговым искателем В исходном положении модемы были инициализированы и выведены на режим лежачей трубы (командный режим). При вызове одного другим они "договаривались" друг с другом и из командного режима переходили в режим обмена данными. И тоже возникало что-то такое, когда один еще был в режиме обмена, а другой уже бросал трубу и переходил в командный.

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

Кажется, что у вас что-то подобное происходит сейчас. Невывод из командного режима в режим обмена данными.

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

Короче, что-то у вас именно с переключением режимов. Если ждете данные, а приходит от сервера команда, то так и есть. Все вспомнил

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

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

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

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

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

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