New AVR simulator

85 posts / 0 new
Last post
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.

Pages