| Author |
Message |
|
|
 Posted: Nov 23, 2009 - 12:41 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 01:44 PM |
|
Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia
|
|
|
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)? |
|
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 01:48 PM |
|
Joined: Jul 18, 2005
Posts: 62230
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| 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. |
_________________
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 02:19 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
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
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 02:28 PM |
|
Joined: Apr 15, 2009
Posts: 4860
Location: San Jose, CA
|
|
What about peripherals simulation? Can I put "LED" to port and see it blinking?
Open sourcing will be good idea anyway. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 03:03 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
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
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 07:33 PM |
|
Joined: Nov 29, 2007
Posts: 3219
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 08:17 PM |
|
Joined: Nov 22, 2002
Posts: 12036
Location: Tangent, OR, USA
|
|
What is the coding language and environment?
Jim |
_________________
Jim Wagner
Oregon Research Electronics, Consulting Div.
Tangent, OR, USA
"The only thing standing between us and victory is defeat" P.G.Wodhouse in Wooster & Jeeves series
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 08:26 PM |
|
Joined: Nov 17, 2004
Posts: 13820
Location: Vancouver, BC
|
|
|
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.
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 08:52 PM |
|
Joined: Feb 19, 2001
Posts: 25891
Location: Wisconsin USA
|
|
|
Quote:
What makes you think that C++ is bloated and slow?
Steve, Steve--Are you still trying to make converts out of us? 
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 |
|
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 09:23 PM |
|
Joined: Nov 17, 2004
Posts: 13820
Location: Vancouver, BC
|
|
| 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.
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 09:39 PM |
|
Joined: Feb 19, 2001
Posts: 25891
Location: Wisconsin USA
|
|
|
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 |
|
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 09:55 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
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
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 10:36 PM |
|
Joined: Nov 17, 2004
Posts: 13820
Location: Vancouver, BC
|
|
|
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.
|
| |
|
|
|
|
|
|
Posted: Nov 23, 2009 - 10:47 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
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...  |
_________________
Author of simavr - Follow me on twitter : @buserror
|
| |
|
|
|
|
|
|
Posted: Nov 24, 2009 - 06:31 AM |
|
Joined: Apr 15, 2009
Posts: 4860
Location: San Jose, CA
|
|
| Getting back to the topic: will we see source code? |
|
|
| |
|
|
|
|
|
|
Posted: Nov 24, 2009 - 11:58 AM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
| yeah, it's almost ready, commenting stuff! |
_________________
Author of simavr - Follow me on twitter : @buserror
|
| |
|
|
|
|
|
|
Posted: Nov 24, 2009 - 01:23 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
|
|
|
|
|
|
Posted: Nov 24, 2009 - 06:08 PM |
|
Joined: Sep 26, 2004
Posts: 78
Location: Stirling, UK
|
|
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)
Code:
// wait for transmit to complete
while(!(UCSR0A & (1 << TXC0)));
//reset the transmit completion flag
UCSR0A |= (1 <<TXC0);
|
|
|
| |
|
|
|
|
|
|
Posted: Nov 24, 2009 - 10:17 PM |
|
Joined: Apr 12, 2007
Posts: 298
Location: Windsor, UK
|
|
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
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
