AVR-Chat

New member here. New to AVR but experienced (long ago) in Mot' 68K assembler, and all things electronic.

The AVRs come with 3 basic different types of memory: Flash, EEPROM, and SRAM. I'm familiar with the technical differences between these, but not clear on what each of these is used for when writing a program for the AVR. 

I presume (because of the largest size) FLASH is where the program code is (downloaded to and) stored. But what, typically, is the EEPROM (ie, 512 bytes) is used for? I presume the SRAM is used for storing temporary parameters, data, etc. 

Looking forward to getting the hands "dirty" in asm again! 

Cheers,
Dave
San Jose, CA USA

--- In AVR-Chat@yahoogroups.com, Dave C  wrote:
>
> ... Flash, EEPROM, and SRAM ... not
> clear on what each of these is used
> for when writing a program ... 

Flash stores the program and fixed data.  It can only be modified by a special programming interface (ISP, JTAG, PDI, etc.) or by a special Flash Loader program residing in a special area of Flash memory.

SRAM stores all data that will be modified at run time but does not need to survive a reset or power cycle, including all standard 'C' language variables (except automatic variables in registers).

EEPROM can be used to store data that may be modified at run time but must survive a reset or power cycle.  Many applications don't use EEPROM at all, so you will probably ignore it at first.

The AVR is a Harvard Architecture device, in the original sense of having separate address spaces for program and data memory.  As the 'C' language assumes Von-Neumann Architecture, i.e. a single address space for program and data, like the 68k, assembly language or non-standard features are necessary to get at data in Flash or EEPROM.

Graham.

One application of EEPROM I've done is to store frequency correction
data for DFS chips like the AD9854. The little canned oscillators are
never exactly on the frequency they specify, but the counter in the
DFS chip can be calibrated by zero-beating with a known accurate
frequency source. The calibration info is then stored in EEPROM and
read each time the circuit is powered up. As the oscillators drift
with age, it may need to be re-calibrated.

Zack

On 1/10/13, bayramdavies <Yahoo37849@ecrostech.com> wrote:
>
>
> --- In AVR-Chat@yahoogroups.com, Dave C  wrote:
>>
>> ... Flash, EEPROM, and SRAM ... not
>> clear on what each of these is used
>> for when writing a program ...
>
> Flash stores the program and fixed data.  It can only be modified by a
> special programming interface (ISP, JTAG, PDI, etc.) or by a special Flash
> Loader program residing in a special area of Flash memory.
>
> SRAM stores all data that will be modified at run time but does not need to
> survive a reset or power cycle, including all standard 'C' language
> variables (except automatic variables in registers).
>
> EEPROM can be used to store data that may be modified at run time but must
> survive a reset or power cycle.  Many applications don't use EEPROM at all,
> so you will probably ignore it at first.
>
> The AVR is a Harvard Architecture device, in the original sense of having
> separate address spaces for program and data memory.  As the 'C' language
> assumes Von-Neumann Architecture, i.e. a single address space for program
> and data, like the 68k, assembly language or non-standard features are
> necessary to get at data in Flash or EEPROM.
>
> Graham.
>
>
>

On 10 January 2013, at 6:07 AM, bayramdavies wrote:

> EEPROM can be used to store data that may be modified at run time but must survive a reset or power cycle. 

I thought EEPROM data cannot be modified unless erased (via UV light or such) and re "burned". Doesn't that mean that during runtime modification is not possible? 

Or is my understanding decades out-of-date (like my asm skills are...)? 

Thanks,
Dave

[Non-text portions of this message have been removed]

On 10 January 2013, at 10:26 AM, Dave C wrote:

> I thought EEPROM data cannot be modified unless erased (via UV light or such) and re "burned". Doesn't that mean that during runtime modification is not possible? 

Oops... ELECTRICALLY-eraseable PROM. I see.

Thanks,
Dave

[Non-text portions of this message have been removed]

At 05:13 PM 10/01/2013, you wrote:
>New to AVR but experienced (long ago) in Mot' 68K assembler, and all 
>things electronic.

If you are/were familiar with the 68HC711 then a typical AVR would 
have the same
memories except that the EEPROM is serially accessible rather than parallel
accessible like the 68HC711.

With the 68HC711 the main program residing in the OTP main memory could change
any EEPROM locations for anything that is required.

ie customer Baud rate settings, messages to be displayed which could 
change with
different version of firmware, engine management parameters which would be set
in the field...and anything else which needs to be user changeable but not part
of the main code.

You will find the AVR assembler pretty easy to use once you get your 
head around
the way it works. And yes you will mostly bump into the same people here which
you bump into at AVRFreaks. :-)


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

>> New to AVR but experienced (long ago) in Mot' 68K assembler, and all 
>> things electronic.
> 
> If you are/were familiar with the 68HC711

Never heard of it. lol

> then a typical AVR would have the same memories except that the EEPROM is serially accessible rather than parallel
> accessible like the 68HC711.
> 
> With the 68HC711 the main program residing in the OTP main memory could change
> any EEPROM locations ...

Ah. Grok.

> You will find the AVR assembler pretty easy to use once you get your head around the way it works. And yes you will mostly bump into the same people here which you bump into at AVRFreaks. :-)
> John Samperi

Thanks!