Re: [Simulavr-devel] SimulAVR + simulated hardware

[Theodore A. Roth]

On Wed, 24 Dec 2003, Bill wrote:

> 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.

It was added very recently. Only available in cvs:

  
http://savannah.nongnu.org/cgi-bin/viewcvs/simulavr/simulavr/README.mem_vdev?rev=1.1&content-type=text/vnd.viewcvs-markup

I'll reply to the rest of this message later today.

Ted Roth

>
> 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
>
>
>
> _______________________________________________
> Simulavr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/simulavr-devel
>