В моей проге есть запись по команде в еепром:
1. посылаю команду
2. Байтики принемает уарт и они вне прерывания обрабатываются функцией приемника
3. При получении нужной команды в еепром пишется байт (пишется средствами IAR) и отсылаеются байтики о выполнении. Отсылается не дожидаясь окончания записи (флаг не проверяю).

Задержка между окончанием приема команды на запись до отправки ответа около 7.5 мсек. если не пишу, а отвечаю сразу, то 0,3мсек.
Вопрос: чем вызвана такая большая задержка? Кварц 8 МГц. Время записи одного байта должно быть 1 мсек. МЕГА8

Это не просто любопытство - есть проблемы при записи в еепром в других частях проги. Пытаюсь разобраться.

А почему вы думаете что время записи 1 ms?
уже давно у всех новых атмелов еепром тактируется от внутреннего генератора и время записи
примерно 8.5 ms

Кое что дошло. для МЕГИ8 время записи байта в еепром до 9 мсек. и оно определяется внутреним генератором и свойствами самой еепром.

Вопрос: надо ли запрещать прерывания при записи в еепром или все проходит нормально?

Для начала посмотрите ассемблерный код Вашей программы на запись в eprom, если там нет команды запрещения прерывания, сделайте самостоятельно запрещение прерывания при записи в eprom в своем коде. Это обязательно!

Спасибо всем!
IAR сам не запрещает прорывания ни дожидается окончания записи

сделал так:
__disable_interrupt(); //CLI

здесь пишу

while(EECR&(1<<EEWE));
__enable_interrupt();

Запрещать прерывания нужно только
что бы биты EEMWE и EEWE установились подряд!



а вот пока ждется окончание записи наоборот имеет смысл прервания разрешать! а то все уснет на 9 ms
(если только конечно в перываниях еепром не пишется)

Спасибо KRS. Замечание ценное, но не для моего случая - сбор инфы идут по прерываниям таймера, а анализ вне прерываний. железяка все равно обломается с измерениями.
Если только с индикацией будет плохо попробую поколдовать.

Посмотрите также здесь.
Это я когда-то выкладывал исправленный файл иаровского исходника для работы с ЕЕПРОМ.

Этим файлом надо заменить старый в ИАРЕ? как он работает (что исправлено от родного)? Бегло глянул - прерывания не запрещает.

Исправлений как раз много и прерывания запрещает как положено.
А смотреть намного удобнее не бегло, а какой-нибудь утилитой сравнения\слияния (WinMerge, KDiff3, CS Visual Diff, ...).

Копаться в чужом тексте дело не благодарное. Жаль что нет описания изменений, но все равно спасибо.

Ну я же дал себе труд покопаться в иаровском тексте. И нисколько не жалею. Надо же как-то квалификацию поднимать.
А описание можно свести к двум пунктам:
1) любая критическая работа с ЕЕПРОМ (за исключением кристаллов AT86RF401), требующая непрерываемости, обрамлена в обёртку типа:
сохранить SREG
CLI
критическая работа с ЕЕПРОМ
восстановить SREG
2) исправлена ошибка в подпрограмме записи в ЕЕПРОМ 64-битных чисел.

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

А зачем так сложно? Гораздо проще объявить переменную в EEPROM. Тогда обращения к ней IAR делает автоматически все сам, со всеми прибамбасами.

Я так тоже думал...
Я обявил масив в еепром и пишу в него так:
void Conf_B_B(unsigned char z, unsigned char y)
{
unsigned char __eeprom* ub;
unsigned char* uc;
unsigned char i=6;

ub = Conf_BR + z;
uc = str + y;
*(ub) = *(uc);

__disable_interrupt(); //CLI
while (i)
{*(ub) = *(uc);
uc++;
ub++;
i--;}

while(EECR&(1<<EEWE));
__enable_interrupt();
}
Пришлось самому прерывания запрещать