IAR: запись в EEPROM по прерыванию, как это организовать? Опции

[vitko]

Подскажите, пожалуйста, как в IAR оpганизовать запись во встроенную EEPROM из буфера по прерыванию, так чтобы это не мешало обращению к переменным в EEPROM как обычным переменным в памяти данных.

Сообщение отредактировал vitko - May 24 2007, 10:23

[vitko]

Мне нужно переписать N байт из ОЗУ в ЕЕПРОМ. Если я напишу:

for (i=0, i<N, i++ ) *EE_ptr++ = *RAM_ptr++ ;

- надеюсь компилятор не запретит глобально прерывания на все время записи масива ?

[IgorKossak]

Мне нужно переписать N байт из ОЗУ в ЕЕПРОМ. Если я напишу:

for (i=0, i<N, i++ ) *EE_ptr++ = *RAM_ptr++ ;

- надеюсь компилятор не запретит глобально прерывания на все время записи масива ?

Нет!
Если взглянуть как реализованы библиотечные функции обращения к ЕЕПРОМ (\avr\src\lib\eeprom.s90), то видно, что прерывания там запрещаются на крайне непродолжительное время.
Когда-то в форуме Кросплатформенный компилятор IAR я выкладывал доработанный файл eeprom.s90 (с исправленным багом). Поищите.

[singlskv]

Подскажите, пожалуйста, как в IAR оpганизовать запись во встроенную EEPROM из буфера по прерыванию, так чтобы это не мешало обращению к переменным в EEPROM как обычным переменным в памяти данных.

Мне нужно переписать N байт из ОЗУ в ЕЕПРОМ. Если я напишу:

for (i=0, i<N, i++ ) *EE_ptr++ = *RAM_ptr++ ;

- надеюсь компилятор не запретит глобально прерывания на все время записи масива ?

Нет!
Если взглянуть как реализованы библиотечные функции обращения к ЕЕПРОМ (\avr\src\lib\eeprom.s90), то видно, что прерывания там запрещаются на крайне непродолжительное время.

И чем это поможет(запрет прерываний на очень короткое время) когда нужно
писать в eeprom и из основного цикла и из прерывания ?
И как нужно написать обработчик прерывания что бы он правильно разруливал
эту ситуацию (конкурирующие запросы на запись в eeprom)?

ИМХО
Для столь медленного устройства каким является eeprom есть только 2 стратегии его использования
1. Все делаем в прерывании eeprom, заводим буфер обмена с eeprom, как-то разруливаем
переполнение этого буфера.
2. Делаем все поллингом или через стандартный доступ к ЕЕ переменным в IAR, или, что намного
лучше, если в системе есть переодическая обработка событий (например прерывание таймера/
ADC или что-то еще ) опрашиваем окончание последней записи и запускаем новую(если надо),
ну и опять же как-то разруливаем возможные переполнения буфера(ну или как вариант,
делаем функцию опроса занятости буфера и пишем в него только если он свободен)

[IgorKossak]

И как нужно написать обработчик прерывания что бы он правильно разруливал
эту ситуацию (конкурирующие запросы на запись в eeprom)?

И не только на запись. Чтение сразу после записи требует окончания предыдущего процесса.
Не следует при этом забывать одно из пожелений в теме - обращение к обьектам в ЕЕПРОМ как к переменным.
При этом предположение, что всё можно поставить в очередь и эта очередь будет разгребаться где то по прерываниям, а фоновый процесс будет идти без ожиданий, по моему некорректно. Ибо прежде чем прочесть какую то переменную в одном процессе, нужно дождаться окончания записи, начатой в другом процессе (или в этом же). Ситуация, когда нужно только писать, может быть решена с помощью очереди, но это частный случай.

[singlskv]

И не только на запись. Чтение сразу после записи требует окончания предыдущего процесса.
Не следует при этом забывать одно из пожелений в теме - обращение к обьектам в ЕЕПРОМ как к переменным.
При этом предположение, что всё можно поставить в очередь и эта очередь будет разгребаться где то по прерываниям, а фоновый процесс будет идти без ожиданий, по моему некорректно. Ибо прежде чем прочесть какую то переменную в одном процессе, нужно дождаться окончания записи, начатой в другом процессе (или в этом же). Ситуация, когда нужно только писать, может быть решена с помощью очереди, но это частный случай.

Про чтение не упоминал по тому что с ним все гораздо проще.
Никто ведь не мешает нам организовать 2 очереди, одна на запись другая на чтение,
и учитывая то, что чтение практически не отнимает ресурсов, можно при каждом прерывании
по окончанию записи выполнять все отложенные процедуры чтения прямо в этом прерывании.

P.S. Правда это все не имеет никакого отношения к использованию IARом переменных
в области EEPROM, зато имеет отношение к грамотному использованию eeprom.

[VladimirYU]

Про чтение не упоминал по тому что с ним все гораздо проще.
Никто ведь не мешает нам организовать 2 очереди, одна на запись другая на чтение,
и учитывая то, что чтение практически не отнимает ресурсов, можно при каждом прерывании
по окончанию записи выполнять все отложенные процедуры чтения прямо в этом прерывании.

P.S. Правда это все не имеет никакого отношения к использованию IARом переменных
в области EEPROM, зато имеет отношение к грамотному использованию eeprom.

Как бы не пытались, но природу не обманешь. ЕЕПРОМ медленное устройство, поэтому основная программа должна это учитывать. Как это сделать, вариантов предложено достаточно. ИМХО разработчик разберется, выберет или предложит собственный вариант решения СВОЕЙ ЗАДАЧИ. А IAR здесь в самом деле ни причем. Предлагаю тему закрыть.

[IgorKossak]

Предлагаю тему закрыть.

Автор темы согласен?

P.S. Правда это все не имеет никакого отношения к использованию IARом переменных
в области EEPROM, зато имеет отношение к грамотному использованию eeprom.

Грамотное использование ЕЕПРОМ не самоцель ибо операции с переменными должны осуществляться тогда, когда они встречаются в программе, а не скопом. На эту тему было много разговоров при обсуждении volatile. Переменные в ЕЕПРОМ имеют как раз такое свойство. Представьте себе такую же ситуацию с обычными переменными - сначала делаем все записи, потом все чтения. Абсурд.

[singlskv]

Автор темы согласен?
Грамотное использование ЕЕПРОМ не самоцель ибо операции с переменными должны осуществляться тогда, когда они встречаются в программе, а не скопом. На эту тему было много разговоров при обсуждении volatile. Переменные в ЕЕПРОМ имеют как раз такое свойство. Представьте себе такую же ситуацию с обычными переменными - сначала делаем все записи, потом все чтения. Абсурд.

Не все записи а потом все чтения.
По окончании текущей записи делаем все накопившиеся чтения.
Если Вы пользуетесь ячейками EEPROM как переменными, то Вы в любом случае
ждете окончания текущей записи.

[BratherLU]

По-моему проще надо быть - и работать с еепром (читать/писать) только в одной нитке, а фон это или прерывание - это на усмотрение разработчика :)