Насколько я понимаю, gcc строки символов помещает в ОЗУ.Например:

превращается в примерно следующее:

где name во второй строке есть указатель на область ОЗУ, где находится строка.
Теперь вопрос: как сделать так, чтобы gcc в местах, подобных первому примеру, помещал строки во FLASH и брал указатели соответственно.
Вариант, когда все строки перечисляются в начале программы с атрибутом __attribute__((section(".flash"))), не годятся, ибо неудобно. Точнее, годятся, но неудобно и потому не годятся.

Есть мнения ?
Спасибо.

Я недавно решал такую проблему с ИАРом. Там есть хедер pgmspace.h, который надо подключить, плюс в командной строке компилера прописать команду --string_literals_in_flash

Я не пользуюсь gcc, но, возможно, там есть и хедер и в командной строке подобная директива

Это совсем недавно обсуждалось. На самом деле вы подумайте, ведь не могут строки располагаться не в ПЗУ. Иначе как контроллер будет "помнить" строчку test после выключения питания?? ))) Она располагается в ПЗУ (флэш в данном случае), а в момент инициализации контроллера ПРОГРАММНО подобные строки ( глобальные переменные...) перепичываются (копируются) в ОЗУ и далее используются оттуда, чтобы быстрее было.

Наверное дело не в скорости, а в стандарте языка Си... не знаю

impatt ответ на поставленный вопрос Вы найдете в этой теме.

Это мне известно

Нашел вариации на тему __attribute__((section(".flash"))), оно же макрос PROGMEM или как там его. Мож, я плохо глядел ?...
Интересует именно работоспособность варианта №1 в моём первом посте. Делать заготовки в виде переменных в начале единицы компиляции (файла *.с) неудобно.



Боюсь, что нет, но позже погляжу: gcc не заточен на микроконтроллеры, он вообще ни на что не заточен. Потому там понятие FLASH вне закона вообще. Что можно сделать, так это, например, не копировать секцию .data в RAM, и как-то заставить линкер подставлять указатель нужным образом. Вообще-то я эту кухню не очень хорошо знаю.

GCC это компилятор стандартного языка C!!!

Первое: В стандартном C есть только ОДИН вид указателя, указатель на ячейку памяти. Нет указателя на флеш, на EEPROM на порты ввода/выводы..... только один указатель который должен ссылаться на все. НО: В стандартном C размер типа 'указателя' равен размеру типа 'int', для AVR-GCC - 16-бит.

И тут для AVR-GCC начинаться проблемы.
У AVR можно насчитать четыре адресных пространства:
1. RAM до 64KB;
2. EEPROM - обычно до несколько килобайт, но есть микросхемы с 144 КВ.
3. Байт адресуемая флеш (когда используется для хранения данных) до 256 КБ на ATmega2560.
4. Память программ до 128Кслов на ATmega2560.

Можно ко всей этой памяти обращаться с помощью одного 16-ти битного указателя? НЕТ НЕЛЬЗЯ!!! А ЕСТЬ ТОЛЬКО ОДИН! И НАДО!!!

Теоретически можно избежать всех проблем если сделать указатель 32-х битным... но представьте себе на сколько возрастет размер кода. А еще и int тоже будет 32-х битным.

Приходиться выкручиваться и применять разные нестандартные средства. В GCC это атрибуты. С помощью атрибутов компилятору указывается в какой памяти разместить переменную.
В RAM, без атрибутов. Во флеш:
char __attribute__((__progmem__)) str[] = "Строка";
или тоже самое:
prog_char str[] PROGMEM = "Строка";

Дальше, в GCC оператор присваивания не работает с переменными которые размещены во флеш (и EEPROM тоже). Например:

prog_char с1 = 'A';
char c2;
c2 = c1;

c2 не будет присвоено значение переменной с1 (А), а будет присвоено значение из адреса &с1, но не из флеш а из адресного пространства RAM. Надо писать:

c2 = pgm_read_byte(&c1);

И наконец ответ на ваш вопрос: разместить строку во флеш и передать в функцию указатель на нее, не объявляя переменную можно так:
puts_P (PSTR("test\n"));


Но внутри функции символы из этой строки вы должны получать используя макрос pgm_read_byte():
puts_P (PGM_P str)
{
char c;
....
c = pgm_read_byte(str);
....

}

Анатолий.

PS: Ответы на другие вопросы: "Что будет если стока не попадет в нижние 64К флеша?", "Почему для ATmega256 хватает 16-ти битноко указателя для 128 Кслов?" - дам если спросити.

