Как-то не густо в сети с исходниками на Си для AVR.
Интересует момент полноценного приема ответов от SIM300x по UART (глубина буфера, тайминги между посылками, использование прерываний или постоянный опрос UART, длительность таймаута, если не пришел очередной символ). Где глянуть образец?

Для ПИКа есть исходники на Си от олимекса.

http://www.olimex.com/dev/images/PIC/PIC-GSM-sch.gif

http://www.olimex.com/dev/soft/PIC/PIC-GSM/PIC-GSM.zip



Смотреть файлы MainDemo_gsm.c и test_gsm.c

Я для своих нужд написал свои процедуры. Заняло 2 дня и строчек 300 кода, но зато теперь работает именно так, как я хочу. Не прихоидится подстраиваться под чужие процедуры.
Все АТ команды проверяют приход эха, сверяют его на идентичность посланной команде, потом в спец буфере хранят обработтаные ответы - без CRLF и т д.
Если уж очень надо, могу поделится. Хотя наверняка вам лучше попробывать своё сваять

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

Да, если это не коммерческий продукт, можно исходники?

Проект коммерческий, но на свой страх и риск поделюсь своими умоизвержениями. Принцип такой. Перед посылкой АТ комманды устройтсво устанавливает переменную ATcomMode и ATanswerType. Первая используется в прерывании, что бы понять, что сейчас должно приходить - это или какой-то ответ. А второая, после корректного получения эха, говорит в какой режим перепрыгнуть ATcomMode. Разные ответы могуть быть. Например ATcomMode=2 ожидет прихода ответа OK или ERROR. В режиме 4 - (+AT: answer; OK)
Файлы из проекта для CODE VISION 1,29 под мегу128
declare - список переменных с коментами
at_command - каркасы для комманд + их конкретные реализации
tcp_ip - набор готовых комманд для поднятия GPRS сессии и CSD соединения.

Ещё раз убедился, что лучше всё делать самому. На форуме эффективнее делиться алгоритмами и идеями. А не их реализацией. Но это ИМХО.

Моя цитата выше " Хотя наверняка вам лучше попробывать своё сваять". В тех кодах чёрт ногу сломит. Есть там слегка избыточность функциональности, но в моём проекте она была необходима.

На мой взгляд, эхо лучше отключить. Заодно и программа упростится.

+1
Аналогично, никогда эхо не применял, МК сразу его выключает в модеме. На мой взгляд, эхо - это рудимент в управлении модемами, сохранившийся со времен ручных текстовых терминалов, когда команды набирались "ручками" операторов

В любом случае, обработка ответов идет по таймаутам, т.к.:
- модем может не ответить;
- есть ответы, в которых отсутствуют коды <CR><LF>

Зато всё нагляднее, когда есть эхо. Вижу и команду и ответ.


Если не ответил, это уже сбой.


Это какие команды?

Наглядность нужна для человека при отладке, процессорам она ни к чему
А при отладке я программно шлю копию (эхо) обмена между МК и модемом в другой CОМ, подключенный к РС, и вижу то же самое.
Так сбои тоже нужно отлавливать. Для этого все равно есть таймер максимального ожидания ответа. А в прерывании процедура одна: все запихивается в кольцевой буфер, а по таймауту взводится флаг для обработчика в основном цикле. Мне особенно спешить некуда, мегабайты передавать не нужно.
Например при передаче данных: галка-приветствие (> 0D 0A 3E 20).
Или на прием данные валятся как есть, в бинарном виде...

Запоздал конечно я со своим коментом, но лучше поздно чем никогда.
На горьком опыте убедился, что ЭХО действительно абсолютно не нужно. Хотя в моей первой реализации эхо обрабатывалось и довольно успешно, лафа закончилась, когда программа стала ветвится и очень глубоко. Отладка стала практически невозможной.
Короче пришлось всё полностью убить и переписать заново.

Долго анализировал и пришёл к выводу, что практически все команды, которые я использую, будут состоять из кусков двух типов. Только предварительно нужно указать короткий формат команд (ATV0).
Тогда куски будут следующие:
1) <byte>CR - назвал shortMessage;
2) CRLF<string>CRLF - назвал longMessage.
Если в прерывании по приёму данных создать процедуру, которая бы ловила и считала количество shortMessage и longMessage, то можно можно достаточно достоверно знать, что пришёл ответ. Только перед посылкой команды нужно не забыть "счётчики кусков" обнулить. Для каждой комманды заведомо известно из каких кусков она будет состоять. Исключение из правил составляют два случая:
1) Команды, ответ на которые состоит из нескольких строк CRLF<string1>CRLF<string2>...CRLF<stringN>OK. Примером такой команды может быть AT+CLCC.
2) Когда ответ на команду ERROR или +CME ERROR и т.д.

С первым случаем решил просто. Они мне не нужны и я не использую такие команды.
Со вторым - после получения и shortMessage и longMessage анализирую их на содержание возможных неожиданных кодов, которые должны досрочно прервать ожидание корректного ответа. Если такое наблюдается, то вспомогательный флаг экстренного прерывания устанавливается и процедура, ожидающая прихода ответа нужного формата вываливается досрочно. Причём в анализаторе содержания встроена логика, которая на полезные неожиданные сообщения реагирует нужным образом (например на сообщение RING).

А я свой драйвер реализовал аля State Machine с таймаутами и всякой фигней. Работает, однако.

Можно тут глянуть принцип.