Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
buserror
PostPosted: Nov 23, 2009 - 12:41 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
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.
 
 View user's profile Send private message  
Reply with quote Back to top
damien_d
PostPosted: Nov 23, 2009 - 01:44 PM
Resident


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)?
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Nov 23, 2009 - 01:48 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71738
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.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
buserror
PostPosted: Nov 23, 2009 - 02:19 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
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
 
 View user's profile Send private message  
Reply with quote Back to top
alexru
PostPosted: Nov 23, 2009 - 02:28 PM
Raving lunatic


Joined: Apr 15, 2009
Posts: 6514
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.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
buserror
PostPosted: Nov 23, 2009 - 03:03 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
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
 
 View user's profile Send private message  
Reply with quote Back to top
ArnoldB
PostPosted: Nov 23, 2009 - 07:33 PM
Raving lunatic


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.
 
 View user's profile Send private message  
Reply with quote Back to top
ka7ehk
PostPosted: Nov 23, 2009 - 08:17 PM
10k+ Postman


Joined: Nov 22, 2002
Posts: 14064
Location: Tangent, OR, USA

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.
 
 View user's profile Send private message  
Reply with quote Back to top
Koshchi
PostPosted: Nov 23, 2009 - 08:26 PM
10k+ Postman


Joined: Nov 17, 2004
Posts: 15100
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.
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Nov 23, 2009 - 08:52 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 29211
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? Twisted Evil

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
 
 View user's profile Send private message  
Reply with quote Back to top
Koshchi
PostPosted: Nov 23, 2009 - 09:23 PM
10k+ Postman


Joined: Nov 17, 2004
Posts: 15100
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.
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Nov 23, 2009 - 09:39 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 29211
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. Wink

Lee
 
 View user's profile Send private message  
Reply with quote Back to top
buserror
PostPosted: Nov 23, 2009 - 09:55 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
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
 
 View user's profile Send private message  
Reply with quote Back to top
Koshchi
PostPosted: Nov 23, 2009 - 10:36 PM
10k+ Postman


Joined: Nov 17, 2004
Posts: 15100
Location: Vancouver, BC

Quote:
Nah; wouldn't work.

Definitely wouldn't work Wink
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.
 
 View user's profile Send private message  
Reply with quote Back to top
buserror
PostPosted: Nov 23, 2009 - 10:47 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
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... Very Happy

_________________
Author of simavr - Follow me on twitter : @buserror
 
 View user's profile Send private message  
Reply with quote Back to top
alexru
PostPosted: Nov 24, 2009 - 06:31 AM
Raving lunatic


Joined: Apr 15, 2009
Posts: 6514
Location: San Jose, CA

Getting back to the topic: will we see source code?
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
buserror
PostPosted: Nov 24, 2009 - 11:58 AM
Hangaround


Joined: Apr 12, 2007
Posts: 299
Location: Windsor, UK

yeah, it's almost ready, commenting stuff!

_________________
Author of simavr - Follow me on twitter : @buserror
 
 View user's profile Send private message  
Reply with quote Back to top
buserror
PostPosted: Nov 24, 2009 - 01:23 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
Location: Windsor, UK

Here goes !

http://gitorious.org/simavr

_________________
Author of simavr - Follow me on twitter : @buserror
 
 View user's profile Send private message  
Reply with quote Back to top
jone
PostPosted: Nov 24, 2009 - 06:08 PM
Wannabe


Joined: Sep 26, 2004
Posts: 78
Location: Stirling, UK

That's pretty cool! Smile

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);
 
 View user's profile Send private message  
Reply with quote Back to top
buserror
PostPosted: Nov 24, 2009 - 10:17 PM
Hangaround


Joined: Apr 12, 2007
Posts: 299
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 (Wink), 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
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits