Тут пример Micro Menu. Проект написан для WinAVR (AVR Toolchain). В этом проекте размер структуры зависит от размера текстовой строки. В IAR никак не могу добиться и понять, как мне сделать, чтобы размер структуры зависел от размера текстовой строки. Проект компилируется, только если задать так:

Есть ли возможность добиться, чтобы в IAR размер структуры зависел от размера текстовой строки?

Напишите так:
const char* Text;

Оригинальный вариант
const char Text[];
ей эквивалентен, хотя некоторые компиляторы его не любят.

Ваш вариат
char Text[20];
в данном случае имеет совершенно иной смысл - это вы засандалили в структуру массив целиком, а в оригинале только указатель на него.

P.S. В системах меню имена айтемов - обычно всегда константные стринги, а потому никогда не бывает необходимости их куда-то копировать, в том числе и в структуры.

Чтобы не разбираться, можно просто заменить "char Text[];" на "char *const Text;".

Ксения, благодарю за подсказку! Сделал так:

Даже программу не пришлось править. С const IAR выдает ошибки.

Нет, совсем не эквивалентен. В стандарте C99 это называется flexible array member.
Там не сказано, что будет с таким массивом, если объявить переменную, имеющую тип такой структуры. Поэтому моя версия такова: яр при объявлении переменной игнорирует массив переменной длины и не выделяет для него память, как будто его нет совсем, - то ли поленились реализовать, то ли решили, что стандарт этого не требует (вроде бы так оно и есть). А вот gcc реализовал: выделил память под массив нужной длины и положил туда текст - молодцы, чо. Только в результате получается, что этот код не переносимый.


Вот так неправильно: "char __flash *Text;"
Вот так правильно: "char *__flash Text;"

Error[Pa004]: illegal declaration G:\Work\Projects\ATMEL\IAR\C\MENU_TEMPLATE\menu.h 32

Иар прекрасно работал с массивами переменной длины. Но при соблюдении трех условий:
1) В соответствии со стандартом этот массив должен быть последим членом структуры (это условие выполнено).
2) В соответствии со стандартом нельзя делать массив из таких структур (gcc имеет такое же требование, значит и это условие выполнено).
3) Файл должен компилироваться в режиме Си, в C++ массивы переменной длины не поддерживаются стандартом что в ИАРе, что в gcc.

Отсюда можно сделать вывод, что у автора вопроса в настройках стоит галочка "компилировать как C++".

А где такая настройка? Полазил в настройках, пока не нашел.

А на нормальных процах, где не __flash, а const, отлично работает.
Получается, строки будут сидеть в ОЗУ. М-да, кривой этот яр для авр. Что простительно, так как авр сам кривой (раздельные адресные пространства для ПЗУ и ОЗУ).

Отчего же кривой. В данном случае указатель, находящийся внутри структуры, должен указывать на истинный тип стринга. Это не вина указателя в том, что одни програмисты хранят стринги в ОЗУ, а другие в ПЗУ. А если у тех стрингов есть еще какие-то дополнительные атрибуты типа far или huge, то, стало быть, и их придется добавить в тип указателя, иначе его не присвоить.

IAR же в этом отношении не кривой, т.к. позволяет по требованию программиста помещать строковые константы во flash или держать их в OЗУ (последний способ по умолчанию). Там на этот счет у комилятора специальная опция имеется. Тем не менее, в программе тип указателя приходится определять явно - добровольно заменять const на __flash компилятор не станет. И для этого есть очень серьезные основания.

Ну, а в том, что адресные пространства для ПЗУ и ОЗУ раздельные, виноват не IAR, а Гарвардская архитектура.

То есть запись типа char __flash *ptr; вполне нормальна для IAR?

Ну вот "char *const txt;" работает и делает то, что нужно, а "char *__flash txt;" не работает. Так что заменяй-не заменяй, а нужного результата нет. Да и нет способа написать строковый литерал, автоматически ложащийся в ПЗУ (что-то типа "abc"@FLASH).


На этот Гарвард столько собак повесили, что диву даёшься :-)
Тот же Cortex-M3 - очень даже гарвардская архитектура, и адресное пространство у него единое.
Так что архитектура ни при чём. Они решали какие-то другие задачи, но вместе с водой выплеснули и ребёнка, ИМХО.

Да, именно этот атрибут имеют стринги, помещенные во flash. Содержимое хидера pgmspace.h - тому яркое подтверждение (в нем определены printf и scanf, работающие с форматом, лежащем во flash).


Чему тут удивляться, определение const или __flash должно стоять непосредственно перед указателем, к которому оно относится.


32-битник может себе это позволить, а AVR-ке приходится экономить, чтобы адрес поместился в 2 байта.


IAR вроде бы тоже так умеет, только там не FLASH, а имя сегмента надо писать. Впрочем, в отношении стрингов я этого делать не пробовала.

Не надо на IAR наговаривать. Пусть с флеш у него лишние телодвижения. По сравнению с другими компиляторами - небо и земля. С WinAVR (AVR Toolchain) взаимопонимания у нас не нашлось. Чего стоят эти pgm_read_byte, pgm_read_word. И так далее и тому подобное. WinAVR (AVR Toolchain) позволяет писать функции, переменные как попало. IAR тут же выдает сообщения, что функция,к примеру, объявлена\не объявлена не по феншую...
Размер исполяемого кода, опять же, к примеру, гораздо выигрывает, по сравнению с WinAVR (AVR Toolchain)

Виноват, нужно именно так. Я немного запутался, когда написал "char *__flash ptr;" - такая запись для полей структуры довольно бессмысленна.

Структура меню же не меняется в процессе работы? Может тогда проще __flash сразу ко всем menu_item?

Что-то как-то сложно у вас...

Это пример. А что, макрос MAKE_MENU делает что-то принципиально иное?
Просто подумал, что раз меню статически задается, то нет необходимости в двусвязном списке - можно узлы подуровеня в дереве сразу в массиив положить, тогда поля.Next и .Prev будут не нужны.

Уже сделали просто атрибут - и чтение из другого адресного пространства стало прозрачным. И оптимизатор это лучше обрабатывает.