Если код буквы менее 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$.