[vassabi 0]

... выставляет сигнал РТЦ. После выхода, убирает.

Вы имеете ввиду RTS?

 

[zebrox 0]

да, ртс

[jack_avenger 5]

Для этого, этого использую контроль потока.

Процессок, перед проходом по "отправляющим" функциям, выставляет сигнал РТЦ.

После выхода, убирает.

Ну это скорее к отсрочке чем к отработке относится. Самое интересное это как отличить URC от ответа на команду?

[vassabi 0]

...Самое интересное это как отличить URC от ответа на команду?

По этому поводу нашел вот такую ссылку

[zebrox 0]

Честно говоря, не совсем понимаю зачем отличать юрц от ответа.

Я все строки обрабатываю по одному алгоритму, проверяю, с чего строка начинается.

 

Список юрц известен, просто проверяем каждую строку на начало интересующего юрц, если совпало - значит пришел юрц.

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

К тому-же на 90% ответов можно сделать такую-же ловушку как на юрц, если строка начинается на что-то, значит это ответ.

 

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

[jack_avenger 5]

По этому поводу нашел вот такую ссылку

Спасибо. У меня на том же принципе все построено (эхо включено и анализирую эхо команды). Из плюсов получаю на выходе TX модема следить за командами и ответами. Но вот гарантированно ли URC не вклинивается между эхом команды и результатом ее выполнения нигде в документах не нашел.

Честно говоря, не совсем понимаю зачем отличать юрц от ответа.

Я все строки обрабатываю по одному алгоритму, проверяю, с чего строка начинается.

Если я правильно Вас понял то ответы у Вас парсятся обработчиком текущей команды. Так вот чтоб в каждом парсере не вылавливать все возможные URC и пригодилось бы всегда знать что мы получили: результат выполнения команды или URC.

Список юрц известен, просто проверяем каждую строку на начало интересующего юрц, если совпало - значит пришел юрц.

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

К тому-же на 90% ответов можно сделать такую-же ловушку как на юрц, если строка начинается на что-то, значит это ответ.

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

У меня такой проблемы нет. После отправки команды модему жду (с тайм-аутом) получения эха команды. После получения эха все строки до OK, ERROR , CONNECT и др. считаются результатом выполнения команды.

[vassabi 0]

Но вот гарантированно ли URC не вклинивается между эхом команды и результатом ее выполнения нигде в документах не нашел...

....После получения эха все строки до OK, ERROR , CONNECT и др. считаются результатом выполнения команды.

Это легко проверить, имхо. Просим модем выполнить что нибудь долгое, типа GPRS соединения, и сразу не дожидаясь CONNECTа позвонить на него.

 

[zebrox 0]

Да нет, обработчик один, на все отведы, эха, юрц.

Я ж говорю, какая разница, что идет от сима, ответ, эхо или юрц.

Получили строку, пропустили ее через фильтры, если какой-то сработал, обрабатываем ответ в контексте состояния порта (последней команды).

 

например приходит ОК

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

 

void ProcessOKAnswer(char who_called)

{

if(GL_GSM_STATES.UART_State == GSM_STATE_TIME_SYNCHRONISATOR)

{

TMR_ProcessAnswer(TRUE);

}

else if(GL_GSM_STATES.UART_State == GSM_STATE_VOICECALLREJECTING)

{

GSMSetUARTState(11, GSM_STATE_FREE);

}

else if(GL_GSM_STATES.UART_State == GSM_STATE_VOICECALLANSWERING)

{

GSMSetUARTState(12, GSM_STATE_VOICECALLONGOING);

GLF_SetOutgoingCallTime(1, 60);

}

}

 

Для меня нет никакой разницы, что за строка пришла от модема, они все обрабатываются одиннаково и в одном месте.

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

Ловим только то, что нас интересует.

[jack_avenger 5]

Это легко проверить, имхо. Просим модем выполнить что нибудь долгое, типа GPRS соединения, и сразу не дожидаясь CONNECTа позвонить на него.

Проверялось, но хотелось бы убедиться в этом и документально.

[vassabi 0]

Проверялось, но хотелось бы убедиться в этом и документально.

GSM 0710, Time that a station will wait for an acknowledgement before resorting to other action, 100 milliseconds

[jack_avenger 5]

GSM 0710, Time that a station will wait for an acknowledgement before resorting to other action, 100 milliseconds

Думаю это что-то другое. 0710 я не использую и не планирую пока

 

[Vladivolt 0]

17.03.2013 в 21:00, kan35 сказал:

по ">" тоже нудно отсекать - все верно, для SMS по нему отсекаю так же. В другое время этот символ никогда не появляется.

s:012>          AT+cpbr=99(x0D)
s:044>(x0D)(x0A)+CPBR: 99,"+78002001001",145,"Trap>trap"(x0D)(x0A)
s:006>(x0D)(x0A)OK(x0D)(x0A)

если не заложить преднамеренно ловушку

 

[Sh@dow 1]

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

Разрабатываю свой парсер AT комманд.

Вопрос такой. 

Ответ модуля на команду всегда атомарный по отношению к URC?

Тоесть если модем начал отвечать на команду и в этот момент ему позвонят например.

Ответит ли он RING после ответа на команду или URC сообщение RING может быть внутри ответа?

Конечно RING может прийти сразу после отсылки комманды. До того как пришло эхо.

Но может ли URC прийти между эхом и концом ответа?

Нигде этого не нашел.

PS:

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

Edited January 3, 2024 by Sh@dow

[aaarrr 70]

12 minutes ago, Sh@dow said:

Ответит ли он RING после ответа на команду или URC сообщение RING может быть внутри ответа?

Может быть внутри. Хороший парсер должен уметь разобрать URC в любой момент времени.

[jcxz 307]

43 минуты назад, Sh@dow сказал:

Ответ модуля на команду всегда атомарный по отношению к URC?

Тоесть если модем начал отвечать на команду и в этот момент ему позвонят например.

По идее должен быть атомарным. Т.е. - границы кадра = коды конца строки (или один код). Между границами может быть только или ответ или URC.

Но это если нет багов в прошивке модуля. У некоторых AT-командных чипов, с которыми работал (например Bluegiga WT-12) - атомарность нарушается. Там URC может влезть внутрь ответа. А например у ESP8266 как ни странно - всё прекрасно (на последних прошивках). Там всё атомарно. Хотя вроде и китайчатина.

47 минут назад, Sh@dow сказал:

Но может ли URC прийти между эхом и концом ответа?

Может. Это не относится к атомарности кадров. Так как в AT-командных протоколах кадр = это последовательность символов между двумя соседними концами строк.

У пары "команда-ответ" атомарности нет. Она только у кадров (строк) должна быть. Да и то как видно - не всегда по факту есть.

К тому-же в некоторых AT-командных протоколах ответ может состоять из нескольких строк.

51 минуту назад, Sh@dow сказал:

Что если зацепиться за эхо то можно быть уверенным что до окончания ответа URC не прийдет.

Эхо - это отдельный кадр (строка). Которая сама по себе атомарна. Но последовательность: команда-эхо-ответ - не атомарна.