Psychlow 
Noob question:
How would one go about executing code from a location other than the AVR's on-board flash memory (ie, a CompactFlash card or external flash chip). Is this possible?
For example, the way a PC executes programs that are stored on a hard disk.
No, not possible.
Unless you reprogram the internal flash with data from an external source, but that can only be done only so often before it wears out. But it still executes from internal flash. There is no other source for instructions, only the internal flash.
clawson 
This one's been done to death - your thread search should find LOADS of prior traffic. The bottom line is that the Harvard nature of the AVRs make it kind of tricky (they can only execute code out of the code flash) so the solutions either involve mechanisms to SPM code into the code flash so it can be executed or to write some kind of interpreter that will execute some other kind of "code tokens". Amongst the many suggestions previously offered are "Forth", "p-code", "Java", "an AVR emulator"(that was my one!) and a search for any/all those search terms should lead you to the prior traffic.
Psychlow Okay - kind of figured the only option would be to program my own firmware that would execute instructions like a virtual machine.
Thanks for the information.
danni Noob question:How would one go about executing code from a location other than the AVR's on-board flash memory (ie, a CompactFlash card or external flash chip). Is this possible?
For example, the way a PC executes programs that are stored on a hard disk.
No PC can execute programs directly from the harddisk or memory card!
Only the BIOS-Flash can be executed directly.
You need always a bootloader, which load the program into the code memory (DRAM).
So on the AVR you can write a program, which load code from harddisk to flash.
But watch, that the flash write cycles are limited.
Also you can use architectures, which allow to conntect external code-SRAM, e.g. 8051. Then the write cycles are unlimited.
Peter
farang 
Good solution - use a microprocessor with a different architecture if speed is an issue. Otherwise write or adapt an interpreter.
clawson I still think an AVR emulator/interpreter ought to be FAIRLY easy to write on an AVR! Basically it would just do everything the AVR already does, opcode for opcode but makes the opcode fetches from SRAM or SD card or whatever (and SPM would be a lot easier to emulate though the downside of that is that it might encourage self-modifying code which, thankfully, Harvard normally prevents)
though the downside of that is that it might encourage self-modifying code
I'm sure there are programmers who do write self modifying code, and I'm even more sure there are a lot of truly bad programmers. But in 41 years I have had one occasion to write self modifying code, and it was for a benchmark where we were required to keep the (FORTRAN) source code identical. My little trick was to dynamically go in and restructure the calling sequences so that there were hooks to a set of helper routines that were invisible at the source level. A very bad practice, and I would never do it except in dire situations.
Not to say I haven't written a lot of code that unintentionally self-modified. Perhaps that's what you're talking about, although the word "encourage" would suggest otherwise.
So I guess my naive question is, have you seen a lot of intentionally self modifying code?
js 
have you seen a lot of intentionally self modifying code
Guillem Planisi 
Well, there is always the option to switch to another uC, like ARM's (AT91SAM7 famili, as example).
clawson So I guess my naive question is, have you seen a lot of intentionally self modifying code?
Obviously not on AVRs but yes, lots on Z80.
My history is that I first joined this company 24 years ago when it had just lauched a games computer to rival the Commodore 64 and the Sinclair Spectrum (a company/product we later bought). I spent many happy years "hacking" some of the well known Z80 computer games on the Spectrum and CPC (or range) not with the intention of breaking their code protection or anything like that but simply to see how they worked inside and rather famously I was the first person to write a map editor for a magazine article for Knightlore 3D on the CPC and Spectrum. This was not helped by the fact that both the protection schemes that initially prevented me "breaking in" and then the games themselves made heavy use of self-modifying code. They actually did it (well apart from the protection stuff) for reasons of speed. They were operating "so tight" that they could not afford the over-head of a call/ret in some sections so the code was actually modified inline with the right sprite movement or collision detection routine or whatever. However it made it close to impossible to follow what was going on (well short of just single stepping the entre operation) because a block of code you thought was doing an AND-mask when you first looked at it might actually end up doing an OR-mask at the time it next executed.
But it wasn't just games authors that did it, back then the 6502 and Z80 programming magazines I read would often advocate it as a solution to a problem, often when something more linear and procedural would actually have been a better solution.
So yes, I guess it was the bane of my life 20-25 years ago and these things stick with you! ;)
Cliff
Thanks, Cliff. Interesting stuff. Although I wrote my share of 8080, Z80, and 6800 code I was never squeezed so tight I resorted to these tricks. But like running with scissors*, I've been told not to for a very long time.
*no matter how sensible your shoes are, you might trip and stab yourself in the eye
js you might trip and stab yourself in the eye
One more OT historical note: the first FORTRAN compiler I used did all call by reference. If you used a constant as an argument it didn't create a copy of the constant and use a reference to it, it just passed the address of the global constant. If the routine changed that argument, suddenly 0 or 1 or whatever was redefined for the entire program. An interesting bug to find (I worked at the university computer center's consulting desk) until you knew to look for it.
(no such things as load immediates on that machine. constants were essentially hidden variables with predefined values)
stu_san 
If the routine changed that argument, suddenly 0 or 1 or whatever was redefined for the entire program.
Stu
PS: don't get me talking about the old Univac Solid State 80 machine and it's card FORTRAN II compiler - *shiver*!
Hi cliff
I started with a commondore PET and later a 64'er.
The basic interpreter was self modifying. The code for reading next byte(token) was a absolute LDA where the addr. changed, and when you started to load from tape a some code got copy'ed to the zero page.
Just a comment about make a virtual AVR. I wrote a simple AVR emulator to a PC, that 16 bit decoder will be a problem to do fast on a AVR! (alot of instructions bit don't line up).
But have fun making it, I can be a beta tester if you want!!!!
I wrote some code to a AVR to emulate a SRET. (a skip return meaning that the instruction after the call get skiped, this can save some code space(think it as a C function that return true or false)). The SRET was a (R)JMP to some code that poped the stack to find the
return addr. but then we had the problem to find out if the instruction to skip was 1 or 2 word big !!!
Some people will call that kind of code self modifying!!! (others just bad code)
Jens
clawson Jens,
The AVR emulator was only half an idea at the back of my mind really but I don't suppose the PC source for your emulator would be available as a starting point for doing it on the AVR? (so far I've just gazed for a while at the bit patterns in the opcode manual but got no further than that!)
Cliff
I can see if I can find it?
It's written in Delphi
Jens
Cliff
I will like to help (be a part of) making a AVR emulator, for me it's just fun I don't see a need for it.
I just looked and I can’t not find my emulator code, (I'm sure I still have it but on a 10 year old HD), and it's not important. But I will like to find some notes I made at that time, where I analyzed all the different groups of instructions, as I remember I made about 12.
(but not included all the newer ones (mul mov word etc)).
I made the hole thing for fun, actually I made it to simulate all mul combinations to see if there ware any errors in my program. (At a AVR seminar they told that you can’t make a software mul faster than 34clk, so I had to prove them wrong!!!). With a table you can do it in 30-32 clk, when it’s in Flash, and 26-28 in RAM (I made it for a Mega103).
Back to a game plan for the emulator:
A good place to start is to look at a disassembler because it do all the frontend work.
The backend is not that hard to make.
In assembler a very very raw estimate give about :
25 clk pr. Instruction +
the time it takes to get it from eeprom.(extern),
So about a 0.5 MHz AVR with 128KByte of code “in” a mega88 will do it.(We will run out of RAM before we are done!)
The real problem is emulating the hardware, and timing of that!
Or should it be a “main” program only emulator, and interrupts etc. is handled in real code on the “host” AVR.
Jens
bobgardner We had a 6800 based computer with 8" floppies and 48K of ram we were using in the maintenance panel trainers (mid 70s). Stupid 6800 didnt have an instruction to add B accum to x... had to write a macro or a subroutine to do that... was easier to just poke the contents of B into the 2nd byte of a ldaa 0,x instruction... that trick would have been harder in a rom based machine... That instruction got added to the hc11 and 6809. Atmel obviously has the c source to the simulator used in avrstudio. If we promised to give them the c source to the ported resident simulator back to them, think Eric W would give us the source? One more item.... I used to do a timed irq single step thru rom on the moto cpus... the reti and pull all regs took 12 cycles, so I loaded the timer up with a 13 just before executing the reti to run the user program (pull all regs and user pc). The irq would hit in that first instruction, and bang.... back into the debug monitor, dump regs and disassemble current instruction. Anyone think they can do this on an avr? (I'm too old and lazy.... but it sounds possible)
glitch 
While you could emulate an AVR on an AVR... the AVR's instruction encoding makes this an expensive process. You are best to create your own byte-code based machine... or emulate an already existing one, if you wish to take advantage of existing front-end tools, like compiers and assemblers.
Alternatively, you could write some PC based code, to 'recode' the avr instructions into a byte-stream that is more easily parsed by your VM running on the AVR itself. It might be possible to do this in a way that would keep the original code length, thus eliminating the need to analyse the code for any jump destinations or data, and recoding their address.
This method obviously wouldn't work on any code that uses code as data, like a code verifying CRC ,or checksumming routine.
Hi glitch you missed the point
The fun was to run AVR code from a extern eeprom.
If we just someting simple we would just run p-code!
The fun would be to use AVR tools for this project.
And I will repeat
"For me it's just fun I don't see a need for it"
To Bob the only way to make a LPM like instuction on a 1200 is to load the timer with the index (-+) and then make a long list of LDI instructions, now you will have the correct value when you take the timer interrupt!
Jens
clawson glitch,
Yup a bytecode virtual machine is a "cleaner" solultion but, like Jens says, it's really just a bit of fun and an intellectual exercise more than anything and the nice thing about an AVR emulator is that you could simply use the standard AVR development tools, have your own choice of using asm or whatever variety of C you like and just build .hex files as normal but now you just put them onto an SD card and can run the code from there (the emulator can do Intel Hex to Bin conversion or I guess you could use .bin files)
Cliff
glitch If it's just an academic exercise then that's fine. I was just trying to point out that the losses in performance would likely make it unsuitable for any real application.
As for the VM... there is nothing stopping you from emulating another processor that has compilers and assemblers already available... thus simplifying the task of code development to run on the VM itself.
My recoding suggestion was to pre-process an AVR binary on the PC and put it into a more manageable format for the VM to handle efficiently. The idea would be to recode the avr instructions 1 to 1. Just remove any of the interleaving of the parameter fields, where it makes sense.
For example LDD Rd, Y+q has the binary format of:
10q0 qq0d dddd 1qqq
the recoding would turn it into something like
100d dddd 01qq qqqq
thus minimizing the number of shifts that the VM has to perform at runtime in order to decode the instruction.
This way you get the advantage of being able to use all the AVR tools as you suggest... but also gaining some more efficiency in execution.
As for bin vs hex... you could do either... though bin is likely easier to handle. A hex file would need to be flattened... otherwise location of jump destinations would be very expensive.
clawson Ah now the idea of a code post-processor on the PC that gets the files ready for quicker emulation on the AVR is a great one - let the PC do all the work rather than wasting time on the AVR - I like it.
Previously (because I have had experience of writing Z80 emulators in the past) I had thought about writing a Z80 emulator to run on the AVR as you are right that there are good assemblers and C compilers for that.
glitch Of course the caveat is, as I mentioned earlier, a code CRC routine would fail, because the binary is physically different now. (unless you apply the CRC to the binary after recoding)
Handling of real hardware interrupts might get interesting too.
Out of curiosity I wonder how far one could distill the AVR's instruction set down? As it stands now, I can see 91 unique instructions, after stripping out the obvious aliases, from the 136 published opcodes. Next step would be to derive additional parameters, from the opcode itself, to combine similar instructions. (like breaking X, Y, or Z into a parameter from the LD and ST instructions)
js All of this would be unecessary if Atmel would make provisions to switch some or all external ram to the program space. So in chips that have ext ram facility one would set ANOTHER few fuses to allocate some or all ext ram to either data or program space.
Then the main flash code would be able to copy applications from external storage into program space ram and run it from there. Selfmodifying code heaven :)
glitch True John... but also remember that the codespace bus is 16bits wide, while the dataspace bus is only 8bits wide, so the penalty would be the equivalent of cutting performance by at least half. Even further for any accesses to anything in data space, as you are now multiplexing code fetches with data fetches. If you're going to do that, you might as well use a Von Neumann architecture from the start.
js The 80188 uses an 8 bit buss for 16 bit instructions, so yes you would need at least another clock cycle to fetch the second half of the instruction.
Alternatively, add another port do do 16 bits instructions fetches from a 16 bit ram. 100 pin devices should not have any problems with 8 less usable pins :?
clawson I just had a thought, the GCC toolchain includes the simulavr simulator with project page at:
http://savannah.nongnu.org/proje...
The main opcode simulator is in the 100K decoder.c file in the package and there's also this very useful table in the README.opcodes:
Instruction Set Summary
Arithmetic and Logic Instructions
| | | | Device Availability|
Mnem | Opcode | Operands | Method Name | 1200 | 4414 | 8515 |
=======|=====================|==========|=============|======|======|======|
ADC | 0001 11rd dddd rrrr | Rd, Rr | ADC | * | * | * |
ADD | 0000 11rd dddd rrrr | Rd, Rr | ADD | * | * | * |
ADIW | 1001 0110 KKdd KKKK | Rd, Rr | ADIW | - | * | * |
AND | 0010 00rd dddd rrrr | Rd, Rr | AND | * | * | * |
ANDI | 0111 KKKK dddd KKKK | Rd, K | ANDI | * | * | * |
ASR | 1001 010d dddd 0101 | Rd | ASR | * | * | * |
BCLR | 1001 0100 1sss 1000 | s | BCLR | * | * | * |
BLD | 1111 100d dddd 0bbb | Rd, b | BLD | * | * | * |
BRBC | 1111 01kk kkkk ksss | s, k | BRCS | * | * | * |
BRBS | 1111 00kk kkkk ksss | s, k | BRBS | * | * | * |
BRCC | 1111 01kk kkkk k000 | k | BRCC | * | * | * |
BRCS | 1111 00kk kkkk k000 | k | BRCS | * | * | * |
BREQ | 1111 00kk kkkk k001 | k | BREQ | * | * | * |
BRGE | 1111 01kk kkkk k100 | k | BRGE | * | * | * |
BRHC | 1111 01kk kkkk k101 | k | BRHC | * | * | * |
BRHS | 1111 00kk kkkk k101 | k | BRHS | * | * | * |
BRID | 1111 01kk kkkk k111 | k | BRID | * | * | * |
BRIE | 1111 00kk kkkk k111 | k | BRIE | * | * | * |
BRLO | 1111 00kk kkkk k000 | k | BRCS | * | * | * |
BRLT | 1111 00kk kkkk k100 | k | BRLT | * | * | * |
BRMI | 1111 00kk kkkk k010 | k | BRMI | * | * | * |
BRNE | 1111 01kk kkkk k001 | k | BRNE | * | * | * |
BRPL | 1111 01kk kkkk k010 | k | BRPL | * | * | * |
BRSH | 1111 01kk kkkk k000 | k | BRCC | * | * | * |
BRTC | 1111 01kk kkkk k110 | k | BRTC | * | * | * |
BRTS | 1111 00kk kkkk k110 | k | BRTS | * | * | * |
BRVC | 1111 01kk kkkk k011 | k | BRVC | * | * | * |
BRVS | 1111 00kk kkkk k011 | k | BRVS | * | * | * |
BSET | 1001 0100 0sss 1000 | s | BSET | * | * | * |
BST | 1111 101d dddd 0bbb | Rr, b | BST | * | * | * |
CALL | 1001 010k kkkk 111k | k | CALL | - | - | - |
| kkkk kkkk kkkk kkkk | | | | | |
CBI | 1001 1000 AAAA Abbb | A, b | CBI | * | * | * |
CBR | 0111 KKKK dddd KKKK | Rd, K | CBR | * | * | * |
CLC | 1001 0100 1000 1000 | | CLC | * | * | * |
CLH | 1001 0100 1101 1000 | | CLH | * | * | * |
CLI | 1001 0100 1111 1000 | | CLI | * | * | * |
CLN | 1001 0100 1010 1000 | | CLN | * | * | * |
CLR | 0010 01dd dddd dddd | Rd | EOR | * | * | * |
CLS | 1001 0100 1100 1000 | | CLS | * | * | * |
CLT | 1001 0100 1110 1000 | | CLT | * | * | * |
CLV | 1001 0100 1011 1000 | | CLV | * | * | * |
CLZ | 1001 0100 1001 1000 | | CLZ | * | * | * |
COM | 1001 010d dddd 0000 | Rd | COM | * | * | * |
CP | 0001 01rd dddd rrrr | Rd, Rr | CP | * | * | * |
CPC | 0000 01rd dddd rrrr | Rd, Rr | CPC | * | * | * |
CPI | 0011 KKKK dddd KKKK | Rd, K | CPI | * | * | * |
CPSE | 0001 00rd dddd rrrr | Rd, Rr | CPSE | * | * | * |
DEC | 1001 010d dddd 1010 | Rd | DEC | * | * | * |
EICALL | 1001 0101 0001 1001 | | EICALL | - | - | - |
EIJMP | 1001 0100 0001 1001 | | EIJMP | - | - | - |
ELPM | 1001 0101 1101 1000 | | ELPM | - | - | - |
ELPM | 1001 000d dddd 0110 | Rd, Z | ELPM_Z | - | - | - |
ELPM | 1001 000d dddd 0111 | Rd, Z+ | ELPM_Z_incr | - | - | - |
EOR | 0010 01rd dddd rrrr | Rd, Rr | EOR | * | * | * |
ESPM | 1001 0101 1111 1000 | | ESPM | - | - | - |
FMUL | 0000 0011 0ddd 1rrr | Rd, Rr | FMUL | - | - | - |
FMULS | 0000 0011 1ddd 0rrr | Rd, Rr | FMULS | - | - | - |
FMULSU | 0000 0011 1ddd 1rrr | Rd, Rr | FMULSU | - | - | - |
ICALL | 1001 0101 0000 1001 | | ICALL | - | * | * |
IJMP | 1001 0100 0000 1001 | | IJMP | - | * | * |
IN | 1011 0AAd dddd AAAA | Rd, A | IN | * | * | * |
INC | 1001 010d dddd 0011 | Rd | INC | * | * | * |
JMP | 1001 010k kkkk 110k | k | JMP | - | - | - |
| kkkk kkkk kkkk kkkk | | | | | |
LD | 1000 000d dddd 1000 | Rd, Y | LDD_Y | - | * | * |
LD | 1001 000d dddd 1001 | Rd, Y+ | LD_Y_incr | - | * | * |
LD | 1000 000d dddd 0000 | Rd, Z | LDD_Z | * | * | * |
LD | 1001 000d dddd 0001 | Rd, Z+ | LD_Z_incr | - | * | * |
LD | 1001 000d dddd 1110 | Rd, -X | LD_X_decr | - | * | * |
LD | 1001 000d dddd 1010 | Rd, -Y | LD_Y_decr | - | * | * |
LD | 1001 000d dddd 0010 | Rd, -Z | LD_Z_decr | - | * | * |
LD | 1001 000d dddd 1100 | Rd, X | LD_X | - | * | * |
LD | 1001 000d dddd 1101 | Rd, X+ | LD_X_incr | - | * | * |
LDD | 10q0 qq0d dddd 1qqq | Rd, Y+q | LDD_Y | - | * | * |
LDD | 10q0 qq0d dddd 0qqq | Rd, Z+q | LDD_Z | - | * | * |
LDI | 1110 KKKK dddd KKKK | Rd, K | LDI | * | * | * |
LDS | 1001 000d dddd 0000 | Rd, k | LDS | - | * | * |
| kkkk kkkk kkkk kkkk | | | | | |
LPM | 1001 0101 1100 1000 | | LPM | - | * | * |
LPM | 1001 000d dddd 0100 | Rd, Z | LPM_Z | - | - | - |
LPM | 1001 000d dddd 0101 | Rd, Z+ | LPM_Z_incr | - | - | - |
LSL | 0000 11dd dddd dddd | Rd | AND | * | * | * |
LSR | 1001 010d dddd 0110 | Rd | LSR | * | * | * |
MOV | 0010 11rd dddd rrrr | Rd, Rr | MOV | * | * | * |
MOVW | 0000 0001 dddd rrrr | Rd, Rr | MOVW | - | - | - |
MUL | 1001 11rd dddd rrrr | Rd, Rr | MUL | - | - | - |
MULS | 0000 0010 dddd rrrr | Rd, Rr | MULS | - | - | - |
MULSU | 0000 0011 dddd rrrr | Rd, Rr | MULSU | - | - | - |
NEG | 1001 010d dddd 0001 | Rd | NEG | * | * | * |
NOP | 0000 0000 0000 0000 | | NOP | * | * | * |
OR | 0010 10rd dddd rrrr | Rd, Rr | OR | * | * | * |
ORI | 0110 KKKK dddd KKKK | Rd, K | ORI | * | * | * |
OUT | 1011 1AAd dddd AAAA | A, Rd | OUT | * | * | * |
POP | 1001 000d dddd 1111 | Rd | POP | - | * | * |
PUSH | 1001 001d dddd 1111 | Rd | PUSH | - | * | * |
RCALL | 1101 kkkk kkkk kkkk | k | RCALL | * | * | * |
RET | 1001 0101 0000 1000 | | RET | * | * | * |
RETI | 1001 0101 0001 1000 | | RETI | * | * | * |
RJMP | 1100 kkkk kkkk kkkk | k | RJMP | * | * | * |
ROL | 0001 11dd dddd dddd | Rd | ADC | * | * | * |
ROR | 1001 010d dddd 0111 | Rd | ROR | * | * | * |
SBC | 0000 10rd dddd rrrr | Rd, Rr | SBC | * | * | * |
SBCI | 0100 KKKK dddd KKKK | Rd, K | SBCI | * | * | * |
SBI | 1001 1010 AAAA Abbb | A, b | SBI | * | * | * |
SBIC | 1001 1001 AAAA Abbb | A, b | SBIC | * | * | * |
SBIS | 1001 1011 AAAA Abbb | A, b | SBIS | * | * | * |
SBIW | 1001 0111 KKdd KKKK | Rd, K | SBIW | - | - | - |
SBR | 0110 KKKK dddd KKKK | Rd, K | SBR | * | * | * |
SBRC | 1111 110d dddd 0bbb | Rd, b | SBRC | * | * | * |
SBRS | 1111 111d dddd 0bbb | Rd, b | SBRS | * | * | * |
SEC | 1001 0100 0000 1000 | | SEC | * | * | * |
SEH | 1001 0100 0101 1000 | | SEH | * | * | * |
SEI | 1001 0100 0111 1000 | | SEI | * | * | * |
SEN | 1001 0100 0010 1000 | | SEN | * | * | * |
SER | 1110 1111 dddd 1111 | Rd | LDI | * | * | * |
SES | 1001 0100 0100 1000 | | SES | * | * | * |
SET | 1001 0100 0110 1000 | | SET | * | * | * |
SEV | 1001 0100 0011 1000 | | SEV | * | * | * |
SEZ | 1001 0100 0001 1000 | | SEZ | * | * | * |
SLEEP | 1001 0101 1000 1000 | | SLEEP | * | * | * |
SPM | 1001 0101 1110 1000 | | SPM | - | - | - |
ST | 1001 001d dddd 1101 | X+, Rd | ST_X_incr | - | * | * |
ST | 1001 001d dddd 1100 | X, Rd | ST_X | - | * | * |
ST | 1001 001d dddd 1001 | Y+, Rd | ST_Y_incr | - | * | * |
ST | 1000 001d dddd 1000 | Y, Rd | STD_Y | - | * | * |
ST | 1001 001d dddd 0001 | Z+, Rd | ST_Z_incr | - | * | * |
ST | 1000 001d dddd 0000 | Z, Rd | STD_Z | * | * | * |
ST | 1001 001d dddd 1110 |-X, Rd | ST_X_decr | - | * | * |
ST | 1001 001d dddd 1010 |-Y, Rd | ST_Y_decr | - | * | * |
ST | 1001 001d dddd 0010 |-Z, Rd | ST_Z_decr | - | * | * |
STD | 10q0 qq1d dddd 1qqq | Y+q, Rd | STD_Y | - | * | * |
STD | 10q0 qq1d dddd 0qqq | Z+q, Rd | STD_Z | - | * | * |
STS | 1001 001d dddd 0000 | k, Rd | STS | - | * | * |
| kkkk kkkk kkkk kkkk | | | | | |
SUB | 0001 10rd dddd rrrr | Rd, Rr | SUB | * | * | * |
SUBI | 0101 KKKK dddd KKKK | Rd, K | SUBI | * | * | * |
SWAP | 1001 010d dddd 0010 | Rd | SWAP | * | * | * |
TST | 0010 00dd dddd dddd | Rd | AND | * | * | * |
WDR | 1001 0101 1010 1000 | | WDR | * | * | * |
glitch Hopefully the simulator doesn't contain the same bug as the document for LSL.. it should be using "ADD Rd, Rd" and not "AND Rd, Rd" as stated above. Same for the branches... BRBC shouldn't be calling BRCS. Actually all the 'named' branches should be calling one of the 2 branching functions BRBC, or BRBS. The same reduction should be applied to all the status register bit set/clear instructions, as they are all aliases for SBRC, and SBRS. The rest looks to be fine, at a glance... though I'm betting it can be distilled further, thus reducing the code that needs to be written. (A more critical thing on an AVR, than on a PC)
theusch 
Re emulating the AVR on the AVR, whether pre-processed or not; whether to get "extra" code space or not:
It is an interesting discussion piece, but IMO that is all it is. No-one would seriously saddle their AVR app with 100:1 or more slower execution.
The approaches/reasons/justifications/goals can be grouped into many categories:
-- "Just because." OK, fine. I thought about it a bit and decided no way I would want to spend time and effort on 100:1 slower.
-- PC or other host simulator/emulator. Always an interesting exercise. Already been done, several times. Note the current thread with the simulator bug on Bxxx in one of them--that drives you more nuts than not having it.
-- More code space. With 256k AVRs, wouldn't that be mostly moot? That is a LOT of real microcontroller code for an 8-bit app. Flash-eating tables and graphics and the like >>can<< be fairly efficinetly handled with the external memory interface.
-- Modular/adaptable/configurable programs. I'd think that most of these, in the real world, could be handled by SPM-in a chunk of "configurable" flash. 10k or even 1k erase/write cycles is a lot.
-- Learning/educational load-and-go systems. Again, with 10k guaranteed cycles 10k is a lot. If you really want to reload 100 times a day for 1000 days, then...
-- ... use a REAL configurable system. Use an AT94 for that. Or one of the AVR cores for your logic device. And at that point what is so sacred about AVR architecture? The instruction set encoding makes it a bear to decode efficiently (thus my 100:1 comment above). Use a "better" core for that task. In education or simple apps the language/instruction set can be greatly simplified.
-- Use an applicable language. JAVA and FORTH have been refined to death for these types of apps, and are quite adaptable to AVR. Throw in P-code systems like some Pascals and BASICs. Probably many others as well.
Lee
bobgardner I agree with your analysis. BUT, there is something neat and tidy about a self contained system, with a self hosted development system, like the early microcomputers. I think there is an expectation that each system should have some sort of resident debugger/dissassembler like cpm and every other system has. I think a ram based AVR that ran at 44MHz or whatever sounds fine to me. Hey Atmel guys.... think there's a market for a screamer like that? Sort of blows the doors off of EVERY OTHER 8 bit micro doesnt it?
theusch Bob--have you ever even LOOKED at the AT94? What part of that does NOT fit your feature query? If the feature set is so desireable then why the dearth of discussion about it on the site over the past 7 years?
Lee
bobgardner Most of the discussion here is about how to get my uart working before I have to turn in my masters thesis three days from now. If you go to the mall and ask 100 people to name one or two makers of computer chips what will you get? Are engineers and programmers idea guys and entrepreneurs? Or do they just program what the marketing geeks and the EEs dream up? Maybe I'm the only guy in the world that has thought about a double speed turbo hot AVR. Now all I need is some sort of killer app that needs a hotternhell microcontroller in it. Do you think apps drive components, or do components drive apps? I think if it was up to engineers, we'd all be using dips and thru hole Rs and Cs. The marketing guys seem to want everything microscopically small. My background was trying to do impossible stuff with 1mhz 6800s and counting usecs... there was a lot of 'my computer is way faster than your comnputer' bragging back then... still some of that going on isnt there?. So my tendency is to extrapolate that 'I can make an AVR dance a jig. Now if I can make something really cool that someone wants to buy for $100, I'm all set. Got any world class ideas you want to develop?
Got any world class ideas you want to develop?
I've always thought the ideal job would be to go out to the mailbox every day and find money addressed to me. Unless you're Stephen King, writing is probably not the answer.
bobgardner Folks seem much more amenable to buying a piece of hardware that comes with free software rather than buying ANY piece of software, even if it comes with free hardware. You cant see it, it isnt worth anything. Though job I picked for myself huh?
bobgardner Folks seem much more amenable to buying a piece of hardware that comes with free software rather than buying ANY piece of software, even if it comes with free hardware. You cant see it, it isnt worth anything. Tough job I picked for myself huh?
theusch First Bob opines about his dream system:
I think a ram based AVR that ran at 44MHz or whatever sounds fine to me. Hey Atmel guys.... think there's a market for a screamer like that? Sort of blows the doors off of EVERY OTHER 8 bit micro doesnt it?
Then in response to
Bob--have you ever even LOOKED at the AT94? What part of that does NOT fit your feature query? If the feature set is so desireable then why the dearth of discussion about it on the site over the past 7 years?
Maybe I'm the only guy in the world that has thought about a double speed turbo hot AVR.
Lee
bobgardner My point was... some entrepreneur somewhere wants to make an electronic thingy... you cant expect him to know the depth and breadth of the product line for a dozen microcontroller companies... innovative use of off the shelf components in unintended ways is often a very clever quick time to market trick. Like if something like an ipod sucked up the worlds supply of 20mhz AVRs, you could still make an ipod eater out of a 44mhz AT94. I'd still like to hear your answers about apps drive components or vice-versa, and your estimate of how many folks out of 100 in the mall could name a chip maker besides intel. Others weigh in with their answers as well please. Sorry about the double post. tried to hit the edit button before the screen refreshed.
Frito Lay, Tim's (local), and Huh? would be the answers at our mall.
Jepael Back on track here:
So if the host AVR would interpret some kind of bytecode, what kind of standard bytecodes there are and are there C compilers (GCC would be fine based on my experiences of GCC for x86 and AVR platforms) which generate this bytecode? Can you name a few? If I ever wanted to use this idea to do any real work with it, how should I proceed?
I am already thinking about state machines which pass events to trigger pieces of code that could change the state, and the state machines and/or code would preferably be drawn/described with some graphical software tool, and not written like C code is.
Ooh, and think about multiple AVRs running the same code in parallel, from the same SD card or serial eeprom! Which would not make much sense, would it..
- Jani
edit: my point being that the actual virtual software running would be executed the same way independent of the host CPU, whether it is a PC, AVR or ARM etc.. would help a bit when debugging maybe, as long as there is a way for the virtual software to interact with real hardware.
bobgardner Sounds like Java or Forth to me.
clawson My point was... some entrepreneur somewhere wants to make an electronic thingy... you cant expect him to know the depth and breadth of the product line for a dozen microcontroller companies... innovative use of off the shelf components in unintended ways is often a very clever quick time to market trick.
http://en.wikipedia.org/wiki/Ala...
He employs "backroom boffins" like me for exactly the reason you gave - so he doesn't need to know the names of a dozen micrcontroller companies (because my colleagues and I do).
He hasn't done too bad through it - he started selling car aerials from a van 40 years ago and is now worth a little short of $2bn.
The problem with the AT94 is that it's old, meaning no MUL instructions. And I don't think that it will come ever, (read AT94 is a dead end).
Back til the emulator cliff beat me to the table but I made this yesterday :
NOP 0000 0000 0000 0000
FMUL 0000 0011 0ddd 1rrr
FMULS 0000 0011 1ddd 0rrr
FMULSU 0000 0011 1ddd 1rrr
MOVW 0000 0001 dddd rrrr
MULS 0000 0010 dddd rrrr
MULSU 0000 0011 0ddd 0rrr
CPC 0000 01rd dddd rrrr
SBC 0000 10rd dddd rrrr
ADD 0000 11rd dddd rrrr
ADC 0001 11rd dddd rrrr
SUB 0001 10rd dddd rrrr
CP 0001 01rd dddd rrrr
CPSE 0001 00rd dddd rrrr
AND 0010 00rd dddd rrrr
EOR 0010 01rd dddd rrrr
OR 0010 10rd dddd rrrr
MOV 0010 11rd dddd rrrr
CPI 0011 KKKK dddd KKKK
SBCI 0100 KKKK dddd KKKK
SUBI 0101 KKKK dddd KKKK
ORI 0110 KKKK dddd KKKK
ANDI 0111 KKKK dddd KKKK
LD(y) 1000 000d dddd 10xx (xx=00,01,10)
LD(y) 10q0 qq0d dddd 1qqq
LD(z) 1000 000d dddd 00xx (xx=00,01,10)
LD(z) 10q0 qq0d dddd 0qqq
ST(y) 1000 001 r rrrr 10xx (xx=00,01,10)
ST(y) 10q0 qq1 r rrrr 1qqq
ST(z) 1000 001 r rrrr 00xx (xx=00,01,10)
ST(z) 10q0 qq1 r rrrr 0qqq
ELPM 1001 000d dddd 011x (x=0 Z, x=1 Z+)
LD(x) 1001 000d dddd 11xx (xx=00,01,10)
LDS 1001 000d dddd 0000 kkkk kkkk kkkk kkkk
POP 1001 000d dddd 1111
LPM 1001 000d dddd 010x (x=0 Z, x=1 Z+)
PUSH 1001 001d dddd 1111
ST(x) 1001 001r rrrr 11xx (xx=00,01,10)
STS 1001 001d dddd 0000 kkkk kkkk kkkk kkkk
ASR 1001 010d dddd 0101
BCLR 1001 0100 1sss 1000
BSET 1001 0100 0sss 1000
CALL 1001 010k kkkk 111k kkkk kkkk kkkk kkkk
COM 1001 010d dddd 0000
NEG 1001 010d dddd 0001
SWAP 1001 010d dddd 0010
INC 1001 010d dddd 0011
LSR 1001 010d dddd 0110
ROR 1001 010d dddd 0111
DEC 1001 010d dddd 1010
IJMP 1001 0100 0000 1001
EIJMP 1001 0100 0001 1001
EICALL 1001 0101 0001 1001
ELPM 1001 0101 1101 1000
ICALL 1001 0101 0000 1001
JMP 1001 010k kkkk 110k kkkk kkkk kkkk kkkk
LPM 1001 0101 1100 1000
RET 1001 0101 0000 1000
RETI 1001 0101 0001 1000
SLEEP 1001 0101 1000 1000
SPM 1001 0101 1110 1000
WDR 1001 0101 1010 1000
ADIW 1001 0110 KKdd KKKK
SBIW 1001 0111 KKdd KKKK
CBI 1001 1000 AAAA Abbb
SBIC 1001 1001 AAAA Abbb
SBI 1001 1010 AAAA Abbb
SBIS 1001 1011 AAAA Abbb
MUL 1001 11rd dddd rrrr
LD & ST 1010 this is when the high q=1
RJMP 1100 kkkk kkkk kkkk
RCALL 1101 kkkk kkkk kkkk
IN 1011 0AAd dddd AAAA
OUT 1011 1AAr rrrr AAAA
LDI 1110 KKKK dddd KKKK
BRBS 1111 00kk kkkk ksss
BRBC 1111 01kk kkkk ksss
BLD 1111 100d dddd 0bbb
BST 1111 101d dddd 0bbb
SBRC 1111 110r rrrr 0bbb
SBRS 1111 111r rrrr 0bbb
This is all AVR instructions (not 100% on order but close).
The rest of the instructions is only other names for the same instruction:
BRCC,BRCS,BREQ,BRGE,BRHC,BRHS,BRID,BRIE,BRLO,BRLT,BRMI,BRNE,BRPL
BRSH,BRTC,BRTS,BRCV,BRVS,CBR,CLC,CLH,CLI,CLN,CLR,CLS,CLT,CLV,CLZ
LSL,ROL,SBR,SEC,SEH,SEI,SEN,SER,SES,SET,SEV,SEZ,TST
Ok this give a clear picture of what we have to deal with.
I would read the two byte in the next instruction. Make a IJMP table of the high byte, and then make the rest of the decoding.
All the move and the logic things should be made with a LD (or two) allways to the same Reg and then the result is stored with a ST to the correct place.
I'm not sure how many of the emulated Reg that should be stored in Reg and how many in RAM.
1. All Reg in correct place
This will give to many PUSH and POP.
2. ALL REG in RAM
This will be simple, clean and slow !!!
3. Some Reg in reg the rest in RAM
Store reg 16-31 in reg 0-15 and the rest in RAM
And store SFR in a high Reg.
I will like to make 3. but for a start number 2 will be a simpel way to get something to work.
The sugestion to have a PC to change the (op)code, have a big problem, you need to know what is code and what is data in the code you emulate.
Jens
theusch The problem with the AT94 is that it's old, ... And I don't think that it will come ever, (read AT94 is a dead end).
That is pretty much my point, isn't it? "Oh, woe, why can't Atmel give us a 40MHz AVR that can run from SRAM?" They did. Years ago. Noone (well, certainly very few posters on this site) cares much, as we want to do microcontroller programs with a near-single-chip solution. So we certainly don't hear much about that series.
Load-and-go is a niche; I pointed y'all to the device that satisfies your requirements; it has been around for years. I'll look forward to seeing the annoucement of your world-beater product.
Lee
theusch
meaning no MUL instructions. And I don't think that it will come ever,
I don't use them (US$20 to 30 in quantity! Our whole app board costs that to build.), but the summary says
Hardware Multiplier (8-bit) Yes Yes Yes
Lee
I wrote a M32/128 simulator recently and used opcode caching to improve performance. It helped some, but still I get about 3MHz on my PC without peripherals enabled, 1.3MHz otherwise.
Sampling a test program provided the following instruction distribution which I could use to improve performance. Such information could be used to optimize throughput in an emulator.
To cpluscon
Thanks for the infomation.
And that give the real info about what is the problem.
How to deal with hardware in the emulator.
What speed is the PC to give 3MHz. It sound a bit slow to me.
It's should only take about 50 PC clocks (no peripherals)to make a AVR instruction. So let's say a 2GHz CPU (I have a Athlon 4200 2x2.2GHz that's 2GHz for the emulator, and the other CPU run the rest(windows it's self)). That give me a 40 MHz AVR!!! Do you make a lot of log data?
If you make a 64K function pointer table it should be even faster.
Jens
Update
I just tested a commodore64 emulator and that give me a 6502 emulation at about 35MHz (with hardware emulation)and for a PC a AVR and a 6502 should be about the same.
clawson In a project we did (http://www.amstrad.com/products/emailers/emp.html) we were able to emulate a 3.5MHz Z80 based Sinclair Spectrum on a 48MHz ARM (= 14:1) so I'm not sure why there's talk of 50:1 or even 100:1 for emulating an AVR on an AVR. Surely it could be done at 20:1 worst case? (so a 20MHz AVR could emulate a 1MHz AVR perhaps?)
Cliff
Do you make a lot of log data?
My point is that an emulator could use both caching and opcode likelihood to achieve higher performance. For instance, what is the probability that a PUSH is followed by another PUSH?