А что, в GCC модификаторы __flash и __eeprom не работают?
Ужас какой

Может так попробовать:
__no_init __eeprom unsigned int count_SMSinput;

или даже лучше так:
typedef unsigned char __flash FDATA;
typedef unsigned char __eeprom EDATA;
чтобы потом вот так:
FDATA AT_prefix[] = "AT";

И с указателями должно быть все ОК. Наверное так надо:
FDATA power_on[] = "POWER ON";
FDATA *ptrF;
а потом что-то типа:
while(*ptrF) *ptrA++ = *ptrF++;

В ИАРе все работает.
Завтра на работу прийду если не забуту, проверю в GCC

Анатолий, большое спасибо за комментарий. Правда, всё, что вы написали,я себе внятно представляю.
Насколько я знаю, gcc (вернее, cc1, компилятор С) делает из С текста текст на asm-е, который добивает as, а потом получившийся объектник линукет ld. Вплоть до последнего этапа, в объектных файлах (можно прогнать дизассемблером и убедиться) указатели равны нулю, их потом расставляет линкер. Это, видимо, сделано исходя из того, что именно линкер знает, в каких адресах будут находиться секции кода и данных. Это написано в опциях линкера а также его скриптах. Сам cc1 встретившиеся инициализированные и неинициализированные переменные, а также константы, распихивает по секциям уже на этапе изготовления asm. И на этом же этапе учитываются пожелания в виде атрибутов вида __attribute__((section("имя"))), которые где-то в исходниках avr-libc определены как PROGMEM или я забыл, как дословно.
Вероятно, чтобы добиться результата, то есть, получить ответ на мой первоначальный вопрос, нужно знать, как уломать gcc понимать, что инициализированные локальные строки следует воспринимать как константы и кандидатов на размещение не в секцию .data, а в секцию .text. Предполагаю, что это задача нетривиальная.
Возвращаясь к начальной теме, скажу, что текст наподобии:

неудобен как раз тем, что надо строки сперва где-то наверху инициализировать. Неудобно тем, что из-за неимения отладчика я вынужден в код вставлять простецкие ловушки, печатающие в UART слова, и постоянно удаляю их и вставляю в другие места новые.
Конечно, задача не бог весть архиважная, просто думал, мож, известен способ сделать всё просто,используя возможности gcc.


Спасибо за предложение Я чётко себе представляю, как это делается и что получается


Применительно к данным работает атрибут, заставляющий помещать данные в любую секцию: __attribute__((section("имя"))), а линкеру потом объяснить, в каких адресах находится секция с этим именем. Вот и всё. Модификаторов, про которые вы упомянули, в gcc нет (как мне известно). Если что-то подобное есть, то это макросы avr-libc, что не есть часть gcc.

Для одиночной строки

prog_char str_ok[] = "<ok>";

Я писал про это в конце своего предыдущего поста.

Анатолий.

Почитал я все ваши размышления по поводу gcc...Мдя... А чем, не нравится ИАР? Или Вы программируете в пингвинных осях? Зачем столько сложностей?

Религиозные убеждения.

Анатолий.

Ясна

Да, понятно. Как вариант годится, спасибо.



Может, это и ко мне вопрос адресован ?
Если так, то могу сказать, что этот компилятор интересен своей настраиваемостью, многоплатформенностью (включая ОС, на которой запускается и архитектуры). Мне, например, интересны Линукс на x86 и ARM9, и ещё по работе приходится дело иметь с AVR-ками. Мне видится более удобным использовать один компилятор для всего.
Ну и понимая кое-какие аспекты работы этого компилятора появляется интерес полазить в его исходных кодах или даже поучаствовать в его развитии (до этого пока далеко).

1. чем инструмент универсальнее, как это не парадоксально, тем он ограниченнее...

2. одно дело использовать инструмент для того, что бы быстро и качественно что то создать с его помощью, другое дело использовать этот инструмент, для того что бы с помощью него набить себе шишек и узнать его неограниченные возможности...

Назовите хотябы 3 фишек в которых avr-gcc уступает например IAR compiller.

PS.
-Я не люблю кошек!!
-Ты просто не умеешь их готовить...

Я ничего не имею против avr-gcc, и, тем более, не собираюсь здесь разжигать религиозные войны по поводу какой компилятор лучше. Каждому свое: кому то нравится есть кошек, ради Бога, но для меня лучшая рыба - это колбаса.

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



PS: Кстати, в отличае от avr-gcc - iccavr заточен именно под AVR, ну а фишки от этого сами можете посчитать