[ARV 0]

Спасибо за заботу... но в ноутбук сие чудо чудное не вставить.

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

[k155la3 26]

2 minutes ago, ARV said:

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

нет, тут "ничего личного", просто вариант. Может что в цепи протеус-драйвер-COMx-USB ?  В этом случае лучше "брать частями" 

[ARV 0]

Только что, k155la3 сказал:

Может что в цепи протеус-драйвер-COMx-USB ?

Дык я уже предположил это...

Я задал тут вопрос в надежде услышать подтверждения, что у модуля нет никаких проблем с приемом байтов один-за-другим, что после отправки AT+CMGS с номером можно сразу шуровать текст сообщения, не дожидаясь приема "промпта" и т.п. Короче, гарантии того, что проблема не в модуле... чтобы хоть в чем-то быть уверенным.

[k155la3 26]

по "этой" части (если не хотите сами проверять) можете получить ответ от "первоисточника" :)  CADiLO

[Grigorij 0]

2 hours ago, ARV said:

Я задал тут вопрос в надежде услышать подтверждения, что у модуля нет никаких проблем с приемом байтов один-за-другим, что после отправки AT+CMGS с номером можно сразу шуровать текст сообщения, не дожидаясь приема "промпта" и т.п. Короче, гарантии того, что проблема не в модуле... чтобы хоть в чем-то быть уверенным.

Советую внимательно посмотреть описание данной команды (я про AT+CMGS) в документации от Simcom, а также примеры ее использования. В старой документации написано, что максимальное время ответа на эту команду может достигать 60 секунд. Это значит, что при попытке отправить что-то до получения ответа модем будет возвращать либо ERROR, либо просто в ответ будет тишина. 

У самого SIM800 никаких проблем с UART-ом нет. 

[ARV 0]

6 часов назад, Grigorij сказал:

В старой документации написано, что максимальное время ответа на эту команду может достигать 60 секунд.

Это написано и в новой документации, задержка ответа связана с отправкой самого сообщения в сеть, а я говорил про задржку другую. Эта команда состоит как бы из двух частей: отправки команды с номером доставки и ввода самого текста сообщения. Так вот, после отправки первой части модуль выдает '>' в качестве "промпта" для ввода текста. Вот я и интересуюсь: надо ли его дожидаться или достаточно выдать первую часть команды и сразу можно переходить ко второй, передача и прием в USART же асинхронные? Или надо ждать этого промпта, и лишь потом все?

Просто я сделал полностью асинхронную работу с USART и теперь вынужден заниматься синхронизацией обмена. Может, и не стоило асинхронничать, а тупо делать поллингом USART и прием, и передачу? И память сэкономилась бы, и логика не пострадала бы, а проблемы "задержек тупого ожидания" разруливала бы RTOS?

[k155la3 26]

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

Само "железо" модема асинхронность USART обеспечивает. Но это не означает, что модем постоянно в "онлайне" по Rx.

Попробуйте выдайте "пакетом" 2-3 команды AT&V. У меня есть сомнения, что получите также 2-3 результата.

Да и зачем это делать, кроме как самому запутаться. В этом смысле - никакой "асинхронности". Команда-ожидание-прием-разбор ответа. Только после этого следующая команда.

 

[ARV 0]

3 часа назад, k155la3 сказал:

В этом смысле - никакой "асинхронности"

Можно попросить подробностей?

 

Вот смотрите: есть printf и scanf, потоки вывода/ввода для которых элементано настраиваются на USART. изначально в концепции Си это полностью синхронные функции, и работают посимвольно. Я до последних пор пользовался именно ими для реалзации обмена со всем, чем было надо. И не парился на счет того, что из scanf нет выхода, пока не поступят все входные данные или не возникнет ошибка. И все было шикарно, с моей точки зрения.

 

Но вот тут взялся за SIM800, а он имеет обыкновение посылать совершенно непредсказуемо... и применение scanf мне показалось не логичным. Да и систему задумал я такую, что не очень комильфо пропасть надолго в scanf... И я ушел от этого, как мне показалось, полностью. Прием от модуля идет по прерываниям через кольцевой буфер, а передача - напрямую с ожиданием. В приеме по прерыванию ловлю '\r' и отдаю на разбор полученную с прошлого '\r' строку. И оно тоже как-то работает. Но в случае с отправкой СМС получается, что лучше действовать по-старинке...

 

Так что ж лучше-то? От бессмысленных зависаний в циклах ожидания я избавился путем применения RTOS: сколько бы я в scanf не висел, а важное событие не пропущу все равно. Так что посоветуете: продолжать изголяться в реализации синхронного обмена при помощи асинхронно-реализованных возможностей или вернуться к "тупым ожиданиям"? Честно говоря, мешанина из подходов напрягает, уж лучше безобразно, но однообразно...

[Vladivolt 0]

Просто для информации (к чему надо быть готовым): однажды мною было зафиксировано поступление URC между строками многострочного ответа на запрос AT+CMGL=4

 

 

[k155la3 26]

