Здравствуйте!

Насколько стабилен и удобен Embedded AT?
Есть ли какие-либо ограничения, подводные "камни" и др.?
Имеет ли смысл закладывать его в изделия, планирующиеся к выпуску на следующие несколько лет?

Напишите товарищу с ником Peps, он с самых первых версий разбирался.

За время работы с ЕАТ особо больших глюков не заметил. Достаточно стабильно и удобно. Но! Если модуль зависнет - то будет висеть долго и успешно. Поэтому тут на форуме пришли к выводу, что нужно внешний вачдог - я делал на PIC10F200.
Первое устройство сделанное на ЕАТ работало без вачдога. Я отдал все заказчику, и дальнейшая судьба проекта неизвестна.
В следующем проекте я от EAT отказался - поставил дешевый STM8S и буду использовать дешевые SIM900R.
Хотя, надо отдать должное, использование EAT очень удобно - ваша програмерская задача будет заключатся в обратотке событий. Кроме того, если ограничены в размере платы, сэкономите на размере внешнего контроллера, питании контроллера, кварцевом резонаторе и т д. Еще удешевится сборка.


Ограничения обнаружилось в виде невозможности управлять быстрыми процессами, типа почитать DS1990. А в остальном все отлично.


Решать Вам. Если это будет контроллер ядерного реактора - то навряд ли.... А так - почему бы и нет... Я склонился к варианту SIM900R+микроконтроллер.

Все же почему? И габариты больше и стоимость.

Добавлю что мне на сегодня известно о более чем 50 рабочих проектах на ЕАТ. Из них несколько достаточно крупные (500-600 изделий в месяц). "Антизависатель" желателен - способ реализации может быть любой - от одновибратора до маленького контроллера.
Релиз был анонсирован и выпущен к GSMA Mobile World Congress 2012 - находится по известному адресу.
Ну и останавливаться на этом Симком не будет, список того что будет добавляться представлю чуть позже, по имеющимся сведениям в прошивку войдут примерно в начале лета.


>>> Все же почему? И габариты больше и стоимость.

Габариты - да только за счет контроллера - 900 и 900R pin-to-pin.
Хотя контроллер в TQFP или QFN можно и под модулем разместить. Не так уж габариты и выростут.
http://oko.plys.kiev.ua/oko-s.htm
http://smartprecision.ru/projects/rf/z1100_stm.html
По стоимости при серийном производстве можно выйти на цену обычного SIM900 при большей функциональности.

Я писал свое ИМХО для одного из семинаров - процитирую кусочек:

.........желание иметь все в одном модуле не есть стратегически продуманое решение. Если большинство функций возложено на контроллер и внешние микросхемы, то пропажа с рынка или временная недоступность модуля не будет являться проблемой. Сменили производителя и всего-то делов.
А чистый GSМ софт правится под другой модуль за пару дней – стандарт команд GSM07.07 еще никто не отменял.
Ну а самые хитрые…. Есть пользователи у которых на плате разведено под 4 (ЧЕТЫРЕ !!!) модуля – SIM900, GL868, M10 и Wismo228 – и софт сразу знает кого на плату воткнули – так что продукция будет выпускаться если даже три производителя из 4х пропадут с рынка. Да и варьировать легче - хочешь подороже но с "фирмой" - пожалуйста, а массово и подешевле - так тоже ничего переделывать не нужно.
А вот если все функции завязать на модуль…. Несколько недальновидно….. Правильнее будет на модуль возложить только то что все умеют – а фирменные «фишки» пусть контроллер обрабатывает.....

Вставлю и свои пять
Я с EАТ мало работал, т.к. предпочел оцпу из-за большего входного буфера ком-порта (1024 байт против 256 в ЕАТ), но:
+ ЕАТ (= ОЦПУ) очень хорош для реализации максимально дешевых и компактных изделий (например, бюджетные охранные сигнализации, трекера, GSM-коммандеры и т.п.) для массового производства;
+ очень полезен для создания своих протоколов (или АТ-команд) работы модуля с внешним процессором (т.к. ком-порт - это "бутылочное горлышко" и глюкогенератор...;
+ ресурсы ЕАТ достаточно весомы, что упрощает программирование;
- код EAT практически незащищен от копирования, поэтому необходимо пользоваться програмными механизмами защиты, что усложняет проект;
- это не RTOS, выполняется в своем потоке, приоритет ниже GSM, что требует специфики в реализации низкоуровневых протоколов с ног модуля (а часто необходимости дополнительного контроллера);
- сильно усложняется обеспечение энергосбережения, аварийного мониторинга и т.п., тут проще использовать дополнительный дешевый пик, а математически нагруженные алгоритмы исполнять средствами ЕАТ

Если сравнивать ЕАТ (Simcom) и OCPU (Quectel), то:
- оцпу имеет гораздо шире API (например, IP-стека, СМС, звонки и т.д.), в то время как ЕАТ вынужден пользоваться стандарными АТ-командами через виртуальный порт;
- в оцпу больше размер буфера данных для событий;
+ в SIM900 более мощный ARM

А так все одинаково: в отдельном потоке на платформе 32 bit ARM исполняется нативный код, скомпилированный с исходников на С. Т.о. можно включать в ваш код С-реализации любых функций.

Наши забугорные друзья подошли к использованию GCC вместо RVCT, осталось конвертнуть линкеровский сценарий....
Может кто реализует - тогда и компилятор не будет "проблемой".

As I could see in SIM900DevIDE\EmbatSIM\gsmos\tools\app_make_inc_s file (included in make script), our friend brucefan used yagarto 4.5.0 (arm-none-eabi-gcc-4.5.0.exe), I used yagarto 4.6.2, just removing the version (arm-none-eabi-gcc.exe in app_make_inc_s file).

I have no problem with compiler. Now, there is no linker script file (embat.lds). Using RVCT, the linker comand begin with:

"armlink.exe --catter ../EmbatSIM/gsmos/flcode/scatter.map(...)".
Did someone do the ADS scatter to GCC linker script conversion?

Во первых, антизависатель на пике мне бы обходился в 0,5 у.е., столько же планирую платить за STM8S103 с 8 кБ флешки и прочими приятными вещами. Далее - по просьбам трудящихся сохранил работу с ключами на DS1990 - тож без контроллера не обойдешься... При наладке нужно прошивать модуль и PIC, в моем случае только один микроконтроллер.
Да и как заметил уважаемый CADiLO, если (тфу тфу тьфу) SIMCOM навернется, с легкостью перейду на другого производителя. ЕАТ - отличный инструмент для быстрой разработки.

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


В принципе, не вдаваясь в тонкости оптимизации, без разницы чем компилировать. А вообще-то RVСT, наверное, получше GCC будет. Кстати, им же ядро китайцы компилируют. Неужели все такие щепетильные стали, что влом серийный диска поменять? Ну, народ...

Ну как говорится - "сильно просят"..... Хочется некоторым GCC, почему бы и нет....
Если на том форуме сделают раньше наших - выложу откуда взять результаты....

Если кому интересно в архиве исходники тестового приложения для SIM900 со всеми потрохами для сборки arm-none-eabi-gcc

Если кто может поделиться более свежим sym файлом ядра, чем 1137B04V01SIM900M64_ST_EAT.sym, буду премного благодарен.

Последний этот.

Спасибо. Вот обновлённая версия

Поправил багу с инициализацией статических переменных