Вот такой код написан под ИАР. Мне нужно его переписать под WinAVR чтобы тоже во флеш и как из флеши читать потом блоком по три значения? Спасибо.

Вот, навскидку.
Или ещё поищите

Это я знаю. Там запись и чтение одного байта, а не блока.

Не совсем понял: а чтение блока это разве не многократное чтение байтов?

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

Интересно, а как вы читаете массив в IAR, не переделывая под чтение одиночных байт?

Видимо, имелось в виду, что в ИАРе можно один раз определить переменную как _flash или _eeprom и дальше работать с ней как с обычной, без привлечения дополнительных функций.
Ну, на то он и ИАР... Он за это и денег стоит...

Оно действительно так. Ну да чего уже, все переписал заново.

Это как, подробнее можно? Для каждого присваивания выполняется запись через регистры EEPROM? А как же ожидание готовности? Или компилятор считает, что программисту не фиг обращать внимание на такие мелочи?

Да.
А вы считаете, что создатели компилятора, которые предусмтрели запись через регистры EEPROM настолько глупы, что не догадались организовать и ожидание готовности?

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

Все же, в ГЦЦ сильно не хватает указанных фич, а именно - чтоб был предусмотрен insn для работы с данными, находящимися в определннном сегменте. Вот было бы б!....

Когда программист пишет свой код, ему не мешало бы думать. Это не компилятор, это программист захотел в этом месте использовать переменную, расположенную в EEPROM, а не ее локальную копию в ОЗУ. Если он пользуется инструментом не думая - сам себе злобный Буратина и не нужно пенять на компилятор, который предоставляет думающим программистам удобный способ обращения. Не нравится, хотите врукопашную - вперед, никто (а тем более компилятор) не запрещает писать в регистры EEPROM ручками. Быстрее код от этого не станет, а вот сложнее - однозначно.
Начиная с 4.5.0 в GCC появилась поддержка нескольких адресных пространств, которые будут в новом стандарте. Ждем...

Ну вот я пишу в регистры EEPROM ручками. Естественно, код от этого стал быстрее. Потому что я использую для этого прерывания, имеется кольцевой буфер, куда помещаются ожидающие записи байты, откуда они по прерываниям записываются, не мешая ходу программы. EEPROM - это не область памяти, а фактически устройство, и "естественно" работать с ним именно по прерываниям, а не ожидая часами миллисекундами готовности. Мне кажется, это куда естественней, чем представлять его как память в некоем адресном пространстве, доступ к которому осуществляется экзотическим способом. Лучше честно предъявить пользователю этот способ, а уж он сам решит, как ему работать.

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