IAR AVR 4.10A, как обеспечить доступ к EEPROM Опции

[Sergio66]

Еще один вопрос - никак не могу найти ни одной библиотечной функции для доступа к EEPROM. Компилятор Embedded C++, библиотека DLIB. Подскажите, плз.

[IgorKossak]

Не нужно никакой функции. Просто обьявите переменную в области EEPROM:

Код

__eeprom int MyIntEEPROMVar;

[Sergio66]

Еще один вопрос - никак не могу найти ни одной библиотечной функции для доступа к EEPROM. Компилятор Embedded C++, библиотека DLIB.  Подскажите, плз.

И что, доступ к ней ничем не будет отличаться от доступа к обычным переменным в SRAM????????

[KRS]

Еще один вопрос - никак не могу найти ни одной библиотечной функции для доступа к EEPROM. Компилятор Embedded C++, библиотека DLIB.  Подскажите, плз.

И что, доступ к ней ничем не будет отличаться от доступа к обычным переменным в SRAM????????

Да для программы на С это прозрачно! просто компилер вызывает функцию записи или чтения проще всего посмотреть листинг. только вот время записи получается большое и это надо учитывать

[IgorKossak]

!!!
Не следует также забывать, что количество записей в EEPROM не бесконечно.
В этом случае функция больше мобилизировала бы, но зато не так элегантно выглядело бы.
И ещё, в EEPROM нельзя объявлять объекты, имеющие конструктор и деструктор (из C++).

[-Tумблер-]

Еще один вопрос - никак не могу найти ни одной библиотечной функции для доступа к EEPROM. Компилятор Embedded C++, библиотека DLIB.  Подскажите, плз.

Возьмем да и напишем :

#define EEMWE_BIT (1<<2)
#define EEWE_BIT (1<<1)
#define EERE_BIT (1<<0)

#define _EEPUT_(ADR,VAL) {while (EECR & EEWE_BIT); \
EEAR = (ADR); EEDR = (VAL); _CLI();EECR = EEMWE_BIT; EECR = EEWE_BIT;_SEI();}

#define _EEGET_(VAR, ADR) {while (EECR & EEWE_BIT); \
EEAR = (ADR); EECR = EERE_BIT; while (EECR & EERE_BIT);(VAR) = EEDR;}

[IgorKossak]

#define _EEPUT_(ADR,VAL)  {while (EECR & EEWE_BIT); \
EEAR = (ADR); EEDR = (VAL); _CLI();EECR = EEMWE_BIT; EECR = EEWE_BIT;_SEI();}

Комбинация _CLI()/_SEI() плоха, т. к. прерывания до этого могут быть запрещены.
EECR |= EEMWE_BIT; EECR |= EEWE_BIT; // скомпилируется намного оптимальнее

[KRS]

#define _EEPUT_(ADR,VAL)  {while (EECR & EEWE_BIT); \
EEAR = (ADR); EEDR = (VAL); _CLI();EECR = EEMWE_BIT; EECR = EEWE_BIT;_SEI();}

Комбинация _CLI()/_SEI() плоха, т. к. прерывания до этого могут быть запрещены.
EECR |= EEMWE_BIT; EECR |= EEWE_BIT; // скомпилируется намного оптимальнее

Это не поможет! потому что между этими командами не должно быть больше 4 циклов!

[IgorKossak]

Это не поможет! потому что между этими командами не должно быть больше 4 циклов!

И не будет.
Вот что получается:

Код

   146              _EEPUT_(0x2456,0x56);
  \   00000000   99E1                       SBIC    0x1C,0x01
  \   00000002   CFFE                       RJMP    ??init_1
  \   00000004   E506                       LDI     R16,86
  \   00000006   E214                       LDI     R17,36
  \   00000008   BB1F                       OUT     0x1F,R17
  \   0000000A   BB0E                       OUT     0x1E,R16
  \   0000000C   BB0D                       OUT     0x1D,R16
  \   0000000E   94F8                       CLI
  \   00000010   9AE2                       SBI     0x1C,0x02
  \   00000012   9AE1                       SBI     0x1C,0x01
  \   00000014   9478                       SEI

