Newbie question on Atmel AVR expanding program Flash

Newbie question : Suppose that the Atmel AVR internal flash memory is to
small to store my new asm program into it, and suppose that you can't make
your program smaller than what it is (graphics are in SRAM, did it all in
ASM and so one. ps: this is a theoretically question). Is there a way to
expand the program-flash memory of the AVR. I'm writing in ASM and I rather
not want to use pseudo code stored in SRAM and make my own compiler for it
(or use any other compiler and have to learn a new pseudo language to do
this). I was hoping on adding a new large SRAM chip on the PCB and store the
full program into that one, and let the instruction pointer jump to that one
or fetching lines of code out of the new SRAM and process it. (I'm dreaming
right now.)

Anybody ?

John wrote:
> Newbie question : Suppose that the Atmel AVR internal flash memory is to
> small to store my new asm program into it, and suppose that you can't make
> your program smaller than what it is (graphics are in SRAM, did it all in
> ASM and so one. ps: this is a theoretically question). Is there a way to
> expand the program-flash memory of the AVR. I'm writing in ASM and I rather
> not want to use pseudo code stored in SRAM and make my own compiler for it
> (or use any other compiler and have to learn a new pseudo language to do
> this). I was hoping on adding a new large SRAM chip on the PCB and store the
> full program into that one, and let the instruction pointer jump to that one
> or fetching lines of code out of the new SRAM and process it. (I'm dreaming
> right now.)
> 
> Anybody ?
> 
> 
> 

No

  I spent too much time on 8515 , trying to put code in RAM .
  The architecture is just too hard to work with .

  It was too slow accessing the run code in FLASH ,
  But i did get it to work by using lots of INTERUPTS as
 vectors into modular code .

  You could execute "mid" level routines in RAM and they would
 call routines in FLASH , by vectoring thru those fixed location
 INTERUPTS .

  But i use tiny low powered MCUs that are far easier to
code and very cheap .  ARM7 ....

John wrote:
> Newbie question : Suppose that the Atmel AVR internal flash memory is to
> small to store my new asm program into it, and suppose that you can't make
> your program smaller than what it is (graphics are in SRAM, did it all in
> ASM and so one. ps: this is a theoretically question). Is there a way to
> expand the program-flash memory of the AVR. I'm writing in ASM and I rather
> not want to use pseudo code stored in SRAM and make my own compiler for it
> (or use any other compiler and have to learn a new pseudo language to do
> this). I was hoping on adding a new large SRAM chip on the PCB and store the
> full program into that one, and let the instruction pointer jump to that one
> or fetching lines of code out of the new SRAM and process it. (I'm dreaming
> right now.)
> 
> Anybody ?

Hello ,

   Look for a different Chip (of the same family), which has higher
flash, that will meet your requirement.

Best Regards,
Vivekanandan M

