New AVR simulator

Last post
85 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wrote a new AVR simulator that runs on linux so far, and uses gcc's header files for the IO register to simplify the generation of new devices.

The goal of the project is mainly to have a "work" simulator that is easy to customize and fast to emulate. I don't like the C simulavr, and I don't like the C++ bloaty rewrite either. I want something lean, fast, and mean.

I wanted something that is easy to work with, like "qemu" is for bigger CPUs. The goal is to be able to simulate your project in an "easy" way. I also have the idea of being able to "embed" AVR cores into another application and run logic there.. like a plugin with replaceable code.

Right now I have about 95% of the core working, I have some of the timers function working (including async ones), the interupts work, UART work, eeprom work, IO port "work" too..
I'm finishing the gdb support. The simulator loads .elf file directly, including eeprom values.

I'm wondering if someone like minded would be interested to contribute, in which case I could open-source the thing.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

buserror wrote:
I wrote a new AVR simulator that runs on linux so far, and uses gcc's header files for the IO register to simplify the generation of new devices.

The goal of the project is mainly to have a "work" simulator that is easy to customize and fast to emulate. I don't like the C simulavr, and I don't like the C++ bloaty rewrite either. I want something lean, fast, and mean.

I wanted something that is easy to work with, like "qemu" is for bigger CPUs. The goal is to be able to simulate your project in an "easy" way. I also have the idea of being able to "embed" AVR cores into another application and run logic there.. like a plugin with replaceable code.

Right now I have about 95% of the core working, I have some of the timers function working (including async ones), the interupts work, UART work, eeprom work, IO port "work" too..
I'm finishing the gdb support. The simulator loads .elf file directly, including eeprom values.

I'm wondering if someone like minded would be interested to contribute, in which case I could open-source the thing.

One thing I am interested in is unit testing and regression testing on the AVR, particularly if it can be automated and scripted.

Do you think your framework may be able to support that (somehow)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It'd also be interesting to see if this code can be compiled on the AVR itself and work successfully. It could then break the "Harvard limitation" and allow programs to be run from EEPROM or SD memory cards, AT45 dataflash and other "external" memory which is something that must be requested here about once every 2-4 weeks. But I wonder what speed of AVR a 20MHz (say) AVR could simulate? IOW how many opcodes per AVR instruction? Perhaps 40 on average? That'd give 0.5MHz performance with a 20MHz clock.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That last point is tricky, I wrote it with a 32 bits CPU in mind, and porting it to AVR would be pretty enormous. Also, you would need SRAM space for the SRAM of the target, and it's flash, and eeprom (if any) !

I already do "unit testing" of the core itself, basicaly if you do a SLEEP with interrupts off it takes that as a "quit please", so I can run a program to it's course instead of "forever loop"

As for scriptability it's not there yet. It runs in the command line, thats about it.. That bit of "user interaction" will be done later.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What about peripherals simulation? Can I put "LED" to port and see it blinking?

Open sourcing will be good idea anyway.

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes the ports "work" ie they call code that knows about them. Even the PCINT works. However right now nothing is "plugged" onto them. I'm going to add something similar to qemu "irq" to interface to them.
I'd also like a way to use for example UDP to send/receive port values from external programs..

For now I think it'd need people with a reasonable knowledge of assembly, to possibly isolate/find core bugs. The IO modules are reasonably simple, in a way.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

buserror wrote:
I'm wondering if someone like minded would be interested to contribute, in which case I could open-source the thing.
You have kind of a chicken and egg problem here.

It is anyhow difficult to recruit people for open-source projects. And without having the code already in the open it is even more difficult.

So you'd probably have to "invest" in opening the code first. If you also go the extra mile and define a number of clear, small tasks for which you seek help your chance of finding helpers increases.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the coding language and environment?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
and I don't like the C++ bloaty rewrite either. I want something lean, fast, and mean.

What makes you think that C++ is bloated and slow?

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What makes you think that C++ is bloated and slow?

Steve, Steve--Are you still trying to make converts out of us? :twisted:

