Кто и как принимает, данные ? (готовым изделием)

Есть несколько вариантов приема:

1. Принимаем по стокам пока не встретим OD OA а далее копируем в буфер для обработки в основной программе !

2. Или принимаем до тех пор пока не встретим "OK" + OD OA а потом отдаем в обработку основной программе.

Хочу услышать мнения.

я делаю по первому варианту,только плюс проверка-не пустая-ли строка,так как обрамление OD OA стоит с обоих сторон.

Я тож по первому варианту.
Плюс дополнение когда идет обмен двоичными данными. Там свой протокол и другие условия начала конца пакета.

http://ru.wikipedia.org/wiki/ASCII
смотрим этот абзац
Управляющие символы
а что нам сим300 может выдать из этого списка?????
0D 0A.... что ещё?????


вот про это можно поподробней...
что за двоичный обмен?????
значит можно общатся не только в ASCII???????????

меня больше прикалывает формат обмена между модулем и симкой..
CMD INS P1 P2 LL
ту всё просто и понятно.. всегда всё на своих местах.. итд.

вот и между процом и модулем тоже такоеже хотелось бы увидить

после установления соединения с сервером, обмен идет в двоичном формате. так компактней.
Но там свой протокол, шифрование данных. Это вся конечно я не имею права раскрывать.

нихрена я там такого не увидел.....опять же ВАШ "ДВОИЧНЫЙ ФОРМАТ" преобразуется в ASCII
и идёт в модуль...
вот у меня например получается так... после соединения по TCP с сервером
отправляю так

ldi___BUF,0x31 ; 1
rcall_TX_232
ldi___BUF,0x32 ; 2
rcall_TX_232
ldi___BUF,0x33 ; 3
rcall_TX_232
ldi___BUF,0x34 ; 4
rcall_TX_232
ldi___BUF,0x35 ; 5
rcall_TX_232
ldi___BUF,0x36 ; 6
rcall_TX_232
ldi___BUF,0x37 ; 7
rcall_TX_232
ldi___BUF,0x38 ; 8
rcall_TX_232
ldi___BUF,0x39 ; 9
rcall_TX_232

ldi___BUF,0x1A ; ENT
rcall_TX_232

опятьже в ASCCI!!!!!!!!!!!!!
А на сервере стоит прога от симкома (сервер.ехе) и она принимает 123456789

и опять же.. этож протокол общения с сервером!!!!!
а меня интересует связна проц-сим300
какой тут возможен обмен кроме ASCII ???????????
или тут только ASCII ????????????????????

А где Вы это смотрели???



а что такое
ldi___BUF,0x39 ; 9
rcall_TX_232
???
все гораздо проще
после соединения шлем команду
at+cipsend=N
а потом по приглашению шлем в модуль N любых байт
они уходят на сервер

прогу от симкома (сервер.ехе) я не пользую
у нас свой сервер и там программа наша.

M_Z
с вами всё понятно....:

а как вы отрпавляете это .. at+cipsend=N
в модуль????
пишите на бумажке и засовываете её в модуль?????
-----------------------

спрашивыете откуда это..

ldi___BUF,0x31 ; 1
rcall_TX_232
ldi___BUF,0x32 ; 2
rcall_TX_232
ldi___BUF,0x33 ; 3
rcall_TX_232..............

это текст программы на асемблере под авр, в данном случае мега 16

расмотрим ...
ldi___BUF,0x31 ; 1
rcall_TX_232

надо в модуль отправить 1.
для этого её надо перевести в ASCII...это получится 0х31
0х31 загружаем в регистр BUF
вызываем ПП отправки этого в модуль
что тут не понятного...????

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

Нет.
Печатаю с помощью цветного лазерного принтера и потом показываю модулю.


кто первый раз увидел проц, это конечно вопрос???
я как то удивлен что ктото еще пишет на асме такие процедуры


вот именно тестовая!!!
Оне не предоставляет всех возможностей.

ну да ладно меня это не волнует и вопрос закрыт.

Вот тут почитайте, может чего полезного для себя найдете:
Как обрабатывать сообщение REMOTE IP
SIM300 Встроенный TCP. Как различить принимаемые данные от сообщений самого модема


Да вы что!!! У SIM300 однобитное техническое зрение, при считывании цветного текста очень велика вероятность ошибок! Только черно-белый лазерник.

пишем... ещё и не такие....
значит вы на нём не пишете...
а пишите скорее всего на С... тогда понятно..
там да бумажка паказал и оно отправилось..
и пофиг в каком формате... народ даже не задумывается...:-(
а те кто пишет на асме может разжувать всё по битам.

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

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

Ага. ТЗ показал и все.

ВАХ!!!!!1 ХОРОЩАЯ КОМПАНИЯ СОБРАЛАСЬ!!!!
главное понимаем друг друга.

Спасибо всем за разъяснения но разговор зашел не туда, меня интересует именно первоначальный опрос (инициализация)и управление модемом. чтение данных отсылка, прием SMS.

Я тоже использую первый способ, но на днях меня осенило что второй способ лучше т.к. ответ принимается целиком а не по строкам. Так удобнее искать данные(все в одной строке) а не в нескольких ( сколько не изветно )

Есть ли люди которые так делали или делают?
Может есть какие подводные камни?

....действительно отвлеклись.
непосредствено с сим300 занимаюсь не давно....поэтому своих нароботок на эту тему мало
но наблюдения уже есть.
------------------
по инициализации...
RTS должен быть в 0. тогда модуль начинает отвечать.
------------------
проц сразу встаёт на приём и ждёт Call Ready
и только после того как это примет начинается движение самой проги.
но вот тут и начинаются затыки....
например поле АТ пытаюсь поймать ОК
а он не ловится...
тогда сделал так
АТЕ0
АТЕ0
тут тупо ставлю паузу и не ловлю ок
ОК
АТ
ОК
а вот тут после отключения эхо начинает всё пекрасно работать
ОК теперь ловится без проблем.... причём без изминений в проге.
я думаю что надо над этим ещё поработать...
---------------------------------------------

а сам приём хочу сделать так. так у меня работает в других устройствах.
цыплятся за байты типа 0D 0A не надо..
короче начинаем принимать всё подряд по прерыванию и складывать в озу
а из приёма будем выходить по отсутствию приёма какоето время
причем с конкретным результатом например 0х01
и после приёма байта будем увеличивать регистр длины на 1.
чтобы знать длину команды.
а так как модуть сам тормас ... и не выдаёт ничего во время его работы то ТХ
то прерывания мешать нам не будут.

Не всегда сообщения заканчиваются OK
бывают ERROR и так далее, поэтому ОК можно не дождаться
Есть еще варианты по тайм ауту, но там тож много гемороя.

я с тобой согласен
но ок я ловил там где заведомо знаю что получу его

AT
;AT+CMGF=1
;AT+CSCS="UCS2"
например в таких

AT+CMGF=1
OK
AT+CMGS="+7903ххххххх"
а тут я например ловлю 0х22 (это ") и начинаю потом всё грузить в озу пока не появится опять 0х22
так у меня номер из первой ячейки озу переселяется в озу проца.

готовых устройств я на сим300 ещё раз повторяю я ещё не делал
это всё у меня пока прверяется в связке стк500 + SIM300C_EVB_V2.01
пока изучаем доки проводим экспкременты...
получилось поработать с инетом..
сконектится с сервером... по отправлять на него байтики..
там эти байтики попринимать
поотправлять смс по русски нажатием на кнопки на стк500 на разные лелефоны.
позвонить другу!!!!! ну и ищё всякие мелочи..

короче просто покрутил модуль понаблюдал за ответами...

ЭТО КАК...можно поподробней.

-----------------------------------------
короче позанимался я с приёмом....

посылаю ATE0
принимаю
41 54 45 30 0D 0D 0A 4F 4B 0D 0A 01 <-этот последний байт дописывает ПП приёма
байта , если не дождолась его... и по 01 я знаю что это конец сообщения
ловить по 0D 0A не вижу смысла так как они встречаются несколько раз
и .. или можем принять сразу несколько строк !!!! (это неболшое достоинство)

посылаю AT

принимаю
0D 0A 4F 4B 0D 0A 01

и не лету сравниваю с двумя байтами 4F 4B - это ОК
если совпало то даём небольшую паузу на приём остальных байт
и идём дальше....

Сейчас проверил с NOKIA 6230i там нет последнего символа 01



А может быть после уверенного приема когда точно поймали "0D 0A" проверить что там перед ними стоит OK или ERROR
тем самым мы освободим контроллер от лишней работы, сделаем прерывание как можно короче.
Таймауты необходимы (по моему мнению) это поможет исключить долгие ответы и возможное наложение команд.

Кстати вопрос знатокам сколь времени проходит от подачи команды до получения ответа. Интересует самое длинное (дабы создать правильный таймаут).

возможны ответы и другие, типа разрыва соединения и т. д. без ОК и ERROR

У меня это время зависит от посланной команды. Максимальное время таймаута я использую 1минуту.

ну ёлы палы... читать не умеем
написаноже ...
41 54 45 30 0D 0D 0A 4F 4B 0D 0A 01 <-этот последний байт дописывает ПП приёмабайта
а ПП .. это под программа.. если ктото не знает.

типа сделано так... если на пике -
если таймаут то RETLW 0X01

есле на авр то типа..
LDI R16,0X01
RET
------------------------
тоесть если байт у нас НЕ принят то выходим из ПП с заведомо извесным результатом по которуму и узнаём что это конец приёма!!!!!!


--------------------------------------------------------
ну это для очень умных
--------------------------------------------------------
;----------------------------
RX_232_B:
ldi Temp,0xFE ;
out TCNT1H,Temp ; грузим содержимое в регистр таймер-счетчика TMR1
ldi Temp,0x00
out TCNT1L,Temp ; грузим содержимое в регистр таймер-счетчика TMR1

ldi temp,(1<<TOV1)
out TIFR,Temp ; стираем Флаг прерывания TOV1 по переполнению TMR1
RX_232_STB:
sbis PIND,2 ; ловим перепад с 1 в 0....
rjmp RXB_232 ; если дождлись старт бита то идём читаь байт

in Temp,TIFR
sbrs Temp,TOV1 ; по TOV1 проверяем небыло ли переполнения TMR1

rjmp RX_232_STB ; если его небыло ждём старт бит дальше

ldi BUF,0x01 ; если не дождались старт бита то выходим с результатом 0хХХ
ret
;----------------------------

RX_232_C:
;---------------------------------------------------
sbic PIND,2 ; ловим перепад с 1 в 0
rjmp RX_232_B ;
sbic PIND,2 ; ловим перепад с 1 в 0
rjmp RX_232_B ;
sbic PIND,2 ; ловим перепад с 1 в 0
rjmp RX_232_B ; три раза типа защита от дребезга!!!
nop
;---------------------------------------------------

RXB_232:
clr BUF
и тут сам приём байта....

-----------------
я надеюсьпо тексту доглдались что ВХОДОВ в ПП у меня три RX_232_А: RX_232_B: и RX_232_С:
первые одинаковые разница тока в загрузке таймера...
а третий... будет ждать до посинения... пока не придёт перепад с 1 в 0

http://electronix.ru/forum/index.php?s=&am...st&p=390286

У меня сейчас на отдельные команды работы с GSM сетью время ожидания ответа до двух минут.
И еще двухкратная попытка повторения команды в случае молчания. Только потом вываливаюсь по ошибке...

Baser
я вот подумал.. надо сообща написать алгоритм работы с модулем...
опрос ответов... какие бывают. итд
в разных вариациях...
например не сносить же мне ближайщую соту для выяснения ответов о качестве сигнала.
есть правда и другой вариант... погрузится в машину и погонять по району... но ща зимой.. чёта не охота.. хотя машина позволяет.
у меня ест наработки... но они пока все заканчиваются на ОК
а если не ОК ???

ПОЛЕЗ ОПЯТЬ ЧИТАТЬ ......
У КАКЯ КОМАНДА.. облегчающая жизнь
ATV0

Мысли вслух ?
Если хотите получить конкретный ответ - задайте конкретный вопрос

Ну на такой случай есть команта которая говорит статус соединения если я не ошибаюсь то "AT+CLCC"
А она уж и говорит: входящий звонок, набор номера, набрали номер идет разговор, И.Т.Д.

Можно этой командой каждые 30 сек долбить модем.



Меня тут еще такой вопрос заинтересовал.

Допустим для работы устройства (контроллер) необходимо знать зарегистрирован ли модем в сети это команда "AT+CREG"

Так вот если я посылаю эту команду каждые 30 сек и в один прекрасный момент одновременно с посланной командой приходит SMS
А это +CMTI:"SM",4 так вот что я получу в ответ от модема?

Сначала ответ на посланную команду, а потом сообщение о входящем SMS, или наоборот. Возможен и 3 вариант все повалится одновременно.
А как из этого следует я потеряю SMS. <- понижение надежности устройства.
кто знает подскажите???

даже, не представляю, как контроллер может пропустить +CMTI:"SM",4
вы на чем и как пишете?

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

поэксперементируйте на входящем вызове....

а долбить модем cregam-i пробовал и по 3 секунды, не виснет.

Я хотел спросить, как модем себя поведет если ему через RS232 идет одна команда, а от сети оператора сообщение и все это одновременно.
Что я увижу в окне терминала? Нужно ли мне ожидать конкретный ответ, на посланную команду или есть возможность что в ответе придет еще что-нибудь( например +CMTI:"SM",4), а потом ответ. Как мне писать обработчик, на что надеятся.

А пишу я на Си. (опыту мало, вот и задаю вопросы)

Возможны варианты когда вы послали команду по RS232 и если ответ приходит не скоро, то может придти сообщение что-нибудь( например +CMTI:"SM",4). пример возможных не быстрых ответов at+cgatt=1, и другие есть команды которие требуют обработки оператором.
Поэтому стоит не ждать конкретного сообщения а приняв сообщение от модема, анализировать его и выполнять соответствующие действия.
Я принимаю сообщения от модема по признаку 0x0d 0x0a(конец строки, принято сообщение). Сличаю полученное сообщение с списком ожидаемых сообщений. В списке ожидаемых сообщений конечно не все возможные сообщения, а только те, которые я ожидаю и буду обрабатывать. Если это превая строка сообщения(сообщение состоит из нескольких строчек), веточка уходит на прием следующих строчек сообщения. Это уже как параметры.
В таком случае не важно если вы послали команду а пришло сначало какое то другое сообщение а потом ответ на ваше сообщение. Все будет обработано как надо.

во... наконецто народ сознаваться сталь что у него нихрена ничего не работает..
в силу того что даже незнает как модуль работает.
впрочим как и я.
ну для этого мы тут и собрались.... чтобы выяснить все "китайские" моменты.

пока я заметил тока одно..что модуль одновременно принимать и передовать не может ( я думаю что оно так и должно быть, ПОТОМУ ЧТО ПОДРУГОМУ НЕ ПОЛУЧИТСЯ!!)
потому что если прям сразу отправить ему что нибуть после прихода чево нибуть из модуля... и даже по теме модуль бывает нихрена не понимает.
поэтому приходиться делать между ними паузу.
-------------------------
теперь по обработке ответов.
вот пример....
подключаемя к серваку и дрочим модуть входящими звонками..в момент подключения!!!

--------
пояснение небольшое....
чтобы упростить себе жизнь и не набирать каждый раз то что можно не набирать я сделал так..
; предварительная настройка модуля
;
; ATE0 - выключаем эхо
; ATV0 - переводим режим ответов в цыфровой режим
; AT+CMEE=0 - выключаем коды ошибок, и получаем цифровой вид error без пояснений на код ошибки
;
; настраиваем под PPP
;
; AT+CIPATS=0 - отключаем таймер авто посылки
; AT+CDNSORIP=0 - выбираем режим IP
;
; настраиваем под SMS ---- я исползую смс на русском языке
;
; AT+CMGF=1 - включаем текстовый режим
; AT+CSCS="UCS2" - включкем юникод
; AT+CSMP=17,167.0,25 - выбираем параметры текстового режима
;
; AT&W - Запись в модуль выбраных настроек
;
после этого эти команды находятся в таком состоянии по умолчанию...
следовательно их больше не набираем.

так вот ДЕЛАЮ ТАК..
влючаю устройство....

Call Ready - жду пона оно не поймает это и только потом начинает рабатать

AT+CGATT=1 - выдаю это !!!! тут 0=ОК и оно сразу не вываливается, есть какаято пауза
похоже что тут ок вываливается не на приём команды а на конкрето конект в сети gprs.. ну или не конект

0 - это ОК в цыфровом виде - далее понятно...

AT+CIPCSGP=1,"internet.volga"
0
AT+CIPSTART="TCP","89.X.X.X","6565" - а вот тут чуть зарание беру телефон и звоню на модуль... ОК вываливается сразу после набора команды итолько потом сразу RING=2
0

2 - это RING

2

2

3 - а это я дал отбой..и если долго ждать то отбой даст оператор.
так вот дальше конектится к серверу нет смысла.. потому сто мы звонком отвалили жпрс

AT+CIPSHUT - этим надо закрыть подключения к серверу... а то без этого дальше ничего не получится <--- вот тут уже результат обработки ответов
0 = ок

AT+CGATT=1
0
AT+CIPCSGP=1,"internet.volga"
0
AT+CIPSTART="TCP","89.X.X.X0","6565"
0

+PDP: DEACT

6
AT+CIPSHUT

0
AT+CGATT=1
0
AT+CIPCSGP=1,"internet.volga"
0
AT+CIPSTART="TCP","89.X.X.X","6565"
0

+PDP: DEACT

6
AT+CIPSHUT

0
AT+CGATT=1
0
AT+CIPCSGP=1,"internet.volga"
0
AT+CIPSTART="TCP","89.X.X.X","6565"
0

+PDP: DEACT

6
и так далее по кругу... пока не включим сервер
он был спецыально выключен для настройки обработки комант начинаюшихся на +.....+PDP: DEACT
кокоче сделан автоматический конект к серверу..пробовал звонить.. посылать смс..ничего не мешает.. всё это игнорируется и конект начинается заново...
(тут ещё не закончено... пока не настроен сам конект при включеном сервере... по тех причинам.. но это дело времени)
-----------
теперь про обработку осветов....
как вы уже заметили я модуль переключил на цифровые ответы.. (посмотрите командуATV0)
но в работе с жпрс некоторые команды идут всётаки в текстовом формате
например CONNECT.... в разных вариациях
(если кто знает как это сделать..дайте знать.. я пока не нашол.)

короче после команды сразу после неё AT+CIPSTART идёт ответ на принятие самой команды который может быть только двух видов
0 или 4 = ок или еррор
впринципе ответ 4 теоретически возможен а практически если передача в модуль отлажена хорошо то 4 получить трудно но реально ( короче в некоторых устройствах можно не делать)

так вот если 0 идём дальше если 4 набираем команду занова.
теперь после ОК
будут ответы на сам конект к серверу.. + цифровые
значит будут и цифровые и текстовые...
тут требуется помощь колектива!!!! так как в пдф нет реального синтаксиса ответов... гдето перед текстом стоит + гдето нету...
а проверить все РЕАЛЬНЫЕ ответы я не могу.
поэтоу у меня щас запущена обработка не всех команд....
для меня это важно... для того чтобы избежать всякие зависания ПОТОМУ ЧТО Я НЕ ПОЛЬЗУЮСЬ ПРОЦОВЫМ ВОТЧДОГ или кто он там не важно...
так вот чтобы у нас ничего не повисло нам надо знать все варианты ответов...
( странно ... описывая это .. сам начинаю понимать как оно работает!!!)
теперь ..после уже обработаного 0 просто принимаем байт и начинаем его сравнивать

выглядит это так
принимаем байт - пусть например будет 0D
И НАЧИНАЕМ СРАВНИВАТЬ СО ВСЕМИ ВОЗМОЖНЫМИ В ЭТОМ МЕСТЕ!!!!!!!!!
0=
1=
2=
3=
4=
6=
7=
8=
9=
(некоторые могут начинатся на +... например в этом месте может прийти смс..проверено...заначит добовляем+)
+=
(некоторые могут начинатся на CONNECT ... я не помню начинается ли он на +..заначит добовляем 43)
43=
если дошли досюда то значит нам это байт не нужен и начинаем ловить его занова- идем на "принимаем байт "
--------------
пеперь по веткам

0 = значт ок (тут надо проверить как откликнится CONNECT ОК- возможно будет ответ = 1) если по этой команде то
идём на CIPSEND
---------------
2= это ринг, он нам нах не нужет при конекте... но есть два варианта (мы пытаемся приконектится поэтому 3й вариант нах)
1й дать ответ ATH и потом уйти на "принимаем байт "
2й просто проигнарировать и уйти на "принимаем байт " - у меня пока так
3й обработать звонок если вам надо
---------------
раз была 2
значит обязательно 3
3= уйти на закрытие конекта и начинаем заново... так как звонок нам сорвал жпрс
---------------
если приняли
43=то это могут быть
CONNECT в разных вариациях ..ОК или FAIL --ТИПА КАСЯК!!!
тогда после 43 начинаем ловить дальше пропуская 7 байт и цыпляемся за 8й
это будет О или F - ну что делать с ними понятно...опять ухлдим в две ветки..
-------------
+= это значит будет текстовая команда с ней поступаем также как с предыдущей..
----------------------------------------------------

я думаю принцип обработки ответов понятен...
это я приводил опираясь на применения асемблера.
и не приводил реальных исходников чтоб народ не заморачивался а понял принцип действия.
я не утверждаю что это правельный или единственый метод..
но на обработке некоторых команд уже проверено.

-------------------------------------------
теперь "помошь зала"
нужен весь список реальных ответов (реальных это не из пдф. а хотябы из гипер терминала) с правельным синтаксисом
после команды..

AT+CIPSTART="TCP","89.X.X.X","6565"
ОК - это поняно
нато то что возможно тут!!!!!
уже знаю такие ответы

+PDP: DEACT
+CMTI:.....
CONNECT ОК
CONNECT FAIL
2=RING
3=NO CARRIER
6=NO DIALTONE
-----------------
А ВОТ ЭТИ 2 Я ДУМАЮ ЧТО НЕ ВОЗМОЖНЫ... МЫЖ ТУТ НЕ ЗВОНИМ!!!
7=BUSY
8=NO ANSWER
-----------------

КАКИЕ ЕЩЁ ???????

Вот такого ответа я и ждал. Мое любопытство удовлетворено.
Громадное спасибо.

Принцип написания программ у каждого свой (сколько людей столько и мнений) интересно узнать все мнения.
А может есть еще варианты????

У модема есть две разновидности команд, одни работают только внутри модема, не вылазя наружу, а другие посылаются дальше в ГСМ сеть.
Так вот, по моим наблюдениям, всё что не вылазит из модема, обрабатывается "атомарно", т.е. между моментом окончания команды и ответом модема ничего другого вклиниться не может.
Вторая группа команд работы с сетью обычно имеет два ответа: чаще всего ОК и ответ сети. До ответа ОК ничего не вклинивается, а вот во время ожидания ответа сети может вывалится какой-нибудь "незапрашиваемый ответ" (URC - unsolicited result code).

А по поводу начального момента времени: если одновременно придет ответ сети и команда от вас,
то тут "кто первый" попадет на обработчик события. Интерфейс-то дуплексный, а "одновременность" это абстрактное математическое понятие
Так что вполне возможна ситуация, когда во время передачи команды модему (еще все байты не передались, конца строки нет, обработка не началась), модем начинает выдавать вам сообщение о принятой SMS

По поводу глюка SIM300 при звонке на него в момент подключения GPRS, о котором вскользь упомянул KGB, то о нем написано здесь:
<AT+CIICR> + <RING> + <SIM300C> = ГЛЮК, Модем странно себя ведёт
Я тоже немного поисследовал этот глюк и подтверждаю его наличие в версии SIM300Z B15. Версии новее не проверял, может уже исправили.


to KGB
оставьте надежду обрабатывать ВСЕ возможные ответы от модема, поскольку никто кроме разработчиков точно не знает, сколько их и какие они.
И даже сами разработчики модема не знают, что им придется добавить туда завтра
Так шта... Программа просто не должна затыкаться, если наткнется на неизвестный для неё ответ.

+100
и три строчки кода. ))

