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 ?

Reply to
John
Loading thread data ...

No

Reply to
Donald

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

Reply to
werty

Reply to
werty

Hello ,

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

Best Regards, Vivekanandan M

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

Reply to
John

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

Reply to
Al Borowski

The AVR uses a Harvard architecture. See

formatting link

The 8080 uses a Von Neumann architecture. See

formatting link

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

Reply to
Arlet

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

Reply to
jetmarc

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.
 Click to see the full signature
Reply to
CBFalconer

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

Reply to
Anton Erasmus

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

Reply to
Rocky

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!

Reply to
John

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