[KRS]

Это не поможет! потому что между этими командами не должно быть больше 4 циклов!

И не будет.
Вот что получается:

Код

   146              _EEPUT_(0x2456,0x56);
  \   00000000   99E1                       SBIC    0x1C,0x01
  \   00000002   CFFE                       RJMP    ??init_1
  \   00000004   E506                       LDI     R16,86
  \   00000006   E214                       LDI     R17,36
  \   00000008   BB1F                       OUT     0x1F,R17
  \   0000000A   BB0E                       OUT     0x1E,R16
  \   0000000C   BB0D                       OUT     0x1D,R16
  \   0000000E   94F8                       CLI
  \   00000010   9AE2                       SBI     0x1C,0x02
  \   00000012   9AE1                       SBI     0x1C,0x01
  \   00000014   9478                       SEI

Откуда взялись в листинге CLI и SEI ?
вы же и хотели их убрать

[vet]

Откуда взялись в листинге CLI и SEI ?
вы же и хотели их убрать

Меняем _CLI() на

Код

char sreg_temp = SREG; _CLI();

а _SEI() на

Код

SREG = sreg_temp

[IgorKossak]

...Откуда взялись в листинге CLI и SEI ?
вы же и хотели их убрать

Листингом я хотел обратить внимание на преимущества EECR |= EEMWE_BIT; EECR |= EEWE_BIT; против EECR = EEMWE_BIT; EECR = EEWE_BIT; в Вашем примере.
А что касается прерываний, то у меня в рабочих проектах сделано как у vet.

[IgorKossak]

Существует бесконечно малое количество причин в применении макроса вместо обьявления переменной в области __eeprom.
Накладные расходы на вызов функции при этом ничтожно малы по сравнению с длительностью записи, использование стека - 1 слово.
Зато компактность программы намного возрастает и, что очень важно, повышается наглядность и безопасность использования типизированных обьектов (ошибки, если они есть, вылазят ещё на этапе компиляции).

[-Tумблер-]

Существует бесконечно малое количество причин в применении макроса вместо обьявления переменной в области __eeprom.

Могу обьяснить "свою" причину - я не считаю EEPROM памятью вообще.
Считаю раз и навсегда "это" - внешним устройством.
А для этого гораздо удобнее использовать макрос или функцию
(безразлично - дело вкуса или наличия ресурсов). И совершенно
неудобно использовать обьявление переменной.
Это связано с потенциально высокой уязвимостью этой области
памяти, cбои которой стали уже притчей-во-языцах. Гдето в недрах
этой конференции я уж писал, как сделать, чтобы было хорошо.
И совершенно очевидно, что вероятность сбоя EEPROM-a
слишком высока "просто принципиально", что бы можно было
использовать ее просто как память, которая "не забывает после
выключения".

[IgorKossak]

Интересное мнение, хотя и не бесспорное.
Из под моего начала вышло более 50000 устройств (с AVR) за последние 5 - 6 лет и ничто не дало мне повод усомниться в EEPROM как именно в памяти. Просто в нашем отделе принято читать и Datasheets и Erratasheets и различные hints и recomendations как программистские, так и конструкторские. И когда мне говорят о проблемах, которые даже "притча во языцех", то я совершенно честно не знаю чем помочь.
Появление квалификатора __eeprom привнесло много удобств и совершенно не добавило проблем, т. к. сейчас библиотечные функции решают то, что раньше решалось вручную.
Тем не менее. Хотелось бы услышать мнения и других пользователей.

[-Tумблер-]

лет и ничто не дало мне повод усомниться в EEPROM как именно в памяти.

Пожалуйста - простой пример:

Прибор время от времени должен спасать некоторые значения
в EEPROM в процессе работы. Которые должны запоминаться.
Это как раз и есть назначение этой области памяти, не так ли ?

Итак, спасение началось. Спасаются...ммм.. 10 значений float.
Посто "так надо".
В этот момент пропадает питание..кратковременно.
Срабатывает системный монитор. Например MAX1232.
По достижении питания 4.5 V.
Что получилось ?
Например, первые два значения спасены целиком правильно,
3-е - прописалось частично (первые 2 байта), остальные значения
остались прежними.

