Подскажите, существуют ли модули способные отправить SMS по номеру например из SIM карты с каким нибудь коротким сообщением? Производитель любой. Цена разумеется чем дешевле тем лучше. Если могут то что кроме питания им надо. Управление отправкой например по GPIO или встроенному ADC

Могут, open-cpu называются.

У SIMCOM это называется EAT. Можно писать свое, довольно сложное приложение, а модуль будет его исполнять.
Можно не только принимать/отправлять SMS, можно заставить модуль говорить.
Например, SIM800C (там несколько моделей, желательно брать с памятью 32М).

Есть Telit с питоном внутри (GL868 или GL865 за 7-8 буказоидов).
Пишешь программу, загружаешь и радуешься.
И GPIO, и ADC есть там.
Конечно можно бубен купить и с open-cpu танцы устроить, но с питоном как то попроще.

Про open-cpu лучше сразу забыть, смотрел я их исходники - я в первом классе лучше писал, такое г. просто редкость. EAT - гораздо лучше, но очень много косяков, есть функции которые не работают, UART наполовину нерабочий, а при написании чего то чуть более сложного перезагружается, короче надо долго приспосабливаться и обходить "ловушки". В китае очень разочаровался. Telit выглядит достойнее, намного лучше документация, проще программируется. Я его особо не щупал, только на этапе выбора модуля, сейчас бы выбрал его. Но задачка совсем примитивная так что думаю EAT подойдет.

есть еще модули от cinterion - BGS5 и wavecom (что там сейчас не знаю), модули в два раза дороже но это того стоит, тем более если штучные изделия. BGS5 программируется на Java ME, все просто, документация отличная, тех поддержка отзывчивая и готова исправлять баги достаточно быстро (найти их будет крайне тяжело).

>>> EAT - гораздо лучше, но очень много косяков, есть функции которые не работают,

На сегодня для SIM800C уже девятый билд ЕАТ - 1418B09SIM800C32_BT_EAT
Особых косяков не обнаружено, а что касается UART, то там вопрос только к буферу - многим он не нужен, поэтому переписывают работу без него прямо через API.

>>>а при написании чего то чуть более сложного перезагружается,

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

Зато по цене на сегодня у SIM800C конкурентов не вижу.
SIM800C_24 в розницу $4
SIM800C_32 (именно он нужен под ЕАТ) в розницу $4.8

Если устройство удаленное, нужно предусмотреть автоматический включатель модуля.
у нас sim800C + mega13.
EAT имеет API для SMS, позволяющий получать/отправлять массив сообщения.
Если использовать режим PDU, то этот массив разбирать-собирать нужно будет самостоятельно.

>>> Особых косяков не обнаружено, а что касается UART, то там вопрос только к буферу - многим он не нужен, поэтому переписывают работу без него прямо через API.

тогда такой вопрос, какое API нужно использовать используется?
скажу сразу, то что проверяется 1 строчкой кода:
1. функция eat_uart_get_free_space не работает, все время возвращает 2048 (буфер пуст) даже если вызывать сразу после записи в порт. Если записывать не ориентируясь на свободное место, UART повисает, и больше не выдает данные.
2. EAT_EVENT_UART_READY_WR никогда не приходит. это к пункту 1 вопрос когда же можно записывать следующую порцию данных что бы UARt не повис.
3. уже не 1 строчкой кода. Если при установленном TCP соединении, включенным EAT_EVENT_UART_SEND_COMPLETE и низкой скоростью (проверял на 1200 бит/с, с 115200 работает) отправить данные то модуль перезагружается (стек около 5 вхождений - переполнение маловероятно, запись в UART производилась в callback от сокета, можно попытаться завернуть на очередь сообщений , но все это не очевидно , идем по граблям). это к пункту 2, EAT_EVENT_UART_READY_WR этим способом заменить не получится.

Остается только 1 функция - eat_uart_get_send_complete_status которая еще работает (пока не выявил в ней косяков, но это еще не последнее слово). Как переписать без буфера, он не отключается, записывать по 1 символу и в цикле ждать eat_uart_get_send_complete_status? модуль уйдет по своим делам и жди межсимвольный интервал по 5 мс.

По поводу SMS, ADC проблем пока не выявлено , но я пока еще его особо не тестировал. GPIO тож нормально за исключением пина SIM_DET, если его настроить как EINT то при изменении состояния модуль перезагружает.

для конкретной задачи, EAT оптимальное решение.

Можно для начала узнать на какой версии ЕАТ это происходит?
Какое ядро в модуле?

прошивка 1418B09SIM800C32_BT_EAT, ядро сразу не отвечу, как посмотреть? :-). Могу функции для проверки пунктов 1-2 написать, там не больше 10 строк, все видно сразу.

Про SIM_DET тож могу написать

но это не в эту тему

Ядро это и есть прошивка - B09

Есть нюанс - было несколько версий SDK

Крайняя для модулей с ядром от 07 и выше - SDK_1418B07SIM800C32_BT_EAT

Если ваш код скомпилирован на более ранней версии, а потом это просто пробуете грузить в модуль где ядро B07 и новее, то будут глюки.

Чтобы все работало, нужно перекомпилировать с новым SDK и его библиотеками.

Если компилировали именно с SDK 07 и глючит, тогда связывайтесь с локальным дистрибом и отправляйте ему багрепорт с примерами кода.
Будем разбираться и проверять.

Добрый день,
По wavecom сейчас это SierraWireless. Из умных модемов это серия WP. Есть несколько вариантов их запрограммировать. От написания простого варианта приложения под Linux используя нашу надстройку Legato так и просто написать под Linux свои приложения или пересобрать все ядро. Тут ограниченно фантазией автора.
Так же под Legato доступна система обновлений по воздуху ваших приложений которые отказоустойчиво все обновят при этом не убьют флеш память модуля.
И главное вам будет доступно полноценно процессорное ядро. Не время в планировщике.
Так же есть модемы по проще SL8 они поддерживают OpenAT.

использую SDK_1418B07SIM800C32_BT_EAT, сравнил с предыдущими версиями SDK , у них файлы core.lib идентичны, кроме него больше ничего линковать не требуется (кроме стандартной либы RVCT, которая к SDK не относится). В последней версии SDK только заголовочные файлы изменились, + API индивидуальное я так понял для конкретных заказчиков. Потому велика вероятность(проверю еще раз но маловероятно что есть ошибка) что это все в последней версии прошивок и sdk.

Вот же охота вам этим г....м заниматься.
Чем питон не угодил ?
Да - 4 бакса конечно офигенная разница.
Но учитывая время на танцы с бубном - как то всё смахивает на маз....м.

Разница становится существенной на тиражах от нескольких тысяч... особенно если прибыль с девайса составляет этак 10-15.

На тысячах и GL868 будет 4 бакса стоить.
Дело хозяйское конечно.

А как у него с энергопотреблением в активном режиме и в спящем? Что то подсказывает, что питон потребует доп. существенных энергозатрат по сравнению с eat.

питон - интерпретатор >> как бейсик на старых ПК
ЕАТ/OCPU/OpenAT - компиляторы >> выполняемый код

отсюда Вы правы - потребление у питона будет выше.

Если нужно что то совсем простое, типа отправка SMS по внешнему событию, то можно обойтись монитором событий. Соответственно потребление будет минимально, модуль будет просыпаться только по событию.

ADD: а если более сложное, то по монитору событий можно и скрипт запускать, по завершении которого модуль опять погружается в спящий режим.