SIM800 + stm030 как правильно принимать по USART?

[AR_Favorit]

Всегда есть какой-то предел, когда насрать, что пропустили часть данных.

Ну да, по большому счету почти все пропуски исправляются логикой работы программы.

Но в варианте "2 буфера со сменой активного в прерывании по \r" получается очень нехорошо, например, если в текстовом режиме прочитать даже однострочную СМСку (+CMGR) - в один буфер упадет ответ с параметрами (среди которых, между прочим, номер отправителя) во второй собственно текст, а сразу за текстом летит "ОК" и портит первый буфер, если прога замешкалась и уже не распарсила его.

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

[miwutka]

Если один большой буфер то как тогда его лучше анализировать? Тоже искать символы начала и конца ответов? Потом strncmp сравнивать начиная с конкретного места в строке?

[miwutka]

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

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

[H4LF]

Если один большой буфер то как тогда его лучше анализировать? Тоже искать символы начала и конца ответов? Потом strncmp сравнивать начиная с конкретного места в строке?

Именно, AR_Favorit уже написал как - конечным автоматом определять начало и конец (или длину) и передавать их дальше на обработку(поиск). Обработчик прерывания занимается только приёмом/передачей и ловлей ошибок передачи/переполнения. Вот только для поиска прямо в кольцевом буфере strncmp вряд-ли подойдёт, скорее всего придётся писать свои, но это просто.
Вот неплохая статья, хотя там примеры с modbus и клавиатурой, но принцип тот же http://kit-e.ru/articles/circuit/2006_11_164.php

[eddy]

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

От задачи зависит. С GPS проще два буфера (хотя, я сомневаюсь, что может возникнуть ситуация, когда за 1 секунду не успеешь данные из буфера распарсить), а с GSM, наверное, действительно лучше один кольцевой буфер побольше. Правда, если будет переполнение, то к чертям пойдет все содержимое...

Если один большой буфер то как тогда его лучше анализировать?

Я бы в промежуточный буфер сначала считывал данные вплоть до последнего '\n', потом их анализировал. Заодно освобождается сразу гора места в кольцевом буфере. А промежуточный буфер имеет обычный вид для всяких strchr, strstr и т.п.
А вообще, у меня уже пару лет валяются GSM модули, все никак руки не дойдут для них прошивку под STM32F030 нарисовать (да и под другие МК все это влет пойдет). Можно было бы дополнительную приблуду к автосигнализации сделать или чем-нибудь удаленно управлять.

[Someone]

Значит я просто получаю ответ из шести возможных, очищаю буфер весь,

Физически чистить не обязательно. Достаточно перенести указатель на начало буфера, предварительно скопировав его для обработки в другой буфер. Пока будешь разбирать и анализировать скопированное, в приёмный буфер будут приниматься новые символы, затирая старые. В твоём случае, кстати, признак окончания приёма строки - коды 0x0D - "ввод". И "перенос строки" 0x0A (кстати, в С строки заканчиваются кодом 0, учитывай это, работая с библиотечными функциями обработки строк). Это если ты хочешь построчно разбирать, то, как ты и говорил, отслеживать конец строки по этой комбинации символов. Можно как AR_Favorit, говорит, ориентироваться по переполнению буфера, но это более громоздко, и менее очевидно для неопытных программистов, и часто допускаются дурацкие ошибки.

[Someone]

А беспокоиться не из-за проверки символа на равенство \r или \n, а из-за того, что по результату предлагается сразу же и заняться парсингом,

Да не предлагает он парсингом заниматься в прерывании - только определить конец строки, и выставить флаг "строка принята", и установить указатель приёмного буфера в начало, ну ещё быть может скопировать из приёмного буфера в буфер для последующего приёма. А уже в основном цикле, проверив наличие флага "строка принята", производить разбор принятого.

[Easyrider83]

Копировать буфер в прерывании - это не красиво. Красиво - переключать указатели и поднимать флаги.

[H4LF]

Можно как AR_Favorit, говорит, ориентироваться по переполнению буфера

Разве он такое говорил? Как я понял - он говорил о контроле переполнения кольцевого буфера. В прерывании только инкрементируется указатель записи и производится сама запись в буфер, плюс отслеживание ошибок, в том числе переполнения кольца, если нужно. А в основной программе постоянно(т.е. в основном цикле, не блокируя ход программы) сравниваются индекс чтения и индекс записи, и если не равны, то читаются байты (с инкрементом индекса чтения) пока не станут равны индексы и вычитываемые байты отправляются на КА который и определяет начало/конец/длину строки. И передаёт полученные данные на обработку далее.
Вариант возможного кода был в другой и не такой давней теме, тоже про работу с модемом, ЕМНИП.

[AR_Favorit]

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

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