Ами относно протокола слушай Лео, но за буфера да, не е лошо да имаш голям буфер. Като жяло то зависи и от хардуера ти. На малки процесори не можеш да си позволиш кой зане колко голям буфер, както и някакви супер друпер парсери, обаче ако имаш малко повече ресурс голям буфер с гъвкав парсер. Аз обичам конкретните решения, т.е. написано като за случая, но понякго обратното е доста по гъвкаво.

От моята практика буфера трябва да е поне 500 байта за да работи всичко гладко и да не изпускаш байтове ... има разни команди дето връщат сумати отговор - например AT#MONI. Помага ако можеш да включиш flow control линиите на серийния канал ама с известни уговорки ...

Заминах си от тази работа преди да завърша комуникацията - така и не направим CMUX ... комай това беше единственото решение да се подкарат нещата само по един сериен порт без да се пише на питон в Telit-а ... ша ма извиняваш, ама сега съм на агнешко ...

1. Аз лично винаги организирам нещата с двойно буфериране. Имаш един първичен буфер, където ти идват символите от UART. Големината на този буфер се смята лесно спрямо времето ти за реакция. Например при 115200, имаш 80us на байт или при 100 байта буфер, ще имаш 8ms "спокойствие", което е максималното време, което можеш да се правиш на разсеян. Втория буфер композира съобщенията. Взимаш символ по символ от първичния и събираш във втория, докато получиш CR (или каквото там ти маркира край на съобщение). Композираш, композираш и като се получи цяло съобщение го мяташ на парсера да сравнява стрингове. Тук има една уловка, както казаха колегите, всеки модем си има "особенности" и понякога има съобщения които нямат CR накрая. Например като получаваш данни в транспарентен режим и дропне конекция, ти напъхва насред данните едно DISCONNECT. Или нещо от сорта. Без CR. И трябва докато си композираш съобщения да следиш и за такива "изключителни" събития преди парсера. Най-тъпото е, че тия неща ги научаваш докато си блъскаш главата, защото, често в документацията те са обяснени зле. Този вторичния буфер трябва да е толкова голям, колкото е най-голямото единично съобщение, което можеш да получиш от модема. И понеже това е неизвестна величина, която никой не ебава да специфицира в документацията - действаш като Мечо Пух - колкото повече, толкова повече.

2. Не виждам голям смисъл да пази някъде цели съобщения - като ги пускаш едно по едно през парсера ти ще извлечеш важната информация от тях и ще запазиш само каквото ти е нужно. Например като парснеш RING от примера на колегата - вдигаш един флаг - "звъня" и го зарязваш на стейт машината да си го дъвче по натам. Няма нужда да пазиш "RING" като стринг. Още по драстична става разликата при команди като MONI в който ако те интересува само нивото на сигнала например, няма нужда да пазиш 4 реда щуротии.

3. При всички положения трябва да пускаш данните за анализиране байт по байт. В момента в който получиш някакво съобщение, което разпознаваш - си го подаваш към стейт машината обработваща GSM-a. През глобални променливи или през каквото искаш там. Например можеш да имаш една променлива за отговор на твоя команда една(или по скоро няколко) променливи/флагове за URC-та и т.н.

4. При всички положения ти трябва стейт машина. Аз поне друг смислен начин за управление на GSM модем не съм видял. Ситуациите и състоянията са прекалено много и ако нямаш някаква що годе добре разписана структура на фирмуера ще стане една боза от if-then-switch, в който не можеш да се ориентираш.

5. Както коментирахме и в другата тема - зора на тая работа е да обработваш всички възможни състояния на системата, както и всички приходящи събития. Които много често са привидно лишени от логика, а понякога са си напълно лишени от логика Просто имаш натрупване на критична маса случайни фактори - хардуер, индийски/китайски фирмуер, мобилна мрежа и оператор и твоя софтуер с задължителните му бъгове.


За мен това е начина за работа с всички подобни черни кутии, комуникиращи по някакъв къстъм ASCII протокол - първичен буфер за сурови данни, вторичен за цели съобщения, парсер и стейт машина. Дали ще е ГСМ модем, ВИФИ модул, Блутут модул... това е общия принцип.

Цецо, мен ме "изнасилиха" парсера да го направа със sscanf ... като цяло стана. По лесно ми беше да парсна резултата от всяка команда наведнъж за да не се усложнява самия парсер с допълнителни стейтова от рода на "сега съм на ред N от M очаквани линии в резултата" разбира се това беше за сметка на големината на буферите - ОК е ако имаш ARM с 128кб рам, ама не го виждам на някой малък PIC с има няма 1к.
Единственото което мога допълнително да добавя е, че в списъка на модулите си пропуснал един особенно важен - GPS ... то и при него е една боза ...

O GPS-a е песен бе човек. Поне сравнено с разните комуникационни модули. Имаш да парснеш една NMEA, тривиална задача. Иначе принципа е същия, разликата е само, че комуникацията е еднопосочна (има и изключения естествено).

