[SiriuS 0]

Добрый день. Я начинающий товарищь в области модулей GSM. База знаний в области электроники имеется. Хотелось-бы спросить, возможно-ли на Quectel-овском модуле М12 собрать схему автодозвонщика без дополнительного контроллера? Охранная система для дачи. Какой нужен программатор, и как программируется сам модуль? Заранее всем огромное спасибо.

Добрый день!

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

 

Изменено 29 декабря, 2010 пользователем CupuyC

[Vylkan 0]

Добрый день!

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

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

[SiriuS 0]

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

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

Ранее я выкладывал спецификация на openCPU.

 

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

 

[Vylkan 0]

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

1.Какую схему контроллера для программирования модема необходимо спаять.

2.Как правильно писать АТ команды.

3.Как подключать программатор.

Заранее спасибо всем.

 

1.Какую схему контроллера для программирования модема необходимо спаять.

2.Как правильно писать АТ команды.

3.Как подключать программатор.

Заранее спасибо всем.

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

[kovz 0]

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

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

 

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

Ну и прошивка своей программы, естественно не в DSP, а во флеш память.

Языки - C, C++, для извращенцев - ASM :)

 

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

Короче говоря, если обладаете минимальным пониманием что такое ARM, компилятор для него и что такое RTOS - работать с OCPU одно удовольствие!

 

 

[Telit 0]

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

 

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

Ну и прошивка своей программы, естественно не в DSP, а во флеш память.

Языки - C, C++, для извращенцев - ASM :)

 

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

Короче говоря, если обладаете минимальным пониманием что такое ARM, компилятор для него и что такое RTOS - работать с OCPU одно удовольствие!

 

 

 

если вы действительно программист :smile3046: , каким и я был когда то давно, то слова

"Исходники не даются, даётся набор функций(некий API), при помощи которого можно написать свой код" наводят на тихий ужас.

очередная openAT..., даже Wavecom уже начал потихоньку отказываться от этих технологий.

Ведь цены на кортексы валятся и валятся вниз и вниз. уже доллар за микроконтроллер на 120МГц.

TI, так те вообще обещают в этом году полубаксовый вариант :) тут хоть как то рулить можно своим приложением...

хотя если вам нужно просто послать SMS то возможно ...

Изменено 2 января, 2011 пользователем Telit

[kovz 0]

"Исходники не даются, даётся набор функций(некий API), при помощи которого можно написать свой код" наводят на тихий ужас.

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

 

Как бы вы не говорили о крутости виртуаальных машин(а интерпретатор phyton это и есть виртуальная машина), но почемуто все производители тех же мобилок, стремятся сделать игры и приложения не на виртуальной машине(Java), а неким приложением исполняемым CPU.

Например платформы Brew, BADA, симбиан, андроид и яблочная ось. Они тоже Вас наводят на тихий ужас? А ведь принцип один.

Я питон(фитон?) телита не пробовал, но сам принцип виртуальной машины, при прочих равных условиях, не может позволить ей работать быстрее кода, исполняемого без этой программной прокладки.

И думаю с этим согласится любой программист.

Если я не прав то поправте.

Изменено 4 января, 2011 пользователем kovz

[Telit 0]

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

 

Как бы вы не говорили о крутости виртуаальных машин(а интерпретатор phyton это и есть виртуальная машина), но почемуто все производители тех же мобилок, стремятся сделать игры и приложения не на виртуальной машине(Java), а неким приложением исполняемым CPU.

Например платформы Brew, BADA, симбиан, андроид и яблочная ось. Они тоже Вас наводят на тихий ужас? А ведь принцип один.

Я питон(фитон?) телита не пробовал, но сам принцип виртуальной машины, при прочих равных условиях, не может позволить ей работать быстрее кода, исполняемого без этой программной прокладки.

И думаю с этим согласится любой программист.

Если я не прав то поправте.

 

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

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

А если хотите что-то быстрое, то малоногий кортекс M3 за доллар и минимум дополнений на печатной плате.

 

 

 

 

 

 

[CADiLO 9]

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

 

[SiriuS 0]

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

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

А если хотите что-то быстрое, то малоногий кортекс M3 за доллар и минимум дополнений на печатной плате.

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

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

Кортекс за бакс + обвязка + дополнительная стоимость за плату и монтаж умножаем на 500...1000изделий в месяц и получаем ЗП для хорошего программиста, который напишет стабильный код. При этом мы получим изделие более компактное, низкопотребляющее, дешевле, конкурентнее(по сравнению с изделием имеющим внешний МК).

 

[kovz 0]

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

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

 

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

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

 

А если хотите что-то быстрое, то малоногий кортекс M3 за доллар и минимум дополнений на печатной плате.

 

Тут спорить не буду, но если можно и без него то зачем платить больше ;)

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

 

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

[Telit 0]

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

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

Кортекс за бакс + обвязка + дополнительная стоимость за плату и монтаж умножаем на 500...1000изделий в месяц и получаем ЗП для хорошего программиста, который напишет стабильный код. При этом мы получим изделие более компактное, низкопотребляющее, дешевле, конкурентнее(по сравнению с изделием имеющим внешний МК).

 

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

 

я к тому написал, что не надежно все это. лучше внешний процессор как с точки зрения энергопотребления так и с точки зрения контроля за своим приложением.

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

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

а стоимость железа здесь просто минимальна.

 

 

 

[sobr 0]

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

Согласен с одним НО...

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

P.S. Еще совсем недавно, когда я говорил про возможность декодировать DTMF средствами модуля многие кричали: "Нафиг не нужно, МТ за полбакса...". А теперь какой ажиотаж поднали.

[kovz 0]

Многие здесь пишут о том, что встоенная ОСь справится только с "бебиситором", мне было бы интересно узнать какие проекты создает уважаемое сообщество, для которых ОБЯЗАТЕЛЬНО нужен внешний процессор?

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

 

А на счет надежности... Я думаю выскажу не только мое мнение, один процессор надежнее чем два в связке. Принцип "слабого звена" никто не отменял...

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

 

P.S. Еще совсем недавно, когда я говорил про возможность декодировать DTMF средствами модуля многие кричали: "Нафиг не нужно, МТ за полбакса...". А теперь какой ажиотаж поднали.

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

 

[Telit 0]

но и handshake и kissoff в стандарте ContactID(кто не знает что это - не заморачивайтесь, оно вам значит не нужно).

 

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

 

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