Надеюсь, что в правильную тему пишу…
Уважаемые форумчане, помогите… скоро начну биться головой обо что-нибудь)
Делаю 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, а потом уменьшить до реально используемого объёма. Забыл сказать о памяти данных, это тоже единицы КБайт в лучем случае (хранение только конфигурации), до единиц мегабайт (звук, трасса движения).

Сообщение отредактировал Frolov Kirill - Jun 1 2012, 09:14

я наврал, срывает не стек, конечно, просто закончилась 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 не знал.