Еще одни грабли от 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 абсолютно прав. Копии данных, которые могут потребоваться в прерывании надо держать в ОЗУ. И грабли сразу исчезнут.

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

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

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

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

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

Он это должен сделать тогда и только тогда когда вызов идет из прерывания. Во всех остальных случаях это будут ненужные накладные расходы. Как компилятор определит, что вызов делается из прерывания?

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

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

?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика.

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

Нет, компилятор тут не при чем. Он физически не может тут ничем помочь. Если уж если вам так хочется поизвращаться - напишите обертку для функции чтения из прерывания.

[ArtemKAD]

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

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

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

Он это должен сделать тогда и только тогда когда вызов идет из прерывания. Во всех остальных случаях это будут ненужные накладные расходы. Как компилятор определит, что вызов делается из прерывания?

Вы сами руцями указываете ему, что процедура является обработчиком...

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

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

?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика.

Именно так. Внутри обработчика (предворительно исключив собственную рекурсию если она могла быть) разрешается прерывание. Чего тут непонятного ?

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

Вы сами руцями указываете ему, что процедура является обработчиком...

Ну так напишите обертку и вручную используйте. Компилятор-то тут при чем?

?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика.

Именно так. Внутри обработчика (предворительно исключив собственную рекурсию если она могла быть) разрешается прерывание. Чего тут непонятного ?

Опс. Еще и вложенные прерывания организовать там, где можно просто тупо взять данные из копии в ОЗУ. Тогда не удивительно, что "грабли" :-)

Сообщение отредактировал Сергей Борщ - Jul 20 2006, 12:24

[ArtemKAD]

Вы сами руцями указываете ему, что процедура является обработчиком...

Ну так напишите обертку и вручную используйте. Компилятор-то тут при чем?

"Грабли" на то и грабли - мирный инструмент пока не получишь от него по носу... Я уже говорил - исправить не сложно, сложно заметить...

?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика.

Именно так. Внутри обработчика (предворительно исключив собственную рекурсию если она могла быть) разрешается прерывание. Чего тут непонятного ?

Опс. Еще и вложенные прерывания организовать там, где можно просто тупо взять данные из копии в ОЗУ. Тогда не удивительно, что "грабли" :-)

Это не "грабли" - при вложении прерываний сразу ожидаешь неприятностей и особо обращаешь внимание на это место.
Ну а по поводу "там, где можно просто тупо взять" - просто и тупо иногда обработка того прерывания и без ЕЕPROM занимает сотни милисекунд. Оставлять запрещенными прерывания на подобное время мне как-то влом .