[vpd 0]

Спасибо, это уже что-то. Тогда дополнительные вопросы еще:

1) Как определить, какая входящая строка есть ответ на мою команду, а какая - асинхронный вывод на произвольную команду? Чтобы не быть голословным, приведу пример команды AT+CCID, лог которой в предыдущем посте есть. Видно, что первая строка ответа есть запрошенный идентификатор, но можно ли рассчитывать, что так будет всегда, и что туда не вклинится какой-нибудь RING или другой асинхронный ответ? Был бы ответ вида +CCID: nnnn, проблем бы не было.

2) Существует ли какой-нибудь критерий асинхронного ответа, чтобы его можно было игнорировать, если для него нет обработчика? Мне не очень нравится перспектива, когда в процессе работы асинхронные ответы начнут появляться и портить логику работы необходимых команд.

3) Существует ли вообще перечень асинхронных ответов, которые могут порождаться конкретным модулем?

[Integral 0]

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

 

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

 

Как определить ответ на AT+CCID ??? Ну можно пробовать ориентироваться на:

1. Эхо AT+CCID

2. Длину ответа

3. Проверить весь ответ что бы там были цифры, без букв/точек и т.п.

 

Как проверить ответ на AT+CIFSR ??? (ответ IP)

1. Эхо AT+CIFSR

2. В IP 100% должно присутствовать 3 точки + все остальное цифры, между точками должно быть от 1 до 3 цифр и т.д.

 

и т.п.

 

Кароче, ловить идиотские не стандартные ответы можно, просто зависит от фантазии, а по флагам ориентироваться пришел ответ или нет, ну и что если вклинится ринг/смс и т.п.? отправим повторно команду. Нужно обрабатывать ринги/смс и т.п.? ну и что... выставим флаг что приходила смс, а мы, ептеть, тут подключаемся к серверу, нам по приоритетам важнее сервер, а не смс, поставим флаг что смс приходила, после работы с сервером по флагу обработаем входящие смс (если вообще нужно)

Изменено 25 апреля, 2012 пользователем Integral

[Палыч 11]

Тогда дополнительные вопросы еще...

Имхо, при проектировании обмена следует считать, что OK/ERROR - это ответ модуля на команду: "Команда принята к исполнению/Отвергнута". Команды должны передаваться по одной (одна за другой по получении ответа OK/ERROR или по тайм-ауту, в случае, если нет ответа). Всё остальное в ответах, считать приходящим асинхронно (возможно, а иногда - как правило, до ответа OK/ERROR). Впрочем, и сами ответы OK/ERROR можно расматривать как асинхронные.

В этом случае выдача команд производится следующим образом:

1. Выдаём команду (предватительно сбрасывается признак приёма команды OK/ERROR)

2. Некоторое время опрашивать "драйвер/диспетчер команд" на предмет получения OK/ERROR

3. При ОК - запросить у "драйвера/диспетчера команд" ответ на эту команду (как правило, начинаются они на "+команда" - исключений не так уж и много). Запрашивать ответ - в течении некоторого времени.

4. При неполучении ответа за некоторое время в п.п.2 и 4 - тайм-аут.

[vpd 0]

Integral

 

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

 

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

 

Вопрос только в том, есть ли какое-либо простое правило, по которому можно сказать, что очередная строка от модуля - это асинхронный ответ? Если все асинхронные ответы пустить через отдельный обработчик, то тогда можно вполне довольствоваться тем, что ответом на AT+CCID является первая не пустая строка.

 

И еще. Для устойчивости приложения ставится цель: не ловить всякие нестандартные ответы, а игнорировать их, чтобы они не мешали работать основному алгоритму.

 

Палыч

Проблема в том, что, как я писал уже в первом посте:

1) есть команды, которые не выдают OK, а выдают ответ.

2) есть команды, которые выдают ответ, а потом ОК

3) есть команды, которые выдают ОК, потом выдают ответ.

4) не все ответы имеют формат "+команда: ...", что затрудняет их идентификацию в качестве ответа.

 

[Палыч 11]

Проблема в том, что, как я писал уже в первом посте:

1) есть команды, которые не выдают OK, а выдают ответ.

Пример, пожалуйста. Возможно, Вы имеете в виду команду отправки СМС, которая, можно считать, состоит из двух частей (команд), тогда на первую часть (команду) аналогом ОК будет приглашение ввода тела СМС (символ ">").

 

2) есть команды, которые выдают ответ, а потом ОК

3) есть команды, которые выдают ОК, потом выдают ответ.

Если ответ ОК считать таким же асинхронным, то оба этих варианта превращаются в один...

 

4) не все ответы имеют формат "+команда: ...", что затрудняет их идентификацию в качестве ответа.

Да, затрудняют, но не делают задачу невожможной. Тем более таких ответов: раз-два и обчелся (навскидку - RING, и, что-то не вспомнилось более...)

 

[Integral 0]

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

 

Тогда сработает таймаут и отправим повторно команду, не будет же до бесконечности вклиниваться, та и случаи такие редкие, или нужен мегоалгоритм за 100 лет работы ни единого еррора от модуля?

 

Где мало памяти я вообще пробовал не ловить ответы, ловлю только ерроры, есть такое мнение, что если НЕ ЕРРОР, значит все ОК, для компактности шлем команды "в слепую" с предусмотренной задержкой, и все, нормально работает, а вот если уже появился еррор, цпин нот реади, коннект клосед и т.п. уже разбираемся. В общем по компактности/сложности/универсальности можно реализовывать под конкретные задачи оптимальные решения

Изменено 25 апреля, 2012 пользователем Integral

