Перейти к содержанию
    

Плавающие задержки ответов на AT команды

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Наверняка у разработчиков SimCom есть багтрекер(вот бы одни глазком взглянуть :) ) и там хватает более важных задач.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

И тут вы правы, одинаковый чипсет, одинаковые фичи/баги, так как основное ядро дает производитель чипсета, а производитель модулей делает только "надстройки" пользуясь выделенными ресурсами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Rash

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это нормальное поведение для этого модуля.

На другом модуле может быть по другому.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Нет никакого стёба - нет настроек по изменению приоритетности снаружи.

Поэтому как есть так и есть.

Либо модуль другой брать, либо использовать как есть.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...