Давайте посмотрим, на Вашем любимом IAR:

Скомпилируйте этот код и пройдитесь по нему отладчиком,
я думаю что результат Вас сильно порадует, особенно второй memcpy

P.S Тока не нужно мне рассказывать что этот пример высосан из пальца...
Прямое преобразование типов конечно вставлено специально,
тока где и когда Вы наткнетесь на такой результат в реальной программе будете знать
тока Вы и Ваш доктор в дурке (после отладки такого кода)

Преимущества они и в Африке преимущества.

Вы прекрасно понимаете, что ими можно не пользоваться. Иными словами, если вас не устраивает по какой то причине прямое обращение к EEPROM либо FLASH памяти, вы можете использовать обращение аналогичное применяемому в WinAVR. Никаких проблем не вижу. Более того вы, естественно можете переписать и сами процедуры обращения. Или использовать свои библиотеки.

У меня действительно один раз было, при применении в одном операторе различных видов памяти, компилятор неверно (точнее не так как я хотел) компильнул. Проблема обнаружилась легко. После локализации места, прошёл оператор по шагам на асме в отладчике. Обнаружил ошибку. Устранилась легко. Прямым приведением типа.

Трагедии никакой здесь нет. Я думаю в WinAVR тоже найдётся немало скелетов в шкафу.

Я, совершенно не приумаляю достоинства WinAVR. Я просто отметил что им не так уж просто пользоваться и привёл свои аргументы. Исключительно исходя из своих наблюдений. Мне оказалось проще и приятнее работать в IAR. В то же время, если человек свободно программирует и в IAR и в WinAVR, то ему это только плюс. Знаний, как известно, лишних не бывает.

Если хочется писать PORTB_0 = 1, это можно сделать средствами любого ANSI C совместимого компилятора. Например, как в SDCC для HC08:


Изменил одну строчку, чтобы работало для AVR. PTB0 = 1, и даже PTB0 = PTB2 будет работать без проблем, причем для всех портов (где-то как sbi/cbi, где-то lds + sts). Написали один раз что-нибудь типа bitio.h, и пользуйтесь. Но лучше (надеюсь, грамотные люди со мной согласятся) для конкретной задачи шевеления ногой писать макросы или online функции типа led_busy_on(), led_busy_off() и в коде использовать уже их. led_busy = 1, IMHO, хуже, разве что led_busy = ON ...

Операцию = можно перегрузить для eeprom, но это уже будет C++.

Про генерацию кода ничего не скажу. Сам использую gcc для разных платформ, включая PC.

Ок, аналогичный пример:

Проблема здесь та же самая что и в вашем примере, и даже без переменных в eeprom.
Поэтому можете также вместе с доктором ковырять и этот код. Ибо когда нет понимания, что происходит в программе и что может происходить - забудьте про (void *).

И совершенно без понимания. Отсюда сюрпризы и жалобы на компилятор. Подсказка - любой указатель (на RAM) приводится к void * автоматически. Имеено поэтому в прототипе данной функции используется указатель на void* а не на char*. А любой указатель на флеш автоматически приводится к void __flash *. Поэтому в прототипе memcpy_P в качестве источника использован void __flash *. Чтобы если вы ошибетесь - компилятор мог распознать эту ошибку. Аналогично с указателями на __eeprom. Если вы примените __eeprom указатель как аргумент memcpy, компилятор вам выругался, что вы хотите невозможного. Если после этого вы тупо делаете явное приведение (и тем самым отключаете контроль типов) - то кто же вам злобный буратина? Вот вам встречный пример:Напишите с функциями то же самое. Как минимум код будет менее понятный и вы не обойдетесь без приведений типов - а они источник потенциальных ошибок, что вы нам продемонстрировали сами чуть выше.

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

Насколько я знаю, в стандарте С вобще нет такого типа void __eeprom *

А вот теперь представьте себе:

Хрен знает какие данные оказались не совсем хрен знает какими, а все по тому что
кое кто придумал свой новый тип данных... __eeprom xxx

А я жаловался на компилятор ?
Нет, ну конечно было пару раз когда я указывал на проблемы с оптимизацией, но не более того...
Разговор о том что нету в С таких типов __flash xxx и что не стоит этими придуманными типами
пользоваться как обычными типами.
Менее понятен/более понятен, это все таки очень субъективные вещи,
для меня например значительно более понятным при работе с EEPROM является или
прямой вызов функций записи в него, или просто запуск записи с последующей проверкой
что запись уже закончилась. При этом вопросов с приведением типов обычно не стоит,
поскольку посредством вызова функции я четко указываю о своих намерениях.
Тот код который Вы привели конечно выглядит красиво, мой намного зануднее...
НО, объясните мне как Вы будете пользоваться такими присвоениями в следующей
ситуации:
Есть прога:
- все события(опросы) синхронизированны(системный тик) например с тактом 200-500мкс
- есть одно или несколько прерываний которые получают данные
- есть основной цикл который ведет обработку полученных в прерывании данных
- НУЖНО, не прерывая обработку, писать некоторые изменения соcтояния проги в EEPROM