I can easily resemble the "mean" part, but I fear that my "lean" and "fast" days may be over...

Hmmm--my coding style for e.g. Mega88-class apps is heretical with global data and global scratchpad register variables and a flat program with virtually no stack required may well break the bank of an OOP approach. I.e., you may not be able to pack as much into a Mega48 or Mega88 as I do. But maybe it is indeed the cat's meow--the results of previous battles are quite impressive.

Lee

You can put lipstick on a pig, but it is still a pig.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But what does that have to do with a program written for a PC? And besides, I have never tried to "convert" anyone when it comes to programming for the AVR.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

And besides, I have never tried to "convert" anyone

Sorry--I was just stirring the pot, and assumed you were one of the evangelist.

Quote:

But what does that have to do with a program written for a PC?

...and before stirring said pot, I should really review the entire context.

Hmmm--maybe I can edit my content to look less of a fool? Nah; wouldn't work. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, C++ is not necessarily bloated, however most of what gets written, is.

Anyway, thats beside the point. I want something small, lean, with /known footprint/ and the minimal amount of dependencies. Like qemu, even if the c++ crowd is trying hard to infect/bloat that one too nowadays.

Note that I spent 15+ years writting c++ professionaly, I know what I'm talking about :>

So the code is plain c99, with the the gnu extensions (since it requires avr-gcc installed anyway!). I only requires libelf to build.

I created a page on gitorious, I'll push the tree as soon as I finish pasting bits of GPL goo everywhere!

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Nah; wouldn't work.

Definitely wouldn't work ;)
Quote:
Well, C++ is not necessarily bloated, however most of what gets written, is.

But that is the fault of the programmer, not the language. If you simply hack away at C++ like it was C with a few extra features, then this might be the result.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I do agree, and I used it like that a lot too (no templates, no RTTI etc) but when you look at it at that point it's not very much different from c99 or so.. OK the nice encapsulation is agreable etc, but well, one can do without too...
I woudn't write a huge app in C99 clearly, but for a lean library/a tool or something you want to keep the footorint in check, C99 is really not that bad...

And C99 has /cool/ extensions I miss in C++:
struct blah a = { .field = 9, .field2 = { .sub = "blah", }, }; and so on.. makes generating complex definitions of complex types out of const a real pleasure, It's used all aver the linux kernel, and I've grown very fond of it so... :D

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Getting back to the topic: will we see source code?

The opinions and views expressed by me on this forum are my own and do not represent my employer or anyone else that I'm affiliated with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah, it's almost ready, commenting stuff!

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's pretty cool! :)

I've got an ATMEGA88 app running under the simulator, and can see the UART output.

A couple of comments;

I get an "invalid write address... out of ram" error unless I comment some code out. At first glance it doesn't seem to be related to any specific lines, just the volume of code?

The transmit complete flag never seems to get set following UART output (so the following code fragment never completes)

// wait for transmit to complete
while(!(UCSR0A & (1 << TXC0)));
//reset the transmit completion flag
UCSR0A |= (1 <<TXC0);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pretty cool it works for you! There are two possibilities for "out of ram address" it could be a genuine bug in your code (;-)), OR a lurking problem in the AVR simulator core. I know there's one of them somewhere, I just need a smaller test case to isolate it :>

For the UART the logic is VERY simple, and it doesn;t respects all the bits; commend out the while() and it will work. I will fill in the uart emulation later on..

If you find a genuine crash of AVR code, try to send me a test case as little as possible, with what you'd expect, and what happend instead !

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do you download and run this simulator? I know nothing about "git", never heard of it before.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a distributed source control system. There's plenty of help on gitorious.org, or everywhere on the net..
You also need linux to build it, I made no attempts at windows compatibility...

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, its not an executable.

That leaves me out.

jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Open source" implies... sources... ? :D

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To me, it means "source available" and does not meant that its the only way to use it. OpenOffice is open source. You can get executable versions. Ditto Wine. Ditto git.

jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA There are some answers that have no questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

