[xemul 0]

Судя по всему, никто из отвечавших здесь не заглянул сюда.

Угу:). Я, если предполагается возможность попытки одновременной записи в EEPROM или записи более 1 байта, организую простенькую очередь и запись с верификацией. Состояние записи и состояние очереди проверяются по программному таймеру 8,2 мс (мне так удобнее). Если необходима и возможна запись в EEPROM, на время ее старта прерывания, естественно, запрещаются.

Все это давно работает на PIC'ах (потому и удобнее). На AVR сейчас плавно пытаюсь переползти, ощущения пока двойственные. И тоже нет флага четности. Может сразу в MSP податься?:)

[TomaT 0]

...

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

 

Выдержка из атмеловского даташита: :1111493779:

Caution: An interrupt between step 5 and step 6 will make the write cycle fail, since the

EEPROM Master Write Enable will time-out. If an interrupt routine accessing the

EEPROM is interrupting another EEPROM access, the EEAR or EEDR Register will be

modified, causing the interrupted EEPROM access to fail. It is recommended to have

the Global Interrupt Flag cleared during all the steps to avoid these problems.

[artemkad 59]

Судя по всему, никто из отвечавших здесь не заглянул сюда.

Уже заглянул . Действительно нечто похожее уже обсуждали и в прикрепленном файле грабли были убраны.

Что касается компилятора, то он и не должен строить предположения насчёт прерываний.

Для него EEPROM и система прерываний - две разные сути. Если пользователю вдруг захотелось эти сути объединить в своей задаче (требованиях), то пусть он (пользователь) этим и займётся, причём тут компилятор.

Там суть в глобальных ресурсах - сохраняет-же он при входе в прерывание SREG, так чем EEAR и EEDR хуже?

Выдержка из атмеловского даташита: :1111493779:

Caution: An interrupt between step 5 and step 6 will make the write cycle fail, since the

EEPROM Master Write Enable will time-out. If an interrupt routine accessing the

EEPROM is interrupting another EEPROM access, the EEAR or EEDR Register will be

modified, causing the interrupted EEPROM access to fail. It is recommended to have

the Global Interrupt Flag cleared during all the steps to avoid these problems.

Тем более IAR-овцы должны были на эту выдержку обратить внимание :( .

Изменено 21 июля, 2006 пользователем ArtemKAD

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

Что касается компилятора, то он и не должен строить предположения насчёт прерываний.

Для него EEPROM и система прерываний - две разные сути. Если пользователю вдруг захотелось эти сути объединить в своей задаче (требованиях), то пусть он (пользователь) этим и займётся, причём тут компилятор.

Там суть в глобальных ресурсах - сохраняет-же он при входе в прерывание SREG, так чем EEAR и EEDR хуже?

Поразительное упорство. А регисты таймера, портов, UARTa, АЦП и прочей периферии компилятор не должен сохранять при входе в прерывание? Нет? А чем они лучше чем EEAR, EEDR?

 

Выдержка из атмеловского даташита: :1111493779:

Тем более IAR-овцы должны были на эту выдержку обратить внимание :( .

Да не надо валить с больной головы на здоровую. Вам пять человек пытаются объяснить, что компилятор тут не при чем. Это не ИАРовцы, а Вы должны были прочитать эту выдержку и обратить на нее внимание. Ибо только Вам известно где Вы работаете с EEPROM - в прерывании, в основном цикле или и там и там. В двух случаях из упомянутых трех никаких "срадств защиты" на которых Вы настаиваете не требуется. И только в третьем случае нужно предохраняться. Но компилятор не имеет _никакой_ возможности определить какой метод пользуете Вы в своей программе. А поскольку обычно (грамотно) используют первые два подхода, то нет никакого резона перестраховываться и генерить лишний код на случай если кому-то придет в голову поизвращаться.

[artemkad 59]

Там суть в глобальных ресурсах - сохраняет-же он при входе в прерывание SREG, так чем EEAR и EEDR хуже?

Поразительное упорство.

:) Я знаю :)

А регисты таймера, портов, UARTa, АЦП и прочей периферии компилятор не должен сохранять при входе в прерывание? Нет? А чем они лучше чем EEAR, EEDR?

Тем, что с этой самой переферией приходится работать самому. Т.е. ее в программе рассматриваешь как набор этих самых регистров. Т.е. в программе таймер ты видишь не как таймер, а как регистры. А ЕЕPROM компилятор представляет как ПАМЯТЬ в которую можно писать и из которой можно читать. Использование "потрохов" для работы с EEPROM для корректной работы выглядит как-то странно.

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

Изменено 22 июля, 2006 пользователем ArtemKAD

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

Там суть в глобальных ресурсах - сохраняет-же он при входе в прерывание SREG, так чем EEAR и EEDR хуже?

Поразительное упорство.

:) Я знаю :)

:-) Но все равно "не выйдет из тебя путёвого старика" :-)

А регисты таймера, портов, UARTa, АЦП и прочей периферии компилятор не должен сохранять при входе в прерывание? Нет? А чем они лучше чем EEAR, EEDR?

Тем, что с этой самой переферией приходится работать самому. Т.е. ее в программе рассматриваешь как набор этих самых регистров. Т.е. в программе таймер ты видишь не как таймер, а как регистры. А ЕЕPROM компилятор представляет как ПАМЯТЬ в которую можно писать и из которой можно читать.

Да, но об особенностях работы с этой памятью ты должен позаботиться сам. Тебя не удивляет ведь, что компилятор не запрещает прерывания при доступе к многобайтовым volatile - переменным? А ведь прерывание может изменить эту переменную посередине чтения в основном цикле. Хочешь атомарный доступ - ручками. Не хочешь - тебе виднее. Когда компиляторы научатся бегать за пивом я уволюсь - ибо тогда программы они смогут писать без меня и подавно.

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

Попробуй вызвать таким манером библиотечную функцию strtok(). Получишь именно только что тобой описанное. Тебя это удивляет? Меня нет. Я знаю, что эта функция нереентерабельная (как и многие другие _библиотечные_ функции).

 

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

[SapegoAL 0]

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

EEAR=adres; и EEDR=data;

Результат ясен?

 

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

 

Кстати аналогичное может произойти не только с EEPROM. И не только в СИ. :)

 

В своё время я нарвался на очень редко проявляющуюся ошибку. При выяснении причин выяснилось что в фоне я делаю сравнение 16-ти битного указателя кольцевого буфера (для определения XON/XOFF) Ну а в прерывании он изменяется. Так вот, если прерывание вызывается м/у сравнением 1-го и 2-ого байта, а в это время в прерывании осуществляется переход по кольцу ... то возникала ошибка. :)

 

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