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

Вы ошибаетесь насчет хранения номера в тексте sms.
Вот вам пример отсылки русской sms на произвольный номер

encode() - функция преобразования в unicode

P.S. В теме неверной вы пишите - перенес в нужное место

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

Added "AT+CMGS=">index"" function to simplify short message sending operation.

с этим вопросов нет. тут Вы с МК отправляете и текст и номер абонента. А у меня такая беда, что нет возможности хранить их в EEPROM (просто не помещается, его всего 512В). Мне нужно отправлять СМС из памяти на номер из записной книги по индексам. Причем если номер я еще могу извлечь из модема, то текст СМС не могу (он в самом худшем случае занимает 280 байт = 70 символов * 4 Байта/символ). Или я не верно понял Ваш код.

Спасибо за поправку с темо)


К сожалению выбирали модуль без меня, мне просто дали его со словами "на, делай"
что-то мне эта команда кажется знакомой. Может она и на квиктеле есть? завтра погляжу.

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

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

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


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


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

Практически для такой задачи нужно начинать от MCU с объёмом программной памяти в ~128кБайт и оперативной памяти 8кБайт. И это весьма скромные цифры, для опытов стоило бы начать с 512/128, а потом уменьшить до реально используемого объёма. Забыл сказать о памяти данных, это тоже единицы КБайт в лучем случае (хранение только конфигурации), до единиц мегабайт (звук, трасса движения).

я наврал, срывает не стек, конечно, просто закончилась SRAM. Сейчас запаял МК пожирнее (324 мегу), буду пробовать. Но если задуманного изначально красивого решения на индексах не получается, то проще уже хранить тексты СМС в EEPROM.

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

Трудно не согласиться. Хотя собственно, из похожих соображений использую Мегу серии хх4 - для возможности при необходимости безболезненно поменять МК на более мощный.

Собственно, как я понимаю, придется считывать в буфер МК из памяти номера телефонов и тексты СМС, юзать обычную команду AT+CMGS и силами МК подсовывать ей параметры.

Можно не в UCS, а в ISO-8859-5 (ака ГОСТ-кодировке). Тогда байт на символ. В 4 раза компактней, чем PDU.

Спасибо за идейку, но к сожалению, тексты СМС записываются пользователем в процессе конфигурации прибора, а что он там напишет мне не известно)))


подскажите, поподробнее, может ссылку каку-нить: т.е. я из этого ИСО могу конвертнуть в PDU и обратно без потери информации? а как это делать?

На мой взгляд AVR хуже всего подходит для подобного рода задач. Ниже почему:



В нормальном проекте существует достаточно большой (килобайты) объём констант для этого. Текст SMS через sprintf выводится и кодируется далее в PDU... Вся суть в константах. Их практически трудно отделить от программной памяти на внешний носитель. А известные мне компиляторы для AVR имеют трудности с сохранением констант в программную память. А оперативной памяти у контроллера ещё меньше (куда и попадают константы). В PIC18 ситуация веселее если использовать hitech-C, или даже с x51 совместно с компилятором KEIL (но оба этих компилятора генерируют код в "рантайме" решающий обращение к какому типу памяти использовать). И проблемы нет с более большими контроллерами (MSP430, PIC24, PIC32, все виды ARM). Суть в общем-то в том, что AVR больше предназначены для небольших управляющих программ, и не очень подходят для обработки текста, звука и подобных задач. Всё потому, что т.н. Гарвардская архитектура разделяет код и данные. А на большие объёмы данных контроллер не расчитан. В PIC24, например, есть функция отображения программной памяти в область памяти данных, специально для того.

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

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