buserror wrote:
If you find a genuine crash of AVR code, try to send me a test case as little as possible, with what you'd expect, and what happend instead !

Sure, I'll try to get it down to a minimum test case that still crashes..

Regards,
Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also created a mailinglist, check the link on the gitorious page...

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jone wrote:
Sure, I'll try to get it down to a minimum test case that still crashes..

I take it all back :oops: I must just have messed something up when rebuilding my code!

I went back to a copy of my original AVRStudio project, added the simulator support & it's running fine (with just some unsupported functions commented out).

Regards,
Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not support a win32 platform? Most won't stage a Linux machine just to get an AVR simulator running.

Mostly your code compiles with VS2008 except the funky struct initialization stuff. And of course ELF. Can it read an Intel hex file?

I could install Cygwin and port it that way but that's kind of a pain.

For what it's worth, browsing the code it looks like you've done a pretty nice job. Now if I could only run it....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cpluscon wrote:
Why not support a win32 platform? Most won't stage a Linux machine just to get an AVR simulator running....I could install Cygwin and port it that way but that's kind of a pain....
I suspect that will still be easier than porting to win32.

---------------------
John Firestone

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But Atmel already delivers simulators running under windows.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As was mentioned earlier running unit tests via command line would be very useful. Many of us gave up on simulavr so options are scant.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will gladly join to this project, but C looks very messy to me. I will try to look at the code. If I can suggest any features – it will be nice to introduce something like optional memory protection during simulation. So any memory overrun, addressing null or invalid pointers or writing beyond available memory or stack problems could be easy detected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well..I don't want to use windows only for develope AVR projects!!!

I don't use (and don't want to use) Windows in any my machines!!!

There are a lot of tools in windows and a very few in others OS.

A solution will be to develope in a cross plataform languaje (like java)

cpluscon wrote:
Why not support a win32 platform? Most won't stage a Linux machine just to get an AVR simulator running.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I don't use windows. At all. I use Linux & OSX only. There already are tools for windows and none (I like) for linux & osx. So here goes..

I want a small, lightweight emulator I can embed in a (different) program too, so I can run C code "firmwares" to run some replaceable logic and so on. Think of it as a java-light.
I also want to streamline the decoder and IO system so that I understand it fully, and can then make a nice VHDL implementation.

@TFrancuz, the simulator already check out of bounds addresses for code execution, stack munching and so on.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I don't use Linux at all. I did fire up a copy a couple of years ago precisely to compile a version of my AVR simulator, for others to use.