Где в этой проге можно написать cfg_EE = cfg_RAM ?

Момент номер 2,
когда Вы пишите cfg_EE = cfg_RAM , Вы принудительно заставляете перезаписывать
в EEPROM даже те ячейки которые в данный момент не требуют модификации.
Этим Вы осознанно уменьшаете ресурс EEPROM.
Во всех моих занудных алгоритмах записи в EEPROM, перед тем как
записать байт из какой-то структуры в соответствующее место EEPROM происходит
чтение этого адреса и проверка на то, а нужно ли его вобще перезаписывать.

Как Вы думаете, в среднем, какой вариант общения с EEPROM будет более
быстрым и более надежным(в смысле ресурса EEPROM) ?

В вашем примере баг абсолютно такой же как и в моем.
Ибо нефиг несовместимый тип приводить к PVOID.


В AVR три адресных пространства. Насколько это удобно или неудобно не вам судить, и не мне. Они просто есть, IAR дает нам простой инструмент доступа к этим адресным пространствам, если вам такой способ доступа не подходит - пользуйтесь другим, более сложным.



Кому что.. Меня как правило интересует конечный результат, если воспользовавшись фичей X я смогу добиться конечного результата меньшим числом строк кода и не в ущерб наглядности, читабельности программы и скорости испольнения, то обязательно ей воспользуюсь (по крайней мере подумаю об ее использовании). Минусом будет только "Портируемость" внутри семейства и на другие многоадресные семейства МК, а на "протируемость" на одноадресные МК (напр ARM) оно вообще никак не повлияет.

Да и палку вы здесь перегибаете. Что может быть понятнее присваивания?
x = y;

Замечу, что чтение из "откуда-попало" куда удобнее (хотя производительность несколько ниже) при использовании указателей с модификатором __generic, реализация которого у IAR есть, а у остальных аналогичного, похоже, даже в проекте нет.

Хорошо, будем говорить тока за себя,
лично мне очень не нравится ситуация когда
x=y; выполняется несколько сот наносекунд, а
e=k; (где e - eeprom) выполняется несколько миллисекунд.

Ну и остальные отрицательные стороны использования EEPROM как переменных я
уже описал выше.

Ну и что?! У eeprom еще и ресурс ограничен, такова уж особенность этой памяти.
100k раз запишете дальше пойдут сбои.
Какое это имеет отношение к удобному механизму обращения к этой памяти?

Не нравится медленный внутренний eeprom используйте RAM или ставте быстрый внешний FRAM, но удобного способа доступа к нему средствами компилятора уже не будет, придется писать драйвер.

Похоже Вы невнимательно читаете мои посты,
перечитайте пожалуйста №37, и если Вас не затруднит,
ответьте на 2 поставленных мной вопроса,
продублирую их на всякий случай:

НО, объясните мне как Вы будете пользоваться такими присвоениями в следующей
ситуации:
Есть прога:
- все события(опросы) синхронизированны(системный тик) например с тактом 200-500мкс
- есть одно или несколько прерываний которые получают данные
- есть основной цикл который ведет обработку полученных в прерывании данных
- НУЖНО, не прерывая обработку, писать некоторые изменения соcтояния проги в EEPROM

Где в этой проге можно написать cfg_EE = cfg_RAM ?

.......................
Как Вы думаете, в среднем, какой вариант общения с EEPROM будет более
быстрым и более надежным(в смысле ресурса EEPROM) ?

Для этой задачи я поставлю исключительно внешний eeprom либо NVRAM и не буду даже морочиться с внутренним, которого судя по условию задачи просто не хватит для хранения какого либо существенного объема статистики.
Внутренний eeprom лично я использую только для: хранения параметров конфигурации устройства, хранения информации о рестартах + дамп критических структур в случае перезагрузки по WDT.

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

А мне вот и для всей остальной статистики хватает
Наверное по тому что я не умею пользоваться встроенной EEPROM ?
Это вы о чем ? Об этой простоте cfg_EE = cfg_RAM ?
Ну и где здесь минимизация количества записей ?

Свой вариант реализации я уже описал, читаем-проверяем-если нужно пишем, и
это все на уровне байта.
Раскажите мне как Вы планируете минимизировать количество записей при помощи
этой простоты cfg_EE = cfg_RAM ?

такую операцию нельзя прерывать независимо от компилятора - это АППАРАТНОЕ ограничение. Если это не понимать, то знание особенностей использования диалекта языка и компилятора не помогут. Потому вопрос

просто не имеет смысла.
Если используется внешняя память, о чём упомянул defunct, то задача относится опять же не к компиляторам, а есть вопрос архитектуры программы.