Я с смс не работал. Свой интерфейс для работы с модемом у меня был на базе ф-и

mdm_err = ModemCMD( Rxbf,  "AS0=1", "OK", 2 );

Это было очень давно, для PC. Сама ф-ия работала синхронно, внутри нее - "растормаживался" поток с ожиданием, цикл с синхронной ф-ей приема из COM-порта.

Соответственно, алгоритм на ней "залипал", но не более, чем на таймаут в несколько секунд, в любом случае получаем: или успешное выполнение или код ошибки.

m_ret = ModemCMD( RxBf,  "AS0=1", "OK", 2 ); // адрес буфера приема, команда для модема, ожидаемый ответ модема, кол-во байт в ответе (без 0D 0A)

Ф-ия должна возвращать 1, если после выдачи команды получен ожидаемый ответ (ОК) и 0, в противном случае. Если (m_ret == 0), смотрим, что находится в RxBf. Если пусто - ошибка "нет ответа". Если строка - разбор.

m_ret = ModemCMD( RxBf,  "AT+CMGS", ">", 1 );
if( m_ret > 0 ) // код "положительный", те команда выполнена успешно с подтверждением от модема в виде промпта

{
	int size;
	static char myMessage[100] = "HelloSMS";
	size = strlen(myMessage);
	myMessage[size] = 0x1A; myMessage[size+1] = 0x00; 
	size = size + 1; // или strlen(myMessage)
	m_ret = ModemCMD( RxBf, myMessage, "OK", 2 );
}
. . . анализ m_ret . . . 

там еще надо учитывать \n\r - не помню. sscanf я "напрямую" никогда не использовал. Для памяти пользуюсь постоянно, даже с сложными шаблонами.

Типовой цикл обмена (простые AT-команды)

- сформировать в памяти шаблон ожидаемого от модема ответа ( "ОК" )

- очистить (обнулить) буфер приема RxBf[] (строки)

- в буфер передачи TxBf[] записать требуемую строку команды.

- разрешить передачу буфера TxBf  через USART- ждем освобождения TxBf[]

- начинаем отсчет таймаута ожидания ответа модема (должен ответить не позже чем )

- цикл: проверяем заполнение буфера Rx[] с учетом переполнения таймера ожидания ответа. 
- выход - анализ флага таймаута, неответ модема (принято 0 байт), несоответствие заданному шаблону ответа "OK" "ERROR" итп

Quote

Так что ж лучше-то? 

Если Вы используете RTOS - выносите ф-ии обмена с модемом в отдельную задачу, которой управляете из "основной" задачи. Это можно делать даже обычными флагами-переменными. Хотя в RTOS должны быть встроенные средства для этого - семафоры, мьютексы. Это получится такой большой while(), со switch внутри, перед закрытием цикла ставите sleep(100) - смотря какого типа RTOS. Под case - блоки "сессий" с модемом подобные коду выше.

Пока сделайте (IMHO) в однозадачном режиме, синхронно. Если будет надежно работать и такой подход (код выше) Вас устроит,

можно делать распараллеливание на задачи (асинхронность).

 

[ARV 0]

Мда... получается, асинхронность я зря затеял... что ж, спасибо за советы.

[ARV 0]

4 часа назад, Vladivolt сказал:

однажды мною было зафиксировано поступление URC между строками многострочного ответа на запрос AT+CMGL=4

Не представляю, как к этому можно быть готовым... По-моему, это нереально. Невозможно при приеме текста СМС отличить URC от принятого текста! URC просто будет потеряно и все дела. И, мне кажется (просто кажется, ничего более), что разработчики модуля это должны были понимать и исключать подобное... если это не так - то вообще не представляю, как с этим жить...

[Vladivolt 0]

1 час назад, ARV сказал:

Не представляю, как к этому можно быть готовым... По-моему, это нереально. Невозможно при приеме текста СМС отличить URC от принятого текста! URC просто будет потеряно и все дела. И, мне кажется (просто кажется, ничего более), что разработчики модуля это должны были понимать и исключать подобное... если это не так - то вообще не представляю, как с этим жить...

Устанавливаем формат pdu, и тогда нас не собьёт с толку тот шутник, который смс-ом отправит некий текст существующего URC.

На примере запроса AT+CMGL поступаем примерно так:

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

<CR><LF>+CMGL:...<CR><LF>[pdu]<CR><LF>

и финальной <CR><LF>OK<CR><LF>

Так вот, приняв очередную порцию <CR><LF>text<CR><LF>, смотрим что есть text.

Если не OK, не +CMGL:..., то отвлекаемся от чтения смс и отрабатываем URC.

[ARV 0]

Мда... ужос. Еще больше убеждаюсь, что в данном контексте асинхронность - злейшее зло, поллинг наше все.

PDU, однако, шибко жирно для моего проекта.

[rx3apf 0]

А что сложного с PDU ? Первое, что я сделал, когда потребовалось обрабатывать SMS - именно обработку PDU. Все ж совершенно тривиально...