[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruce D. Lightner
Subject: Re: [avr-gcc-list] How can I use external flash memory?
Date: Sun, 29 Oct 2006 12:59:25 -0800
User-agent: Thunderbird (Windows/20060909)

Anton Erasmus wrote:

The only way to add "program" memory to an AVR is if you have some sort of 
which can execute from data memory.  Your actual application hence runs in the 
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.

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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]