Привет всем!

Возникла у меня странная ситуация с SIM800.
Ожидаю смс вызовом в цикле AT+CMGR=1,0. Он мне возвращает OK пока смс не принят.
Посылаю смс на номер, после чего uart стоит по таймауту, буфер, естественно пустой.
Кто нибудь встречался с такой бедой? Таймаут 5 сек.

Да, и еще. Если смс отправить до того, как sim зарегистрировался в сети, то все
нормально отрабатывает. Получаем +CMGR: 1,...

Помогите люди добрые. Уже невмоготуууу...

Прошивка 1418B03SIM800C24
Uart на autoban(менял на фикс.скорость - не помогает)
Регистрируюсь в сети обычно.
AT+CFUN=1
AT+CSQ
AT+CPIN?
AT+CREG?
AT+CMGF=1
AT+CSCS="GSM"
AT+CPMS="SM"

M2M, МТС

Чет так и не понял, в чем проблема и кто стоит.
Если уж совсем ничего не выходит, то все предположения проверяются в точке МОДУЛЬ-МК внешним UART, заведенным на компьютер.
И ничего не сказано об управлении потоком.

Может не совсем понятно выразился. После приема смс из uart ничего не читается командой AT+CMGR=1,0. Также я пробовал и AT+СMGL.
Поведение аналогичное.

При отладке я вижу значения регистров UART, но я в них как-то слабо разбираюсь. Подскажите куда глядеть

Для начала научитесь выражаться правильно. А то моя не понимать, что такое

Ваши термины чужды мне.
Понимаете ли Вы сами себя?

Следующим этапом научитесь пользоваться переходником USB-UART, благо, высокоуровневый обмен данными с модулем можно написать и на большом компьютере.
А потом уже полученные знания (или готовый *.с файл) переносите в МК.

Способен ли кто-нибудь еще понять документ SIM800 Series AT Command Manual V1.05.pdf с
описанными там AT командами, которые я отправляю с МК STM32 на SIM800 по UARTу?

Вроде что может быть проще. Отправил команду AT+CMGR=1,0 с помощью функции HAL_UART_Transmit



а HAL_UART_Receive как раз должна мне вернуть



если смс в наличии. И она это делает, если смс был принят SIM800 ранее.
Если смс не было то HAL_UART_Receive мне возвращает



И так в цикле я опрашиваю и жду смс. Тут она приходит и мне UART
ничего не возвращает. Ни HAL_ERROR ни HAL_BUSY ни HAL_OK. Таймаут
в функции HAL_UART_Receive истекает и я вижу просто пустой буфер.

Функции HAL_UART_**** из stm32l0xx_hal_uart.h. Копирайт STMicroelectronics.

Чтобы не придумывать для себя проблемы с UART, наверное стоит изучить как работают AT команды.
Начать желательно не с руководста по командам для конкретного модуля, ибо оно уже предполагает, что пользователь знаком с предметом.
А начать со стандартов где это более подробно описано. Иначе это будет попытка написать роман не прочитав букварь.
Желательно под рукой иметь следующие стандарты
GSM 03.38.
GSM 03.40.
GSM 07.05.
GSM 07.07.
GSM 11.11.

И до написания на Си тоже рановато - отмоделируйте алгоритм в терминале - сначала вручную, потом макросом.
А уж когда все будет понятно, тогда к программе можно приступать. Иначе сами путаетесь и объяснить не можете.

И совет на будущее - не крутите циклы, изучите как работает CNMI

AT+CNMI Настройка формирования отчетов о событиях SMS.
"Команда AT+CNMI управляет настройками SMS, относящимися к представлению кодов URC.
По этой команде выбирается процедура индикации приема нового короткого сообщения для TE, если это устройство TE активно (например, сигнал DTR находится в состоянии ON).
Если TE неактивно (например, сигнал DTR находится в состоянии OFF), прием сообщения должен быть выполнен согласно спецификации 3GPP TS 23.038.
Если сигнал DTR отсутствует или его состояние игнорируется (команда AT&D0 V.250), то достоверная передача сообщения обеспечивается использованием процедуры подтверждения AT+CNMA......"

ну и так далее

