Ну вот подумайте STM32103RET стоит около 5$(в принципе хватит даже STM32103RСT). Порт FreeRTOS для этого контроллера есть, так-же есть порт lwip+ppp для freertos, т.е. практически все системное п.о. уже написано, только бери и кушай . При этом мы получаем систему с которой работать на порядок удобней чем со встроенным стеком соответственно уменьшается время разработки. Кроме того возможности такой системы намного шире, например попробуйте открыть с помощью Simcom-вского встроенного стека пару серверних портов, с помощью стека от Telit вы сможете открыть несколько портов но при этом каждый серверный сокет может принять только одно соединение, а это не годиться, к примеру, для web-сервера, и.т.д. Кроме того, как бонус, отказавшись от встроенного стека мы получаем практически полную независимость от типа gsm модуля.
Честно говоря вижу лишь один случай когда использование встроенного стека оправданно - когда программа работает на самом модуле(OpenAT, OpenCPU, phyton, java итд)
ЗЫ Недавно пришлось преводить девайс на Sagem HILO NC на внешний стек по причине глючности внутреннего. И был приятно удивлен насколько это просто.

А как смс принимать? А входящие звонки?
TCP стеку для стабильной работы нужны приёмные буферы приличных размеров. В simcom они влазят, а в ST 103 уже со скрипом.

Режим мультиплексирования(CMUX). Один порт на передачу данных, другой на SMS и прочие нужды.

Насколько большие?
В реальности хватило даже LPC2146 с ее 32 + 8К.

Точно не знаю, но lwIp у меня без буфера в 4K начинал внезапно чудить. И это клиент с одним сокетом. Сервер без 16K лишней ОЗУ я бы не рекомендовал делать.

Вы про MEM_SIZE? У меня установлен параметр MEM_LIBC_MALLOC, так-что вместо отдельной кучи для lwip используется общая системная размером 10К. Два серверных сокета, максимум 2 активных соединения. Занято 34 501 байт ram, это на все не только ip стек.
PS разумеется 32+8К это мало.

>>>например попробуйте открыть с помощью Simcom-вского встроенного стека пару серверних портов

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

UDP server function in Multi-connection mode
we add one more parameter <index> before the parameter <mode>

AT+CIPMUX=1

OK
AT+CIPUDPMODE=0,1 //0 is the <index>

OK

AT+CLPORT=0,"UDP",8888 //udp local port 8888

OK

AT+CIPHEAD=1

OK
AT+CIPSRIP=1

OK
AT+CSTT

OK
AT+Ciicr

OK
AT+Cifsr

10.4.64.80
AT+CIPSTART=0,"UDP","116.236.221.75",6666

OK

0, CONNECT OK
AT+CIPSEND=0

> test
0, SEND OK

+RECEIVE,0,9,"116.236.221.75:6666":
test 6666

AT+CIPUDPMODE=0,2,"116.236.221.75",3114

OK
AT+CIPSEND=0

> test
0, SEND OK

+RECEIVE,0,11,"116.236.221.75:3114":
werfafqfqwf

+RECEIVE,0,9,"116.236.221.75:6666":
test 6666

2 CADiLO ну вы хоть-бы ":)" поставили. Разумеется речь идет tcp сервер. Не зря ведь там дальше про web-сервер написано.

не переживайте, TCP тоже тестировали... спроса на мультиконнект нет, а делать "абы було" китайцев еще убедить надо.

TCP сервер тоже работает

P.S. поставлю смайлик на всякий случай : )

Да я и не переживаю и на simcom кстати не наезжаю. Основная мысль такова - если в проекте предполагается использование внешнего контроллера то зачем использовать внутренний стек модуля? Это даст экономию максимум пара $ зато потенциальной головной боли... причем боли с которой вообще ничего сделать нельзя(пример - Sagem чтоб его HILO).


Работает, один, поддерживает несколько соединений. Попробуйте создать 2 сервера один к примеру на 80 порту второй на 502. Да суть собственно не в том. Контроллер это не комп(даже на компе есть ограничения), ограничения будут в любом случае, но разница в том, что вы можете сами выбирать эти ограничения.

http://youtu.be/ezLFV-mZ8bE

Мда... в некоторых случаях медицина бессильна...

Что, и SSL прикрутили, или VPN ?

И зачем дивайсу с подключением по GPRS несколько слушающих портов?
Чтоб из него весь лимит выкачали всякие сетевые сканеры?

Т.е. я тоже за отказ от встроенных в модули стеков, но аргументацию привел бы другую.

SSL это да... прикрутить можно, например PolarSSL, но контроллер понадобиться со 128K RAM, что-то вроде STM32F207VCT. А это уже порядка 9$. По поводу VPN насколько знаю модулей со встроенным VPN нету(ну может у telit 863 которые с linux на борту но там цена...).


