Добрый писать и День! Нигде не могу найти подходящую информацию как и извлекать информацию из флешь памяти (есть такая насущность) в IAR.
На ассемблере таких проблем почемуто не возникало.

#include <pgmspace.h>
.......................

unsigned char tt;
const char __flash Sound[3] = {0,1,2};

...включаем компилятор - всё ОК!
..........
далее хочу взять константу из flash ... пишу

tt = Sound[2]; ( .....пробовал _flash Sound[3] ..и по всякому менял синтаксис)

компилятор выдаёт ошибку:

Ошибка [Pe077]: эта декларация не имеет класса хранения или спецификатор типа
Ошибка [Pe147]: декларация несовместима с "неподписанные символ ТТ"
Ошибка [Pe028]: выражение должно иметь постоянное значение

Вам надо было указать платформу, для которой пытаетесь писать.
Насколько помню, объявления в IAR различаются в зависимости от платформы.
Для STM32 и STM8 достаточно написать:
const char Sound[3] = {0,1,2};
А для AVR нужно:
__flash const char Sound[3] = {0,1,2};
У вас вероятно нарушен правильный порядок объявления.
А обращение во всех случаях одинаково:
tt = Sound[2];

исправил... платформа IAR AVR 6.12

char tt;
__flash const char Sound[] = {0,1,2};

tt = Sound[2];
компилируем имеем

Error[Pe077]: this declaration has no storage class or type specifier C:\pistol\main.h 14
Error[Pe147]: declaration is incompatible with "char tt" (declared at line 11) C:\pistol\main.h 14
Error[Pe028]: expression must have a constant value C:\pistol\main.h 14
Error while running C/C++ Compiler
Total number of errors: 3

Три ошибки в слове х..... многовато даже для двоешника


причем порядок ключевых слов при объявлении массива компилятор пропускает в любом порядке ,но как только константу из флеша присваиваю переменноц так три ошибки


одну ошибку извел объявив переменную int

__flash const char Sound = 6;
int tt;
tt = Sound;


имеем

Error[Pe077]: this declaration has no storage class or type specifier C:\pistol\main.h 14
Error[Pe028]: expression must have a constant value C:\pistol\main.h 14
Error while running C/C++ Compiler

Total number of errors: 2
Total number of warnings: 0



Сообщение отредактировал laryc - Feb 20 2017, 15:22

Простите, а вы на ассемблере тоже команды писали в любой файл в любое место? Попробуйте так:
файл main.c
И если это сработает - читайте букварь по языку Си.

Обратите внимание на "коварность" (в хорошме смысле) оптимизатора IAR.
Если ОН обнаружит что некая переменная на ЕГО взгляд не используется,
то код для ее "обслуживания" вполне может не сгенерироваться.
Отключайте в отладке оптимизацию.

ps - если есть атрибут в версии AVR IAR __root - попробуйте его.
Смотрите распределение памяти в map-файле.

Сообщение отредактировал k155la3 - Feb 23 2017, 15:06

А от себя добавлю, даже с отключенной оптимизацией гарантирует наличие чего-либо "__required"

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

Разбираться, почему не работает оптимизированный код - сильно укрепляет мозг, но не все готовы на такие жертвы
В идеале - надо идеально знать процессор, компилятор, язык программирования и ошибок не допускать.
А на "старте", в том числе для изучения оптимизатора - можно использовать вышеуказанный способ. IMHO.

Хорошо, отключили вы оптимизацию, как бы отладили программу, включили оптимизацию - программа не работает. И что толку от потраченного на эту отладку времени? Какие следующие действия неокрепшего мозга? А я вам скажу: "Аааа!!!! Компилятор глючит! Отдадим в производство программу без оптимизации и надо всем советовать писать программы с выключенной оптимизацией!"

В конце концов программированием занимаются не первокласники, которым на старте проще сказать "на ноль делить нельзя".

По поводу main{} присоединяюсь: ТС троллить пытается...


И вот тут правильный новичок начнёт разбираться что да как, но имея в качестве соломки, да пусть неоптимизированный, но работающий код.
И ко второму проекту правильный шеф получит молодого специалиста (:



До первого курса универа, пока пределы и неопределённости не введены как понятие, да - "на ноль делить нельзя"; и в контроллерах, пока обработчик исключения (если есть это исключение) не прописан - не стоит (читай - нельзя) (;

Правильный начал бы разбираться сразу, не отключая оптимизацию.

Честное слово, напоминает ситуацию - "ищи под фонарем, там светлее".

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

Невозможно укреплять то, чего нет . Увы

А я просто ещё раз напомню, что оптимизация требуется редко. Обычно всё работает и без неё, и памяти тоже хватает.
Вы же предлагаете использовать оптимизацию не по прямому назначению, а с целью вытряхнуть из кода некий класс глюков. Интересная концепция, конечно, но немного спорная

Я только "за". Один из методов анализа при поиске багов, своих и и чужих.
Никак не метод устранения ошибок-глюков.
Ошибка или глюк, причина которых не установлена на 100 проц - исправленным не является.