Еще одни грабли от IAR AVR, на этот раз касабельно EEPROM Опции

[ArtemKAD]

При чтении ЕЕPROM в прерывании нет сохранения регистров адреса/данных(EEAR EEDR). Или что то-же самое - не защищаются от прерываний участок с момента записи EEAR EEDR до собственно подачи комманды чтения/записи.
Результат - при работе с ЕЕPROM в прерывании возможна ситация когда разрушаются адрес или данные в операции чтения/записи из основного цикла. В связи с редкостью подобного события возможен крайне трудноуловимый глюк ...

Сообщение отредактировал ArtemKAD - Jul 19 2006, 19:58

[arttab]

Какая версия IAR?

[ArtemKAD]

Какая версия IAR?

Последняя не профи.

Вопрос первый: Зачем запрещать прерывания если программа уже находится в прерывании?
Из него плавно вытекает второй: как компилятор определит что в одном случае функция вызвана из прерывания и запрещать не нужно а в другом случае из фона и запрещать нужно?

Компилятор должен был запретить прерывания при всех обращениях в основном цикле... Как - это уже отдельная тема. У компилятора более чем один способ решить этот вопрос.

Если уж вы решили извратиться и работать с eeprom в прерывании (что само по себе уже глюк, только алгоритма)

Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк ...

Предпочитаю работать с EEPROM вот так из основного цикла программы, когда знаю что, все прерывания запрещены и не что мне не помешает:

void EEPROM_write(unsigned int adres,unsigned char data)
{
while(EECR & (1<<1));
EEAR=adres;
EEDR=data;
EECR |= (1<<2);
EECR |= (1<<1);
}

unsigned char EEPROM_read(unsigned int adres)
{
while(EECR & (1<<1));
EEAR=adres;
EECR |= (1<<0);
return EEDR;
}

Вы не поверите - компилятор делает так-же ... Вот только представте, что произойдет если EEPROM_write было вызвано при не запрещенных прерываниях, а в прерывании вызвано EEPROM_read. И это самое прерывание попало между
EEAR=adres; и EEDR=data;
Результат ясен?

Тоже самое когда без запрета прерывания будет вызван EEPROM_read. Только там последствия сразу не столь разрушительные....

[Сергей Борщ]

Компилятор должен был запретить прерывания при всех обращениях в основном цикле... Как - это уже отдельная тема. У компилятора более чем один способ решить этот вопрос.

Огласите хотя бы один способ.

Если уж вы решили извратиться и работать с eeprom в прерывании (что само по себе уже глюк, только алгоритма)

Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк ...

Теперь знаете - вы сами на него напоролись. Для обхода приходится запрещать прерывания в основном цикле, хотя без этого можно было обойтись. Обращение к eeprom требует ожидания готовности eeprom, а ожидание чего-либо находясь в прерывании - ошибка алгоритма.
TomaT абсолютно прав. Копии данных, которые могут потребоваться в прерывании надо держать в ОЗУ. И грабли сразу исчезнут.
А главное, компилятор сразу станет не виноват.

[ArtemKAD]

Компилятор должен был запретить прерывания при всех обращениях в основном цикле... Как - это уже отдельная тема. У компилятора более чем один способ решить этот вопрос.

Огласите хотя бы один способ.

PUSH/POP-нуть глобальные временные регистры EEAR, EEDR...

Если уж вы решили извратиться и работать с eeprom в прерывании (что само по себе уже глюк, только алгоритма)

Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк ...

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

Даже при разрешенных прерываниях? Даже если ожидаемое событие все равно глобально должно поменять весь алгоритм работы?

TomaT абсолютно прав. Копии данных, которые могут потребоваться в прерывании надо держать в ОЗУ. И грабли сразу исчезнут.

Исправить эти грабли не сложно - сложнее на них не наступить особенно когда о "такой малости" в доках ни слова...