[Flashboy_87 0]

Если честно то когда у нас берут модуль на МТК, как известно это L10, L10-C и на Сирфе L20 или L30. то я тоже потом перезваниваю и интересуюсь как ведет себя модуль что лучше. Так большинство разработчиков склоняется к МТК, а СИРФ берут в основном из-за габаритов.

 

[Telit 0]

Ну, не смог удержаться...

Это все от кривых рук (или мозгов) программистов, которые только понты умеют гонять и лапшу вешать (а сегодня, к сожалению, много "профессионалов" именно такие). Если грамотно написать внутренний софт и учесть все возможные ситуации, то дополнительный внешний проц только снизит общую отказостойкость устройства. Ведь внутренний проц Вы никуда не дели - он параллельно работает.

 

Вот это бред так бред. Вы бы не позорились перед обществом с такими постами... - "дополнительный внешний проц только снизит общую отказостойкость устройства". Кстати технически правильно будет - отказоустойчивость.

"Стойкость" - фраза хорошая для дуболомов в армии.

 

И по вашему, одна из задач внутренней ЗАКРЫТОЙ OS модуля, читай приложение EAT или OpenAT (!!! с наинизшим приоритетом по отношению к обработке GSM дел) будет быстрая и отказоустойчивая ???

Какие же варианты у вас есть по контролю этой вашей задачи если КОД OS ИЗНАЧАЛЬНО ЗАКРЫТ!!!. Даже производители модулей ничего гарантировать не могут... Вспомним историю с OpenAT. а EAT это то же самое ...

 

Я конечно рад за вас, как за менеджера, поддерживающего здесь некоторых продавцов, но хоть какой то этикет соблюдать нужно.

 

И еще, уточните только, какой это такой внутренний процессор параллельно в модуле работает? Но это так вопрос, для смеха уже ...

 

 

[Flashboy_87 0]

Вот это бред так бред. Вы бы не позорились перед обществом с такими постами... - "дополнительный внешний проц только снизит общую отказостойкость устройства". Кстати технически правильно будет - отказоустойчивость.

"Стойкость" - фраза хорошая для дуболомов в армии.

 

И по вашему, одна из задач внутренней ЗАКРЫТОЙ OS модуля, читай приложение EAT или OpenAT (!!! с наинизшим приоритетом по отношению к обработке GSM дел) будет быстрая и отказоустойчивая ???

Какие же варианты у вас есть по контролю этой вашей задачи если КОД OS ИЗНАЧАЛЬНО ЗАКРЫТ!!!. Даже производители модулей ничего гарантировать не могут... Вспомним историю с OpenAT. а EAT это то же самое ...

 

Я конечно рад за вас, как за менеджера, поддерживающего здесь некоторых продавцов, но хоть какой то этикет соблюдать нужно.

 

И еще, уточните только, какой это такой внутренний процессор параллельно в модуле работает? Но это так вопрос, для смеха уже ...

 

Че за бред ты несеш вообще башню снесло? Это кто здесь менеджер я или Gegel? Ты если не знаешь так молчи лучше пиарщик мля.

[Telit 0]

Че за бред ты несеш вообще башню снесло? Это кто здесь менеджер я или Gegel? Ты если не знаешь так молчи лучше пиарщик мля.

 

Без эмоций, ок?

 

А модераторы есть в Этой ветке вообще?

 

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

[fk1 0]

Это все от кривых рук (или мозгов) программистов,

 

Ну это традиционно. "В мировом финансовом экономическом кризисе виноваты программисты" © rbc.ru

 

которые только понты умеют гонять и лапшу вешать (а сегодня, к сожалению, много "профессионалов" именно такие). Если грамотно написать внутренний софт и учесть все возможные ситуации, то дополнительный внешний проц только снизит общую отказостойкость устройства. Ведь внутренний проц Вы никуда не дели - он параллельно работает.

 

А внутри SIM900, например, софт достаточно грамотный? А как быть с зависаниями и пересбросами, а? А то вон соседние темы смотрим -- у кого завис, у кого сбросился, у кого на NRESET не реагирует.

 