наверно это не глюк, мож оно так и должно быть.
отбить то звонок можно.



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

короче как говорится после сборки обработать напильником....
сделал всё проше...
установил конект с сервером.. и сидел отрубал ... врубал сервак
смотрел в каких местах вываливаются какие команды...
конект отладил... теперь полный автомат... ни звонок ни смс .. ему пох.... работает (если надо то можно сделать их обработку)
потом стал модуль дрочить звонками и смс во время передачи данных серверу... тут тоже вылезло несколько касяков.
которые уже поправлены...
короче теперь есть можно сказать полный автомат конекта и передачи данных серверу..
причём после любых дисконектов делаю CGREG проверяю жпрс
и если надо то врубаю его обратно.

Baser
обрабатывать не всё не получится...
смотри какой прикольный касяк вылез..
-----------------------------------------------------
AT+CIPSEND

> 123456789
SEND OK

+CMTI: "SM",7
AT+CIPSEND

> 123456789
SEND OK

+CMTI: "SM",8 ------------- тут 8ку восприняло как дисконект ...
надо тут добывить обработку +, а то цыпануло за 8ку...это не правельно.
врпинципе это надо сделать везде..
будем ловить + а после него 0D ...обработка в холостую
смс нам тут не нужно.. но если понадобится можно и сделать


