Плавающие задержки ответов на AT команды, SIM800C Опции

[Rash]

Доброе время суток.

В результате анализа логов работы SIM800C заметил плавающие задержки получения ответов на AT команды. Вот список команд, для которых задержки появляются регулярно:
1. AT+CFUN=1 ответ приходит через 0.2 - 4.2 сек.
2. AT+CSMINS? ответ приходит через 0.05 - 3.6 сек.
3. AT+IPR? ответ приходит через 0.05 - 2.5 сек.
3. Включение BT модуля (AT+BTPOWER=1) ответ приходит через 2 -7.5 сек.
4. Разрешение на передачу данных по профилю SPP ">", приходит через 4.3 секунды,
если предыдущей командой был запрос RSSI (AT+BTRSSI=1) или был запрос сети AT+CREG?
5. AT+BTSPPCFG="MC",1 ответ приходит через 0.05 - 2.7 сек.
6. AT+BTSTATUS? ответ приходит через 4.1 сек.
7. AT+BTSPPCFG="MC",1 ответ приходит через 1.3 сек.
8. AT+BTRSSI=1 ответ приходит через 0.2 - 2.5 сек
9. AT+CBC ответ приходит через 0.2 - 1 сек.
10. AT+CREG? ответ приходит через 0.2 - 2.9 сек.

Возможно, такое поведение есть и на другие команды.
Появления факта задержки заметил при переходе от одного системы к другой. Например, 1. Был сделан запрос наличия сети AT+CREG?, ответ на неё быстрый. А потом передача по BT (AT+BTSPPSEND=1,37), то приглашение на передачу (“>”) придёт уже с задержкой.
2. Был сделан запрос АКБ (AT+CBC), а потом был сделан запрос наличия сети AT+CREG?, ответ пришёл с задержкой. Потом передача по BT (AT+BTSPPSEND=1,37), то приглашение на передачу (“>”) приходит уже без задержки.

Питание модуля от ST1S14PHR, напряжение 4.1В. Напряжение стабильное, без просадок, измерено осциллографом. При питании от лабораторного БП, макс. ток которого 3А, поведение такое же. 2 платы ведут себя одинаково. Инициализация PWR KEY по даташиту.

Теперь вопрос, это нормальное поведение? Т.к. на SIM900R я таких задержек не замечал.

[CADiLO]

Абсолютно нормальное явление. В модуле крутится многозадачная операционка в которой приоритет отдан основным стекам.
Поэтому для АТ команд выделен низший приоритет. Как я уже объяснял, в документе SIM800 Series_AT Command Manual для
некоторых команд указано максимальное время выполнения. Если его нет, то либо выполняется сразу, либо она операторозависима
и будет ждать реакции оборудования оператора. Поэтому ждем OK, ERROR, URC и так далее и не делаем из модуля пулемет.

[Rash]

Да это я всё понимаю. Сложно принять то, что в эпоху армов, тактовой в несколько сотен МГц, с кучей каналов DMA и ОЗУ приходится наблюдать ответ в единицы секунд. Когда это операторозависимая команда, это логично. Для всех остальных команд, ИМХО, ответ должен быть в приделах макс. 100-500 мсек.
В документации на большинство команд ожидания ответа стоит прочерк, но на самом деле это не так. Даже прочитать напряжение батареи может доходить до 1 сек. По факту внешний CPU должен читать уже сохранённые статусы модуля, Напряжение, Сеть, RSSI и т.п., а такое впечатление, что эти проверки модуль делает по запросу с AT команды.

[HardEgor]

По факту внешний CPU должен читать уже сохранённые статусы модуля, Напряжение, Сеть, RSSI и т.п., а такое впечатление, что эти проверки модуль делает по запросу с AT команды.

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

[Rash]

возможно, только эти же задержки (естественно команды касающиеся GSM сети не отправляются) можно наблюдать когда сим карты нет, а работа ведётся только через BT модуль. Да и работу через UART реализовать можно используя DMA и принимать посылки целыми фреймами, в случае ARM.
Ну а если времени не хватает, то некорректно выбрана процессорная база или написанное ПО. Повторю, что в SIM900R этого не видел, там всё чётко было. Но в данном случае либо подстраиваться под текущий модуль, либо искать другой. Но с нынешними тенденциями в мире, что ПО всё больше и больше жрёт ресурсов, но при этом полезность его не увеличивается, думаю что у других производителей будет примерно тоже самое, тем более если чипсет такой же.

[ArtemKAD]

Сложно принять то, что в эпоху армов, тактовой в несколько сотен МГц, с кучей каналов DMA и ОЗУ приходится наблюдать ответ в единицы секунд.

Дык всё просто. Внутри многозадачка в которую встраиваются в т.ч. задачи отправляющие ответ в шину. И пока не выполнятся более приоритетные задачи задача отправки ответа будет висеть на ожидании.

[CADiLO]

800 серия имеет возможностей на треть больше чем 900, вот ресурсоемкость. Кроме того в 900 крутилась OC от PNX, а в 800 - от МТК, и реализована многозадачность совершенно по разному.
И тут вы правы, одинаковый чипсет, одинаковые фичи/баги, так как основное ядро дает производитель чипсета, а производитель модулей делает только "надстройки" пользуясь выделенными ресурсами.

[Rash]

ArtemKAD, ну так в чём проблема, если это многозадачка, выделить время на ответ обычной команде, не операторозависимой. Оправдать можно всё что угодно. Если в следующей версии модуля ответ на запрос сделают 20 секунд, то тоже будем списывать на многозадочность. Там, что мега на 8МГц работает?

CADiLO, вот и получается, что ОС от PNX в моём понимании лучше, чем MTK, но вернуться нет возможности. Подстроится можно под всё, а вот осадок остаётся. Т.к. потом юзеру нужно объяснять, что шли благополучно данные, а потом опа - пауза на 5 сек., а моё ПО проверило всего лишь сеть (как антизависон) и АКБ. Понятно, что с одной строны к Симкому претензий нет, т.к. они используют ресуры ОС, но с другой стороны выбор ОС стоял за разработчика и железо тоже, которое её по факту тянет с трудом.

[ArtemKAD]

ArtemKAD, ну так в чём проблема, если это многозадачка, выделить время на ответ обычной команде, не операторозависимой.

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

[HardEgor]

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

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

[Rash]

Коллеги, Ваши объяснения хороши, но я не новичок в электронике и программировании. И если честно, то объяснения про многозадачность ОС, её приоритеты, сто тысяч пятьсот модулей для покупки, воспринимаю, как оправдания за кривой драйвер UART или кривой диспетчер задач в ОС, или железо не подходящее по производительности. Т.к. модуль себя ведёт одинаково, что с СИМ картой, что без. А соответственно, если нет сим карты, то какие особые задачи он обслуживает?
Другой вариант - это возможно, что общение с UART специально сделали таким, чтобы пользователь не нагружал или перегружал модуль большим количеством команд, а изначально ориентировался и привыкал к такой медленной работе.

[krux]

Rash
в некоторых чипах есть DSP-ядро для обработки baseband от GSM и bluetooth. а в других его нет, и он обсчитывается на основном CPU.

[x893]

Так как вопрос риторический (тем более от гуру электроники и программирования), то ответ такой же должен быть.
Это нормальное поведение для этого модуля.
На другом модуле может быть по другому.

[Rash]

x893, Стёб то тут причём?

[x893]

Нет никакого стёба - нет настроек по изменению приоритетности снаружи.
Поэтому как есть так и есть.
Либо модуль другой брать, либо использовать как есть.

Может и есть настройки, что бы поменять внутренние настройки, но никто их не скажет.