И вы предлагаете внутри этого ещё и свой софт запускать? И потом объяснять почему он то завис, то пересбросился, то просто глючит? Без внешнего процессора (чтоб регулярно отключать питание) это просто не работает.

 

А можно я вопросов наводящих позадаю сразу? А предусматривается (например, Cortex-M3 предусматривает и это реализовано в LPC17xx, в STM32xxx) ли изоляция разных задач в этих ОС, встроенных в модем? Они работают в разных адресных пространствах, есть защита памяти? Скорей нет. Любые ошибки в ПО самого модема могут вести к сбоям в прикладном ПО. Так и наоборот. Количество сбоев растёт лавинообразно...

 

На вопрос как реализовать голосовое меню в Embedded AT ответ отрицательный. Никак. Что-то изменилось? Опять внешний процессор, внешняя память, внешний DAC (при том, что всё есть внутри модема, казалось бы) и двойное преобразование цифра-аналог-цифра (хоть бы PCM уж вывели, если так).

 

Может ли Embedded AT обрабатывать данные поступающие с частотой ~300 выборок в секунду (аналоговый акселерометр, например) ? Ответ скорей отрицательный. В теории может, на практике упрётся в ПО и недостаточно реактивную ОС. То же касается DTMF-декодера, только там уже 8000/сек.

 

PIC-контроллер может выполнять массу задач при потребляемом токе в ~3мА с частотой ~8МГц, наконец. И засыпать снижая потребление до десятков мкА. Для модема было сказано -- 600мкА. Разница на порядок в рабочем режиме и режиме сна.

 

И ещё очень много ньюансов. Сейчас Embedded AT применима лишь для узкого ряда ограниченных задач, на самом-то деле. Будь там качественная RTOS внутри, сфера применения была бы шире. Но не для микропотребляющих приборов в любом случае.

 

[CADiLO 12]

Сказано верно. Где EAT или OCPU справятся, а где уже и что посерьезнее нужно.

Так что под каждую задачу надо просто выбрать инструмент обладающий разумной достаточностью. Или я не прав ?

[gegel 0]

Вот это бред так бред. Вы бы не позорились перед обществом с такими постами... - "дополнительный внешний проц только снизит общую отказостойкость устройства". Кстати технически правильно будет - отказоустойчивость.

"Стойкость" - фраза хорошая для дуболомов в армии.

 

И по вашему, одна из задач внутренней ЗАКРЫТОЙ OS модуля, читай приложение EAT или OpenAT (!!! с наинизшим приоритетом по отношению к обработке GSM дел) будет быстрая и отказоустойчивая ???

Какие же варианты у вас есть по контролю этой вашей задачи если КОД OS ИЗНАЧАЛЬНО ЗАКРЫТ!!!. Даже производители модулей ничего гарантировать не могут... Вспомним историю с OpenAT. а EAT это то же самое ...

 

Я конечно рад за вас, как за менеджера, поддерживающего здесь некоторых продавцов, но хоть какой то этикет соблюдать нужно.

 

И еще, уточните только, какой это такой внутренний процессор параллельно в модуле работает? Но это так вопрос, для смеха уже ...

 

 

Ну, я привык к таким эмоциям... Но этим ничего не изменишь ведь :)

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

А что касается технических деталей, то у вас, как на мой взгляд, немного неверные стереотипы, что, впрочем, очень характерно для профи. Я не профи, и никогда им не был, поэтому разрабатываю, как мне хочется, и как я считаю нужным, а не как учили - и в этом вижу некоторые преимущества :)

 

По существу: проц внутри - это проц модуля (АРМ). Он работает паралельно внешнему процу, в который Вы пишите пользовательский код. Причем мотивируете это необходимостью контроля за внутренним процом модуля. Для этого нужен внешний проц под линуксом??? Абсурд... А его кто дергать будет, если что? Если хотите сделать контроль, поставьте PIC10 как вотчдог и подстрахуйте внутренним его вотчдогом, чтобы управлял стабилизатором модуля. Чем проще, тем оно надежнее, знаете ли...

Конечно, если надо спецпериферию, это другое дело. Но для обычных задач вполне достаточно ресурсов внутреннего АРМ.