Спасибо за ответ. Вам мой вопрос оказался понятен и это радует. Причину проблемы я нашел 20 минут назад самостоятельно. Оставлю решение здесь, так как вижу что здешние гуру в практике не очень сильны. Итак.

В SIM800 по умолчанию неожиданно выставлено AT+CNMI 2,1 что приводит к тому, что после первой любой команды чтения смс SIM в UART начинает гнать оповещения при приеме смс. Естественно, мой цикл чтения смс этого не ожидает и посылает в UART команду чтения AT+CMGR. Тут UARTу и наступает конец.

Решение простое. Если хотите получать смс методом опроса выполните перед циклом AT+CNMI=0. Если хотите методом оповещения, то после первого AT+CMGR переходите к циклу чтения из UART и ожидайте оттуда +CMT.

Всем успехов!

Дык тот кто знаком с принципом приема SMS, в первую очередь проверит и настроит кодовую страницу, вид сообщения (текст или PDU) и реакцию на его приход.

Ну а по поводу "неожиданно выставлено AT+CNMI 2,1" - где написано, оставляю поискать самим. Документацию нужно читать всю.
Слева для 800 серии, справа для 900 серии.

Спасибо за док. Полезно. Но справедливости ради, скажу что весь интернет пестрит примерами приема смс от разных знающих людей.
И никто из них даже не упоминает, о том, что перед приемом нужно выставить AT+CNMI. Наверное потому что мало кто с SIM800 работает.
Ну да ладно. Еще раз спасибо.

>>>И никто из них даже не упоминает, о том, что перед приемом нужно выставить AT+CNMI.

Дело не в конкретном модуле. Мало кто хочет читать больше даташитов, да и те редко внимательно прочитывают.
На форуме (в этой тематике) дотошных инженеров ну десятка два наберется.
Да и не преподают у нас в вузах подобного - а самому нужно время и желание чтобы учиться и разбираться.

Поэтому часто такие перекосо-недосмотры и возникают.
Ошибиться не стыдно, не ошибается только тот, кто ничего не делает. Стыдно не желать развиваться и учиться.

Поэтому и существует совет забросить МК и освоить вначале терминал.
А потом написать на компьютере C файл, работающий с модемом. А всякие UART_Read и UART_Write опередлить на ReadFile и WriteFile. Отладка на компьютере в разы удобней.

Ваш цикл все равно никуда не годится, если он "зависает" на таких мелочах. От "RING" как спасаться будете? А он с очень большим успехом залезет там, где его не ждут.

И еще совет: научитесь выражать свои мысли правильно. Если Вы не можете сформулировать грамотно задачу, исполнить ее (написать программу) не получится.

Приема SMS кем? /модулем, телефоном, базовой станцией/
Как можно из UART прочитать командой AT...? Из него можно вычитать ДАННЫЕ функцией чтения. А вот прочесть СМС из МОДУЛЯ (заставить его ВЫДАТЬ данные) можно подав ему команду.

Бороться с другими URC планировал с помощью ATE0.

Мда.... Тяжелый случай.
Советую все же начать с более глубокого изучения документации. А не чьих-то вредных советов в интернете.
И ни в коем разе не пишите сразу программу, чтобы потом ее всю не переписывать. Проверьте свои предположения в терминале.

C URC не бороться, а пользоваться нужно, зачем всё выспрашивать, когда модуль автоматом выдаёт. Да и работать с модулем циклами ожидания ИМХО бред. Выкиньте ХАЛокуб от stm, напишите нормальный драйвер для USART с DMA и прерыванием по IDLE и будет счастье.

Rash, ему еще далеко до этого. Если он не понимает, что есть регистры UART.

Конечно далеко. Это моя первая программа на МК. Вряд ли я способен реализовать DMA
и даже работу с UART через прерывания. Я хотел, как мне казалось, сделать простую
вещь. Работая c UART в полудуплексе включить питание на SIM800, прочесть SMS, инициировать GPRS,
выполнить HTTP запрос, выключить питание.

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

Зато я могу поделится своими впечатлениями от стандарта GSM, его реализации в продуктах Simcom и о программах на МК, которые я видел. Очень краткое суждение - теперь мне понятно, почему сотовая связь столь ненадежно и криво работает.

