Re: [avr-gcc-list] How can I use external flash memory?

[Bruce D. Lightner]

Anton Erasmus wrote:
> Hi,
>
> The only way to add "program" memory to an AVR is if you have some sort of 
> interpreter
> which can execute from data memory.  Your actual application hence runs in the 
> internal
> flash, and "executes" the user program in data memory. This data memory can be serial, 
> parallel or even directly from a serial link or other comms link. This might sound silly, but the 
> AVR is actually quite fast enough to run interpreted code at a very reasonable speed.
> Look at http://projects.cappels.org/ for a BASIC interpreter for the AVR.
>
> Regards
>   Anton Erasmus
>   

If anyone is thinking about doing something like this themselves, you 
may be interested in this (rather long) story...

This is the way devices like the "BASIC Stamp" work.  An external 
(serial) EEPROM holds a "pseudo-code" which is read by native AVR code 
and then read and interpreted, one "p-code" instruction at a time.  The 
PicoWeb Server, based on the AT90S8515 (now the ATmega8515), using the 
"avr-gcc" toolset, originally debuted in Circuit Cellar online in July 
1999), worked exactly this way...

 http://www.circuitcellar.com/library/ccofeature/lightner0799/index.asp

The original PicoWeb used a 128K byte I2C serial EEPROM to store 
"p-code" (and Web pages).  The AVR microcontroller only held 8K bytes of 
program (and 1K bytes of SRAM).  The code size of the PicoWweb's p-code 
interpreter was about 3K bytes.  Like many other "pseudo-code" 
instruction sets out there, PicoWeb "p-code" is best characterized as a 
kind of "interpreted" assembly language.

One problem with PicoWeb p-code was that it did not have a compiler that 
allowed users to write programs in a high-level language, like Pascal, 
BASIC or C.  Coding in "p-code" assembly language, although very 
space-efficient, is not for everyone.

Sometime in 2000 I created a C-code emulator for the AVR '8515, in fact 
a complete software-based emulator for 100% of the hardware that made up 
the then commercial version of the PicoWeb Server, including the 
Ethernet controller.  As near as I can tell, to this day, the PicoWeb 
emulator is the fastest AVR instruction-set emulator out there.  On a 
modern Windows (or Linux) PC it actually emulates the AVR instruction 
set at a speed near to (and sometimes faster than) real-time.  (It ain't 
"pretty", but it is fast!)

With a PC-based software emulator in place, debugging new PicoWeb AVR 
code became infinitely easier.  Plus I had learned everything that I 
needed to write yet another AVR emulator.  This gave me a great starting 
point to "teach" the PicoWeb server an interesting "Stupid Computer 
Trick".  Why not write an instruction-by-instruction emulator for the 
AVR written to run *natively* on the AVR?  The Harvard Architecture be 
damed!  With such a thing AVR programs could be run from "data space", 
and stored external to the microcontroller, in the PicoWeb Server's 
relatively spacious serial EEPROM.  Plus, these programs could be 
written in C and compiled using "avr-gcc".

So, using the AVR emulator running on a Windows PC, in a matter of a few 
days (or so!) I was able to write and debug a mostly hand-coded version 
of the AVR instruction set emulator, written to run "natively" on a 
AVR.  This in turn enabled me to write code in C, compile and link it 
with "avr-gcc", and then read and interpret that code from serial 
EEPROM.  The emulator used the same SRAM stack as the native AVR code, 
and could switch back and forth seamlessly between native and 
interpreted code.  Therefore the users could partition C-code routines, 
running some routines as native code, and other (less time-critical) 
code in external serial EEPROM.  (I also experimented with using the 
SRAM in the Ethernet controller chip as an instruction cache for the 
slow serial EEPROM.)

So, how did this AVR interpreter compare to the original PicoWeb's "p-code"?

As it turned out, the size of the AVR interpreter was about the same as 
the "p-code" interpreter, about 3K bytes.  (Maybe "interpreters" are a 
"Zero Sum Game" of some kind?)  As for the size of a "p-code" routine 
that did more or less the same thing as an "avr-gcc" compiled one, the 
p-code had a clear advantage (2-3x), but this varied greatly according 
to exactly what was being coded (and who was doing it!).

Note that in terms of execution speed, the PicoWeb "p-code" and the 
"interpreted AVR" code showed more or less the same performance.  This 
was because the execution speed of both was dictated by the speed at 
which the microcontroller could fetch instructions from serial EEPROM 
via I2C, which was quite slow.

How about the efficiency of the AVR interpreter?  Using the AVR 
emulator, this was easy to determine.  Using the once popular "tiny 
computer" benchmark, "Eratosthenes Sieve Prime Number Program" (BYTE 
January 1983) we determined that on average, the AVR interpreter 
executed 72 "native" AVR instructions for every "interpreted" AVR 
instruction.  As for overall execution speed, as I recall, the 
"interpreter" executed code about 200 times slower than "native" AVR 
code, including the cost of serial EEPROM instruction fetch.  (BTW: My 
1.6 GHz Pentium 4 laptop executes the same program about 2000 times 
faster than "native" AVR code running on an ATmega8515 clocked at 8 MHz).

I haven't touched the native AVR emulator since early 2001.  The fact 
that it allows users to compile and run C-code using "avr-gcc", even if 
the code cannot fit inside the AVR microcontroller, may be interesting 
to some, but it has narrow application.  Atmel keeps giving us bigger 
program memory to work with and we can now change the program code by 
running AVR code (i.e., "bootstrap")!  The cost advantage of using a 
smaller AVR part with an external EEPROM may or may not be there, 
depending upon your application.  Nevertheless, in some situations, 
using an interpreter may make sense.

BTW: I've always wondered how Forth would have worked out for the 
PicoWeb server.  Early on, we had seriously considered using Forth 
instead of our tiny "p-code" interpreter.  However, looking at the 
requirements for PFAVR Forth (13K bytes of program space and 32K byte of 
external SRAM, is clear that particular Forth "port" would not have been 
a good answer for the '8515!

Best regards,

Bruce

--
Bruce D. Lightner
Lightner Engineering
La Jolla, California
Voice: +1-858-551-4011
FAX: +1-858-551-0777
Email: address@hidden
URL: http://www.lightner.net/lightner/bruce/