QUOTE (TELIT. @ Oct 31 2011, 22:46)

Стэк AT комманд будет тот же как и для всего остального телита.
P.S. Имеет смысл начать применять телит

Тот кто скажет что я не пытался - соврет.

Но вот скажите, КТО придумывал интерфейс стека? Он пытался сам его использовать, или сделано "на отстаньте"?

Пример - выставляю в конфиге SRING URC по приему пакета с выдачей длины и данных сразу в hex виде. Ну надо мне именно unsolicited и именно в командном режиме.
Приходит UDP пакет длиной 67 байт. Я получаю...
SRING: 1,64,A60B41810000000000000000000000000000000007000000070A800002000000070A8000000
00000070A800001000000070A800004000000070A800006000000
SRING: 1,3,020300
Каким святым духом обработчик должен догадаться что первая строка SRING это не вся датаграмма, что надо ждать еще данных?... А если пакет был длиной 64 байта - просто тупо ждать таймаута? А если за это время еще пакет успеет прийти?
Второе - ну в последней версии вроде отправку UDP с одного сокета по разным адресам почти по людски сделали... Но прием... Почему чтобы узнать от кого пакет (если я работаю с одного сокета с несколькими peer-ами) надо запрашивать AT#SI? А если один за другим свалятся пакеты от двух разных узлов? Мне сама идея в проекте (изначально сделанном под Моторолу) где два разных треда занимаются отправкой команд и приемом данных с модема (включая обработку URC "на лету") делать дополнительные запросы по только что полученному URC - как серпом по гениталиям.
Ну почему бы не сделать как у той же Моторолы - каждый URC самодостаточен, в нем есть от кого, с какого порта, сколько данных здесь и сколько еще до конца датаграммы? Склеенные UDP датаграммы - все равно что не дошедшие, только трафик спален зря...
Реализация +CIEV URC оставляет только эхо матерных слов после себя. Ну нафига мне например обрабатывать +CIEV: rssi,5 (с текстовым названием параметра) когда практически у всех параметры - числовые. Держать таблицу названий параметров, тратить время на поиск по ней... Ну это ладно, даже не грабли, а так, измывательство.

Проматерились, пар выпустили, и живем дальше...

А вот грабельки (детские) похоже я одни несколько раз заметил. Правда на 200% еще не уверен в них, очень уж оно редко происходит, да и у меня код серийного устройства доработанный под Телит еще без серьезной обкатки, но все же... Выглядит так, что при столкновении выдаваемого модулем URC и команды от хоста эхо команды подрезается (теряется начало или все эхо целиком), команда выполняется и модуль уходит в несознанку, не принимая больше ничего, пока не дернешь питание. При этом URC из него продолжают сыпаться, если например сила сигнала изменилась, данные пришли или еще что. Прошивку до последней еще не обновлял (с OTA непонятка а на плате прототипа разъем ко второму порту я заложить то заложил, но вот оказалось что заказанные гнезда не лезут в посадку - заказал другие).
Если честно - я сейчас в раздумьях - не поднять ли восстание против "настоятельно рекомендующих" GL-865/868...

Особенно если по результатам "креш-тестов" изложенное в последнем абзаце подтвердится.
PS: Вообще интересно, какой процент потребителей вообще активно "на всю катушку" unsolicited responces использует? Может оно годами числящееся реализованным на самом деле и не обкатывалось никем и я хожу по "грабельному полю" в одиночку?