прибираш се в къщи и започваш диалог с жената:

Принципно е така... но може още малко да се украси

Първо, интерфейсът между приложението и стека може да се стандартизира. В общия случай според 7-те нива на ISO, има няколко вариации на тема API като аз предпочитам т.н. Barkeley sockets. Веднъж направено да работи под формата на сокети, приложението си става независимо. И вече днес може да е gsm/gprs, утре ethernet или wifi или нещо друго. Уточнявам, че под сокет не се разбира само tcp/ip сокет, а по-глобално логиката на работа, т.е. последователността на викане на API функциите и т.н.
Сега интерфейсът може да е просто набор от блокиращи функции, но за предпочитане е да има ОС или някаква друга форма на многозадачност, така че приложението да може да си живее неговия собствен живот без да се бърка от тайминга на съответния стек. Демек по-добре вместо просто "викане" параметрите на заявката да си се пъхат в нещо като опашка, а стекът от другата страна да вади и да обработва една по една. В тоя случай стекът има една нишка и в нея върти една стейт машина за заявките. Но тая стейт машина е на високо ниво, т.е. гледа дали последователността на заявките е правилна, дали състоянието на модула позволява дадената заявка и т.н. Примерно някой иска да вдигне някаква връзка, та стейт машината проверява първо дали е включен модула. При нужда му дава захранване, инициализира и т.н. и чак тогава да прави каквото прави. Тая стейт машина също може да следи като остане известно време без заявки да гаси, също през определено време да сваля ниво на сигнала, да следи за отвявания и т.н.
Самият модул може да се имплементира като класче. Всъщност едно базово класче със стандартните методи по включване, стандартни АТ-команди и т.н. За конкретния производител може да се направи наследник с общите за него неща и накрая евентуално още един наследник със специфичните за самия модул неща.
Вече на ниво една АТ команда/транзакция нещата доста варират. Както много пъти съм казвам има Ентелегентни модули, които нямат "забиващи" команди, т.е. всичко си е разумен таймоут, т.е. дори и операцията да не е завършена ти дава отговор. Така лесно се следи транзакцията, включително и по паузи в трансфера може да разпознае границата между транзакции. Отделно форматът когато формата на командите и нотификациите е универсален нещата ставата много много по-лесно. А пък и като се разкара и прозрачния/транспарентния режим направо заспиват

Дедо, ЦАР СИ!

ако искаш да разбереш как да работиш с АТ команди отваряш гугъла и търсиш RIL MODEM DRIVER за линукс
Има и една опен-сорс библиотека AT_TOK.C за парсване на отговори без скан-еф

Дедо, синтаксиса на АТ-командите ти е грешен. Трябва да пробваш с АТ$... или АТ€...
Ако не помогне, си вземаш любовница - на такива команди тя винаги ще ти връща ОК.

Съвет от един лаик: може да пробваш short rezult code format <numeric code><CR> - ATV0
За по-елементарни приложения може да свъши работа, или докато се напише светстен парсер.

Имам въпрос! Трябва да докарам модулчето да използва APN. Това, което намерих като команда за конфигуриране е AT+QIREGAPP. В описанието се дава - Start TCPIP task and set APN, user name, password! ОБАЧЕ като конфигурирам картата на компа има и една опция access number. Също така избирам APN да бъде static. Тези двете не ги намирам къде се сетват! Признавам, че за първи път се сблъсквам с APN.
Още нещо! Кое е за предпочитане - всеки път при инициализация на модула да си му задавам настройките или да ги задам веднъж и да не ги пипам повече?!

access number нямаш, тва е само при компютрите.
Дали еднократно да задаваш APN-а.... не го знам тоя модул, някои модули имаха такива функции да си помнят настройките. Ако е така изцяло от теб зависи дали ще разчиташ на модула да помни или твоя софтуер ще управлява всичко.
Принципно, някой ден може да ти се наложи да ползваш няколко APN-а в рамките на един оператор, няколко оператор, няколко държави и т.н. Тогава приложението ще казва сега искам да вляза в еди каква си мрежа, т.е. APN. Съответно ти ще трябва да провериш дали модула е настроен за него и ако не да го настроиш. Това ти го казвам, защото нищо не пречи още сега приложението да подава настройките всеки път като иска връзка, ти си пускаш командата и продължаваш.

За да нямам проблеми с APN, user name и password, съм заделил място за списък на тези параметри за нашите и няколко чужди оператора. При всяко включване на модула, той си проверява картата (IMSI) и задава съответните настройки на APN, user name и password за използваната в момента карта (ако вече не са зададени). Предвиди възможност за актуализиране на тези параметри със СМС. Имах проблеми с едни мои дивайси в Китай - китаеца даде настройките за един техен оператор, но междувременно получил по-добра оферта от друг и сменил картите, без да предупреди. Докато разберем що няма гпрс... Затова всички параметри, свързани с гпрс (и не само) мога да ги проверя и променя със СМС.