AT+CIPSTART="TCP","X.X.X.X","6565" -- послали заново конект
4 --------------------- и нихрена не поняли

+CMTI: "SM",8 --- ЭТО ВХОДЯЩЕЕ СМС №8
А БУДУТ ЖЕ ещёи 30,38,40,48,34,44,33,43,32,42, итд на которые это будет
срабатывать если не обработать


я заметил такие ситуации что когда не по теме что приходит и оно игнорируется а после этого от модуля нет никаких ответов...
вродибы и рад чтото обработать а нету.... вот и получаем висяк...
я думаю что единственый выход это подождать его малость и послать его нах

Мне нравится когда люди сначала создают сами себе проблемы настройками такого рода, а потом с ними же борются.
Былиб нормальные настройки и получал бы не цифру 8 а а конкретное сообщение, которое трактуется однозначно.

добавил обработку +____0D и всё работает нармально.
правда если с сервака послать 8 то получится автоматический переконект (почти перетонит )
-----------------------------------------------
AT+CIPSEND

> 123456789
SEND OK
8 .............................десконект
AT+CIPSHUT

0
AT+CGREG?

+CGREG: 0,1
0
AT+CIPSTART="TCP","ч.ч.ч.ч","6565"
0

+PDP: DEACT

8 ............................. конект
AT+CIPSEND

