Здравейте! Става дума за този GSM модул, за който става дума в раздел "Хардуер". Правил съм прости асинхронни комуникационни протоколи до сега - примерно 1 стартов байт, 1 адресен и 1 команден. В случая обаче GSM-а връща цели стрингове и малко нз как да подходя! Опитах няколко подхода, но нещо не дават добри резултати. Не съм сигурен дали да използвам синхронизиращите пинове или да оставя нещата само на UART. Дали да не задам някакъв стартов символ, от който контролера да започне да пише в буфера според командата? Проблемът по-скоро е в обработката на съобщението. Софтуерът, който трябва да напиша е доста сложен и отнема доста процесорно време да се декодира отговора на модула. Та дали да се опитвам да оптимизирам процеса на трансфер на данни или просто да извиквам многократно информацията от модула?
Опитах да разгранича отделните съобщения с "\r\n", но нещо не се получава.
Може ли едно рамо по въпроса?

ГСМ връща отговорите на АТ-командите, затова се съобразявай с техния формат за конкретния ГСМ и таймаута на командата.

На това му се вика "парсер" и е общо взето стандартна задача при работа с подобни модули

Анализираш всеки приет символ. Като получиш /r/n (често е само едното зависи от имплементацията на модула), значи имаш цяло съобщение - сравняваш го някакви предварително маркирани патерни и решаваш какво ти е казал. Следващите байтове са ти част от новото съобщение и те така...

Особенно полезни в случая са функции като memcmp/strcmp, ако ги нямаш готови ще ти се наложи да си надраскаш собствени.

Трудно е да се помогне без нещо съществено. Лео казва че се връат отговори на АТ команди, те пък са подадени от теб. Това което се връща си има структура, но без да знаем каква е структурата е трудно да ти се даде идея за обработка. Обикновенно повечето протоколи са доста прости за обработка, парсера е хубаво нещо, но ако идеята е да пишеш някакъв универсален супер мощен, за повечето протоколи няма смисъл, ако целта разбира се е само протокола, защото парсера може и на много други места да бъде полезен. То така или иначе тов акоето ще обработва пакета е някакъв вид парсер, но в еидния случай ще е съвсем къстом за конкретният случай. Дай някакво инфо за тия пакети, възможно е изобщо да нямаш /r/n, възможно е да имаш и подмяна на някои байтове, примерно ако 0XFF ти е начален байт, то навсякъде в данните трябва да е заменен с нещо, примерно 0xFF 0xFE или каквото и да е. Въпреки че ако това е АТ команди няма такива неща.

Това с вградените функции върши работа. Аз се бях засилил да си пиша свои, но имаха доста бъгове и за това явно не се получаваше добре. Иначе наистина щеше да е по-добре ако връща всеки път за край \r\n.
Отдавна не съм обработвал стрингове и докато си припомня...
Благодаря!
Един въпрос! Когато аз изпращам командите към модула, всичко е ок, защото мога да ги пращам, по колкото си и искам пъти. Какво се случва, когато данните идват от вън(през модула)? Как мога да валидирам входните данни?! Имат ли някакви отличителни белези? Още не съм стигнал до тази фаза, но просто ми изплува?
Поздрави!

Още колко много неща има да ти изплуват... Запаси се с търпение и чети внимателно описанието на АТ-командите на твоя модул, защото отговора на командата може и да започва с \r\n, може тези два символа да ги има в тялото на отговора и отново накрая. А може и да получиш спонтанно съобщение от типа RING, CONNECT, ERROR, NO CARRIER и прочее, където тези два символа въобще липсват. Кучето е заровено в конкретиката, описоно в АТ-командите на този модул, затова наблягам на това.

Когато вкараш ГСМ в режим предаване/приемане на данни е според зависи. При ftp и http е общо взето ясно, а при TCP/UDP ти си определяш начина на опаковане на данните. При ГСМ модули, които имат само един команден дешифратор става твърде весело - ако пропуснеш NO CARRIER или модула се ошашка, не знаеш в режим данни ли си или в режим команди, сокета отворен ли е още, гпрс връзката има ли я, регистрацията как е. Доколкото разбирам, пре теб ГСМ ще е стационарен, та нещата са малко по-предвидими, но го имай предвид, все пак.

Принципно трябва основно да следиш командите, които модула праща към теб. Те са с приоритет. Това са така наречените непоискани (unsolicited messages - UCM). Трябва да имаш достатъчно голям буфер, който да записва отговора, а и не трябва да губиш съобщения докато обработваш.
По принцип при гсм модулите за край приемам CR (0x0D).
Пример:
подаваш: АТ CR LF
отговор
АТ CR LF
RING CR LF
CR LF
OK CR LF

