understanding MCUs: Flash vs. SRAM

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.

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

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?

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.

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...

Thanks,

- Joe

Reply to
Joe Strout
Loading thread data ...

Yes.

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

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.

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

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.

Reply to
Joe Pfeiffer

Yes.

Many MCUs use SRAM but it's not an absolute given. The data does not remain when power is removed; it simply does not need constant refreshing as dynamic RAM does. Remove power and this memory is lost.

Storing data values, lookup tables that may be altered during the course of operation, etc. You write to EEPROM what you want to have remain even when power is removed.

It's not usually a problem for most applications unless you're doing something that requires larger chunks of memory. One case might be interfacing to DOS FAT (for reading/writing SD cards for example). You'd want a few K of RAM in order to keep enough data in memory to do something meaningful. But for the most part the typical MCU program takes up What I'd really like to find -- no doubt for illogical comfort reasons

It just invites bloated coded and there aren't many application that would require it. However, when you need more RAM most MCU's support connection to an external RAM chip, usually via SPI or IC2. This is a better approach because those users who don't need an MCU with so much RAM don't have to pay for it, and Atmel/Microchip/etc. don't have to stock so many variations of their products. Cheaper for everybody.

-- Gordon

Reply to
Gordon McComb

A reasonably close approximation is an ATMEGA640-16AU, which has

64K of flash and 8K of RAM, and delivers about 16 MIPS. The part itself costs about $12 in quantity one.

"64-Kbyte self-programming Flash Program Memory, 8-Kbyte SRAM, 4-KByte EEPROM, 16 Channel 10-bit A/D-converter. JTAG interface for on-chip-debug. Up to

16 MIPS throughput at 16 MHz. 1.8 - 5.5 Volt Operation."

There's a free tool chain for the thing from Atmel (it's really GCC plus downloaders and debuggers), and a good selection of low-cost boards.

If you want more RAM, you can get a board with a memory socket and plug in up to 64K.

A useful board for learning this thing is

formatting link
which costs US $54 and has a slightly differerent ATMega:

128 kBytes Program Flash, 4 kBytes data EEPROM, 4 kBytes RAM. Less RAM, more Flash. That board has five pushbuttons, a 2-line 16 char LCD, a LED, and a power relay, plus all the microcontroller I/O ports and a DB-9 connector. For $17 extra you can get a power supply and data cable to go with it. All the necessary software is free. With that and a PC, you have everything you need to get started.

John Nagle

Reply to
John Nagle

Thanks John, that does look like a nice one.

Neat.

Yes, that looks good. Seems like the ATmega128 is quite popular, too; I see it pop up in a lot of different boards. This looks like a decent one (though I'm still rather fond of Pololu, whose Orangutan line is similar to this in many ways).

Best,

- Joe

Reply to
Joe Strout

My favourite avr board is the mavaric from

formatting link
Brian also has a nice hbridge board
formatting link
code for the board
formatting link
Joe there is an avr gcc package in the fink and darwin ports collections but they are a bit out of date.

Look at

formatting link
for up to date version of gcc, avr dude and other utilities for OSX. They have a nice easy to install dmg file.

or look at Mikey Sklar's instructions for using fink screwdecaf.cx/tools.html

Alex

Reply to
Alex Gibson

That sounds great! But... where is it? The link you mention doesn't exist, but I did a search and found

formatting link
...but the complete contents of that page, apart from links to other pages, is:

Embedded(ActiveProjects){ * The flicker mechanism. * Building and maintaining the Avr-gcc/avra/avrdude tools for OSX. }

...To which I say, sounds great, but where is it? One of the most obtuse web pages I've ever seen.

I've used Fink in the past but wasn't very happy with it, and if the packages therein are outdated, I'd much rather just build from source.

But if the digithink folks really do have a nice up-to-date DMG hidden somewhere on their site, that'd be very helpful.

Best,

- Joe

Reply to
Joe Strout

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.