> 123456789
SEND OK
-------------------------------------------------

кстати... выше описаный недостаток можно использовать и во благо....
например клиента надо переключить на 2й сервер... а на первом мож профилактика
тогда посылаем в модуль команду записать новый ип в епром...
и потом 8
по 8 происходит дисконект .... и потом конект но уже на новый ип.

прикольная фича.

Отличная штука получилась!!!
И сколько еще ям себе накопал???

M_Z
давай не будем друг другу мозг калупать!!!
и о вкусах спорить...

то что мне надо.. работает . жпс принемается и на сервер передаётся.
при дисконектах сам сеодиняется и дальше передаёт
команды с сервера принимаются и устройсто на них реагирует.
всё пучком!!!

Хм. "Пучком" это смахивает... на радиолюбительство...
Кто мешает сделать AT+CIPSTATUS и узнать точно что происходит с модемом?
Я запрашиваю AT+CREG?, AT+CGREG?, AT+CGATT?, AT+CIPSTATUS в зависимости от желаемого режима несколько раз в минуту.

Я ... скажем так .. всего 3 недели пишу прогу.. а не несколько лет как некоторые.. и всё дописывают.
и 4 недели как узнал что такое гсм модуль.
поэтому изза отсутствия практики в работе с модулем я ещё не знаю всех возможностей модуля.
соответственно фантазия работает тока в пределах позноного.
век жеви век учись.. так что я думаю что всему своё время.

