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

Пологаю нужно переписывать eeprom.s90 для работы с прерыванием.

Я бы просто запретил прерывания на время обращения к еепром в фоне для начала...

Может я не понял вопроса, но мне кажется как обычно в IAR. Определяете

#pragma vector = EE_READY_vect
__interrupt void EE_write (void)
{
.....
}

Первый элемент после проверки готовности ЕЕПРОМ пишите в той части программы где надо начать запись, устанавливаете счетчик, а далеее все последующие по прерываниям до тех пор пока не выберете весь буфер. Естествеено в соответствии с правилами обращения с ЕЕПРОМ согласно DS.

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

Игорь, полностью согласен. Сам никогда не использую прерывания при работе с ЕЕПРОМ, но решать, как вы правильно заметили, пользователю.

А, ну если с этой стороны на проблему смотреть
то да, сделать, как Владимир предложил,
либо завести FIFO и писать в него в фоне, а выгребать из него в прерывании (от EEPROM), конечно тормознее получится...

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

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

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

Да тут вообще все ок должно быть, только в прерываниях к еепром обращаться не надо и фсе...

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

Игорь, если не в тягость, в чем суть твоих изменений. Файл я нашел, но с родным еще не сличал. Заранее спасибо.

IgorKossak писал
>Дело в глюке, содержащемся в файле avr/src/lib/eeprom.s90.
>В этом файле надо справить функцию __eeput64_16:
>- ?eeput16 заменить на ?eeput16_64;
>- ?eeput16_inc заменить на ?eeput16_64_inc.
>И далее включить этот файл в проект и компилировать/собирать >всё вместе.

Кроме того, что ответил Вам CSB, там внесены некоторые незначительные изменения в правила доступа к ЕЕПРОМ.
PS Быстро сличать содержимое файлов\папок\архивов мне помогает WinMerge, хотя в сети полно и других средств.

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

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

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

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

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

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

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


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

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

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

Спасибо, с темой понятно. Обойдусь без прерываний.