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

В результате анализа логов работы 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 я таких задержек не замечал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно конечно обойти обработку UART в АТ командах и воспользоваться напрямую АPI.
Это даже решает некоторые проблемы с буфером UART при работе с IP.
Но для этого свой обработчик пишем на ЕАТ и заливаем в модуль.
Большого ускорения конечно не даст, но ответы будем получать прямо из API ядра, а не от промежуточного обработчика.
И есть еще минус - API есть не для всех команд, впрочем это уже другая история - читаем доки по ЕАТ.

А у меня наоборот претензии к Симкому. Прикрывают OC MTK некомпетентность своих разработчиков. У их конкурентов, использующих тот же MTK чипсет, багов о обработке AT команд, присущих Симкому, нет.
Такое ощущение, что грамотные инженеры их покинули, остались лишь "ардуинщики", которые даже не знают, что такое приоритеты OC, и вcе делают на основе "HelloWorld" от MTK.

Я по работе тестировал и Quectel, и Mobiletek, и всяко разно другое - те же уши, только в профиль.
По времени выполнения команд абсолютно одинаково ведут себя.

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

Disadvantages and restrictions:
• There is no way to control the minimum time to wait between finishing an AT command and sending the next one.

About timing.
• The sequence of processing the AT commands may be different from the sequential order of command input.
• Many AT commands cannot be concatenated. Concatenating these commands might end up with an error result code, or leads to an unexpected order of responses.

CADiLO, это понято, что время исполнения плавающее. Только вот порядок разброса времени у разных модулей разный. Честно, устал уже слышать от Симком-а что все это не они, а производители с их ОС (MTK) виноваты...
Хватит уже пенять на зеркало!

По поводу цитаты с BGS2:
>> • There is no way to control the minimum time to wait between finishing an AT command and sending the next one.
Так тут про минимум, а не максимум! Ну, и как бы <OK> надо ждать по-любому.

>> • The sequence of processing the AT commands may be different from the sequential order of command input.
Куда-то в лужу. Если по окончании выполнения комады идет <OK>, и его надо ждать, то как порядок может быть нарушен?
>> • Many AT commands cannot be concatenated. Concatenating these commands might end up with an error result code, or leads to an unexpected order of responses.
Ну, возможно есть ограничения. Так может написано какие можно, а какие - нет. В любом случае, претензии к ним уже.

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

Ну не нравится вам Симком, не пользуйтесь. Или ругаем его но продолжаем жрать кактус?
Поработайте например с Неовеем - потом на Симком молиться будете.

Кстати еще по плавающим времянкам - такое может быть если стоит автободинг, а не фиксированная скорость UART.