IvanPletnev 0 22 апреля, 2014 Опубликовано 22 апреля, 2014 · Жалоба Здравствуйте! Разрабатываю устройство, которое собирает различные данные с датчиков и с периодичностью в одну минуту отправляет их на сервер посредством SIM900. Использую обычный режим AT-команд, не transparent, то есть команда AT+CIPSEND, приходит приглашение ">", отсылаю в порт строку, дожидаюсь SEND OK, всё. В данный момент добился надежной отсылки данных. Встал вопрос приёма команд от сервера. Все в общем, работает, за исключением случая, когда микроконтроллер ждет ответа от SIM900 и в этот момент приходит команда от сервера. Аппаратное управление потоком в этом случае вряд ли подойдет.. Подскажите, пожалуйста, кто как справился с этой проблемой? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zebrox 0 22 апреля, 2014 Опубликовано 22 апреля, 2014 · Жалоба Так понимаю, что процессор ожидает ответ от сима на какую-либо АТ команду? Думаю у команды с сервера должен быть заголовок, по которому ее можно отличить от ответа сима. Выполнить ее, и дальше ждать ответа на АТ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IvanPletnev 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Так понимаю, что процессор ожидает ответ от сима на какую-либо АТ команду? Думаю у команды с сервера должен быть заголовок, по которому ее можно отличить от ответа сима. Выполнить ее, и дальше ждать ответа на АТ? Ну да, это понятно. У команды действительно есть заголовок, и, кроме этого, по этому признаку я помещаю эти команды в другой буфер для дальнейшего парсинга. Видите ли, у меня конец сообщения от SIM900 определяется по таймауту. То есть, после приема последнего символа ответа, таймер отсчитывает 2мс и поднимается флаг, что ответ готов. Если команда приходит во время ответа, когда SIM900 что-то кидает в порт, или во время этой задержки, то целостность ответа нарушается и, соответственно, парсер ответов не может распознать его. Вот в чем проблема. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
V_G 7 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Таймаут приема (большой) использую только для защиты от зависаний. При обычном обмене между процем и GSM-модулем (у меня был SIM700) сообщение разбираю по получении символа ">" (готовность к дальнейшему обмену). Самостоятельные посылки от SIM700 начинаю разбирать при получении символа ":", далее в зависимости от того, что пришло до двоеточия. Если это "+IPD:" (данные от сервера, работаю только с двоичными (нетекстовыми) посылками), жду прихода длины посылки, после чего завожу счетчик на количество принимаемых байтов) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tdocs.su 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Автомат конечный писать надо. Были проблемы когда-то давно с коммуникационной программой для двух модемов, только конечный автомат и позволил добиться устойчивой работы. Его ничем из "седла" не вышибить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IvanPletnev 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Автомат конечный писать надо. Были проблемы когда-то давно с коммуникационной программой для двух модемов, только конечный автомат и позволил добиться устойчивой работы. Его ничем из "седла" не вышибить. Так у меня вся работа с модемом на конечных автоматах. Иначе с ним вообще невозможно работать. В общем, решил проблему "заплатками". Если команда от сервера приходит в неподходящий момент и возникает коллизия с ответом от модема, по таймауту ожидание ответа прекращается и программа выпадает в "диспетчер задач". И если команда не распозналась, сервер не получает подтверждения принятой команды и отсылает её вновь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tdocs.su 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 (изменено) · Жалоба Как-то странно... Ведь в автомате после отправки чего-либо в линию вы принудительно переводите его в новое состояние, в котором он ожидает конкретный ответ из линии, и никакой другой. Может, что-то не так делаете? См. личку. Не принимает ваш ящик личку. См. здесь - http://tdocs.su/4199 Изменено 23 апреля, 2014 пользователем tdocs.su Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IvanPletnev 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Как-то странно... Ведь в автомате после отправки чего-либо в линию вы принудительно переводите его в новое состояние, в котором он ожидает конкретный ответ из линии, и никакой другой. Может, что-то не так делаете? См. личку. Не принимает ваш ящик личку. См. здесь - http://tdocs.su/4199 Спасибо, почитаю. Проблема-то как раз в том, что жду одно, а приходит другое )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tdocs.su 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Спасибо, почитаю. Проблема-то как раз в том, что жду одно, а приходит другое )) Так вот автомат на другое и реагировать не должен вовсе. Если после перехода в case сразу задать ему новое состояние, он в нем и будет находиться и ждать только то, что надо, все прочее просто игнорировать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IvanPletnev 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Все-таки не получается у меня в стандартном, командном режиме принимать сообщения от сервера без грабель. Буду пробовать transparent mode. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tdocs.su 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба Все-таки не получается у меня в стандартном, командном режиме принимать сообщения от сервера без грабель. Буду пробовать transparent mode. С утра я чё-та не догнал. А сейчас вспомнил детали той своей давней задачки. Обрисую. Было 2 компика с зухелом на каждом из них (через COM-порты) и поганейшая линия связи, чуть ли не АТС с шаговым искателем :) В исходном положении модемы были инициализированы и выведены на режим лежачей трубы (командный режим). При вызове одного другим они "договаривались" друг с другом и из командного режима переходили в режим обмена данными. И тоже возникало что-то такое, когда один еще был в режиме обмена, а другой уже бросал трубу и переходил в командный. Тоже пробовал выводить ведомый модем по тайм-ауту, но все это было нестабильно, а к тому же еще были сложные временные требования - ведущий модем мог вызвать ведомого в любой случайный момент времени (напр. в момент инициализации ведомого или во время его попытки обмена данными). Т.е. тайм-аут работал ненадежно. Тут-то автомат и спас. Кажется, что у вас что-то подобное происходит сейчас. Невывод из командного режима в режим обмена данными. Позже еще приходилось решать задачку автоматом - каждое утро высасывать обновленный прайс-лист одного крупного поставщика компьютерной комплектухи, сравнивать его со своим локальным, обходить "старую", уже имеющуюся у нас комплектуху, а затем еще декодировать и конвертировать HTML-код так, чтобы поставщик не мог предъявить претензий по поводу таких ежедневных утренних краж :) Задачка четко решалась автоматом. Короче, что-то у вас именно с переключением режимов. Если ждете данные, а приходит от сервера команда, то так и есть. Все вспомнил :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zebrox 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба И почему конец сообщения определяется таймаутом? Почему не использовать последовательность CR LF? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IvanPletnev 0 23 апреля, 2014 Опубликовано 23 апреля, 2014 · Жалоба И почему конец сообщения определяется таймаутом? Почему не использовать последовательность CR LF? Потому что встречаются ответы модема, в которых есть и две последовательности CR LF, и три. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Radik_1983 0 25 апреля, 2014 Опубликовано 25 апреля, 2014 · Жалоба Потому что встречаются ответы модема, в которых есть и две последовательности CR LF, и три. Это как раз не страшно. У меня идет работа с голосом (прием звонка, дозвон), SMS (прием и отправка) и GPRS (клиент) , плюс полный набор обслуживающих команд и всего в сумме получается не более 60 вариантов заголовков команд/ответов. Если делать не побуквенное сравнение, а более оптимизированный парсер, то получается быстрое автоматическое определение что пришло. Но с GPRS, да, в непрозрачном режиме приходится выкручиваться, а в прозрачном нет мультисокетов. Как вариант - реализовать режим мультиплексирования (CMUX). Было бы очень удобно, если бы китайцы добавили аналог +CIPRXGET, но не по незапрашиваемому ответу, а по запросу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 25 апреля, 2014 Опубликовано 25 апреля, 2014 · Жалоба Потому что встречаются ответы модема, в которых есть и две последовательности CR LF, и три. Самое первое правило - обрабатывать ВСЕ!!! последовательности от модема. Второе - последовательность AT команд четко регламетирована (см GSM 07.07 раздел 4). Заметьте, у всех команд стандарта есть final result code (чего не скажешь творчестве собственных расширений производителей модемов) Все что между - результат выполения команды. И еще есть ансинхронные ответы. Могут влезть куда угодно. либо пропускайте их, либо применяйте. НО РАСПОЗНАТЬ их надо!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться