Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Алгоритм общения с GSM/GPRS модулем
Форум разработчиков электроники ELECTRONIX.ru > Интерфейсы > Форумы по интерфейсам > Сотовая связь и ее приложения
Slonofil
Доброго времени суток, уважаемые!

Сажусь писать программу под PIC18 для общения с SIM300DZ в составе модема GNS-300RS. В общих чертах всё понятно: отсылается строка, принимается и разбирается ответ. С отсылкой строк более-менее просто, например putrsUSART ((const far rom char *)"AT+CSMINS?\r\n"); А вот с разбором строк и временем ожидания ответа от модема (в особенности при работе с GPRS) пока туго... хочется сделать нечто автоматизированное, чтобы был массив или структура с запросом, временем ожидания ответа, типовыми ответами и идентификаторами действий, связанных с теми или иными типами ответов. Мне это видится приблизительно так:

Код
struct GSM_Struct
{
    char Send[XX];
    unsigned int Timeout;
    char Receive[YY];
    unsigned char State[Z];
} GSM[NUMBER_OF_OPERATIONS];


Верно ли я подхожу к решению этой задачи? Может ли кто-нибудь поделиться мыслями на этот счёт? Кто как делает разбор приходящих строк? В особенности при работе с GPRS.

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

Добавлю ещё, что устройство, которое будет работать с модемом, призвано делать много чего ещё помимо общения с интернетом, причём это "много чего ещё" является более приоритетным. Логика работы такова, что даже при зависаниях связи/железа SIM300 (в перспективе SIM900) должны выполняться основные задачи.

Думаю, Ваши ответы очень помогут многим начинающим освоиться с темой. Спасибо всем! С уважением, Максим.
Dron_Gus
Если нужно делать "много чего" с модемом стоит посмотреть на GSMmux. Получите несколько виртуальных портов. не надо будет делить ресурс.
Slonofil
Не могли бы Вы пояснить, что такое GSMmux?
Dron_Gus
Мультиплексор нескольких логических каналов (виртуальных последовательных портов) в один физический (железный uart). Позволяет получить несколько "виртуальных" портов. В них можно независимо (в разумных пределах) слать сообщения и получать ответы. Позволяет нескольким задачам общаться с модемом одновременно.
CADiLO
Описано в документе: http://microchip.ua/simcom/GSM-GPRS-GPS/SI...exor%20v1.2.pdf
Slonofil
Нет, погодите, я не о том, что один модем будет использоваться несколькими приложениями! Я о том, что он не является центром системы. А вообще же вопрос по большей части про программную реализацию общения с модемом...

