[Simulavr-devel] SimulAVR + simulated hardware

[Bill]

I"m interested in learning about how to write simulated hardware for 
simulavr. For proof of concept and to hopefully keep the task 
manageable, I'd like to start with simulating a few LEDs and switches.

How should I start? Who's interested in this topic?

1.)TRoth was kind enough to point me to README.ext_int and 
README.mem_vdev, but unfortunately, I can only find the README.ext_int file.

2.)It sounds like a plugin-architecture is the intended direction for 
what I'm describing. What would this look like/how can I help?

It seems the first thing to think about is what the design goals are:

A.) For me, I'd say that there must be a way to synchronize the 
simulated hardware with simulAVR. At least the internal interrupt should 
be supported (not I/O related, per se, but the concept of time should be 
supported across the I/O interface in both directions)

B.)how portable does this plugin architecture have to be? I'd like to 
see at least Linux (x86, if it matters) and at least cygwin or MINGW 
support.

C.)the README talks about a config file... I agree we should avoid 
writing any parsers...there are so many already available. My vote would 
be for either Python (I have some toy experience with this ala SWIG) or 
GUILE (less experience, but have been through tutorials to laod/execute 
.so, I think via SWIG also) What whoudl this config file do though? I 
would assume it would configure how a plugin hooks up to theh virtual 
pins of the AVR chip.

D.)the actual API of course needs to be worked out. My initial interest 
is(maybe only) in AT90S8515. This could be interesting since on the 
surface, there are ports A-D, but of course, the pins for ports A-D can 
be used to access built-in functionality such as UART, interrupts, 
external memory, etc.. To me this means that the same pins might 
likewise have different interfaces. It doesn't make sense to simulate 
the hardware signals involved with RS-232, it should just look like a 
byte (word maybe, given 9-bit mode?) stream, right? To address TRoths' 
concern, a sample syncronous plugin could be provided to show how I/O 
signals could be buffered to allow asynchronous interaction with the AVR 
chip. This section seems to require a document that specifies the API. 
Lots of work to be done here I think!

My short term project is a chess-clock.
My long term project is to simultaneously record/playback music on an 
old Hammond Organ. That's 44 keys per console plus 13 pedals, lots of 
toggles, tempo adjustment (probably sense only) and a few other things 
to make it all work nicely... It's an electronic organ, meaning no 
microprocessors in the organ. It's mostly analog except for an EEPROM 
that sequences the rythm unit...and likely sensitive to noise I expect 
to be present in a AVR-cirtuit, wihch I think I have several solutions 
for already. Anyway, my father built it from his junk, discard and 
garage-sale piles when we worked at Hammond organ.  I exepct to find 
many projects come up as I learn how to use the AVR chips.


Ok. I've rambled on a bit and will likely be on-and-off given vacation 
plans coming up. But I wanted to get this thread started at least for my 
own peace of mind.

I'm not used to this type of development, but hope to be of some use to 
this project. I've investigated the existing instruction (opcode) 
simulation code, displapy coprocess driver, and a little bit of the GDB 
interation code. The design definitely looks workable.

Comments? Concerns? Suggestions?

Cheers,

Bill