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

[CADiLO]

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

[Alechek]

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

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

[CADiLO]

Я по работе тестировал и 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.

[Alechek]

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, а про невозможность объединять в одной строке несколько умалчивает (хотя по документации своей же разрешает).

[CADiLO]

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

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