Пропадание питания было кратковременным. По достижении
питания >4.5 V прибор нормально стартует. И что же в итоге ?
Данные частично новые, частично старые, частично разрушены.
Допустим, речь идет о...новогодней гирлянде. Это не опастно,
просто неприятно - праздник как-никак.
Но в самолет с таким контроллером я добровольно не полезу.
А то какя то вспышка молнии, и автопилот так руль заложит,
что мало не покажется.

Получается, что Вам везет.
А мне обычно - не везет. Поэтому я использую эту память
как внешнее устройство.
Замечу, что все эти соображения не относятся именно к AVR.
Это относится к любым EEPROM-ам вообще.

Кстати, мне попался процессор с "битым" байтом в области EEPROM.
Данные там стабильно пропадают ~30 мин.
Так вот - прибор с этим процессором работает правильно, и я не стал
его выкусывать.
$3 экономии - пустячок, а приятно.
"Красивый алгоритм - гимнастика ума".

[IgorKossak]

-Tумблер-, Вы похоже очень спешите читать пост и в результате читаете не весь. Я говорил о комплексном подходе (...различные hints и recomendations как программистские, так и конструкторские.).
Когда же я столкнулся с проблемой похожей на Вашу (правда не в самолёте, а в газовом хозяйстве, что не умаляет ответственности), где была необходимость "спасать" около 2 кБайт данных, и не в EEPROM, а в DATAFLASH (что более геморройно), то зная это заранее, предусмотрел и особую схему питания с суперконденсаторами и ранним предупреждением, и специальные программные трюки с контрольными суммами, дублированиями и восстановлениями.
И надёжность работы устройства уж никак не зависила от взгляда или отношения к тому или иному ресурсу.

[Alex_St]

2 Тумблер:

А что в таком случае мешает использовать CRC или прочие алгоритмы контроля целостности данных? И для особо важных данных писать резервные копии?

А то, что Вы привели, относится к любым типам памяти, будь то RAM, eeprom или HDD. А не к способу их описания.

[-Tумблер-]

А что в таком случае мешает использовать CRC или прочие алгоритмы контроля целостности данных? И для особо важных данных писать резервные копии?

Совершенно верно. Так делаю я - также как и Билли Гейтс.
Делаем резервные копии в количестве N штук. Снабжаем
каждую CRC16. Хочется CRC32, но для avr это все таки затруднительно.

Фактически, алгоритм такой же (или очень похожий) как у FAT.
А теперь попробуйте описать это переменной вида:
int my_var;
Конечно, можно попытаться.
Но это черезвычайно не удобно. Эта переменная должна быть удвоена,
утроена и.т.п. Как обратится к ее конкретному образу?
Или придется описывать класс MY_INT_VAR и перегружать все операции.
Или что-то вроде:
int my_var_1;
int my_var_2; /* где то далеко от _1 - но ГДЕ ? */
...
А потом массив указателей. Что-то это все не красиво.

Гораздо легче и понятней:
#define ADDR_MY_VAR 0x.....

#define OFFSET1 0x...
#define OFFSET2 0x...
а потом write_eerpom (word addr, byte dat, word offset);

byte read_eerpom (word addr, word offset);

Все просто, понятно и точно известно - где каждая переменная и
где каждая из таблиц данных (я решил сохранить это определение,
поскольку воспользовался алгоритмом как у FAT)

А то, что Вы привели, относится к любым типам памяти, будь то RAM, eeprom или HDD. А не к способу их описания.

Мне кажется, вы сами себе противоречите.
Уж конечно, описание переменной в RAM сильно отличается от того,
что на HD. То, что на HD вообще как бы и не описывается - туда
доступ "описанием" нельзя обеспечить. К HD можно обратиться, как
к внешнему устройству. И к eeprom я предлагаю обращаться также.

