[fk1 0]

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

 

Если код буквы менее 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. Но только для русского, украинского, беларусского языков.

 

 

[den1s 0]

Если код буквы менее 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). Вдруг поможет из тех кто ни знает.

[fk1 0]

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

 

GCC имеет.

 

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

 

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

 

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

 

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

 

[CADiLO 9]

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

Можно и PIC32 но это уже экономически не совсем оправдано.

[fk1 0]

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

 

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

 

unsigned sms_encode_ucs2(char *dest, const wchar_t *msg, unsigned maxsz)
{
unsigned code;
unsigned n;
        n=0;
        while (maxsz && *msg) { /* ISO8859-5 to UCS2 */
                if (! (*msg&0x80)) code=*msg;
                else code=*(const unsigned char*)msg+0x360;
                sprintf(&dest[n], "%4.4X", code);
                n+=4;
                msg++, maxsz--;
        }
        dest[n]=0;
        return n;
}

/* VS */

static uint_fast8_t sms_decode_7bit(
        wchar_t *text, const uint8_t *msg, uint_fast8_t size
) {
uint_fast16_t byte;     /* сдвиговый регистр */
uint_fast8_t nb;        /* число битов в byte */
uint_fast8_t n;         /* число байт записанных в text */
unsigned code;
        n=0; byte=nb=0;
        while (size--) {
                byte=byte | (*msg++ << nb), nb+=8;
                while (nb >= 7) {
                        code=byte&0x7f; byte>>=7;
                        if (code>=128) code-=0x360;  /* UCS2 to ISO8859-5 */
                        switch(code) {
                                case 0: code = '@'; break;
                                case 2: code = '$'; break;
                                default: break;
                        }
                        text[n]=code;
                        n++, nb-=7;
                }
        }
        text[n]=0;
        return n;
}

 

[den1s 0]

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

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

[=F8= 0]

GCC имеет.

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

 

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

 

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

 

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

 

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

[den1s 0]

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

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

 

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

[CADiLO 9]

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

[fk1 0]

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

 

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

 

 

[Артём__ 0]

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

 

 

 

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

 

Прямо-таки чувствуется какая-то классовая ненависть к АВР (или может что-то подсознательное вылезает) .

Чем они так плохи, что "хуже всего подходит для подобного рода задач".

МК как МК, где-то лучше, где-то хуже.

[CADiLO 9]

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

Так что никакой ненависти - банальная предусмотрительность. Вот многие и уходят кто на себе познал перебои с поставками. MSP, ARM, PIC - но не Атмел

[fk1 0]

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

 

 

[Артём__ 0]

Либо все константы в ОЗУ. Недостатки очевидны. Либо этот 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 - уже может хватить на что-то серьёзное.

 

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

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

 

[=F8= 0]

2 Frolov Kirill.

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