P.S. Особую признательность вызывает URC. Если бы какой-нибудь программист с которым я работал сделал бы такое я бы его просто прибил. Надо же додуматься до такого - посылать неожидаемую нотификацию в последовательный порт, который работает в полудуплексе!
Чуваку, который это придумал, нужно подарить рацию, которая будет изредка самопроизвольно выходить на передачу с посылкой сигнала. Тогда бы он, наверное, смекнул, что напорол чушь.

конечно, но поэтому практически все бесплатные программы под бесплатные оси работают только в тепличных условиях. Чуть затык в сети, непредвиденный таймаут или чересчур быстрая реакция пользователя - и все, финиш. А виноват телефон, провайдер, пользователь, да кто угодно но только не "программист".

Запомните одно великое правило - никогда не считайте Маловероятное - Невозможным!
И удачи в Ваших начинаниях.

Никого не хотел обидеть. Но Вы неправы по поводу тепличных условий. Дело не в этом. Очевидно, что тот кто придумал такую обработку URC не разу не программировал в многопоточной среде, где, как Вы метко выразились маловерояное ВСЕГДА возможно. Обработка URC в Simcom - классическая архитектурная ошибка. Нужно было сделать отдельный поток для оповещений. Отдельное прерывание для его чтение. Отдельный флаг состояния (регистр). Вообщем, все чтобы оповещения не блокировали передачу и прием данных через последовательный порт. Грубо, еще один UART, только односторонний.

Внутри Sim, сюрприз, многопоточная RTOS в которую, в частности, при желании можно встроить свой поток.



Зачем? Каждое сообщение от модуля это цельная строка внутрь которой URC никогда не влазит. Принимай строки и обрабатывай каждую по отдельности и да прибудет с тобой шварц. Есть конечно особенности с GPRS, но на них тебе еще рано заглядывать.



При таком подходе получаешь отдельный геморрой со вторым UARTом который до недавнего времени был большой редкостью в МК. И ради чего?

Ага, и TCP тоже криво реализовали. Надо было отдельный канал делать для ACK и прочих пакетов...

И модем внешний на 1200 бод тоже опрометчиво сделали с всего с 1-м RS-232.
И MODBUS, CAN и прочие шины тоже дураки проектировали....

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

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

Да знаю я это. Правда примеров использования не видно нигде. А испытателем не хочется быть.


Если без прерываний и ухищрений типа DMA то не получится создать надежный код, который будет писать в UART и читать оттуда. Потому что в любой момент
вам может приехать URC и заблокирует запись. Чтобы повысить надежность мне пришлось перед записью проверять RXNE и читать. Короче, костыль.


А для чего сделали два UART? Не для того ли, чтобы сделать нормальный full duplex?



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

У меня опыт программирования 15 лет на хреновой туче языков и такой же туче всяких фреймворков, IDE, библиотек и т.д.
Но то что я увидел в вашей сфере просто удручает. Как будто в 90-Х оказался.

Этот Keil - вчерашний век с текстовым редактором от 6 студии )). ST-link который не может прошить свой же чип.
(а еще его нужно запускать от имени администратора, но перед этим нужно об этом догадаться). Этот OpenOCD,
который просто не работает, а если и работает то только после ковыряния в его коде. А программы, программы...
Все в костылях и подпорках. С глобальными переменными и операторами goto!!! Эти даташиты в которых пишут
примеры с использованием умолчаний. Или просто не пишут примеров. Итак ведь понятно!

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


P.S. Что же вы не откопаете свой внешний модем. Присоединили бы его к RS 232 и выходили бы в инет.







Я на всякий случай Вам перевод кину Universal Asynchronous Receiver-Transmitter, UART. Так, чтобы поржать на досуге )))

С чего вдруг блокировать запись? Входной поток отдельно, выходной отдельно. Они конечно могут стать зависимы, к примеру при отправке SMS когда от модуля надо дождаться приглашение на ввод, но это скорее исключение чем правило. Без прерывания можно только во время отправки не поймать часть входной строки по той мелкой причине, что тупая программа отправляет в цикле всю строку не обращая внимания на входящие символы.

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

