Отправка СМС из памяти в PDU режиме, Отправка СМС из памяти в PDU режиме на произвольный номер Опции

[den1s]

Надеюсь, что в правильную тему пишу…
Уважаемые форумчане, помогите… скоро начну биться головой обо что-нибудь)
Делаю GSM-модуль: прибор на базе модуля Quectel M72 и AVR. Прибор отслеживает состояния подключенных датчиков и по наступлению определенных событий отправляет СМСки и щелкает исполнительными элементами. Конфигурируется прибор с компа, но работает самостоятельно. По схеме наверное необходимо отметить, что AVR посредством одного UARTа подключен к M72, а вторым подключается к компу (только для конфигурации). Комп с модемом связи не имеет.
Собственно железных вопросов нет – все слава богу работает, но вот с отправкой СМС проблема. Но тут стоит опять немного пояснений дать. Прибор должен иметь возможность отправлять СМС большому числу абонентов (последовательно) и на каждое из событий предполагается свой текст. При этом тесты СМС и имена абонетов нужно писать на русском. Держать всю эту кучу инфы в слабенькой АВР не представляется возможным, поэтому было принято стратегическое решение номера, имена абонентов а так же тексты СМС хранить в самом М72. А в процессоре держать только индексы телефонной книги и хранилища СМС. Т.е. когда я все это продумывал в теории, думал что будет так: АВРка говорит М72, а оправь-ка СМС № 1 из памяти абоненту № 2 из телефонной книги, а потом СМС № 3 абоненту№ 8.
Но тут оказалась проблема: нет такой АТ-команды. Думаю, ладно, буду считывать телефонный номер абонента в буфер и просто буду подставлять в команду отправки СМС из памяти. Но тут подставил Режим PDU: оказалось там прямо в тексте хранится номер получателя и его нельзя отправить на произвольный номер. Забирать текст PDU из модема и подправлять номер не выходит – этот текст может достигать 300 байт – мне стек в АВР срывает.
Собственно вопрос, можно ли на практике реализовать придуманный мной подход, и как это сделать? Возможно я не до конца разобрался во всех премудростях прекрасного PDU-режима
Очень много написал, извиняюсь. Заранее спасибо.

[CADiLO]

Команда эта есть в любом модуле, но не в любом она умеет работать не напрямую с номером телефона, а с номером ячейки где размещен номер.

[den1s]

Команда эта есть в любом модуле, но не в любом она умеет работать не напрямую с номером телефона, а с номером ячейки где размещен номер.

Да, это я понял после того как написал... а отредактировать пост не получилось (то ли форум тупил, то ли я)

У вас у AVR сколько памяти? Если вам 300 байт стек разрывают, так не храните их в стеке. Можно в глобальный массив поместить.

Мега164 у меня. Я программист к сожалению не высочайшего класса... может там и не в стеке дело (хотя вряд ли): я объвил глобальный массив в 280 байт и когда пытаюсь в него грузануть хотя бы 1 ячейку - ИАР не компилит. При этом компилится, если размер массива уменьшить в пару раз. Есть конечно, вариант поменять МК на 324 или 644 - но я надеюсь, что есть более красивое решение.

Ещё для экономии памяти можно хранить текст в UCS, а в PDU перекодировать на лету.

интересная идея... если все же придется хранить в EEPROM, скорее всего воспользуюсь)) спасибо)

[=F8=]

Есть конечно, вариант поменять МК на 324 или 644 - но я надеюсь, что есть более красивое решение.

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

2 Frolov Kirill Для данной задачи AVR вполне адекватное решение. Все известные мне компиляторы не имеют проблем с сохранением констант в памяти програм. Единственная проблемма состоит в том, что просто константа и константа во флеш это разные типы данных, соответственно для работы с ними нужны разные функции, неудобно, но не более того(кстати это касается и PIC24). PIC32 и ARM для данного случая это, просто, стрельба из пушки по воробьям.
PS Сори на счет отображения flash в память в PIC24 не знал.

[Frolov Kirill]

Все известные мне компиляторы не имеют проблем с сохранением констант в памяти програм.

GCC имеет.

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

IAR. И, следовательно, библиотечные функции использовать во-первых нельзя (они с RAM работают), во-вторых своих функций нормально написать тоже невозможно, потому, что половина данных будет из RAM, половина из ROM, и не скажешь когда как.

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

Ни разу. А то при умелом подходе и PIC16 можно обойтись, но оно того не стоит.

[=F8=]

GCC имеет.

Какие? Вместо __flash в начале написать PROGMEM в коце? Работать конечно сложней чем в IARе, но ничего особо страшного.