Я прикручивал в оцпу tDES, AES, математику с плавающей точкой и т.д., это не те задачи, о которых стоит волноваться. Опять же, надо грамотно писать код, тогда рационально используются ресурсы. И если Вы ставите внешний проц с линукс-системой и пишите туда охранную сигнализацию или жпс-трекер, то сколько бы вы не пыжылись, кроме улыбки, это ничего не вызовет.

[artemkad 81]

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

 

Скажите, а что делает охранная система внутри модуля когда исчезает GSM-регистрация в сети? А сколько проработает GPS-треккер работающий как закладка от автономного питания? Скажите, если требуется контролировать аналоговый 3-х координатный акселерометр с частотой хотя-бы по сотне выборок в секунду на канал плюс 2-3 аналоговых величины - и как Ваш внутренний АРМ с этим справится?

 

ЗЫ. Это ведь простые задачи - 3-5 аналоговых входа, потребление на уровне десятка и меньше микроампер, независимая работа от наличия связи. Есть еще такая обычная задача для систем защиты - реакция на событие за единицы мкс.

 

ЗЗЫ. Что касается Линукс-системы во внешнем проце, такое решение принимают тогда, когда нужен пользовательский интерфейс и работа с дисками и сетевыми устройствами. Т.е. когда очередной раз повторять интерфейсы к типовым устройствам нет времени и желания.

[gegel 0]

Скажите, а что делает охранная система внутри модуля когда исчезает GSM-регистрация в сети? А сколько проработает GPS-треккер работающий как закладка от автономного питания? Скажите, если требуется контролировать аналоговый 3-х координатный акселерометр с частотой хотя-бы по сотне выборок в секунду на канал плюс 2-3 аналоговых величины - и как Ваш внутренний АРМ с этим справится?

 

ЗЫ. Это ведь простые задачи - 3-5 аналоговых входа, потребление на уровне десятка и меньше микроампер, независимая работа от наличия связи. Есть еще такая обычная задача для систем защиты - реакция на событие за единицы мкс.

 

ЗЗЫ. Что касается Линукс-системы во внешнем проце, такое решение принимают тогда, когда нужен пользовательский интерфейс и работа с дисками и сетевыми устройствами. Т.е. когда очередной раз повторять интерфейсы к типовым устройствам нет времени и желания.

 

Эту уже у нас офтоп пошел, модераторы нас точно отшлепают :) Но рискну ответить.

 

Только давайте отдельно - стационарные системы охраны и энергосбережение автономной закладки.

 

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

 

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

 

А вот по поводу акселерометра - это идея супер, я смотрел эти трекера. Так понял, что речь идет о режиме сна и активации в рабочий режим по движению. Обязательно реализую в своем трекере (автономном варианте). Только вот ума не приложу, зачем трехканальный акселерометр с 300 семплов/сек??? Текст вводить жестами? :)

Я бы не так сделаю - использую максимально дешевый магнитный или пьезо датчик и максимально дешевый пик с компаратором и программой отработки интервалов включения - отключения, управляющий основным питанием модуля. Результат будет тот же, наверное, но цена... :)

 

Диски и сетевые устройства - не спорю, но при чем тут охрана и трекер? Мне кажется, что на рынке выиграет тот, кто демпингует его ценой и возмет массовостью.

 

 

[artemkad 81]

А что должен делать внешний проц охранки, когда исчезнет регистрация? Наверное, попробовать перезагрузить модуль, я так думаю.

Подождать, а затем если само не исправится - снять питание с модуля, подождать несколько секунд разряда емкостей, подать питание. Те, кто не захотели ставить этот пресловутый ключ по питанию рано или поздно сталкиваются с проблемой. Кроме того, есть еще и момент с энергонезависимой памятью. Насколько помню в OCPU с этим небольшой напряг - нужна внешняя EEPROM.

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

Это если совсем чистая закладка.... Но и так потребление обычно выше чем с внешним камнем.

Так понял, что речь идет о режиме сна и активации в рабочий режим по движению. Обязательно реализую в своем трекере (автономном варианте). Только вот ума не приложу, зачем трехканальный акселерометр с 300 семплов/сек??? Текст вводить жестами?

