Цитата(vesago @ Nov 3 2008, 10:54)
Можно
тут глянуть принцип.
Почитал я эту статью и так и не понял зачем она в данной теме. Там что между строк надо находить нужную информацию?! Вообще ни одного слова, которые были бы полезны
Что касается моего сообщения выше (там где описывал принцип обработки AT комманд), то продолжая свои опыты и общаясь с очень уже осведомлённым программистом <@Аrk> пришёл к окончательному варианту. Уже реализовал и проверил работоспособность.
Кусок из переписки с @Ark. Вот что он мне писал:
Я Вам рекомендую всегда использовать следующие настройки модема:
E1 “Эхо”команд включено
Q0 Ответы не подавляются
V1 Текстовая форма ответов
X4 Стандартный полный набор ответов
Тогда избежите массы ненужных проблем.
Действительно один из самых удобных вариантов. Единственно что эхо можно не использовать, тогда незначительно снижается надёжность системы, но упрощается обработка сообщений. Это уже решать каждому по себе. Я для себя эхо убрал и получил вот такой алгоритм.
Можно все сообщения ловить по наличию CRLF в начале и в конце каждого сообщения. После получения очередного сообщения, необходимо его проверить на наличие внештатных кодов. Например ERROR, +CME ERROR, +PDP DEACT, RING, +CSMI. Внештатными я называю всё, что может прийти неожиданно. Так вот, если сообщение не содержит внештатных кодов, то увеличивается счётчик полученных сообщений и процедура, пославшая ат команду, может быть уверена, что в буфере лежит всё, что относится именно к её ответу. Надо хорошо проработать обработку всех внештатных сообщений, что бы обеспечить 100% отлов всего, что не относится к нормальным ответам на команды.
Т.е. алгоритм таков.
- послал команду
- ждешь увеличения счётчика полученных сообщений (внештатные сообщения счётчик не увеличивают)
- увидев пришедший ответ, обрабатываем его.
Кроме того необходимо реализовать механизм аварийного вываливания из цикла ожидания ответа при условии получения кодов ошибки (ERROR, +CME ERROR и т.д.). После получения таких кодов, модуль уже не возращает нормальный ответ.
Т.е. к приведённому выше алгоритму прибавляется ожидание не только нормального ответа, а проверка флага наличия аварийных ответов.
Так же добавлю, что при использовании GPRS и некоторых типов команд (писал выше) возможно появление следующих форм ответов:
1) CRLF <ответ> CRLF <ответ> CRLF <ответ> CRLF (пример CLCC)
2) CRLF <ответ> (пример REMOTE IP: xxx.xxx.xxx.xxx).
Эти ответы не будут корректно обработаны моим алгоритмом, но проблема просто решается. С командами типа CLCC я вообще не работаю - они мне не нужны. А со второрым типом ответа тоже всё очень просто. Это сообщение вылазит после появления подлкючения от другого устройства. Если все подключившиеся устройства будут начинать передавать данные, в начале которых будут стоять байты 0x0D 0x0A, то это и закроет не законченный формат CRLF <ответ> - модуль корректно получив данное сообщение, может продолжать правильно функционировать.
Исходники для SIM300x, AVR
Oct 23 2008, 08:59