IAR. И, следовательно, библиотечные функции использовать во-первых нельзя (они с RAM работают), во-вторых своих функций нормально написать тоже невозможно, потому, что половина данных будет из RAM, половина из ROM, и не скажешь когда как.

Для работы с данными во флеш в IARе есть дубликаты стандартных функций например strcpy_P, strcmp_P итд. Свои функции тоже приходится писать в 2-х экземплярах. Неудобно, но не более того.

Ни разу. А то при умелом подходе и PIC16 можно обойтись, но оно того не стоит.

Я сам не любитель ограничивать себя в ресурсах, но ARM/PIC32 для простейшей оповешалки? ИМХО слишком. PIC24 согласен наверно более оптимально получилось бы, в конце концов они с AVR по цене в одной категории. Но AVR тоже вполне адекватный для данной задачи контроллер.

[Frolov Kirill]

Какие? Вместо __flash в начале написать PROGMEM в коце? Работать конечно сложней чем в IARе, но ничего особо страшного.

Либо все константы в ОЗУ. Недостатки очевидны. Либо этот progmem -- см. ниже:

Для работы с данными во флеш в IARе есть дубликаты стандартных функций например strcpy_P, strcmp_P итд. Свои функции тоже приходится писать в 2-х экземплярах. Неудобно, но не более того.

Объясняю: невозможно написать функцию, которая может одновременно работать с любым типом данных (строка в ОЗУ или строка в ПЗУ). При наличии достаточно большого объёма кода, где десяток вложенных функций, например, это заставит получить 10^2 вариантов их реализации (для flash и не flash), что ставит крест на всей затее. Либо заранее копировать в RAM и потом обрабатывать как обычно -- кажется более разумным. Но в общем случае нельзя взять код работающий на другой платформе и начать использовать. Нужно писать специально под AVR. Это большой недостаток. Гораздо лучше, когда код можно отдельно оттестировать на PC, соместо с development kit модема, а потом перенести на микроконтроллер практически без изменений.

Я сам не любитель ограничивать себя в ресурсах, но ARM/PIC32 для простейшей оповешалки? ИМХО слишком.

Слишком что? Какие критерии, чем АРМ хуже AVR? А наличие того же ARM внутри самого модема -- не круто слишком? Потом не всё так просто как кажется. Любой проект может разрастить в несколько раз в сторону увеличения от начальных условий. AVR не даёт же никакой возможности роста. Адекватный выбор микроконтроллера -- это когда из того же семейства можно выбрать всегда более крупный в ~2 раза хотя бы.

Негативные стороны я указал: проблемы с константами, малый объём ОЗУ, да и ПЗУ тоже (практика на основе реальных проектов). Возможно даже малое число последовательных портов, для некоторых задач (если GSM/GPS то уже 3 нужно), отсутствие гибкости в тактировании и потреблении энергии. У того же ARM, кстати, при таком же размере слова в программной памяти (thumb или cortex m3), плотность кода повыше будет. У PIC24 и то выше, а там слово в 1.5 раза шире. По цене -- антиквариат в цене, увы, кроме самых младших моделей. LPC 2-долларовый ещё когда появился, в прошлой жизни. Просто это инерция мышления. Мол 32 бита -- это для чего-то очень сложного и дорогого. На самом деле не так. 32 бита нужно, если объём обрабатываемых данных превышает 64 килобайта (16 бит). А 8 бит годится только для простейших задач управления. Исходя из таких критериев "для простейшей оповещалки" нужен хотя бы 16-битный микроконтроллер.

PIC24 согласен наверно более оптимально получилось бы, в конце концов они с AVR по цене в одноНо AVR тоже вполне адекватный для данной задачи контроллер.

STM32 дешевле и лучше (моё субъективное мнение...) чем PIC24, практически во всём. PIC -- это тоже инерция. Из плюсов -- только наличие компараторов. Я не говорю про dsPIC -- это отдельная история.

АВР - это традиция конторы моей, уже начались подвижки в сторону того что бы использовать разные контроллеры в зависимости от задачи, но пока АВР))). Просто раньше проекты были совсем простенькие и АВР всем хватало, сейчас типа начали усложнять, но по старой памяти пока на старых МК.

Но полно старых дедов (это не характеристика возраста человека, есть и вполне вменяемые 70+ деды) которые 13 лет назад выучили AVR (когда он только появился) и ни о чём не хотят слышать. Ага, знакомо. В других местах точно также микрочип.

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

128кБайт ПЗУ и 4кБайт ОЗУ -- вполне реальный вариант даже со звуком, SMS в PDU, GPRS и очень многими другими вещами. Для PIC18. Но вряд ли оно того стоит если нет и не будет многотысячных тиражей. Для AVR я бы увеличил ОЗУ в 2 раза -- из-за констант. Но там и есть столько.