Well, I could move to another chip, but then there is still one question in
my mind: What in the hell (sorry for the word) is then the difference
between an 8bit AVR and a (let say) 8080 (easier for me to understand at DOS
level) if they both use a full functional ASM language (kindly different
ASM, but that's not the point). In the 8080 you could load programs via DOS
(which is just an ASM file) from out of anywhere to somewhere and run it
(I'm not talking about multiprocessing or threading, just more DOS alike and
I don't know how they do it in ASM, but DOS is working not?). Why is this
not possible on the AVR? I'm really a newbie on this one and I'm still
wondering, where is the difference? It can not lie in the functionality of
the ASM language, nor it could be in the IO pins we have massively? So what
is the basic difference that make this impossible? Can someone give me a
hint on this one so that I can google further, and sleep back normal again.

John wrote:
> So what
> is the basic difference that make this impossible? Can someone give me a
> hint on this one so that I can google further, and sleep back normal again.

The AVR is a harvard architecture chip  - Program memory is totally
separate from Data memory. These 2 memory spaces do not overlap at all.
You can only run code from Program memory, not Data memory.

To expand the Program memory you'd need an AVR chip with an external
program memory bus. The problem is, as far as I know, Atmel don't make
such a chip. Some AVRs (such as the ATMEGA162) have an external _data_
memory bus but not a program memory bus.

The best solution is to simply upgrade to another AVR chip. This is the
cheapest and easiest option. What chip are you using at the moment?

Cheers,

Al

John wrote:
> Well, I could move to another chip, but then there is still one question in
> my mind: What in the hell (sorry for the word) is then the difference
> between an 8bit AVR and a (let say) 8080 (easier for me to understand at DOS
> level) if they both use a full functional ASM language (kindly different
> ASM, but that's not the point). In the 8080 you could load programs via DOS
> (which is just an ASM file) from out of anywhere to somewhere and run it
> (I'm not talking about multiprocessing or threading, just more DOS alike and
> I don't know how they do it in ASM, but DOS is working not?). Why is this
> not possible on the AVR? I'm really a newbie on this one and I'm still
> wondering, where is the difference? It can not lie in the functionality of
> the ASM language, nor it could be in the IO pins we have massively? So what
> is the basic difference that make this impossible? Can someone give me a
> hint on this one so that I can google further, and sleep back normal again.

The AVR uses a Harvard architecture. See
http://en.wikipedia.org/wiki/Harvard_architecture

The 8080 uses a Von Neumann architecture. See
http://en.wikipedia.org/wiki/Von_Neumann_architecture

Harvard design is simpler, especially if you want single cycle code
execution.

Hi John,

As others have pointed out already, the AVR is a "harvard"
architecture. This means, it is not possible to fetch instructions from
the (separate) data bus.

However, there are (humble) ways around this problem.

1) There exist (a few) AVR parts with a pseudo van-Neumann
architecture. This means, the instruction and data busses are connected
to the same memory, effectively enabling the part to fetch instructions
from data memory. The AT94 FPSLIC parts are an example of this rare
class of AVRs.

2) If your code is changed very infrequently, you can use the "self
programming" feature that some of the newer AVRs provide. It's possible
to load code from an external source, write it to the instruction flash
and then execute it. There is a (quite low) limit on how often you can
do this, so it really depends on your application if this method is
useful to you.

3) While you can't fetch AVR instructions from the data bus, you can
read data from it (obviously). There's no limit on how to process this
data, and in fact you can interpret the data (in software) as if it
were instructions. This effectively allows you to implement a virtual
micro that executes virtual code from the data bus. The "basic stamp"
products do this with a proprietary basic interpreter. The Dunfield
"C-flea" is a cheap 16-bit development suite that includes a C compiler
and virtual machine (he's got one for AVR).

4) Just like the interpreter approach in 3), you can also opt to
emulate an existing microcontroller. This will give you good toolchain
support.  I found the MSP430 architecture is very comfortly to emulate.
In fact I once made a working tiny mixed hardware/software
implementation, that emulates MSP430 on FPSLIC at a 1/6 clock speed (6
AVR cycles imlement 1 MSP430 cycle).

All of this is possible.  However, if you're in an early planning phase
of your project, you're certainly better off choosing another
architecture for your project.  Running into your limits before even
having started is not a good sign.

Regards,
Marc

Arlet wrote:
> John wrote:
> 
>> Well, I could move to another chip, but then there is still one
>> question in my mind: What in the hell (sorry for the word) is
>> then the difference between an 8bit AVR and a (let say) 8080
>> (easier for me to understand at DOS level) if they both use a
>> full functional ASM language (kindly different ASM, but that's
>> not the point). In the 8080 you could load programs via DOS
>> (which is just an ASM file) from out of anywhere to somewhere
>> and run it (I'm not talking about multiprocessing or threading,
>> just more DOS alike and I don't know how they do it in ASM, but
>> DOS is working not?). Why is this not possible on the AVR? I'm
>> really a newbie on this one and I'm still wondering, where is
>> the difference? It can not lie in the functionality of the ASM
>> language, nor it could be in the IO pins we have massively? So
>> what is the basic difference that make this impossible? Can
>> someone give me a hint on this one so that I can google further,
>> and sleep back normal again.
> 
> The AVR uses a Harvard architecture. See
>    http://en.wikipedia.org/wiki/Harvard_architecture
> 
> The 8080 uses a Von Neumann architecture. See
>    http://en.wikipedia.org/wiki/Von_Neumann_architecture
> 
> Harvard design is simpler, especially if you want single cycle
> code execution.

Most machines today are actually Harvard, they just implement a Von
Neuman architecture via the fixed microcoded interpreter.

-- 
Merry Christmas, Happy Hanukah, Happy New Year
        Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
     <http://cbfalconer.home.att.net>