simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Introducement / Status request


From: qmax
Subject: Re: [Simulavr-devel] Introducement / Status request
Date: Mon Sep 2 16:49:08 2002
User-agent: Mutt/1.3.28i

On Mon, Sep 02, 2002 at 11:37:51AM -0700, Theodore A. Roth wrote:
(: Don't worry about duplicating work. There's not much going on right now
(: since I'm pretty busy with a lot of different projects right now.
I supposed someone else may coding something, like those people sent u the
patches u've lost.

(: As for cvs/patching, there's now set in stone rules, only my preferrence.
(: If you have a cvs sandbox, it's really easy to generate a patch as such
(: (from root of sandox):
Ok. got it.
CVS FAQ misses 'sandbox', but jargon file has.
/me is actually a newbie with CVS. Thanx for directions.

(: :) My first-shot suggestion is to implement PIN[A-D] read/write facilities
(: :) in communication proto with external process, similar to, or the same
(: :) as disp-proto. This simply requires latching/updating these addresses
(: :) in main.c: ext_port_* instead of "writing 0x%02x to 0x%04x" and "Enter
(: :) a byte of data to read into 0x%04x" (While not dealing with external
(: :) signal source).
(: 
(: I don't particularly like the ext port io being done in main.c as it is
(: now. It was just an ugly hack to so I could see what's going on.
So they probably should be moved to port.c, since nothing else has external
connectivity.

(: I'd really like to see a plug-in system, where simulavr just checks a
(: directory for modules to plugin which provide whatever interface you want
(: for a port. This would give the user more flexibility in tweaking simulavr
(: to their needs without having to dig into the code so much.
Then there should be some API for plugins. 
Are there any similar projects to get start from ? 
I haven't checked that carefully, but at first look gpsim has only external
signals emulation, but no virtual enviroment.

(: :) Im (up | trying) to write a tcl-powered GUI display program (displavr)
(: :) to introduce widgets representing ports statuses in human-viewable form
(: :) /* mostly those blinkenlighten; attempt to make oscillogramme (egg, to
(: :) watch PWM) leads to requirement of proto packets time/clock
(: :) synchronization */. Adding ability to write to PIN[A-D] addresses will
(: :) make it possible to write tcl scripts implementing hardware enviroment
(: :) logic or simple input widgets.
(: 
(: My only concern with using tcl/tk is that it will be very slow, but if you
(: are hooking in to the disp interface, you are free to do that. Which is
(: why the disp interface uses a coprocess.
Core interaction can be made outside tcl interpreter, as well as widgets
creation/handling. I hope it is possible to use scripts only to events hooking.
The libTcl event loop does not require interpreter at all if to use
Tcl_DoOneEvent and all that stuff "manually".

-- 
qMax

P.S. (: just kidding :)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]