Ну вот конкретный пример: есть девайс основное назначение которого передавать данные через RS232 от счетчиков, контроллеров и.т.д. через GPRS. На контроллере так-же есть цифровые входы, выходы, внутренние регистры к которым можно обратиться по modbus-tcp протоколу. Соответственно один порт открываем для работы с RS232, второй для работы с внутренними регистрами.
А что до сканеров... такие девайсы обычно работают в закрытых сетях, там чужих нет.


Ну я не претендую на идеальную аргументацию. Если есть другие мысли на эту тему, то давайте...

Я так и подозревал судя по номеру порта.
Но здесь большая опасность.
Скажем HMI панели OMRON выдают запросы по modbus-tcp без интервалов. И там вообще нет регулировки этих интервалов.
И если скажем дивайс успевает откликнуться 100 раз в секунду, то панель его столько раз и опрашивает.

Т.е. беспроводную сеть такой modbus клиент просто зафлудит запросами.

Сканеры тоже работают в локальных сетях провайдеров очень агресcивно.
Сканированием например пользуются пакеты управления корпоративной инфраструктурой как HP OpenView.

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

Вам что, работы и головной боли без стека не хватает? Не нравится стек Sagem, перейдите на SimCom или Telit...


Суть как раз в том, что контроллер не комп. Он имеет кучу ограничений как по оперативке так и по быстродействию/потреблению. И ресурсов зачастую внутри модуля гораздо больше чем во внешнем МК.
Кроме того, ошибочно считать, что используя внешний стек можно выбирать ограничения. Для такого надо самому разобраться во всех нюансах протокола и написать собственный стек. Иначе используешь чужой самописный стек как есть со всеми его ограничениями и глюками. Причём зачастую этих ограничений больше чем во внутреннем стеке.

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


И толку с этих ресурсов внутри модуля? Что с ними делать? А по поводу быстродействия... мы ведь говорим не про 100МБ ethernet, или Вы считаете, что 60МГц ARM не достаточно для GPRS? Поверьте более чем достаточно. По поводу потребления - никто при необходимости не мешает динамически управлять частотой проца, внешних шин, отключать неиспользуемые модули, итд.


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

Дать с ними работать встроенному стеку.

Работал я по ModBus и Mbus через GPRS с вполне себе промышленными метрологическими устройствами.
Одно дело, когда всё это по проводам передаётся, другое, когда все посылки бьются кусками и задерживаются минимум на 1-2с гдето в "воздухе".

Вобще не очень понятно чем отличается в конечном счёте прозрачный режим модуля от реализации своего стека. Разве что размер буфера можно самому назначать.

Modbus тут за уши привязан к GSM. Я сомневаюсь что кто-либо имеет удачный опыт применения реального Modbus с GSM.
Как минимум нужны конвертеры.

А термин "прозрачный режим" я вообще не понял.
Встроенный стек это черный ящик основанный на плохо специфицированном управляющем протоколе AT команд, о какой прозрачности можно говорить?

Как на встроенном стеке сделать такие вещи как SNMP, RIP, GRE, IKE и SSL (со своими сертификатами), NAT, IPv6, да даже изменить такие важные параметры TCP стека как: максимальное время ретрансмита, размер окна, задержка ACK, интервал Keep-Alive и еще десятки параметров?

Скажите, какому проценту пользователей нужны такие дебри? Думаю что максимум 2-3% от всех потребителей модулей.
А значит напишут сами. Остальным вполне достаточно того что умеет встроенный стек.
Отсюда прямо по бритве Окама - "Не превышай сущность сверх необходимого".

С конвертерами схема типа [OPS Server] <->[GPRS(modbus-tcp)]<->[Конв. Modbus-tcp to RTU/ASCII]<->RS232/485<->[Конечн.у-ва] прекрасно работает. Т.е. конвертер нужен, но если он есть то все OK.
PS стеки с SSL и возможностью записи своих сертификатов есть, например у телита, правда только клиент.


Так может может встроенный стек это и есть "сверх необходимого"? Ладно если-бы производители договорились о каком-то едином стандарте. А очень весело выходит когда код который работал на старой версии прошивки вдруг начинает глючить на новой, потому-что производитель решил что-то улучшить.

Вопрос немного не в тему, но все-же спрошу.

А каким образом можно реализовать свой стек TCP?
Ведь жсм модуль, в сторону проца, может выдать только два типа какна UDP или TCP.

Или TCP работает поверх UDP, т.е. дайм процу комаду установи UDP соединиени, а затем по верх него мы устанавливаем TCP соединение?
Или жсм модуль может выдать процу еще третий тип канала, который не UDP/TCP, даже не знаю как его назвать, raw data???

Попробуйте начать с http://ru.wikipedia.org/wiki/TCP/IP

Спасибо, поверх IP работает.
Я так понимаю, что модем устанавливает IP соединение, как им можно управлять? (в сим900)

Читать первоисточники.

Нет. Если вы имеете ввиду внешний стек то после набора atd*99***1# т.е. выхода в gprs вы должны установить соединение по ppp протоколу(канальный уровень), и уже поверх него работает IP. И это не зависит от типа модуля.