пока я тока опрашиваю AT+CGREG?
если был разрыв соединения то сперва СИПШУТ потом AT+CGREG? и исхотя из этого на AT+CGATT если жпрс оторвался, или на СИПСТАРТ.

AT+CIPSTATUS
С ЭТИМ ПОКА НЕ РАЗОБРАЛСЯ КАК РАБОТАЕТ.
едининственное подметил из твоих слов что это определяет что происходит.
а не варианты ответа на набраную перед ним коману.

---------------------
единственое могу сказать что С САМИМ модулем уже больших проблем нету, понял как с ним работать..пока всё получается...
главное правельно мониторинг организовать ... и тогда и AT+CIPSTATUS не понадобится... и так видно что происходит.

Откопал же тему)) надеюсь тут еще кто-то есть и увидит мое сообщение)
Ковыряю модем - Quectel m66, но особой роли не играет, главное те же самые АТ команды.
Использую операционку TNKernel, но тоже особой роли не играет, разве что в этой системе в очереди передается указатель на данные, а не сами данные как, например, во FreeRTOS. К этому чуть позже вернемся)

1. Сделал отдельный таск под работу с модемом.
2. Линейный буфер, куда складываются все приходящие данные с модема, которые потом из прерывания передаются в функцию обработчик (modem_process_buffer).
В функции обработчике (modem_process_buffer) проверяется строка от модема со следующими условиями:
если пришел ответ OK, то выставляется определенный флаг, который в последствии мы будем ждать в функции отправке команды.
Если пришел что-то другое, то копируем эти данные в массив буферов и номер в этом массиве отправляем уже очередью.

Пример команды AT:


Тут все просто, нужно только дождаться чтобы флаг ОК был выставлен. Сложности начинаются с командами в которых нужно парсить ответ от модема.
Например, команда AT+CREG?
На нее модем отвечает следующим образом:


Нужно дождаться именно этого ответа. Сделал следующим образом:
Перед отправкой команды помещаю в некоторые переменные условия по которым мы должны отправлять очередь:


И в свою очередь в функции modem_process_buffer (в прерывании):


Либо отправлять в очередь все что пришло и потом уже в функции отправки команды перебирать очереди пока не нашли нужный нам ответ, но так кажется более затратно...

И стоит ли в подобных командах CREG, где нужно разбирать ответ от модема дожидаться именно приходящего ОК сообщения? Или можно просто дождаться уже ответа от модема +CREG и его разбирать, а после флаг ОК просто сбросить...

Ах да, и вот сам таск для модема:


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