[=F8= 0]

Пример, пожалуйста. Возможно, Вы имеете в виду команду отправки СМС, которая, можно считать, состоит из двух частей (команд), тогда на первую часть (команду) аналогом ОК будет приглашение ввода тела СМС (символ ">").

более...)

Вот как раз AT+CIFSR у симкома. Выдает ip адресс и никакого OK.

Я для таких случаев, да и вообще для любых команд ответ на которые отличается от OK/ERROR, использую одельныю функцию-обработчик котрая вызывается(если указатель != NULL) перед обработчиками unsolicited result code и стандартных ответов(OK/ERROR). В итоге если попадается то-то вроде AT+CIFSR эта функция сама отправляет сообщение OK когда приймет ip адрес. Кроме того при таком подходе не нужно парсить все возможные ответы тогда когда они в принципе прийти не могут, плюс расширяемость...

Тогда сработает таймаут и отправим повторно команду, не будет же до бесконечности вклиниваться, та и случаи такие редкие, или нужен мегоалгоритм за 100 лет работы ни единого еррора от модуля?

На эхо не нужно ореитнироаться потому, что это совершенно излишне. Ориентироватся надо на ответ. Вероятность, что модуль приймет вашу команду за другую и выдаст при этом корректный ответ практически равна 0. Эхо, собственно, нужно только для удобства работы с модулем/модемом через терминал.

[Палыч 11]

Вот как раз AT+CIFSR у симкома. Выдает ip адресс и никакого OK.

Да, действительно. Заглянул в документацию и был неприятно удивлен, что команды из раздела "AT Commands for TCPIP Application Toolkit" резко "выпадают" из не такого уж стройного ряда АТ-команд.

 

На эхо не нужно ореитнироаться потому, что это совершенно излишне.

Имхо, эхо - только усложняет разбор ответов от модуля, подключенного к контроллеру/компьютеру. Эхо включаю только в единственном случае: когда с модулем идёт работа "руками/глазами" через какой-нибудь терминал.

 

[artemkad 93]

1) есть команды, которые не выдают OK, а выдают ответ.

2) есть команды, которые выдают ответ, а потом ОК

3) есть команды, которые выдают ОК, потом выдают ответ.

4) не все ответы имеют формат "+команда: ...", что затрудняет их идентификацию в качестве ответа.

 

Сделайте векторными обработчик Ок и ERROR. Кроме того можно сделать векторный таймер. Все остальные ответы можно считать асинхронными. При получении нужного ответа по Ок до Ок обработчик Ок переключаем на заглушку.

 

ЗЫ. Как ни странно самая каверзная команда - отправка SMS т.к. она не заканчивается переводом строки, что вынуждает ее обрабатывать особенно...

 

когда с модулем идёт работа "руками/глазами" через какой-нибудь терминал.

У которого нет мониторинга исходящего потока и нет собственного эха.

[vpd 0]

А бывают ли команды, которые выдают содержательный ответ после ОК, но не в форме "+команда: ответ"?

 

Если нет, то можно не мудрить с обработчиками, а использовать парадигму Aurochs, согласно которой синхронный ответ выдается до тех пор, пока не придут OK или ERROR. Все следующие ответы можно считать асинхронными, и они имеют, как правило, признаки причастности к породившей их команде. Например, AT+CDNSGIP выдает OK, потом через секунду - +CDNSGIP: "ip-адрес".

[Артём__ 0]

А бывают ли команды, которые выдают содержательный ответ после ОК, но не в форме "+команда: ответ"?

 

23:35:29.914> AT+CIPSTART="UDP","xxx.xxx.xxx.xxx","ppppp"

 

23:35:32.057>OK

 

23:35:33.218> CONNECT OK

 

21:38:26.689> AT+CIPSTART="UDP","xxx.xxx.xxx.xxx","ppppp"

 

21:38:28.712> OK

 

21:38:42.682> STATE: PDP DEACT

 

21:38:42.732> CONNECT FAIL

[Aurochs 0]

А бывают ли команды, которые выдают содержательный ответ после ОК, но не в форме "+команда: ответ"?

 

Для SIM900 знаю только одну такую команду AT+CIPSTATUS

И для нее нужен специфический обработчик.

Фразы CONNECT OK, CONNECT FAIL и т.д. можно и нужно рассматривать не как часть ответа на команду, а как асинхронную реплику. В противном случае придется "западать" на несколько минут на обработку одной команды, никак не реагируя на другие события (на тот же входящий звонок, например).

 

[Артём__ 0]

Для SIM900 знаю только одну такую команду AT+CIPSTATUS

И для нее нужен специфический обработчик.

Ответ весма специфический. Нет бы сделать +CIPSTATUS: N, где N - номер состояния сокета.

Но ничего не поделаешь.

 

В противном случае придется "западать" на несколько минут на обработку одной команды

Зачем "западать"? Да ещё и на несколько минут?

Больше минуты на наблюдал.

 

никак не реагируя на другие события (на тот же входящий звонок, например).

 

Просто нужно быть готовым принять RING (и другие нужные реплики) во время ожидания ответа на AT+CIPSTART.

[Apik 0]

Как можно отослать несколько команд одной строкой?

Для составных команд понятно (AT+IPR=19200;+CREG=1;+CMGF=1\x0d)

А как быть, когда среди них есть простая команда, вроде ATE0 или ATV0?

[artemkad 93]

AT+IPR=19200;E0;V0

не помогает?

Вот только не все команды вместе так прокатят... Помнится именно с AT+IPR и еще чем-то у меня получилась проблема...