тук RING е непоискано съобщение и се е намесило в отговора, който е на твоята команда. Така че ако декодираш с прост алгоритъм ще решиш, че модула не ти е отговорил, а той всъщност ти е отговорил че дори ти е дал допълнителна информация - някой ти е звъннал.

абе функциите за които Цецо говори няма да ти решат проблема, те са инструменти но не и решението. Идея си нямам какъв ти е модема и какво връща, дали всички връщат едно и също, с АТ команди последно съм работил някъде около 2000-та, спомен нямам, дори не помня как се терминират и дали има терминация. Лео копае май в тая област напоследък, им а в преди с модулите, но като му чета писането май няма ясен стандарт.
С две думи, нещата като цяло са алементарни, но няма как някой да ти каже как да го напишеш ако не ти знаем формата на данните. За валидацията един господ знае, обикновенно като се подава команда трябва да има някакво ACK или NOACK но това не е задължиелно да е и от двете страни. Освен това едва ли модема ще предаде едно и също не нощо два пъти просто така, рядко са случаите в които протокола предвижда постоянно препращане на едни и същи данни.
Ако визираш случая в който изтърваш данни ... не би следвало да имаш вариант в който ги изтърваш, не е невъзможно но това е изключение, серийния порт е достатъчно надеждна и бавноскоростна медия, ако иа проблем то проблема е бъг, но естествено затова са и тези ACK / NOACK като NOACK не значи непременно че не е прието, може просто да не е изпълнено.

Е няма как да решиш че не ти е отговорил тъй като първото което получаваш е AT CR което в случая е ACK, поне по спомен беше така ... или това беше ACK че командата е приета ... както казах отдавна беше това с АТ, не помня.

AT CR LF е ехото.
Да отговор е все пак, но целият отговор завършва с ОК CR LF.
Т.е. ако направи прост алгоритъм да чака тази последователност от символи, то ще поучи грешка

А е възможен и сценария да получи отговор
RING CR LF
CR LF
AT CR LF
OK CR LF

T.e. няма нищо общо с това което е питал модула
При GSM модулите това е трудното да се справи човек с тези UCM има много писано по въпроса. Иначе за работа със стрингове не виждам къде е сложното. Дали се работи само един символ или поредица не виждам кое е объркващото, принципът е един.

Няколко уточнения:
Line terminator не е задължително да е CR LF може да е само CR - за да е омотвацията пълна може за командите да е само CR ама ехото да ти връща и LF ако го пращаш и него - да ама тъй като това е ехо което модема не го брои за част от командада си запазва правото да вмъкне непоискано съобщение (UM - unsolicited message) ако то се е генерирало точно в този момент и за парсера ти нещата изглеждат супер омотано съответно реве, че има грешка:
подаваш: AT CR LF
отговор: АТ CR RING CR OK CR LF
по законите на мърфи една простотия може ли да се случи то тя се случва ...

Друга простотия е че UM може да се получи и когато си в дата а не в команден режим - примерно подкарал си някакво PPP или TCP/IP и започваш съответно да се чудиш дали това RING CR е част от данните или модема е взел инициативата и те е вкарал в команден режим ...

Майката му е ако има как да ползваш 2 серийни канала - един за AT команди и още един за данни ...

ToHu, отдавна къстъм командите са много повече от стандартните и там всеки производител прави каквото си иска.

Е, па ти имаше тази възможност, нали беше говедар до едно време. Сега май телешко не ти понася.

Чакайте малко! Ако съм ви разбрал правилно, ме съветвате да сложа голям буфер, за да не губя данни. Към този момент използвам буфер около 50 символа. Като стигна до \r или \n приемам, че съм приел съобщение, спирам да пълня буфера, обработвам данните, изчиствам буфера и възобновявам приемането. Вие ме съветвате да приемам данни постоянно, за да не изтърва нещо. Буферът е ограничен, колкото и да е голям. Това означава, че трябва да съхранявам по няколко съобщения в буфера с някакъв разделител и да ги обработвам едно след друго, след което да ги трия от буфера. Това създава някой проблеми, но мисля, че е осъществимо.
Модулът ми е M95 на Quectel. Скоростта ми в момента е 9600, а контролера е ПИК-че на 25MHz. Може да се наложи да сваля още скоростта, за да осигуря повече процесорно време.
Правилно ли съм разбрал?!

stoyanoff, виж т. 1.3 AT Command syntax, първия абзац от АТ-командите на М95.
При твоя "подход" ще хванещ \r\n преди самия отговор.