Потому и руками допиливаются обычные функции и из них появляются особенные - так кроме
int printf(const char *__fmt, ...);
имеем
int printf_P(const char *__fmt, ...);
ЗЫ. Я пробую каждую свежую версию WinAVR и могу заметить, что семимильными шагами движется он в сторону IAR. Проекты под портируемость сразу протачиваем. Но пока это "утомительное застирывание".

to Сергей Борщ
Подскажите, а зачем нужна обвязка из do/while?

Почему не так?

В данном конкретном случае она не нужна. Сила привычки. Началось с того, что увидел такую обвязку в исходниках линукса и задал такой же вопрос в ru.embedded. ReAl мне там ответил, что если внутри макроса будет более одной команды, то их придется заключать в {} чтобы такой макрос можно было использовать как единое выражение в циклах или в конструкциях if(условие) macros(); И все будет работать до тех пор, пока не появится желание сделать if(условие) macros(); else something; - получим ошибку компиляции. Обрамление же в do {}while(0) позволяет использовать такой макрос в любом месте, где допустим вызов обычной функции и не несет никаких дополнительных накладных расходов - сам цикл выбрасывается оптимизатором, остается только его тело. Ну а здесь я их обрамил по привычке, на случай если вдруг придется добавить внутрь еще одно или несколько выражений. Кончно, если пользоваться только С++, то можно реализовать то же самое при помощи static inline функций, но пропадет универсальность в виде совместимости с С.

Подробнее можно? Почему пропадет совместимость, если в C тоже допускаются static inline функции.

В C99. Но, к сожалению, не все компиляторы его поддерживают В С89 inline нет, а если и есть - это расширение конкретного компилятора. В общем "Это работает - не трогай!"

Действительно удобное решение.

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

Кстати, между прочим, переделав eeprom.s90 например на работу с 24xxx получаем удобный инструмент хранения переменных во внешней епромке. Кстати, структуры там тоже отлично хранятся... и массивы...

С точки зрения singlskv это неудобный неиструмент, который может ввести тебя в заблуждение при написании программы и привести десяткам ... нет сотням ошибок. Трудно вылавливаемых ошибок.

Ээээ... А с Вашей?

Я оцениваю это положительно. Сам до такого не додумался. А мне кстати бы не помешало такое решение.
И вообще - всё что сделано - остаётся на годы.

Тут вообще, на мой взгляд бессмыслено оценивать. Раз Вы сделали - значит Вам это понадобилось и для Вас это оказалось удобным. Соответственно моя оценка или оценка другим человеком Вашего труда - будет весьма субъективной.

Я считаю, что фактически, это разработка какой-то базы под себя. И это позволит Вам следующий раз сделать проект быстрее. Соответственно это очень положительное качество. С годами Вы, возможно, переработаете детали и вылижите что-то. Или вообще что-то измените, но наверняка наработанные знания и опыт останутся с Вами навсегда.

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

В принципе была еще одна идея, но это уже злой хак Как известно, ИАР умеет компилировать для моделей памяти с озу >64К. Была идея патчить кодегенератор, дабы он делал не OUT в RAMP?, а out в нужный порт. В результате, можно было бы увеличивать объем озу просто навесив дополнительные адреса на какой-либо порт и не думая о том, как выполнить этот маппинг програмно, все бы на себя взял компилятор. Правда, идея до реализации не дошла (уже не помню почему, кажется, отпала надобность).

Пытался. Используются несуществующие регистры RAMPx. Проблема (сомневаюсь, что показалось) нерешаема.

Rst7, А как Вы считаете, встраивание возможности чтения EEPROM перед ее записью(или
не записью, если там ничего не изменилось) в свой код(или библиотеку) является
правильным/нужным (для увеличения ресурса EEPROM) ?

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

Обычно(чаше всего) обсуждение ведется в русле того, что нужно аппаратными
средствами обеспечить работу контроллера еще какое-то время для того,
чтобы успеть записать эту самую конфигурацию.

Может все-таки стоит в подобных ситуациях озаботиться возможностью
"ВСЕГДА" иметь правильную конфигурацию в EEPROM ?
Правда для этого(часто) придется написать свой код общения с EEPROM.

А давайте вспомним обычную файловую операцию - сохранение файла. Чтобы записываемый файл не убил ещё целый оригинал, нужно писать в другое место. Далее возникают остальные вопросы - как разгребаться с мусоркой и т.п. Файловые системы типа JFFS и новомодная ZFS именно то же делают -записывают на свободное место, а потом разбираются с мусоркой (в JFFS - garbage collection). Но оказывается задачи подобного рода - гарантированная запись некоего блока данных - возникали и раньше, например, в бесконтактных фискальных системах (карточки Mifare). Дык там это не пальцы загибать, а денюжки хранить. ЧТо придумывать будем?))