Всем привет.
Может вопрос глупый конечено, и никакой проблемы нет.

Есть вопрос такого плана.
Как правильно получать строку (ответа) от сима.
\r\nMessage\r\n

Я вижу два возможных варианта.

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

Вариан 2, извращенный
1.При первом прерывании от юарта, получаем символ, записываем в буффер, запускаем таймер на 0.4сек скажем.
2.при следующем прерывании от юарта (до истечения таймера), записываем следующий символ в буффер, перезапускаем таймер.
3.так делаем до тех пор, пока таймер 0,4 сек не истечет или буфер не заполнится.
4.Когда таймер истек, имеем в буффере все сообщение от сима, обрабатываем его.

А как Вы получаете данные с сима?

Что-то не пойму: в чём проблема?
Принимайте символы и складывайте в буфер до тех пор, пока не встретите символы окончания строки "\r\n". Обрабатываете ответ.
Зачем таймер, запрет прерываний? Наверное, Вы плохо обозначили проблему...

если ли по \r\n обрабатывать, то можно начало следующей строки потерять (пока обрабатываешь).
может можно каким то образом заставить сим делать паузу между строками, 0,5 сек например?

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

А какие правильные установки порогов управления потоком? Что это за пороги и как их изменить?

Обработка фоном.
Растасовка пакетов в прерывании.
В чем проблема не пойму. смущает то что на стыке двух пакетов встретится "\r\n\r\n" ?

Сколько времени Вам нужно, чтобы обработать строку?
Если ОЗУ не жалко, то можно использовать два буфера: в один принимается строка; как только строка принята - из первого буфера быстро переписываем во второй буфер; программа разбора строки медленно разбирает строку во втором буфере, а в это время первый буфер заполняется новой строкой... Время разбора не должно превышать времени приёма следующей строки.
Можно. Используйте сигналы управления потоком.

P.S. Осторожнее с признаком конца ввода ответа: не все ответы модуля заканчиваются парой "\r\n" (например, приглашение ввода смс).

пока я это смутно представляю.

правилен ли следующий алгоритм?
имеем N буфферов, b1,b2,b3...bn, скажем по 100 байт каждый, активный буффер b1.

- по прерывании, загружаем символы в ативный буффер, получили \р\н, выставляем флаг что даннанные в буффере b1 готовы.
- в основном цикле, если видим флаг, делаем активным буффер b+1 , обрабатываем данные из буффера b1, если в это время идут симфолы по юарту, они будут загружаться в b+1.
- по окнчанию обработки данных из b1, делаем его как пустой.

Что-то мне это не очень нравится, много памяти нужно.
Повторю вопрос, можно ли заставить сим деалать паузу между выдаваемыми строками?

И правильно не нравится, совершенно извращенный алгоритм. Делается программный кольцевой FIFO (я использую 64 байта на rx и tx), управление потоком (порог 32 байта в моем случае, анализируемый ответ должен заведомо помещаться в эти 32 байта, иначе надо увеличить "по вкусу", ну и учесть возможный "выбег", после деактивации сигнала может еще что-то поступить, один-два байта типично). Получили "конец строки" - обрабатываем. Если не успеваем обработать - то все равно обработчик прерываний UART приостановит прием деактивацией сигнала управления потоком.


Запретить прием деактивацией RTS. Естественно, надо включить аппаратное управление потоком для модема.

ок, если паузу установить нельзя, тогда вопрос по сигналам управления потоком.

Правильно ли я понимаю назначение сигналов?

DTR-выставляем всегда при включении питания (после загрузки модуля), и далее им не дергаем, или дергаем, то когда?
RTS-выставляем когда проц готов получать данные от сима, если проц занят и не готов, нужно держать низкий уровень?

CTS-ничего симу не передаем, пока не увидим там высокий уровень?
RI-если видим RI, готовимся получать данные от сима (реально ничего не делаем по ри, т.к. прием данных завязан на прерывание по юарту)?

Да, только полярности другие - активные уровни "0". А по "RI" можно определять, например, приход SMSки, но для этого надо обрабатывать, измеряя длительность.

Ок, товарищ из третьего района, спасибо большое
только ведь приход смски можно опять-же сообщением от сима определить вроде он должен выдавать +CMTI: и что-то там еще, куда сохранил вроде.

Всем спасибо за участие, буду дальше курить этот процесс

Можно. Но я, например, использую прозрачный режим и типично в состоянии постоянной связи по GPRS, так что служебные сообщения от модема не вижу. Короче, от задачи зависит...

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

А не проще без прерывания принимать по флагу приёма? Правда возможны зависания МК, для этого таймер использовать.