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

[akegor]

поменял скорость на 4800, проверял с IDLE. 10 звонков подряд - норм. Потом поменял на 115200. С первого же звонка - накладка (IDLE сработало на 30 символе). Потом поменял как было на 9600. Тут опять рандом.

Если модем отправляет сообщения через DMA - все будет ОК, а если нет, то забудьте за IDLE. Даже через DMA могут быть валерьянты, если отправляемое сообщение состоит из нескольких "блоков" (только программеры модема знают, как формируется сообщение - частями или сплошным куском).
Если не хотите пить валерьянку, когда уже все готово, но вдруг выясняется, что далеко еще не все, опирайтесь на содержимое сообщения, а не на случайные паузы.

[H4LF]

На странице 26 вообще такого нет. Там описание команды ATDI, которая ничего не меняет.

я читаю:

TC35i Terminal
Siemens Cellular Engine
Version: 02.07
DocId: TC35i_ATC_V02.07

А Вы что? Даже если другая версия - поиск никто не отменял.

Да есть, но они встречаются по 3 раза в ответе.

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

Но а... момент когда уже можно читать-то как определяется? Что посылка зашла в буфер.

Как определить что ответ уже пришёл и можно искать в нём что-то? Очень просто - выделять то что находится в обрамлении CRLF и обрабатывать строку за строкой - сравнивать, искать и т.д. Не помню в деталях как делал я, но принцип такой:
1) если появились данные в кольцевом буфере - читаем байт.
2) если прошли подряд CR LF то после них считаем до появления CR LF; так же запоминаем индекс элемента после CR LF
3) Появился CR LF и при этом что-то насчитано - по запомненному индексу и насчитанной длине можно скопировать в отдельный буфер хоть с нуль терминацией и там обрабатывать. Но я искал прямо в кольцевом буфере самописной функцией.
Вот типа такого конечный автомат нужен, не знаю как правильно его описать - я не настоящий программист.
Можно кстати и через DMA если есть прерывание по приёму знака LF, вроде в каких-то STM32 оно есть.
Хотя полноценный стек(или как это называется?) управления модемом сделать не так уж и просто как может показаться...

поменял скорость на 4800, проверял с IDLE. 10 звонков подряд - норм. Потом поменял на 115200. С первого же звонка - накладка (IDLE сработало на 30 символе). Потом поменял как было на 9600. Тут опять рандом. То со 2, то с 1, то с 5 звонка. Потом меняю опять на 4800 - хлоп, на 8 звонке - накладка.

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

[supercelt]

Показали бы уже пример что-ли...

Какой конкретно пример показать?)

[dgrishin]

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

[supercelt]

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

Короче как сработало idle, проверять массив есть ли там нужное и если нет, не обнулять i ?

[dgrishin]

Короче как сработало idle, проверять массив есть ли там нужное и если нет, не обнулять i ?

Никакого массива. Всё делается в обработчике - попробуйте сами напишите.

[akegor]

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

Если меньше шести - можно не париться. "ОК" - самый короткий ответ - из шести байтов.

Теперь, когда понятно что чудит GSM модем,

С чего это ему "чудить"? Или Вы считаете "чудачеством" работу не по Вашим хотелкам?

проверять массив есть ли там нужное и если нет, не обнулять i ?

H4LF путь показал. Остается осознать и сделать.

[H4LF]

Если меньше шести - можно не париться. "ОК" - самый короткий ответ - из шести байтов.

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

Никакого массива. Всё делается в обработчике

Учить плохому - так уж на полную? Так недолго и до _delay_ms(xxx) в обработчике(с запрещёнными прерываниями)...
Ну и модем не чудит, он так работает. А то, что Вы предлагаете - это не KISS а стрельба по своим ногам из автоматического оружия.

[dgrishin]

Учить плохому - так уж на полную? Так недолго и до _delay_ms(xxx) в обработчике(с запрещёнными прерываниями)...
Ну и модем не чудит, он так работает. А то, что Вы предлагаете - это не KISS а стрельба по своим ногам из автоматического оружия.

Я знаю как решить эту задачу максимально простым способом (и работающим).
То, что вы предлагаете - это построение сферического коня в вакууме. Всё что нужно топикствртеру - это просто принять последовательность символов в буфер (корректно определив конец текущей передачи) и потом получить нужные значения по определённым смещениям в буфере.
Я больше не буду ничего писать - понаблюдаю куда вы заведёте топикстартера такими советами

[NewWriter]

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