Прямо-таки чувствуется какая-то классовая ненависть к АВР (или может что-то подсознательное вылезает) .
Чем они так плохи, что "хуже всего подходит для подобного рода задач".
МК как МК, где-то лучше, где-то хуже.

Ненависти нет. AVR очень хороший для своих маленьких чисто управляющих задач с маленьким потреблением и т.п. Но в данном случае класс решаемой задачи и выбранного контроллера явно несоответствует. Только если не брать наиболее крупные модели ATMEGA128 и т.п. Что, в свою очередь нерационально по той причине, что не оставляет разработчикам какой-то возможности дальнейшего развития проекта. Программисты же склонны ошибаться чуть ли не на порядки. Вообще имею мнение, что вначале стоило бы разработать программное обеспечение, и отладить его на ПК совместно с development kit модема, а потом выбирать аппаратную платформу на которой программное обеспечение может работать. А тут считается, что кто-то решил, что ATMEGA32, например, точно достаточно, а программист как-нибудь (это ключевое слово -- как-нибудь) всё туда постарается и уместит. Только в действительности потом всё оказывается гораздо сложней, чем изначально кажется. Небось и сколько-нибудь детального ТЗ на проект не существует. А тонкостей, сейчас "неизвестных" их же масса. То модем там перезапускать нужно, работоспособность SIM-карты и наличие регистрации в сети проверять. Для входящих SMS откидывать дубли. И не влезет оно в ATMEGA32. А потом и в ATMEGA64 не влезет. А тест для производства, а обновление прошивки (своей и модема)... Одним AT+CMGS с фиксированным текстом не отделаешься.

[_Артём_]

Либо все константы в ОЗУ. Недостатки очевидны. Либо этот progmem -- см. ниже:

Некоторые неудобства есть, но не более того.
Константы вообще в реальности могут на какой-нибудь AT45 находится и как тогда их адресавать стандартными функциями?
Невозможно? А надо.

Гораздо лучше, когда код можно отдельно оттестировать на PC, соместо с development kit модема, а потом перенести на микроконтроллер практически без изменений.

Зачем на ПК?
Когда есть JTAG включенные в схему с модемом и другой обвязкой.

Адекватный выбор микроконтроллера -- это когда из того же семейства можно выбрать всегда более крупный в ~2 раза хотя бы.

У ТС вроде mega32x. Нужно в 2 раза расширить?
Нет проблем: xmega384 - скорость в 2 раза, flash - в 8 раз.

Негативные стороны я указал: проблемы с константами, малый объём ОЗУ, да и ПЗУ тоже (практика на основе реальных проектов). Возможно даже малое число последовательных портов, для некоторых задач (если GSM/GPS то уже 3 нужно), отсутствие гибкости в тактировании и потреблении энергии.

Указанное (порты, ОЗУ, потребление) есть в xmega в достатке.

128кБайт ПЗУ и 4кБайт ОЗУ -- вполне реальный вариант даже со звуком, SMS в PDU, GPRS и очень многими другими вещами. Для PIC18. Но вряд ли оно того стоит если нет и не будет многотысячных тиражей. Для AVR я бы увеличил ОЗУ в 2 раза -- из-за констант. Но там и есть столько.

128кБайт ПЗУ и 4кБайт ОЗУ -- вполне реальный вариант даже со звуком,

Вариант реальный, но понынешним временам скорей минимальный.

Для AVR я бы увеличил ОЗУ в 2 раза -- из-за констант.

С константами - это у вас какая-та ... даже не знаю как назвать, странность. Дались вам те константы.

Только если не брать наиболее крупные модели ATMEGA128 и т.п.

Их и надо брать.

А тут считается, что кто-то решил, что ATMEGA32, например, точно достаточно, а программист как-нибудь (это ключевое слово -- как-нибудь) всё туда постарается и уместит. Только в действительности потом всё оказывается гораздо сложней, чем изначально кажется. Небось и сколько-нибудь детального ТЗ на проект не существует. А тонкостей, сейчас "неизвестных" их же масса. То модем там перезапускать нужно, работоспособность SIM-карты и наличие регистрации в сети проверять. Для входящих SMS откидывать дубли. И не влезет оно в ATMEGA32. А потом и в ATMEGA64 не влезет.

M32 пожалуй мало, только для простейших задач.
M64 - уже может хватить на что-то серьёзное.

а обновление прошивки (своей и модема)...

Вот ни разу не приходилось модем обновлять. Может потому что оно не нужно?