Re: understanding MCUs: Flash vs. SRAM

Joe Strout <joe@xxxxxxxxxx> writes:

I've been reading a lot of microcontroller specs today, and I want to be
sure I understand what I'm reading. Most of them have at least two
kinds of memory. Please let me know if this is right:

Flash Memory: this is written in the course of programming the chip, but
not modified when the program is running. Most kinds of flash memory
can be overwritten a limited (but probably very large) number of times.
Flash Memory of course keeps its contents when power is removed.

Yes.

Internal RAM (also called SRAM): this can be modified while the program
is written. Does this also keep its contents when power is removed?

No -- SRAM "forgets" when it loses power.

Some MCUs have, in addition to these, some EEPROM memory. I know what
EEPROM is, but I don't know how an MCU would make use of it. Can anyone
provide a clue?

I don't think I've seen one with both flash and eeprom -- regardless,
eeprom is used just like flash. The difference between them is that
eeprom is more flexible, as you can erase a single word at a time
rather than a whole segment. It's also more expensive.

I guess if you had both flash and eeprom you'd use flash for things
like the program, and eeprom to hold configuration parameters or logs
that have to survive over power cycles.

Assuming my understanding is correct, it's disappointing how limited
microcontrollers are on internal RAM. PIC- and AVR-based ones have SRAM
measured in bytes (or small kb, e.g. the 4kb on the ATMega128). Even
the ET-ARM Stamp (using an LPC2119 ARM chip) has 128 kb of Flash, but
only 16 kb of internal RAM.

In general, projects that are appropriate for little 8-bit microes
don't need all that much memory (but see below).

What I'd really like to find -- no doubt for illogical comfort reasons
-- is something like an Apple II on a chip: 16k of Flash, and 48k or
more of RAM. In theory, you could then put Applesoft BASIC (or
something very similar) into the Flash, along with a "DOS" for accessing
say an SD card, and then have the full 48k for BASIC programs and
variables. But I'm just dreaming...

That isn't how you'd generally do it -- the basic program would also
be in the flash or eeprom. All you'd have in ram would be variables.
You'd use an emulator for most debugging, and burn your program into
flash or eeprom for on-robot testing. These chips aren't really
intended for the sort of interactive use that an Apple ][ was.

.

Relevant Pages

  • Re: 8051: writing to memory in the program
    ... Non-volatile memory. ... (typically FLASH or EEPROM, ... Interrupts need to be disabled while programming if there are ISRs ... This problem disappears, of course, if you have both FLASH and EEPROM ...
    (comp.arch.embedded)
  • Re: XU1541 and more USB stuff
    ... memory. ... coming along nicely this week (FAT12/16/32/LFN support working for read ... for significantly more buffering reducing the overhead of the USB ... lots of flash and ram. ...
    (comp.sys.cbm)
  • Re: Lifetime of flash memory
    ... FILE ON USB MEMORY" have come out of this. ... and overuse may wear out your memory stick pretty quickly. ... Do _not_ use journalling filesystems on flash memory sticks.) ...
    (Linux-Kernel)
  • Re: making a removable SSD drive nonremovable
    ... Using a FLASH based memory card in the way you suggest is a very ... Are you certain that it's not battery backed RAM? ...
    (microsoft.public.windowsxp.hardware)
  • Re: making a removable SSD drive nonremovable
    ... Using a FLASH based memory card in the way you suggest is a very bad idea. ... Putting in a FLASH based memory will make Windows take a very significant performance hit. ... Are you certain that it's not battery backed RAM? ...
    (microsoft.public.windowsxp.hardware)