Если код буквы менее 128 -- кодируется как есть (было 0x30 --> стало 0x0030 в UCS2).
Если код буквы более или равен 128 -- прибавляется 0x360: было 0xB0 (русская A заглавная) --> стало 0x410 в UCS2.
Обратно точно также. Работает только для ряда языков стран бывшего СССР: http://en.wikipedia.org/wiki/ISO/IEC_8859-5
Преимуществе перед windows-1251 -- не нужна таблица перекодировки во-первых, во-вторых очень удобно использовать текст прямо в исходниках (он хранится в UTF-8, который легко декодируется до UCS2 и легко же декорируется в ISO-8859-5). В последнем случае смысл в том, что при программировании на языке C тип wchar_t можно сделать 8-битным и практически от библиотеки C не нужна полноценная поддержка Unicode (её обычно в микроконтроллерах и нет). И в качестве wchar можно использовать на самом деле ISO-8859-5, а в качестве char -- UTF-8. И всё будет работать (#define wprintf printf и т.п.) точно также, как и с нормальной C-библиотекой на PC. Но только для русского, украинского, беларусского языков.

Во, блин, класс)). Спасибо! Нужно, конечно еще допилить до формата который можно в М72 отправить: ведь чтобы отправить в него символ с кодом 0х0410 нужно послать в модем 4 АСКИшных символа 0 4 1 0 (или 0х30 0х34 0х31 0х30). Вдруг поможет из тех кто ни знает.

GCC имеет.



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



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

PIC24 со своими таблицами в самый раз. А PIC16/18 там уже с извращениями будут.
Можно и PIC32 но это уже экономически не совсем оправдано.

Не факт. Если всё сообщение состоит из ASCII (ну почти, GSM-алфавит немного отличается), то лучше кодирование в 7-битный GSM-алфавит (меньше количество SMS, или больше вмещается в одно сообщение, 160 символов против 70).

Это ясно, но в таком случае нужно разбирать в какой кодировке записан текст... это в теории все делается... но на практике не за горами срок сдачи проекта, а работы еще не в проворот. Пока ограничусь только кодировкой UCS и сообщениями в 70 символов. Со временем, надеюсь доделать. Сейчас главное русский текст.

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



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



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

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

И как я понимаю нет спец команды о которой я так мечтал и ради которой затеял собственно эту тему?)) Тогда буду альтернативным путем идти. Спасибо всем откликнувшимся!!!

Тогда проще всего держать в памяти номера абонентов и сообщения - а их комбинацию по индексам подставлять в момент формирования команды модулю. В PIC можно писать в собственную флеш поэтому там хранилище такое достаточно удобно организовывать....

На практике тоже делается. Ибо житейская практика -- делать всё равно придётся рано или поздно, а сил и времени потрачено уже будет не мало. Через пол-года выяснится, что позарез нужны передачи относительно больших объёмов информации в SMS, например в base64.

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

Просто кто к чему привык. Ну и еще два факта - Атмел продал все свои фабрики и теперь занимается только разработкой и заказывает производство у других, что не может не сказаться на стабильности поставок. Ну и последние несколько лет Атмел не включают в ТОП10 производителей контроллеров.
Так что никакой ненависти - банальная предусмотрительность. Вот многие и уходят кто на себе познал перебои с поставками. MSP, ARM, PIC - но не Атмел

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



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



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

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



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 с фиксированным текстом не отделаешься.

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



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


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



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




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


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



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


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


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

2 Frolov Kirill.
Ваша взяла. Посмотрел на цены младшей 100-й серии STM32 и получил просветление. Таки да Cortex за 2$.

Еррату тоже не забудьте посмотреть, а то мало ли вдруг ему и правда цена - 2$.

Да вроде ничего страшного... Собствено в последних проектах использовал STM32F103RCT и 207VCT. Вполне номальные контролеры. Стоят конечно далеко не 2$.

Чувствуется вся боль разработчика))
Могу подбавить: отладка на КИТе, ДЖИТАГ - это все замечательно (и то и другое есть), но
1) помимо программирования МК, нужно еще написать конфигуратор, а в КИТе МК нету. Если сначала я буду сидеть отлаживать работу с компа, потом соберу образец, только после этого программист начнет писать конфигуратор, мы начнем отлаживать связь с ним... а ещё наше бля..ское производство может собирать образец в течение мясяца в легкую (да, вот так и живу). А менеджеры графики составили в декабре и их не еб..т отсутсвие АТ-команды.
2) ДЖИТАГ не влез на приборе (я пытался) - а собирать сначала образец для ДЖИТАГа... смотри пункт первый... а еще предыдущий проект до конца не отпускает, а еще новый на подходе и нужно уже по-немногу подбирать комплектующие (смешно, уже представляю как оно будет - точно так же).
Да, звучит глупо и многие мугут сказать, что не умеете организовать работу, но это правда лично моей трудовой деятельности.

Того кортекса на много не хватит.