Кроме того, RAM с одной стороны и HD, eeprom с другой - существенно
разные памяти по степени "опастности".
Дело в том, что в случае сбоя и после перезапуска RAM обновляется и
все OK. А HD и eeprom запоминают неверный результат и в этом все дело.
Вот и получается, что для работы с ними я выбрал сходные алгоритмы.
По моему, это естественно. На мой взгляд, странно предложить другое.

Применив "FAT-алгоритм" мы вдруг с удивлением обнаружим что:
1. мы можем работать с частично разрушенным физически (навсегда) eeprom
2. мы можем восстанавливать разрушенные (по любым причинам)участки eeprom
3. мы можем не ставить больше системный монитор (экономия $0.5/шт)
4. мы не нуждаемся в средствах бесперебойного питания
5. мы можем наслаждаться красивым алгоритмом который изобрели сами
(увы - мы были не первые, но все-таки)

Кстати - "FAT-алгоритм" работает в IBM-PC, да еще как!!!!!
Просто мы не знаем об этом.
Но однажды, когда посыпался мой Fujitsu - 20гб, я вдруг получил
сообщение:
что то вроде: "Обе фат коррупт, не могу починить..."
После этого диск я сдал назад в Техмаркет, а сам стал делать
от 3 до 6 дублей в eeprom
<_<

[dxp]

Совершенно верно. Так делаю я - также как и Билли Гейтс.
Делаем резервные копии в количестве N штук. Снабжаем
каждую CRC16. Хочется CRC32, но для avr это все таки затруднительно.

[...]

Или придется описывать класс MY_INT_VAR и перегружать все операции.

А чем не нравится класс?

Гораздо легче и понятней:
#define ADDR_MY_VAR 0x.....

#define OFFSET1 0x...
#define OFFSET2 0x...
а потом write_eerpom (word addr, byte dat, word offset);

byte read_eerpom (word addr,  word offset);

Все просто, понятно и точно известно - где каждая переменная и
где каждая из таблиц данных (я решил сохранить это определение,
поскольку воспользовался алгоритмом как у FAT)

И чем это лучше? Неслабое нагромождение кода в глобаном scope. В то время как, написав класс, где для вашей переменной объявить массив копий в EEPROM, который и обслуживать:

Код

class TMyEEPROM_Var
{
public:
    TMyEEPROM_Var();
    TMyEEPROM_Var(typename x);
    ... // остальной интерфейс

private:
   __eeprom typename CopyArray[N];
};

Тут уж и проверки сделать при обращениях, и журналирование, и все необходимые операции определить. Т.ч. снаружи это будет просто как обычная переменная. А если уж хочется и отдельные копии смотреть, то и для них функцию определить - типа:

Код

typename TMyEEPROM_Var::get_copy(byte intex)
{
    return CopyArray[intex];
}

Но обращаться именно в EEPROM посредством __eeprom. Только это будет тоже скрыто внутри класса. А функции явные ee_read, ee_write - это явно излишне.

[-Tумблер-]

А чем не нравится класс?

Обьясню - чем не нравится класс.
1 Как быть с внешними eeprom-ами ? Концепцию менять каждый раз ?
Вдобавок, в некоторых проектах использовались оба типа.


2. Использую то я C. Так вышло, мне часто приходится
переходить с процессора на процессор. С с++ бывают
проблемы - например для Fujitsu просто нет.
С переносимостью программ на С проблем (у меня) не было до сих пор.
С пол-оборота всегда и везде все работает.


А вот теперь серьезно:
3. Если мы озабочены сохранностью данных eeprom,
то делать приходится вот что:
разные таблицы-копии располагаются на разном смещении,
обязательно с "проплешинами" между собой. Чтобы не портились сразу
две таблицы.
Дело в том, что "исследования" показали - когда данные портятся,
то они и расположены рядом. Т.е. портятся смежные байты.
Поэтому совет расположить подряд N копий не кажется мне удачным.
Кроме того, возникнут большие затруднения написания подсчета CRC
в такой концепции.
В предложенном мной варианте известен начальный адрес таблицы
и ее размер. А это значит удобно обратиться к такой таблице как к массиву.
Причем, к любому. Хотите - к байтовому, хотите - к вордовому.
Подсчет CRC дело циклическое и "длительное". Удобство
доступа всерьез повлияет на скорость процедуры.

