реклама на сайте
подробности

 
 
> Еще одни грабли от IAR AVR, на этот раз касабельно EEPROM
ArtemKAD
сообщение Jul 19 2006, 19:55
Сообщение #1


Профессионал
*****

Группа: Свой
Сообщений: 1 508
Регистрация: 26-06-06
Из: Киев
Пользователь №: 18 364



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

Сообщение отредактировал ArtemKAD - Jul 19 2006, 19:58
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
arttab
сообщение Jul 20 2006, 01:42
Сообщение #2


Профессионал
*****

Группа: Свой
Сообщений: 1 432
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 371



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


--------------------
OrCAD, Altium,IAR, AVR....
Go to the top of the page
 
+Quote Post
ArtemKAD
сообщение Jul 20 2006, 09:04
Сообщение #3


Профессионал
*****

Группа: Свой
Сообщений: 1 508
Регистрация: 26-06-06
Из: Киев
Пользователь №: 18 364



Цитата(arttab @ Jul 20 2006, 04:42) *
Какая версия IAR?

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

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

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

Цитата(Семён @ Jul 20 2006, 11:35) *
Предпочитаю работать с 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;
}

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

Тоже самое когда без запрета прерывания будет вызван EEPROM_read. Только там последствия сразу не столь разрушительные....
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Jul 20 2006, 09:32
Сообщение #4


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



Цитата(ArtemKAD @ Jul 20 2006, 12:04) *
Компилятор должен был запретить прерывания при всех обращениях в основном цикле... Как - это уже отдельная тема. У компилятора более чем один способ решить этот вопрос.
Огласите хотя бы один способ.
Цитата(ArtemKAD @ Jul 20 2006, 12:04) *
Цитата
Если уж вы решили извратиться и работать с eeprom в прерывании (что само по себе уже глюк, только алгоритма)

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


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
ArtemKAD
сообщение Jul 20 2006, 10:58
Сообщение #5


Профессионал
*****

Группа: Свой
Сообщений: 1 508
Регистрация: 26-06-06
Из: Киев
Пользователь №: 18 364



Цитата(Сергей Борщ @ Jul 20 2006, 12:32) *
Цитата(ArtemKAD @ Jul 20 2006, 12:04) *

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

PUSH/POP-нуть глобальные временные регистры EEAR, EEDR...
Цитата
Цитата(ArtemKAD @ Jul 20 2006, 12:04) *

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

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

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

Исправить эти грабли не сложно - сложнее на них не наступить особенно когда о "такой малости" в доках ни слова...
Go to the top of the page
 
+Quote Post
xemul
сообщение Jul 20 2006, 11:35
Сообщение #6



*****

Группа: Свой
Сообщений: 1 928
Регистрация: 11-07-06
Пользователь №: 18 731



Цитата(ArtemKAD @ Jul 20 2006, 14:58) *
Даже если ожидаемое событие все равно глобально должно поменять весь алгоритм работы? blink.gif

И что? Взвести флажок и спокойно его обработать как асинхронное событие. Подобная обработка непосредственно в прерывании гарантирует Вам кучку головной боли, хотя, конечно, событие будет обработано на несколько микросекунд раньшеsmile.gif.
Go to the top of the page
 
+Quote Post

Сообщений в этой теме
- ArtemKAD   Еще одни грабли от IAR AVR   Jul 19 2006, 19:55
- - arttab   Какая версия IAR?   Jul 20 2006, 01:42
|- - Семён   [quote name='ArtemKAD' date='Jul 20 20...   Jul 20 2006, 09:15
||- - Сергей Борщ   Цитата(ArtemKAD @ Jul 20 2006, 13:58) Цит...   Jul 20 2006, 11:17
|||- - ArtemKAD   Цитата(Сергей Борщ @ Jul 20 2006, 14:17) ...   Jul 20 2006, 11:49
|||- - Сергей Борщ   Цитата(ArtemKAD @ Jul 20 2006, 14:49) Вы ...   Jul 20 2006, 12:05
|||- - ArtemKAD   Цитата(Сергей Борщ @ Jul 20 2006, 15:05) ...   Jul 20 2006, 12:47
||- - TomaT   Цитата(ArtemKAD @ Jul 20 2006, 14:58) ......   Jul 21 2006, 10:46
|- - SasaVitebsk   Цитата(ArtemKAD @ Jul 20 2006, 12:04) Вы ...   Jul 23 2006, 20:44
- - Сергей Борщ   Цитата(ArtemKAD @ Jul 19 2006, 22:55) При...   Jul 20 2006, 07:26
- - Семён   Цитата(ArtemKAD @ Jul 19 2006, 23:55) При...   Jul 20 2006, 08:35
- - TomaT   Может и бывает нужда такая, но я не очень понимаю ...   Jul 20 2006, 09:12
- - IgorKossak   Судя по всему, никто из отвечавших здесь не заглян...   Jul 21 2006, 09:30
|- - ArtemKAD   Цитата(IgorKossak @ Jul 21 2006, 12:30) С...   Jul 21 2006, 20:29
|- - Сергей Борщ   Цитата(ArtemKAD @ Jul 21 2006, 23:29) Цит...   Jul 22 2006, 10:03
|- - ArtemKAD   Цитата(Сергей Борщ @ Jul 22 2006, 13:03) ...   Jul 22 2006, 10:42
|- - Сергей Борщ   Цитата(ArtemKAD @ Jul 22 2006, 13:42) Цит...   Jul 22 2006, 11:14
- - xemul   ЦитатаСудя по всему, никто из отвечавших здесь не ...   Jul 21 2006, 10:44


Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 30th July 2025 - 22:26
Рейтинг@Mail.ru


Страница сгенерированна за 0.0148 секунд с 7
ELECTRONIX ©2004-2016