Добрый день!
На М12 реализовать автодозвонщик без внешнего управляющего контроллера невозможно, поскольку этот модуль бюджетный и не поддерживает технологию OpenCPU. Для Вашей задачи вполне подойдет модуль М10.


Сообщение отредактировал CupuyC - Dec 29 2010, 10:26

Спасибо огромное! Понял. А как расшифровать "технология OpenCPU"? Open - я так понимаю "открывать". Для начала я так понимаю необходимо составить програмку из АТ-команд. Слава богу Rainbow AT-команды на своем сайте для М10 выложил. Уже легче дышать. А потом как я понимаю необходимо сварганить программатор, и потом все это запихнуть в контроллер модема.

Open - открытый, CPU - центральный процессор. Короче говоря openCPU - открытый доступ к процесору. Предоставляются исходники прошивки, куда можно дописать свой код на С. Скомпилили все и зашили в DSP модуля.
Ранее я выкладывал спецификация на openCPU.

В моем предыдущем посте есть ссылка на наш сайт - там тоже все выложено.

1.Какую схему контроллера для программирования модема необходимо спаять.
2.Как правильно писать АТ команды.
3.Как подключать программатор.
Заранее спасибо всем.


СириуС спасибо розжевали! Теперь немножко понятно. Со спец терминами в этой области я пока не знаком.

Простите, Игорь, но я вас немножко поправлю.

Исходники не даются, даётся набор функций(некий API), при помощи которого можно написать свой код, зашить его в модуль, и уже из него совершать звонки, отправлять и принимать данные по GPRS и СSD, взаимодействовать с переферией модуля. Программатор для этого не нужен, код записывается в модуль как часть прошивки. Для отладки есть возможность ипользовать только уарт, ну и светодиод(впрочем так у всех, кто дает возможность написать код исполняемый процессором, а не скриптовый язык, как у Telit, какие там механизмы отладки - я не знаю).
Ну и прошивка своей программы, естественно не в DSP, а во флеш память.
Языки - C, C++, для извращенцев - ASM

Компилятор платный - CodeWarrior(в инете есть с таблеткой), легко можно писать на IAR(проверено), на GNU я так думаю тоже получится. Вся суть в том, что в SDK входит непосредственно прошивка модуля, заголовочники функций API, докуентация, примеры и (!)перечень всех переменных и функций с их адресами(не только API). Так же в инете легко находится даташит на процесор.
Короче говоря, если обладаете минимальным пониманием что такое ARM, компилятор для него и что такое RTOS - работать с OCPU одно удовольствие!

если вы действительно программист , каким и я был когда то давно, то слова
"Исходники не даются, даётся набор функций(некий API), при помощи которого можно написать свой код" наводят на тихий ужас.
очередная openAT..., даже Wavecom уже начал потихоньку отказываться от этих технологий.
Ведь цены на кортексы валятся и валятся вниз и вниз. уже доллар за микроконтроллер на 120МГц.
TI, так те вообще обещают в этом году полубаксовый вариант тут хоть как то рулить можно своим приложением...
хотя если вам нужно просто послать SMS то возможно ...

Сообщение отредактировал Telit - Jan 2 2011, 09:24

Простите, а чем это отличается от API, который дает Telit? И почему это Вас наводит на тихий ужас?

Как бы вы не говорили о крутости виртуаальных машин(а интерпретатор phyton это и есть виртуальная машина), но почемуто все производители тех же мобилок, стремятся сделать игры и приложения не на виртуальной машине(Java), а неким приложением исполняемым CPU.
Например платформы Brew, BADA, симбиан, андроид и яблочная ось. Они тоже Вас наводят на тихий ужас? А ведь принцип один.
Я питон(фитон?) телита не пробовал, но сам принцип виртуальной машины, при прочих равных условиях, не может позволить ей работать быстрее кода, исполняемого без этой программной прокладки.
И думаю с этим согласится любой программист.
Если я не прав то поправте.

Сообщение отредактировал kovz - Jan 4 2011, 06:11

Нет. отчасти вы конечно правы. Виртуальные машины медленны, но позволяют очень быстро написать приложение и получить быстрый time to market. В первую очередь потому, что удобно переложить этот самый скрипт под любую аппаратную платформу. Пример этому - огромное количество разных програмулек под ту же симбу, джаву или пайтон (phyton), которые работают на разных платформах без проблем. Второй важный момент, что в случае виртуальной машины практически невозможно завалить саму ось, чего нельзя сказать про, например, OpenAT или китайские попытки избавиться от так называемой вами "прокладки".
Ведь, в случае M2M приложений, в первую очередь, как мне кажется, важна надежность, поэтому все более менее серьезные производители ограничились виртуальными машинами и скриптами.
А если хотите что-то быстрое, то малоногий кортекс M3 за доллар и минимум дополнений на печатной плате.

Соглашусь с "Telit" - Cortex или PIC32 на сегодня стоят достаточно дешево чтобы их ставить в связку с модулем. А возможностей реально больше чем у любого встроеного языка. Да и зависимости от капризов процессора модуля меньше. Но тут уж только дело вкуса.