В конце концов, может, этот вопрос уже всесторонне обсуждался на форуме? Ткните ссылочкой, плиз! К сожалению, нет возможности просмотреть весь форум на предмет искомой темы...
Dron_Gus
Слишком много нюансов. Я делал на вложенной машине состояний. Т.е. есть глобальные состояния типа "Подключение", "отключение", "перезагрузка", "бездействие". Была очередь команд. В состоянии "бездействие" эта очередь читалась, далее переход в нужное состояние. В каждом состоянии множество подсостояний "Отправка команды", "ожидание ответа", "еще что-то там" и т.д. На эти глобальные состояния таймауты. Все входящие (от модема) сообщения парсятся до основного switch'а, некоторый набор сообщений отсеивается (типа +CREG и тому подобных) тогда можно усыпить драйвер до прихода следующего сообщения или до истечения таймаута. Если неизвестное сообщение, то "спускаемся" в swith (возможно сообщение ожидается в текущем состоянии). Если состояние ожидало сообщение, то Ок, иначе еще один "пост"-парсер. Туда обычно падают сообщения об ошибках и тому подобные редкие сообщения. Как-то так.
Slonofil
Спасибо! Уже предметно. Я примерно так и думал. А нельзя ли чуть-чуть поподробнее?
av-master
Немного непонятна тема. ИМХО все пишут по разному...
Процы щас очень быстрые и все успевают....
у меня просто по прерывания работает с разным уровнем приоритета.
в ответственных быстрых местах (например декодер DTMF) просто необрабатываю прерывания. с меньшим приоритеом, после освобождения ресурсов все догонит. темболее управление потоком на автомате работает.
Dron_Gus
А куда подробней? Код, к сожалению показать не могу. Есть еще несколько ньюансов. Типа вложенности состояний. Чтобы после каждой команды модему в каждом "большом" состоянии не ждать ответа "Ок", его можно вынести в отдельное состояние. Для уобства я делал некое подобие стека вызовов. Т.е. из состояния "Бездействие" мы как бы "вызываем" состояние "подключиться", посылаем какую-нить команду и "вызываем" состояние "ожидание_ок". Чтобы реалиовать такие "вызовы" нужно уметь "сохранять" текущее состояние. Я просто заводил массив структур. Каждая структура - описание состояния: состояние, оставшийся таймаут и еще некоторые параметры. При вызове просто инкрементируем указатель (индекс) этого массива и инициализируем новое "состояние" (удобно наследовать оставшийся таймаут вызваному состоянию). При выходе - декрементируем и как бы попадаем обратно (плюс некоторая математика с таймаутами). Некое подобие вложенных вызовов. Можно реализовать и классическим методом через функции, но накладные расходы велики. таким образом получаем некий АПИ для работы с модемом, который опирается сам на себя и на более просты функции.

З.Ы. извиняюсь за дилетиантское описание.
andrewlekar
Через машину состояний как-то сильно круто. Для работы с модемом не актуально, потому что в один момент времени может быть только одно обращение к модему и можно тупо оформить цикл ожидания до прихода ответа. Внутри цикла поллинг других вещей типа индикации если нет оси. Если есть многозадачная ось, то вообще ничего дополнительно не требуется.
Если всё-таки есть желание писать программу на конечных автоматах, то рекомендую погуглить QPC. Очень нехилый (и вроде бы живой) фреймворк. Имеет даже допиленный lwIP.
kovz
Цитата(andrewlekar @ Aug 30 2010, 08:41) *
Если всё-таки есть желание писать программу на конечных автоматах, то рекомендую погуглить QPC. Очень нехилый (и вроде бы живой) фреймворк. Имеет даже допиленный lwIP.

+1 за QP. Действительно живой и продвинутый framework. Сам пользуюсь, только на С++.
Slonofil
Спасибо всем за ответы!

2 av-master: что все пишут по-разному, это понятно. Пока я не научился пользоваться указателями, мучался с правильным представлением данных, освоил структуры, указетели на структуры, массивы указателей на функции и т.п - и мои программы сильно преобразились. Вот для того и спрашиваю, что, может, есть какой-то продуманный и нетривиальный подход к решению этой задачи. Я же не могу всего знать, иногда полезно спросить более опытных разработчиков. В этом нет ничего зазорного.

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

2 Dron_Gus: огромное спасибо, очень предметно и по теме! Мои мысли о реализации очень похожи на Ваши. Кое-что Вы мне прояснили.

2 andrewlekar и kovz: обязательно погляжу на QPC. Спасибо!
Dron_Gus
Не буду спорить, можно проще. У меня была ОС и было несколько потоков, которые обращались к модему. Передача данных, опрос аккумулятора, сбор данных о сотах, СМС. У меня такое решение родилось после долгих мучений. Мне кажется вполне адекватным.

З.Ы. жаль, что в sim508 плохо работал gsmMUX, возможно вышло бы проще.
Slonofil
Ну, у меня весьма тривиальная задача, насколько я её вижу. Нужно лишь выходить через GPRS и запросами GET/POST передавать данные, принимать настройки и (в планах) принимать обновление прошивки для контроллера. Ни звонков, ни SMS, ни DTMF не планирую. Так что, скорее всего, буду лепить массив структур.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.