Любое прямое описание переменной в С приводит к ее автоматическому
размещению компилятором. Собственно, это одно из больших достоинств
этого языка. Как раз это, на мой взгляд, и мешает при работе с eeprom.
В этом случае удобно распределить память самому. Это не сложно, поскольку
таких данных сравнительно немного. И это приведет скорей к более компактной
программе - это же к ассемблеру ближе, чем к c++

... Неслабое нагромождение кода в глобаном scope. 

Извините - я этот вопрос просто не понял .
Понятно, что я описал идею, а не приводил в конференции
исходных текстов коммерческих программ.
"..Идею дал? - Наморщи ум..".
Я так понял - мы оба согласились сделать "ЭТО", но с разным описанием
переменных. Но это значит, размеры исполнимых кодов у нас
не сильно отличаются. Причем точно известно - дополнительная "оплата"
размером за ооп обязательно будет. Полагаю от 5% - 10 %.
Так что кодов больше будет
у Вас.
Вот исходных текстов может быть больше у меня. Но это мне не тяжко.
Написал отдельный модуль один раз + .def файл макроопределений.
Этот модуль кочует из проекта в проект. Как впрочем и многие другие.

Удачи !

[dxp]

А чем не нравится класс?

Обьясню - чем не нравится класс.
1 Как быть с внешними eeprom-ами ? Концепцию менять каждый раз ?
Вдобавок, в некоторых проектах использовались оба типа.

Какая разница? С внешним все равно не так работаете. И тут можно другую реализацию сделать. Впрочем, это к делу не относится.

2. Использую то я C. Так вышло, мне часто приходится
переходить с процессора на процессор. С с++ бывают
проблемы - например для Fujitsu просто нет.
С переносимостью программ на С проблем (у меня) не было до сих пор.
С пол-оборота всегда и везде все работает.

Да, переносимость - это единственное серьезное возражение, тут спорить не буду. Если она рулит, то деваться некуда. Но не удержусь от замечания, что С++ все больше и больше завоевывает позиции, и, как следствие, компиляторов тоже все больше и больше. Причем почти полноценных - с шаблонами, неймспейсами.

А вот теперь серьезно:
3. Если мы озабочены сохранностью данных eeprom,
то делать приходится вот что:
разные таблицы-копии располагаются на разном смещении,
[...]
В предложенном мной варианте известен начальный адрес таблицы
и ее размер. А это значит удобно обратиться к такой таблице как к массиву.
Причем, к любому. Хотите - к байтовому, хотите - к вордовому.
Подсчет CRC дело циклическое и "длительное". Удобство
доступа всерьез повлияет на скорость процедуры.

Да нет вопросов - хочется располагать со смещением - располагайте. Хочется работать с отдельными байтами - пожалуйста, никто не запрещает. Я не понимаю, как это конфликтует с объявлением переменной с квалификатором __eeprom?

Класс-то ведь не в EEPROM живет, он - в обычной памяти. А внутри него забиты адреса данных в EEPROM'е. Просто всю работу он инкапсулирует внутри себя. А данные создаете в EEPROM с помощью слова __eeprom с последующей инициализацией представления класса, где в конструкторе прописываете адреса на EEPROM. При этом нет проблем с созданием многобайтных типов (предположим, Вам понадобилось плавучку в EEPROM хранить или вообще разномастные данные - структуры). И полный статический (т.е. на этапе компиляции) контроль типов.

Любое прямое описание переменной в С приводит к ее автоматическому
размещению компилятором. Собственно, это одно из больших достоинств
этого языка. Как раз это, на мой взгляд, и мешает при работе с eeprom.
В этом случае удобно распределить память самому. Это не сложно, поскольку
таких данных сравнительно немного.