Извините, но я не вижу причин существенного сокращения time to market при написании скрипта по сравнению с использованием API. Алгоритм создания своего приложения обеими способами одинаков(читаем мануал, пишем скрипт/код, отлаживаем работу приложения). Разница в том, что скрипт запускается вместе с интерпретатором phyton, который этот скрипт переводит в понятный для процессора язык. В результате процессор загружен интерпретатором + наш скрипт. Из-за такой цепочки получаем: медленную работу приложения и двойную загруженность процессора(скрипт+интерпретатор).
Используя API мы сразу после компиляции полущаем бинарник понятный процессору. Никаких интерпретаторов потребляющих ресурсы процессора, батареи, замедляющих быстродействие,.... Да, при написании кода с помощу API надо быть более внимательным, продумывать свой код и хорошо его отладить. Все не так уж печально, как Вы обрисовали.
Кортекс за бакс + обвязка + дополнительная стоимость за плату и монтаж умножаем на 500...1000изделий в месяц и получаем ЗП для хорошего программиста, который напишет стабильный код. При этом мы получим изделие более компактное, низкопотребляющее, дешевле, конкурентнее(по сравнению с изделием имеющим внешний МК).

Не согласен. У скриптового языка всёравно свой API. И абсолютно без разницы на чём именно писать.


так это проблемы тех кто пишет, а вот глюки модуля - разработчиков модуля.



Тут спорить не буду, но если можно и без него то зачем платить больше
+АТ команды, это вызов тех же API функций, только после парсинга того, что мы прислали.

Как по мне, механизм хоть OpenAT, хоть виртуальной машины решает именно проблему цепляния мелочи, для управления модулем. В сложных дивайсах без внешнего камня врядли обойтись можно, но там и задачи другие.

phyton это виртуальная машина (задача в ОС), а не интерпретатор, скрипт тоже можно также скомпилировать в бинарник, понятный этой виртуальной машине и скорость ничем не будет отличаться и энергопотребление тоже. ну также как и в случае с API, просто в операционной системе модуля появится дополнительная задача с более низким приоритетом чем GSM стэк. просто Java, Phyton признаны мировым сообществом, есть много уже готовых программистов, а изучать какой то API, выявлять его глюки, потом бесконечно писать в техсаппорт, чтобы подправили сначала одно, потом другое ...попусту тратить время.

я к тому написал, что не надежно все это. лучше внешний процессор как с точки зрения энергопотребления так и с точки зрения контроля за своим приложением.
к тому же если вы будете использовать какой то неизвестный API, то вы автоматом ПРИВЯЗЫВАЕТЕСЬ к конкретному модулю и теряете свободу выбора в дальнейшем. Многие проходили эту историю с OpenAT и Wavecom.
А работа программиста с API стоит таких же денег как и с микроконтроллером, поэтому с фразой "кортекс за бакс + обвязка + дополнительная стоимость за плату и монтаж умножаем на 500...1000изделий в месяц и получаем ЗП для хорошего программиста" я в корне не согласен.
а стоимость железа здесь просто минимальна.

Согласен с одним НО...
"кортекс за бакс" от этого не избавит по той, простой причине что, он (кортекс) общается с модулем через АТ команды. А интерфейс АТ команд есть ни что иное как тот же самый API как и встроенное приложение OpenAT. Быстродействие кортекса как и ПИК32 со всеми его мипсами за бакс, тоже сводится на нет. Да он быстрее среагирует на изменение состояния портов, позволит анализировать сложные переходные процессы с помощью более быстрого АЦП. Но упрется в АТ команды! Он позже OpenAT узнает обо всем что связано с GSM событиями. Будь то входящий вызов или СМС, удачная или неудачная попытка дозвона или отправка СМС. В общем я считаю, что для 90% применений достаточно доступа к процессору модуля, а внешний проц нужен для расшерения (кол-во входов\выходов, CAN, и т.п.). Многие здесь пишут о том, что встоенная ОСь справится только с "бебиситором", мне было бы интересно узнать какие проекты создает уважаемое сообщество, для которых ОБЯЗАТЕЛЬНО нужен внешний процессор? А на счет надежности... Я думаю выскажу не только мое мнение, один процессор надежнее чем два в связке. Принцип "слабого звена" никто не отменял...
P.S. Еще совсем недавно, когда я говорил про возможность декодировать DTMF средствами модуля многие кричали: "Нафиг не нужно, МТ за полбакса...". А теперь какой ажиотаж поднали.

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


абсолютно согласен.


и тут в точку! только вот ажиотаж как всегда возник вокруг SIMCOM. У других производителей эта функция, по сравнению с симком, давно. И работает, и никаких задержек после поднятия трубки, у некоторых умеет не только распознавать, но и генерить и не только DTMF, но и handshake и kissoff в стандарте ContactID(кто не знает что это - не заморачивайтесь, оно вам значит не нужно).

Почему же не нужно?

Было бы интересно если бы кто нибудь попробовал на GL868, успеет ли он посылки ContactID распознать...