Нет, это вариант для GSM сигналки со встроенным датчиком наклона/перемещения/удара организованного на акселерометре. Для отслеживания наклона/перемещения много выборок не надо, а вот для того, что-бы не пропустить удар - вот те самые минимум 300 семплов/сек.

Результат будет

...тот еще... ;)

Диски и сетевые устройства - не спорю, но при чем тут охрана и трекер?

Треккеры могут ведь писать не только координаты, но и картинки. Да и вспоминаем классические навигаторы...

[V125 0]

Просто из любопытства, чем обоснована цифра 300 семплов/сек? Если стукнуть по машине, кузов наверняка будет вибрировать ещё пару секунд.

 

 

[artemkad 81]

Если стукнуть по машине, кузов наверняка будет вибрировать ещё пару секунд.

А от мимо проезжающего камаза - еще дольше. ;) Но нам-то надо удар т.е. пиковое воздействие...

 

[fk1 0]

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

 

Тем, что пик-контроллер 1.5мА будет потреблять в рабочем режиме, например. А не все 30. И просыпаться будет за микросекунды. А не загружаться как windows, то-есть, хотел сказать, OpenCpu, по несколько секунд. А это всё ватт-часы.

 

Будильник... А что если в момент от срабатывания будильника до его перепрограммирования на следующий интервал произойдёт сбой внутри OpenCPU -- больше вооще никогда не проснётся? Аппаратный watchdog так и напрашивается (да всё равно нужен). Значит перезагружаться будет часто и съедать батарейку.

 

Я бы не так сделаю - использую максимально дешевый магнитный или пьезо датчик и максимально дешевый пик с компаратором и программой отработки интервалов включения - отключения, управляющий основным питанием модуля. Результат будет тот же, наверное, но цена... :)

 

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

 

 

 

Кроме того, есть еще и момент с энергонезависимой памятью. Насколько помню в OCPU с этим небольшой напряг - нужна внешняя EEPROM.

 

В OpenCPU же даётся пользователю перезаписываемый flash? Зачем EEPROM?

И в EmbeddedAT тоже. Другое дело, поверх flash напрашивается адекватная файловая система или что-то в этом роде.

 

 

Просто из любопытства, чем обоснована цифра 300 семплов/сек? Если стукнуть по машине, кузов наверняка будет вибрировать ещё пару секунд.

 

Датчик "удара" строится так: фильтр ВЧ, амплитудный детектор. Частота с которой будет вибрировать -- десятки герц, а то и больше сотни. Кроме того, скорей важна даже не вибрация, а скорость нарастания сигнала.

 

Другое дело что... для аналогового акселерометра и обработку можно сделать аналоговую (на АЦП попадает после амплитудного детектора). У кого-то application note был на эту тему. Экономит и ватты и такты MCU. События же типа "наклон", "движение" получаются путём обсчёта данных после фильтра НЧ, это всё медленно и CPU не нагружает (кроме самого фильтра, тоже аналогового). Но по нынешним временам, при наличии достаточно быстрых и малопотребляющих MCU, проще всё программно.

 

А у очень современных цифровых обычно имеется пара каналов с программируемыми фильтрами ВЧ и НЧ -- принцип примерно тот же, и можно просто получать прерывание по факту срабатывания. Но не для всех видов событий (всё же жёсткий диск компьютера и автомобиль имеют не много общего...), и обработка процессором может оказаться более предпочтительна.

 

[gegel 0]

Ну, так а в чем сложность для оцпу по п.1? Посмотрите мою схему, там вобще это на логике сделано.

При работе оцпу выходит меандр, поддерживающий мультивибратор в включеном состоянии. Если оцпу виснет, он исчезает и идет включение-отключение с периодом

7-8 сек до запуска оцпу. Если не виснет, то все под его контролем: и регистрация, и макс-тайм на запуск жпрс, подключение к серверу и т.п.

Можно было и на PIC10 сделать, но не хотелось лишний софт лить.

Может, это и не модно, но ведь цена....

 