Ну и распределяйте, никто не возражает. Только почему бы это не делать с помощью __eeprom. Речь о том, чтобы не лазить в EEPROM руками - для этого использовать интерфейсный объект. Но данные разместить (память выделить) отдельно руками, объявив все необходимое с помощью __eeprom, и проинициализировать интерфейсный объект адресами этих данных в EEPROM. Т.е. внутри класса должны быть указатели типа __eeprom typename *. Конструктор объекта должен требовать определенное количество и тип аргументов-адресов - если забудете что-то ему передать, компилятор ругнется. Безопасность использования выше.

... Неслабое нагромождение кода в глобаном scope. 

Извините - я этот вопрос просто не понял . 
Понятно, что я описал идею, а не приводил в конференции
исходных текстов коммерческих программ.
"..Идею дал? - Наморщи ум..".

Дело не в том, что там было не полное определение реализации дано, а только идея. Дело в том, что согласно тому стилю, присущему С, в глобальной области видимости появится куча достаточно низкоуровневого кода (функции, переменные), работа с которыми, во-первых, неудобна (надо при работе постоянно держать в голове кучу левых сущностей), во-вторых, небезопасна (т.е. через некоторое время начинаешь забывать, что там к чему и легко что-то напутать).

В случае класса вся работа сокрыта внутри - снаружи как раз простой и формализованный интерфейс - пользователь не видит всего этого внутреннего "ужаса" , который не "грузит" ему мозги и не провоцирует на ошибки.

К тому же, можно класс слелать шаблоном и не переписывать все это для разных типов. Один раз написал, и используй для разных типов. __eeprom тут попадает, как говорится, "в струю".

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

[IgorKossak]

Далеко не единственный случай, когда программист не доверяет тому инструменту (компилятору, линкеру), которым пользуется. Причём, под доверием я имею в виду не слепую веру, а точное знание того, как он работает и уверенность в этом.
Мне достаточно часто приходится работать с программистами, которые приходят к C после долгой работы на ассемблере. И едва ли не у каждого из них существует подобная проблема - они теряются от того, что не управляют вручную расположением переменных.

Это мне напомнило один случай из жизни: я спросил у одной подруги: "У тебя есть машина, почему же ты не водишь?", на что она мне ответила: "Когда я сажусь за руль, я колёс не вижу".

[-Tумблер-]

Я не понимаю, как это конфликтует с объявлением переменной с квалификатором __eeprom?

Если происходит обьявление __eeprom int value;
то как раз размещением переменных занимается компилятор.
Это как раз мне и не подходит - для данного случая.

Но я и не предполагал, что некоторая дискуссия о сохранении
данных в eeprom плавно перейдет в дискуссию о применении ооп...
Эти два вопроса совершенно не связаны друг с другом - каждый
сам по себе.

Подумав как следует - пришел я к выводу:
можно было бы конечно написать класс. Но не для переменной.
Класс - таблица. С параметром конструктора "TABLEi_OFFSET".
Это еще "куда ни шло". Полагаю в этом случае оплата за ООП
будет минимальной.
А как вы собираетесь считать CRC в вашей концепции ?
Составлять массив указателей на классы-переменные или
делать связной список из них ? Или разименовывать поочереди ?

В случае класса вся работа сокрыта внутри - снаружи как раз простой и формализованный интерфейс - пользователь не видит всего этого внутреннего "ужаса" , который не "грузит" ему мозги и не провоцирует на ошибки.

Да это я знаю.. (ворчливо).
Пользуемся, как же - когда это всерьез выгодно (шас пойдет реклама):
http://spiprog.narod.ru
Извинением мне служит только то, что обращаю ваше внимание
на исходные тексты, а не на что либо иное.
Действительно, ООП в этом конкретном случае дает огромный выигрыш
в производительности труда. И это меня волнует больше всего.

Теперь о триллере.
Эпиграф: "..Тебе страшно? Мне-нет...". "Малыш и Карлсон", мультфильм.

И где же тут ужас:
my_important_var.save_me_please (); // это у вас
save_my_important_var (); // это у меня.

Мне кажется, что ваши "страхи" на программу в 8К
(а на самом деле в 4- инструкции AVR 16-битные)
слегка преувеличены.