Вы хотите сказать, что в WinAvr уже можно EEMEM или PROGMEM переменную просто взять и присвоить обычной переменной без использования read_eeprom_byte и прочих вспомогательных функций?

В IAR можно.

На два. defunct объяснил почему.
1) При наличии опыта адаптация происходит быстро.
2) Все равно придется что-то править, а в процессе адаптации глубже вникаешь в чужие исходники.
3) По закону подлости нужный код будет под какой-нибудь третий компилятор и вообще не под AVR.
4) По размеру кода ИАР сильно обгоняет WinAVR (по личному опыту, последний эксперимент - AES loader AVR231 буквально вчера. У ИАРа остается свободное место в 2К области, у WinAVRа код вылазит почти на 1К).С точностью до наоборот. Вот уж что-что, а инлайн асм у WinAVR шикарный, а у IAR вообще никакой и они сами его не рекомендуют. А в обработке отдельного асм-исходника возможности у них практически одинаковые.

А как дела обстоят в IAR c обратной операцией, те присвоением переменной __flash или
__eeprom значения обычной переменной ?

Задачи таки разные бывают,
я уже предлагал вариант задачки для сравнения IAR и WinAVR,
но никто не соглашается

eeChar = Ch , Вам не кажется что такая запись просто вводит в заблуждение программера ?
т.е. он то думает что присвоил значение и побежал дальше, а в реальности мы там ждем
как минимум 3,5мс.
Привыкнув к такой простоте, программер не будет такое присваивание
употреблять например в прерываниях ?
ИТД...

Это был просто ответ на ваш вопрос. А так мне кажется, что одиночному "чару" вне функции вообще нечего делать. Сколько-нибудь уважающий себя "программер" волен объявить структуру с подобающим именем, которое будет кричать о том, что поля располагаются в eeprom.


Это из оперы - программисты не ищут простых путей? Или как понимать?
Давайте также покритикуем возможность винды выделять гигабайтные массивы, ведь программист выделивший такой массив может думать, что весь массив лежит в ОП.

PS: к сожалению мне редко приходится наслаждаться возможностями IAR'а, потому что конечный продукт у меня собирается в WinAvr. При портировании с IAR'а на WinAvr частенько приходится поматериться в местах работы со строками во флеш и данными в eeprom.

Согласен, можно. И в CV можно. А еще в CV можно сделать так - PORTB.1=1. Следуя Вашей логике- "CV на порядок превосходит IAR".
Меня лично не напрягают eeprom_read_byte(), зато помогают больше работать с указателями, что в итоге дает более быстрый и компактный код. При портировании проектов с IAR результирующий размер практически одинаков, но как-то было преимущество WinAvr процентов на 10.
И главное - мне не надо искать кряки, пилюли, пургены успокаивать совесть типа - ничего, у них и так денег много... Чистая совесть это тоже немало.

Вопрос все-таки был не о именовании структуры с кричащим именем
EEPROM_xxx, а о том что присвоение переменной хранящейся в EEROM занимает кучу времени.
Нет, это из оперы что программисты должны понимать чем это грозит.
Дык переходите на Gcc, и будет Вам счастье
Не, я почти серьезно.

Ну-ну... Про преимущества CV- выше

Значит если я хочу ездить на машине, мне нужно ее купить, разобрать,собрать, ведь я так глубже вникну в ее устройство. Мне нужно например подключить харддрайв, считать один файл,и может больше никогда в жизни мне это не понадобиться. Зачем мне вникать во внутреннее устройсто FAT32?
А если и понадобиться, лет через 5-10, то все равно придется вникать заново.

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

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

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

Есть ещё один момент для WinAvr. Только за последних пару лет его пересобирали раз десять. Регулярно что-то меняли в том числе координальное. Так что насчёт совместимости и большого количества проектов это не вся правда. Править придётся. То там то тут выскакивают сообщения - пересобрал - неработает. Работать с ним отнюдь не легче чем с IARом. Хотя и IAR к числу лёгких в освоении пакетов не относится. Документация разбросана по всему интернету. Никакой упорядоченности. Что-то надо - полез искать. Чаще всего если и найдёшь, то в каком нибудь FAQе.

Короче очень геморойная вещь. Ясно что если освоил, то тогда нормально.

Выпад по поводу данных в EEPROM и FLASH - явно бредовый. Удобная вещь - она всегда удобная.

Зачем мне для обращения к Flash переменной обращаться ч/з подпрограмму? А если у меня в одной формуле/операторе используются переменные Flash и RAM? Например знакогенератор в видеоозу вывожу. IAR отличный код генерит и прекрасно оптимизирует такие места. А чтобы по ошибке не использовать переменные EEPROM, выход простой. defunct его фактически указал. Обзавите переменную eeMyInt. И всё для вас будет ясно.

Это просто яркий пример как можно всё с ног на голову поставить.

Эквивалент в EWAVR:
PORTB_Bit1 = 1;
DDRB_Bit3 = 0;

Увы! Началась религиозная война!
По поводу автоматической генерации кода: пришлось использовать CodeWarrior для MC56F8346. Есть для него ProcessorExpert. Если скорость не важна, а важно быстро что-то сделать, то работает хорошо. Если аппаратные ресурсы заняты сильно, то не работала программа: из-за накладных расходов автоматической кодогенерации. В CV такая же ситуация или нет? Если большие накладные расходы, то есть ли смысл в больших проектах использовать?

1)Хорошо, но не совсем: не для всех потров такая конструкция работает, поэтому я не могу сделать, скажем, #define LED PORTA.1 а потом безболезненно изменить на #define LED PORTE.7, в то время как конструкция PORT |= (1 << BIT); с макросами поверх нее не страдает подобным недостаком.
2)Собственно на этом преимущества CV заканчиваются и его нельзя рассматривать как серьезный инструмент из-за отсутствия раздельной компиляции и всеми вытекающими несоответствиями стандарту. Вопрос обсуждался, я излагал подробные аргументы. Если интересно, поищите по ключевому слову CV и моему имени.Если мы говорим о любительстве - не за чем Но не уверен, что у любителя все пойдет сразу и без доработок напильником. Если о профессиональной работе - не помешает.Вы меня не поняли. ИАР выдал код размером ~1800 байт, WinAVR - около 2700. Естественно. Чем примитивнее инструмент, тем меньше вы им можете сделать. Вот цитата из мануала: Если вы не умеете пользоваться инструментом потому, что он слишком сложный - это не значит, что инструмент плохой. На уровне ИАРовского инлайн-асма вы в винавре напишете ровно столько же и практически так же.

Я не рекламирую CVAVR, но работать можно и на нем.
Я и писал

но заменить например в Atmege16 :
#define LED PORTA.1
на
#define LED PORTD.3
несоставит труда.