[Sergio66 0]

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

[IgorKossak 0]

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

__eeprom int MyIntEEPROMVar;

[Sergio66 0]

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

<{POST_SNAPBACK}>

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

[KRS 1]

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

<{POST_SNAPBACK}>

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

<{POST_SNAPBACK}>

 

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

[IgorKossak 0]

!!!

Не следует также забывать, что количество записей в EEPROM не бесконечно.

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

И ещё, в EEPROM нельзя объявлять объекты, имеющие конструктор и деструктор (из C++).

[-Tумблер- 0]

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

<{POST_SNAPBACK}>

 

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

 

#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 0]

#define _EEPUT_(ADR,VAL)  {while (EECR & EEWE_BIT); \

EEAR = (ADR); EEDR = (VAL); _CLI();EECR = EEMWE_BIT; EECR = EEWE_BIT;_SEI();}

<{POST_SNAPBACK}>

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

EECR |= EEMWE_BIT; EECR |= EEWE_BIT; // скомпилируется намного оптимальнее

[KRS 1]

#define _EEPUT_(ADR,VAL)  {while (EECR & EEWE_BIT); \

EEAR = (ADR); EEDR = (VAL); _CLI();EECR = EEMWE_BIT; EECR = EEWE_BIT;_SEI();}

<{POST_SNAPBACK}>

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

EECR |= EEMWE_BIT; EECR |= EEWE_BIT; // скомпилируется намного оптимальнее

<{POST_SNAPBACK}>

 

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

[IgorKossak 0]

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

<{POST_SNAPBACK}>

И не будет.

Вот что получается:

    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 1]

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

<{POST_SNAPBACK}>

И не будет.

Вот что получается:

    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

<{POST_SNAPBACK}>

 

Откуда взялись в листинге CLI и SEI ?

вы же и хотели их убрать

[vet 0]

Откуда взялись в листинге CLI и SEI ?

вы же и хотели их убрать

<{POST_SNAPBACK}>

 

Меняем _CLI() на

char sreg_temp = SREG; _CLI();

а _SEI() на

SREG = sreg_temp

[IgorKossak 0]

...Откуда взялись в листинге CLI и SEI ?

вы же и хотели их убрать

<{POST_SNAPBACK}>

Листингом я хотел обратить внимание на преимущества EECR |= EEMWE_BIT; EECR |= EEWE_BIT; против EECR = EEMWE_BIT; EECR = EEWE_BIT; в Вашем примере.

А что касается прерываний, то у меня в рабочих проектах сделано как у vet.

[IgorKossak 0]

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

Накладные расходы на вызов функции при этом ничтожно малы по сравнению с длительностью записи, использование стека - 1 слово.

Зато компактность программы намного возрастает и, что очень важно, повышается наглядность и безопасность использования типизированных обьектов (ошибки, если они есть, вылазят ещё на этапе компиляции).

[-Tумблер- 0]

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

 

Могу обьяснить "свою" причину - я не считаю EEPROM памятью вообще.

Считаю раз и навсегда "это" - внешним устройством.

А для этого гораздо удобнее использовать макрос или функцию

(безразлично - дело вкуса или наличия ресурсов). И совершенно

неудобно использовать обьявление переменной.

Это связано с потенциально высокой уязвимостью этой области

памяти, cбои которой стали уже притчей-во-языцах. Гдето в недрах

этой конференции я уж писал, как сделать, чтобы было хорошо.

И совершенно очевидно, что вероятность сбоя EEPROM-a

слишком высока "просто принципиально", что бы можно было

использовать ее просто как память, которая "не забывает после

выключения".

:)

[IgorKossak 0]

Интересное мнение, хотя и не бесспорное.

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

Появление квалификатора __eeprom привнесло много удобств и совершенно не добавило проблем, т. к. сейчас библиотечные функции решают то, что раньше решалось вручную.

Тем не менее. Хотелось бы услышать мнения и других пользователей.