Изначально второй UART был как технологический, отладочный и для возможности перезаписи модуля не борясь с МК.

Ни в коем случае. Первый UART и так нормальный full duplex. Да и при твоём построении программы без использования прерываний и передаче строки модулю тупым циклом, второй UART тебе не поможет потому как пока ты передаешь строку в один UART процессор занят исключительно этим и не обращает внимание ни на что, включая сообщения со второго UART-а.

Чего-то я вас не пойму: какой-такой "UART в полудуплексе" ?
Если вы решили придумать себе проблемы и потом их героически решать, то зачем обвинять разработчиков ?
Полудуплекс возможен только после управляющего МК, где будет ваш собственный простенький протокол.


В нормальном дуплексном режиме, да еще с сигналами управления потоком, все будет нормально работать.
Мухи(прием) отдельно, котлеты(передача) отдельно. Буферы отдельные. Управление потоком отдельно для обоих направлений.
Где проблемы?
DMA есть далеко не у всех МК, но и без него все работает.


Два УАРТА
- или один только для отладки.
- или один для команд управления модемом, а второй для данных (хотя и данные могут быть многопоточные, т.к. возможно несколько параллельных подключений, которые обслуживаются мультиплексным протоколом).

Конечно UART принципиально ПОЛНОдуплексный. Но в SIM800 он реализован как полудуплексный, так как буфер на прием
и передачу на стороне SIM один. И команда записи блокирует чтение и наоборот. Это мне объяснили
мудрые люди и я это опробовал на железе. Все так и есть. Когда я пишу и читаю со своей стороны я могу соблюсти
нужную последовательность. Но тут вмешивается SIM, который шлет мне неожидаемый (это их термин) код, который
блокирует запись. А я то этого не знаю.

Поэтому пришлось делать костыль.


Можно было делать по прерываниям или DMA, но я доделывал программу, написанную ранее.
Не хотелось все переписывать. Может быть и зря.

Фантастику вы пишете
Если бы так было, то ни у кого бы ничего не работало...

Или "мудрые люди" не то сказали или вы не то поняли. Вариантов тут не так уж и много.

ЗЫ. Я надеюсь Вы работаете не с включенным эхом?

Я вполне могу ошибаться. Вы все так уверенны... Может все таки дело в функциях HAL от STM.
Завтра еще раз вернусь к этому.



Я его выключил. Но меня тут обозвали лохом и я его обратно включил.

Кстати, интересное замечание. Я всегда эхо при начальной конфигурации сразу отключаю,
поэтому никогда не видел, как ведут себя SIMXXX-ы при одновременной подаче команды с эхом и вываливании из модема URC.
Это как-то должна разруливать операционка модема, но интересно как.

Не сталкивались?

+1
Это он еще про мультиплексор GSM 07.11 не слышал...



А как еще. Вполне себя и ведут. Какая разница, в каком месте станет так, что после подачи команды в приемном буфере окажется URC?
* Потому что не вычитали вовремя (перед подачей команды)
* Потому что в момент подачи команды в приемник валился URC
* Или в момент окончания передачи команды в буфере модема образовался URC.

Раньше, когда "я был молодой" и делал все в одном потоке, перед подачей команды я очищал приемный буфер и потом через N мс вычитывал ответ.
Потом понял, что я был неправ (хотя устройства с таким принципом и до сих пор работают, и весьма неплохо), и теперь первое правило - вычитывать и разбирать ВСЕ, что приходит от модема.
А потом уже думать, куда и как это применить.

Когда-то еще на Sim100 пробовал, получил кашу во входном потоке в результате чего забил и первая команда традиционная - ATE0.

Прикольно... Поток ))) Помню когда под DOC программировал, тоже думал, что прерывание это другой поток ))))

Плюнь в рожу тому кто обозвал и выключи обратно. Ничего кроме лишнего мусора эхо при работе с модемом не даёт.


Тут скорее один термин означающий два понятия - поток данных(stream) и поток исполнения(thread).

То есть тогда Вы не представляли себе отличий программного прерывания от аппаратного. А сейчас-то понимаете отличие?