Further, porting your simulator would've been trivial if you hadn't used the (IMO) non-standard struct initialization. I spent a couple of hours on it but suspended the effort in the middle of sim_megax8.h. Might get back to it though....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cpluscon wrote:
Further, porting your simulator would've been trivial if you hadn't used the (IMO) non-standard struct initialization
Designated initializers are part of the C99 standard. Is there some way you can instruct your compiler to compile C99 code rather than (I'm guessing) C++?

---------------------
John Firestone

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Designated initializers are part of the C99 standard.
I know. I said IMO. If I believed in conspiracy thoeries I'd say C99 was standardized to keep open source code from being used on Microsoft products. But I don't.
Quote:
Is there some way you can instruct your compiler to compile C99 code rather than (I'm guessing) C++?
I've looked in Visual Studio and don't see any C99 switch. As alluded to earlier, my only option is install Cygwin and compile it that way. Or hack it up, which I have done, partially.

Now, my problem is that there are no ELF support files available so will have to patch in a hex file parser.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I had a a .hex loader before I made the ElF one, and removed it as the .elf is a lot more practical (symbol names and so on)
c99 static initializers are used everywhere in the linux kernel and qemu, and thats the codebases I hack the most, so I just stick to something that seems to be widely used... No conspiracy, I never imagined anyone would want to use it on windows as theres the "official" one.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
theres the "official" one
Just to be sure, are you referring to simulavr? My impression is that it is a PITA. IIRC it relies on a socket connection to gdb(!). Better to write your own. (Which, like you, I did.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This link: http://bytes.com/topic/c/answers/220072-c99-microsoft-visual-studio talks about this and one person says that the Intel compiler intergrates with Visual Studio:

Quote:
the Intel v8 compiler, which can be fully integrated
into Visual Studio, does support many C99 features using the /Qc99 option:

Restricted pointers
Variable-length Arrays
Flexible array members
Complex number support (_Complex keyword)
Hexadecimal floating-point constants
Compound literals
Designated initializers
Mixed declarations and code
Macros with a variable number of arguments
Inline functions (use inline keyword)
Boolean type (_Bool keyword)

Does this help?

David

Dr. David Harris
OpenLCB Development Team
openlcb.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, IMO it's another option, but slightly less desirable than Cygwin which does not involve potentially messing up my Visual Studio installation. Further, the quoted thread is 4 years old, and I have no idea if Intel's compiler is freely available.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pushed an update:

Cores, decoder, uart, ioports - lots of changes.

+ Cores now use eeprom declare macro
+ Cores now use the "TXCE" etc bits
+ Uart now raise TXC interupt/flag
+ ioports now use new internal IRQ system
+ New command line options for mcu, freq and trace
+ Decoder updates:
- Fixed the last known "crash" bug.
- Added cycles to most multi-cycle opcodes.
- Added optional stack frame watcher
- Skip instruction now handle 32 bits skips

New IRQ subsystem is WIP, all the rest seems to work. Also added the remaining multiply instruction, but I haven't tested them... Last decoder bug was removed, so now I have a pretty large mega644 firmware using timers, protothreads etc all running happily!

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uart, ioports, etc. Many more changes

+ Reorganized source, split simavr.c
+ IRQ support added to IO modules
+ timer8: fixed a bug related to disabling clock
+ uart:
- Added support for txen/rxen flags
- Added a receive fifo, and the rx interupt
- added a "atmega88_uart_echo" test case
+ simavr: hook rx & tx irqs on first uart, for tests

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another update: http://gitorious.org/simavr

+ Added support to build against the Arduino.app toolchain (on OSX anyway).
+ BIG news is support for GDB. Well, still misses a few bits, but it's functional!
+ Renamed, reorganized, cleaned, and fixed a billion typos.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey that's excellent progress!

Hooked it up to avr-eclipse, and stepping though some simple code just fine. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fantastic! Thanks for testing! I'ts probably a bit slow right now, I have a thread to do the gdb bridge and the main code usleeping(500) between gdb commands.
But I'll streamline that next. Turns out the gdb interface is a hell of a lot simpler than it appears when you read the mess of a documentation :>

I'll add a mode to only activate the gdb server when the core has "crashed" (ie detects a bug in the code that is run) so you can have that "on" by default and not have to use the debugger all the time :>

Then back to IO modules, next is core clock registers, finish SPI, timer16, some sort of ADC, i2c....

Then will be time to make something like a fake arduino, by attaching peripherals to the corresponding "pins" IRQs.

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I have a thread to do the gdb bridge and the main code usleeping(500) between gdb commands
Heh, yes it was somewhat slow - but it seemed a bit unfair to comment on the performance at this point :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've sped that up by a huge amount. More or less reconstructed the backend since I now know how it's suposed to work,
I'll push the changes later on. I think the "core" is now pretty much done. I'll add peripherals as I go along.

Next is making simulated "boards" to make examples on how to use the simavr into a wider program, with your own peripherals etc...

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here goes. Just pushed a rather large patchset. Tell me if you see a diffence ;=)

I also made my first "board" but it's not in the emulator tree, just outside of it for testing. It's looking good!

Author of simavr - Follow me on twitter : @buserror

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pushed another biggish patchset. implemented "one shot" timer callbacks, adapted the uart, eeprom timer8 etc.

The codebase is stabilizing a bit now. I'll add timer16 next, and a couple other things but it's now getting into a very, very usable form. I already found/debugged/fixed a problem in a pretty complex mega644 firmware I have, so it's getting the job done!

Author of simavr - Follow me on twitter : @buserror

Pages