Thanks a lot to you all for this information. I really do! I'm learning on
an ATmega8 and was just wondering if I could overrule the limits of the
program memory without much effort or changes in the code itself. It was not
my goal to re-invent the wheel. I didn't know about the program/data bus
designs properties (as you all guessed). I love the ATmega8 for what it is
and if I could do all my dreams on this little creature then ... ooo ...
then... then I declare myself as god the almighty :) But that will never
happen! I will go and google further. For you all, I whishes you all a happy
inventive splendid new 2007. Cheers!

Anton Erasmus wrote:
> On Fri, 29 Dec 2006 09:51:56 +0100, "John" <dontmailme@dontmailme.com>
> 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 is a harvard architecture design which means that it has
> separate code and data spaces. Programs can be in code space
> which is in FLASH. Data is in RAM. There are a few AVR devices
> which has RAM in stead of FLASH for the code space. On these devices
> you should be able to "load" different applications into RAM and
> execute them.  If you want a small cheap MCU that can execute code
> from data space, then I suggest you get one of the many ARM variants
> with an external bus. NXP and Atmel both have devices which with only
> a few extra components is good enough to run full Linux.
>
Have a look at the DS80C410/DS80C411 from Maxim, an 8051 derivative
that has the ability to selectively combine program and data space. And
it can remote boot over the network.
--Rocky

On Fri, 29 Dec 2006 09:51:56 +0100, "John" <dontmailme@dontmailme.com>
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 is a harvard architecture design which means that it has
separate code and data spaces. Programs can be in code space 
which is in FLASH. Data is in RAM. There are a few AVR devices
which has RAM in stead of FLASH for the code space. On these devices
you should be able to "load" different applications into RAM and
execute them.  If you want a small cheap MCU that can execute code
from data space, then I suggest you get one of the many ARM variants
with an external bus. NXP and Atmel both have devices which with only
a few extra components is good enough to run full Linux.

Regards
  Anton Erasmus

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>

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

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.

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

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.

Hello ,

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

Best Regards,
Vivekanandan M

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