Глюк приёма данных по USART

[supercelt]

Интересно, на какую команду он так отвечает? Или у Вас эхо шалит?

Например AT+CSCA?
Ответ без эха вот такой:
\r\n+CSCA: "+700000000",145\r\n\r\nOK\r\n

[supercelt]

Приём в циклический буфер лучше вести всегда (в прерывании USART-а), а не разрешать его после разбора RING и подобных сообщений модема.

Функции типа strstr не очень подходят для обработки сообщений модема, а тем более для работы с циклическим буфером.

P.S. Для работы модемом стоит написать свои функции поиска строк, которые умеют работать с отдельным байтом (то есть сохраняют своё состояние и не ждут символов CRLF и тому подобных). Логично также искаль несколько строк параллельно, так как от модема могут прийти несколько вариантов ответа.

Если возвращаться к циклическому буферу, то приходим в самое начала. Ну вот набили мы этот буфер, точнее набиваем, что-то в него приходит. А как узнать, когда считывать можно? или считывать после каждого принятого байта? Громоздко получится

[_Артём_]

А как узнать, когда считывать можно?

Когда надо, тогда и читаем.
Алгоритм типа такой:
Решили послать какую-то команду
Очистили буфер приёма и передачи.
Послали команду.
Разбираем принятые в буфер данные побайтно (или по несколько за раз).
Как только нашли один из ожидаемых ответов - принимаем решение что делать дальше.

Громоздко получится

Как раз наоборот. Практически не отвлекает и не блокирует ядро для других операций. И не теряет байты.
P.S. Кроме поиска в буфере нужно также завести таймаут на каждую операцию - модем может просто зависнуть и ждать от него ответа станет бессмысленно (например нужно его сбросить).

[supercelt]

Когда надо, тогда и читаем.
Алгоритм типа такой:
Решили послать какую-то команду
Очистили буфер приёма и передачи.
Послали команду.
Разбираем принятые в буфер данные побайтно (или по несколько за раз).
Как только нашли один из ожидаемых ответов - принимаем решение что делать дальше.


Как раз наоборот. Практически не отвлекает и не блокирует ядро для других операций. И не теряет байты.
P.S. Кроме поиска в буфере нужно также завести таймаут на каждую операцию - модем может просто зависнуть и ждать от него ответа станет бессмысленно (например нужно его сбросить).

То есть в прерывании набили в буфер первый байт и тут же его прочитали и так далее?. Ещё возникает вопрос, как тогда таким методом проверить есть ли в буфере строка RING без функции strstr

[_Артём_]

То есть в прерывании набили в буфер первый байт и тут же его прочитали и так далее?. strstr

Можно тут же, можно (и лучше) читать в основной программе (или задаче, ели еcть RTOS). Модем штука медленная, поэтому можно не на каждый байт дёргаться, а на несколько - типа проверять буфер не чаще нескольких миллисекунд. И обрабатывать несколько байт за раз - это выгоднее чем на каждый байт дёргаться.

Ещё возникает вопрос, как тогда таким методом проверить есть ли в буфере строка RING без функции strstr

Написать свою функцию приёма.
Сам писал похожее - функция искала несколько заданных строк сразу (строки задавались в зависимости от ожидаемых ответов модема). Когда одна из строк совпадала, поиск прекращался и принималось решение что делать дальше (в зависимости от того что нашлось).
Пример - посылаем A+7925xxxxxxxx;
может приёти в ответ CONNECT, BUSY и так далее:

Нажмите, чтобы открыть спойлер

case CONNECT:
ClearUARTBuffer();
// ATD
SendATD();
// number
i=0;
while (i‹ConnectNumberLength) {
WriteByteToUSARTTxBuffer(ConnectNumber[i]);i++;}
// CRLF
SendCRLF();
// загрузка шаблонов
LoadNoCarrier(0);
LoadConnect(1);
LoadOk(2);
LoadError(3);
LoadBusy(4);
LoadNoDialTone(5);
LoadNoAnswer(6);
SetTemplateQty(7);
PollingState++;
break;
case CONNECT+1:
// ожидание 'CONNECT' и 'NO CARRIER' и тп
if (TemplateData.FindFlag) {
// найден шаблон
TemplateData.FindFlag=0;
switch (TemplateData.TemlateNumber) {
case 0:
case 4:
case 5:
case 6:
case 3:
// NO CARRIER, BUSY
PollingState=MODEM_IDLE;
ModemCtrlData.ErrorCode=2;
break;
case 1:
// CONNECT
PollingState=MODEM_IDLE;
ModemCtrlData.ErrorCode=1;
break;
default:
break;
}
}
break;

[H4LF]

Ещё я бы посоветовал не скупиться на кольцевой буфер для приёма, если есть свободная память. И если уж не рекомендуемые 512 байт, то хоть 256 выделить. Ну и можно будет в нём же искать самописной функцией нужные ответы и префиксы.