AVR-Chat

Hi,
The Atmel AVRs I plan on programming have 3 types of memory: SRAM, 
Flash, and EEPROM.

I understand that SRAM contents goes away with power, so flash and 
EEPROM are preferable for "permanent" storage. And I presume when 
development time ends it's advisable to load the program into flash?

When and why is it advisable to make use of these different types of 
memory? Is one better to keep constants in (EEPROM)?

Some ideas, please, to best utilize all memory at my disposal.

Specifically, I'm looking at the ATmega8, ATmega816, and ATtiny13 as 
targets for my development.

Thanks,
Dave

--- In AVR-Chat@yahoogroups.com, davec <davec2468@...> wrote:

> When and why is it advisable
> to make use of these different
> types of memory?

All program has to go into Flash; you've no choice in this matter.  You 
can also store constant data in Flash and use special instructions to 
read it out in your program.  Changing (writing to) Flash from within 
your program is very complicated and you can only do it in chunks 
(sectors).

The data manipulated by your program goes into RAM.  If you have 
constant data, you can read it from Flash, as mentioned above, or from 
EEPROM, both of which require extra work, especially if you are writing 
the software in C.

If you have data that you need to preserve when power goes away, a good 
place for it is EEPROM.  Reading and writing EEPROM is fairly 
complicated, but there is existing software to help.  If you have more 
data of this sort than will fit in EEPROM, then you can try storing it 
in Flash along with the program, but this is really quite difficult.

Graham.

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@...> wrote:
> EEPROM is writable at the byte or word level
As an aside, I believe that EEPROM is also organized in pages but the
processor takes care of the read/modify/write process (if required) so
that it is mostly transparent.

One situation where knowing the page organization is important is if
you're implementing a wear-leveling strategy.  Although I've not seen
official documentation of this, I've seen information suggesting that
the write cycle limit for AVR EEPROM applies to each page rather than
to individual bytes.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

On Apr 27, 2008, at 10:14 AM, Graham Davies wrote:

> If you have data that you need to preserve when power goes away, a  
> good
> place for it is EEPROM.  Reading and writing EEPROM is fairly
> complicated, but there is existing software to help.  If you have more
> data of this sort than will fit in EEPROM, then you can try storing it
> in Flash along with the program, but this is really quite difficult.


IIRC FLASH is EEPROM arranged for faster bulk writes in sectors while  
classic EEPROM is writable at the byte or word level, or sometimes at  
the bit level.

In the AVR the only storage available in program space is FLASH. The  
only storage available in variable space is SRAM. EEPROM has to be  
accessed indirectly through CPU registers.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@...> wrote:
> On AVR one doesn't have that control, the entire byte is  
> erased as part of the write.
On some new AVRs (e.g. ATmega644) you can separate the erase and write
process.  This allows you to code your EEPROM writing routine to erase
if the value is being set to 0xff, perform only the write function if
the bits that are changing are being cleared, or perform both the
erase and write.  The advantage of this tactic is that the operations
take varying amounts of time.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

On Apr 27, 2008, at 1:49 PM, Don Kinzer wrote:

> --- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@...> wrote:
>> EEPROM is writable at the byte or word level
> As an aside, I believe that EEPROM is also organized in pages but the
> processor takes care of the read/modify/write process (if required) so
> that it is mostly transparent.

I've never seen EEPROM that emulated SRAM as you suggest. Writing  
EEPROM generally isn't terribly complex but its definitely a  
deliberate process.

IIRC the EEPROM in HC11 is inverted, erases to 0x00, but generally  
EEPROM erases to 0xFF as in the AVR. Each erase is half of one count  
toward the life of the memory. Toggling a bit from 1 to 0 is the other  
half. On the HC11 I had selective control over which bits in a byte  
were erased. On AVR one doesn't have that control, the entire byte is  
erased as part of the write. Don't know if "erasing" a 1 applies wear  
or not.

Have also used Atmel Dataflash on SPI. This is a different animal than  
the FLASH or EEPROM on an AVR. The Dataflash has an internal RAM  
buffer. All writes copy the entire buffer to the designated page.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Apr 27, 2008, at 9:24 PM, Don Kinzer wrote:

> --- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@...> wrote:
>> On AVR one doesn't have that control, the entire byte is
>> erased as part of the write.
>>
> On some new AVRs (e.g. ATmega644) you can separate the erase and write
> process.  This allows you to code your EEPROM writing routine to erase
> if the value is being set to 0xff, perform only the write function if
> the bits that are changing are being cleared, or perform both the
> erase and write.  The advantage of this tactic is that the operations
> take varying amounts of time.

Every few years I wonder about how to make an odometer in EEPROM with  
evenly distributed writes over the EEPROM bits.

The best I have come up with is a pool of bits to use as a tally for  
each increment. March through the array toggling bits. Then have an  
old fashioned traditional counter for the number of times one has been  
completely through the bit pool. Need a counting system where the LSB  
doesn't toggle every time.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.