А по поводу еепром и т.п. - просто, наверное, Вы не совсем в курсе возможностей оцпу Quectel. Там полноценная файловая система, причем достаточно солидного размера (на модуле Т128 - до 9М, если память не изменяет).

На модуле N32 - 500К точно. Ну и остальное - проигрывание мп3 с возможностью вывода в любом направлении, декодирование дтмф, и т.п.

Если заинтересуетесь, я скину доку с API.

 

На счет акселерометра: да уж... Опять же, может, я старомоден, но все ж обычный аналоговый датчик удара чем плох?

Хотя, конечно, согласен - при хорошем алго можно добиться лучшей надежности и помехоустойчивости, но стоит ли оно того?

Метать бисер, а юзер оценит?

 

По поводу картинок и классических навигаторов - вот тут без вопросов: снимаю шляпу! И я бы предпочел линукс. Но пока до этого не дошел.

 

Тем, что пик-контроллер 1.5мА будет потреблять в рабочем режиме, например. А не все 30. И просыпаться будет за микросекунды. А не загружаться как windows, то-есть, хотел сказать, OpenCpu, по несколько секунд. А это всё ватт-часы.

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

gpsM10sch.pdf

Изменено 10 октября, 2011 пользователем GeGeL

[fk1 0]

При работе оцпу выходит меандр, поддерживающий мультивибратор в включеном состоянии. Если оцпу виснет, он исчезает и идет включение-отключение с периодом

 

Вопрос "засыпания" не раскрыт. При засыпании мультивибратор некому будет сбрасывать. Значит будет функция его выключения... Может PIC10 не такая уж и плохая идея. Ещё следует учитывать, что площадь печатной платы тоже критична.

 

И самый главный вопрос -- сколько потребляет модем, в среднем, ток какой?

OpenCPU может при такой вот работе "засыпать" с потреблением на уровне 2мА,

в промежутках между вычислениями? Мне думается, что нет (вспоминаю, что SIMCOM, например теряет первый байт в режиме +CSCLK=2 -- следовательно перифирия контроллера там не работает полноценно в режиме сна, только прерывания). То-есть к потреблению GPS-приёмника на уровне 40mA нужно добавить потребление модема на уровне ~30мА. А если без GPS -- будет засыпать? Наверное, тоже нет, из-за watchdog.

 

Если заинтересуетесь, я скину доку с API.

 

Интересуюсь.

 

На счет акселерометра: да уж... Опять же, может, я старомоден, но все ж обычный аналоговый датчик удара чем плох?

 

Непредсказуемостью его характеристик. Сложностью приобретения готовых датчиков с известными характеристиками. Наверное не секрет, что сейчас болтики с пружинками массово у всех заменяются на MEMS-акселерометры. Кроме, может быть, самых дешёвых решений. К слову, чаще, вполне себе аналоговых.

 

Хотя, конечно, согласен - при хорошем алго можно добиться лучшей надежности и помехоустойчивости, но стоит ли оно того?

Метать бисер, а юзер оценит?

 

"Обычный" датчик не умеет классифицировать события (отличать удар и движение, например). Слишком резко реагирует на резонансной частоте и в одних плоскостях и недостаточно хорошо на других частотах и в других плоскостях. Настроить тяжело. Много ложных срабатываний. "Датчик наклона" же вовсе не сделать.

 

 

 

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

 

Ситуация, на мой взгляд, как раз обратная. В маленькие приборы, с маленькими батарейками и ограниченным функционалом, OpenCPU плохо вписывается. Из-за потребления энергии, в основном. Да и pic-контроллер неплохо справляется.

 

В случае же "большого" прибора потребление волнует уже меньше, а возможностей микроконтроллера не хватает и он быстро обрастает внешней памятью, например, и много чем ещё. И тут OpenCPU очень даже интересна, тем, что позволяет экономить на собственном уже относительно дорогом микроконтроллере (современные кортексы, да ещё память -- по цене больше половина модуля уже), если переносить "тяжёлые" вычисления и коммуникацию внутрь OpenCPU, оставляя на долю маленького внешнего микроконтроллера только наоболее критические функции.