Запоздал конечно я со своим коментом, но лучше поздно чем никогда. На горьком опыте убедился, что ЭХО действительно абсолютно не нужно. Хотя в моей первой реализации эхо обрабатывалось и довольно успешно, лафа закончилась, когда программа стала ветвится и очень глубоко. Отладка стала практически невозможной. Короче пришлось всё полностью убить и переписать заново.
Долго анализировал и пришёл к выводу, что практически все команды, которые я использую, будут состоять из кусков двух типов. Только предварительно нужно указать короткий формат команд (ATV0). Тогда куски будут следующие: 1) <byte>CR - назвал shortMessage; 2) CRLF<string>CRLF - назвал longMessage. Если в прерывании по приёму данных создать процедуру, которая бы ловила и считала количество shortMessage и longMessage, то можно можно достаточно достоверно знать, что пришёл ответ. Только перед посылкой команды нужно не забыть "счётчики кусков" обнулить. Для каждой комманды заведомо известно из каких кусков она будет состоять. Исключение из правил составляют два случая: 1) Команды, ответ на которые состоит из нескольких строк CRLF<string1>CRLF<string2>...CRLF<stringN>OK. Примером такой команды может быть AT+CLCC. 2) Когда ответ на команду ERROR или +CME ERROR и т.д.
С первым случаем решил просто. Они мне не нужны и я не использую такие команды. Со вторым - после получения и shortMessage и longMessage анализирую их на содержание возможных неожиданных кодов, которые должны досрочно прервать ожидание корректного ответа. Если такое наблюдается, то вспомогательный флаг экстренного прерывания устанавливается и процедура, ожидающая прихода ответа нужного формата вываливается досрочно. Причём в анализаторе содержания встроена логика, которая на полезные неожиданные сообщения реагирует нужным образом (например на сообщение RING).
|