Transparent mode я имел в виду.
Я даже шифрование поверх него накручиваю.


ЗЫ Mbus у меня не получилось накрутить на GSM не изза отсутствия конверторов , а изза разбиения посылок на куски и жёсткой временной спецификации на конкретные приборы. Как то криво получается работать с GPRS модулями для установки их в качестве "портала". Даже модемы от производителя как то криво работают. Мож у нас GPRS такой особенный

приведите, пожалуйста, пример ВАШЕГО серийного устройства, ну, хотя-бы 100штук в месяц, где используется ДВА сервера

Согласен с автором, ввнешний стек это вполне юзабельно на далеко не самых дорогих камнях.
Для меня главный повод освоить его было нежелание тратить свой мозг на бестолковые изучения ат команд. И как автор правильно заметил - абсолютная свобода в выборе модема, вплоть до проводных и ethernet. Проектные цены на микроконтроллеры далеки от розничных про которые тут речь шла, контроллер за 2-3$ вполне тянет стек и полезную задачу с несколькими соединениями. Так же стек поддерживаает мульти-PPP, так что можно через 2 соединения одновременно выходить в сеть, например один будет проводной (eth), другой беспроводной (gsm). И много других интересных возможностей открывается программеру при использовании внешнего стека.

при использовании своего стека энергосберегающие режимы работают?

При какие функции идет речь? CFUN абсолютно безразлично какой стек вы используете. Предавать данные в каком либо режиме кроме "1" разумеется не сможете.

Как пример - очень давняя разработка 2007 года на PIC18F1320 (256 ОЗУ, 8К флеш) - в гугле поиск "cambridge gprs": самописный стек на asm, работает через PPP - GPRS старых сименсов (начиная с C55) и Ethernet (ENC28J60). Поддерживал tcp, udp, dns, dhcp-клиенты. Плюс еще tDES или AES128 внутри на выбор. Сложного там особо ничего - иногда с АТ-командами внутреннего стека больше геморроя.
Но сейчас есть встроенные приложения (OpenAT, OCPU), с помощью которых можно реализовать любые надстройки силами самого модуля (в т.ч. и езернет прикрутить ч/з SPI). Также можно изнутри модуля дозвониться на *99***1# и своим кодом программно подять ррр.
Так, например, понадобилось сделать для роутера из LAN ч/з езернет (ENC28J60) в WAN ч/з GPRS (M12). Т.к. необходимо править IP-заголовки (портмаппинг), то внутренний стек модуля не подходит - тут надо работать на уроне IP-пакетов.

Читайте манулы внимательнее. BGS2 прекрасно передает и принимает данные в режиме CFUN=7 (другие просто не проверял, но думаю тоже долно работать). Другие модули также должны. Зачем вообще нужны режимы энерго сбережения если они не позволяют обмен данными. Проще тогда вообще отключать питание модуля.
А вот при самописном стеке такое возможно?

Прежде чем читать мануалы неплохо-бы ознакомиться со стандартами. Так-вот согласно GSM 07.07 описано 5 уровней функциональности 0-4. Из них обязательными к реализации являются только 0 и 1. Все, что выше 4 отдано на усмотрение производителя. Соответственно как ведет себя BGS2 в седьмом режиме я не знаю и знать не могу поскольку с этим модулем не работал. Более логично задать этот вопрос техподдержке производителя.
Стандарты, если интересно, ищите здесь.
Маленько ошибся, мануалы на Ваш модуль ссылаются не на GSM 07.07 а на 3GPP TS 27.007, но там то-же самое

BGS2 приведен для примера. Как он себя при использовании внутреннего стека в режиме энергосбережения я знаю.
При своей реализации IP стека будут ли работать режимы энергосбережения модуля? CFUN=0 например, он обязательный.

Вместо чтения стандартов, предпочитаю читать даташиты, сразу становится понятно что реализовано.

Подключите модем к компу. На компе есть TCP/IP стек. Подайте команду AT+CFUN=0. Сработало? Теперь попробуйте установить соединение не получается? Теперь аналогичные действия для CFUN = 7. Не могу сказать однозначно про BGS2, но MC52i в 7-м режиме соединение устанаваливает, а поскольку оба Cinterion-ы то...


А зря.

Ха. Причем тут стек то. Просто комповый драйвер не умеет выводить из CFUN=0. А еще вероятней проблемы с неработающим/выключенным flow control. CFUN=7 работает и хорошо. разницы по потреблению между этими режимами практически нет. Я получил ответ на свой вопрос, спасибо .

ps: не понравился мне CFUN=0, надо RTS тащить до модуля. CFUN=7 практически тоже самое, но обходимся только CTS.

А в этих режимах энергосбережение сколько мА потребляет модем?
Я всегда пользовался стандартным режимом сна, управляемым как правило через линию DTR, модем потребляет при этом ок. 1мА. При этом и внешние стеки и все остальное полнофункционально работает. Через CFUN можно что то интереснее получить?

Около 1мА и потребляют.