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

[Sergio66]

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

[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 файл макроопределений.
Этот модуль кочует из проекта в проект. Как впрочем и многие другие.

Удачи !