Как-то не густо в сети с исходниками на Си для 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 с таймаутами и всякой фигней. Работает, однако.

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

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




Что касается моего сообщения выше (там где описывал принцип обработки AT комманд), то продолжая свои опыты и общаясь с очень уже осведомлённым программистом <@Аrk> пришёл к окончательному варианту. Уже реализовал и проверил работоспособность.

Кусок из переписки с @Ark. Вот что он мне писал:
Я Вам рекомендую всегда использовать следующие настройки модема:
E1 “Эхо”команд включено
Q0 Ответы не подавляются
V1 Текстовая форма ответов
X4 Стандартный полный набор ответов
Тогда избежите массы ненужных проблем.

Действительно один из самых удобных вариантов. Единственно что эхо можно не использовать, тогда незначительно снижается надёжность системы, но упрощается обработка сообщений. Это уже решать каждому по себе. Я для себя эхо убрал и получил вот такой алгоритм.

Можно все сообщения ловить по наличию CRLF в начале и в конце каждого сообщения. После получения очередного сообщения, необходимо его проверить на наличие внештатных кодов. Например ERROR, +CME ERROR, +PDP DEACT, RING, +CSMI. Внештатными я называю всё, что может прийти неожиданно. Так вот, если сообщение не содержит внештатных кодов, то увеличивается счётчик полученных сообщений и процедура, пославшая ат команду, может быть уверена, что в буфере лежит всё, что относится именно к её ответу. Надо хорошо проработать обработку всех внештатных сообщений, что бы обеспечить 100% отлов всего, что не относится к нормальным ответам на команды.
Т.е. алгоритм таков.
- послал команду
- ждешь увеличения счётчика полученных сообщений (внештатные сообщения счётчик не увеличивают)
- увидев пришедший ответ, обрабатываем его.


Кроме того необходимо реализовать механизм аварийного вываливания из цикла ожидания ответа при условии получения кодов ошибки (ERROR, +CME ERROR и т.д.). После получения таких кодов, модуль уже не возращает нормальный ответ.
Т.е. к приведённому выше алгоритму прибавляется ожидание не только нормального ответа, а проверка флага наличия аварийных ответов.

Так же добавлю, что при использовании GPRS и некоторых типов команд (писал выше) возможно появление следующих форм ответов:
1) CRLF <ответ> CRLF <ответ> CRLF <ответ> CRLF (пример CLCC)
2) CRLF <ответ> (пример REMOTE IP: xxx.xxx.xxx.xxx).
Эти ответы не будут корректно обработаны моим алгоритмом, но проблема просто решается. С командами типа CLCC я вообще не работаю - они мне не нужны. А со второрым типом ответа тоже всё очень просто. Это сообщение вылазит после появления подлкючения от другого устройства. Если все подключившиеся устройства будут начинать передавать данные, в начале которых будут стоять байты 0x0D 0x0A, то это и закроет не законченный формат CRLF <ответ> - модуль корректно получив данное сообщение, может продолжать правильно функционировать.

Есть предложение оформить все разумные мысли в единую библиотеку функций для SIM300 по подобию Procyon AVRlib http://www.mil.ufl.edu/~chrisarnold/compon...ard/AVR/avrlib/

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

Думаю затея хорошая, но нереализуемая.
1) Мало кто будет писать такие библиотеки, в которых будет всё прокоменчено и понятно друг другу.
2) Мало кто будет закладывать всеобщую универсальность = пригодность использования одной библиотеки многими пользователями.
3) В данной ветке будет просто невозможно найти что либо полезное. Надо 100% хостинг + что бы кто-то один следил за порядком там. Что бы не было повторов, глюкнутых библиотек.
4) Ни кто не захочет писать хелпы, как в приведённом примере.

В доказательство своих изречений могу поставить себя в пример. Пункт №1 я бы ещё к себе не применил, но вот 2, 3, 4 - это моё. Библиотека для AT-комманд у меня есть, но к её 1000 сточек кода нужно 5000 строчек объяснения как ей пользоваться.

В статье действительно напрямую не расписываются в деталях особенности алгоритма обработки ат команд, зато к статье прикладвается SMStest_PRG.zip в котором исходники на с, которые я и предлагаю глянуть.