RE: Re: RE: Re: Preserving state across reset

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

EEPROM seems overkill

??? This is the strangest set of conclusions that I've seen in a thread for a long time. You are already paying for it; it doesn't cost anything except 2ms/byte of write time. You've spent how many hours agonizing over this? A few simple "ee_savestat = state;" at the right time or periodically and you are done. [Oops; I forgot. With your compiler there are several more hoops to jump through.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

[Oops; I forgot. With your compiler there are several more hoops to jump through.]

Compiler wars round 9,0000: This time it's personal!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't help it if you resemble that remark.

[Seriously, I >>love<< direct assignment to/from EEPROM (and from flash) of named variables. It makes the code much more straghtforward to read IMO. Certainly, you need to know the "penalty"--what code is actually being carried out--but you need to be aware of that no matter what the scheme. I cannot help thinking that using EEPROM is "overkil" because it has much more involved than

eeprom unsigned char ee_savestate = STATE_INITIAL;
...
// At init
state = ee_savestate;
...
// When shutdown needed, or periodically
ee_savestate = state;

Side note on the "periodically": Yes, the EEPROM has a limited number of erase/write cycles per cell. But certain items such as "what field/menu is being shown on the console" can safely be written every time changed and/or saves every second with my compiler, since it does a read before write and won't erase/write if the contents is already set.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The implementation is five lines of code, including the #include avr/eeprom.h. It's a subroutine call, not an assignment, but I quite like that.

Suit yourself. I quite like

eeprom unsigned long ee_power_on_hours = 0;
...
ee_power_on_hours++;

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now now Lee, you're swinging the CodeVision club again :P

Dean 94TT
"Life is just one damn thing after another" Elbert Hubbard (1856 - 1915)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't mentioned a brand-name in the whole thread, have I? ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Help, pleeease, this is my thread about preserving state across reboot.

I don't want it to die the horrible death of a compiler war !

Markus

Markus

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Help, pleeease, this is my thread about preserving state across reboot.

OK, I ripped of the compiler war thread from your one. ;-)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yearhg! Compiler wars...just a newbie in this, hope i don't get linched...

Theusch: What compiler are you using? I do admit that getting a float out of the damn thing nearly cost me a heart attack, and in the end I made it out of two ints in WinAVR... But other than that I don't see any problems.

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee uses CodeVision. CodeVision is aware of the AVR's Harvard Architecture and so it is capable of generating different memory access code depending on the memory type being dereferenced: EEPROM, Flash, or Data.

Unfortunately, the underlying GCC architecture is not Harvard aware right now. There are some tricks in place that can replace direct access to I/O registers with the IN/OUT/SBI/CBI/etc representations. But as it stands it is insufficient for the task of accessing Flash or EEPROM variables in general.

Apparently there's a draft ISO standard for dealing with multiple memory spaces in "standard" C. Perhaps when that is ratified, it might be possible to persuade the main GCC maintainers to incorporate it into GCC. Until that happens, there won't be any practical way to give just the AVR-GCC port the equivalent functionality.