Еще один вопрос - никак не могу найти ни одной библиотечной функции для доступа к EEPROM. Компилятор Embedded C++, библиотека DLIB. Подскажите, плз.

Не нужно никакой функции. Просто обьявите переменную в области EEPROM:

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

Да для программы на С это прозрачно! просто компилер вызывает функцию записи или чтения проще всего посмотреть листинг. только вот время записи получается большое и это надо учитывать

!!!
Не следует также забывать, что количество записей в EEPROM не бесконечно.
В этом случае функция больше мобилизировала бы, но зато не так элегантно выглядело бы.
И ещё, в EEPROM нельзя объявлять объекты, имеющие конструктор и деструктор (из C++).

Возьмем да и напишем :

#define EEMWE_BIT (1<<2)
#define EEWE_BIT (1<<1)
#define EERE_BIT (1<<0)

#define _EEPUT_(ADR,VAL) {while (EECR & EEWE_BIT); \
EEAR = (ADR); EEDR = (VAL); _CLI();EECR = EEMWE_BIT; EECR = EEWE_BIT;_SEI();}

#define _EEGET_(VAR, ADR) {while (EECR & EEWE_BIT); \
EEAR = (ADR); EECR = EERE_BIT; while (EECR & EERE_BIT);(VAR) = EEDR;}

Комбинация _CLI()/_SEI() плоха, т. к. прерывания до этого могут быть запрещены.
EECR |= EEMWE_BIT; EECR |= EEWE_BIT; // скомпилируется намного оптимальнее

Это не поможет! потому что между этими командами не должно быть больше 4 циклов!

И не будет.
Вот что получается:

Откуда взялись в листинге CLI и SEI ?
вы же и хотели их убрать

Меняем _CLI() на

а _SEI() на

Листингом я хотел обратить внимание на преимущества EECR |= EEMWE_BIT; EECR |= EEWE_BIT; против EECR = EEMWE_BIT; EECR = EEWE_BIT; в Вашем примере.
А что касается прерываний, то у меня в рабочих проектах сделано как у vet.

Существует бесконечно малое количество причин в применении макроса вместо обьявления переменной в области __eeprom.
Накладные расходы на вызов функции при этом ничтожно малы по сравнению с длительностью записи, использование стека - 1 слово.
Зато компактность программы намного возрастает и, что очень важно, повышается наглядность и безопасность использования типизированных обьектов (ошибки, если они есть, вылазят ещё на этапе компиляции).

Могу обьяснить "свою" причину - я не считаю EEPROM памятью вообще.
Считаю раз и навсегда "это" - внешним устройством.
А для этого гораздо удобнее использовать макрос или функцию
(безразлично - дело вкуса или наличия ресурсов). И совершенно
неудобно использовать обьявление переменной.
Это связано с потенциально высокой уязвимостью этой области
памяти, cбои которой стали уже притчей-во-языцах. Гдето в недрах
этой конференции я уж писал, как сделать, чтобы было хорошо.
И совершенно очевидно, что вероятность сбоя EEPROM-a
слишком высока "просто принципиально", что бы можно было
использовать ее просто как память, которая "не забывает после
выключения".

Интересное мнение, хотя и не бесспорное.
Из под моего начала вышло более 50000 устройств (с AVR) за последние 5 - 6 лет и ничто не дало мне повод усомниться в EEPROM как именно в памяти. Просто в нашем отделе принято читать и Datasheets и Erratasheets и различные hints и recomendations как программистские, так и конструкторские. И когда мне говорят о проблемах, которые даже "притча во языцех", то я совершенно честно не знаю чем помочь.
Появление квалификатора __eeprom привнесло много удобств и совершенно не добавило проблем, т. к. сейчас библиотечные функции решают то, что раньше решалось вручную.
Тем не менее. Хотелось бы услышать мнения и других пользователей.