Re: External Program interaction with Insight

[Duane Ellis <duane_ellis@franklin.com>]

duane > In my simulator I used Tcl/Tk's tcp/ip socket interface to simulate a
duane > serial port. When things come in from the remote socket, the 'appear'
duane > as interrupts from the serial port, you read from the 'rx-data'
duane > register and you pull bytes out.

keith> I hope you're using a safe tcl interpreter to do this, interfacing this
keith> interpreter to insight's. It would be a little risky to allow direct
keith> access to Insight's interp. 

In my case, i have a 'compiled in simulator' thus I have a single
thread of execution. As such, I can make use of insights interp :->
directly

keith> I would love to see an interface class for
       this specific purpose. (Hint, hint ;-)

The simulator has been out for quite some time, register to be an
ebookman developer (http://www.franklin.com/ebookman) and download the
sdk source code. It's all right there. You can buy an eBookman quite
cheap too (it ain't no stinking $500 pocket pc)

If you don't want to purchase the unit, You can try out the simulation
and build what we call the "gui test app" under cygwin or RH LINUX
INTEL without purchasing the product.

If you dig into the simulator source, you'll notice that the simulator
builds as a standalone application, without gdb, and builds as a
library that gets compiled into gdb. As such, the code in some places
will seem quite strange... Which answers the question: Why the hell
did he write the code that way....

Basically the simulator execute engine works like this:

At some point, gdb calls a function to tell the target to "run" and
then some function to "wait for it to finish" {ie: wait for target}.

In my 'wait for target' I have a loop that:

a) calls an "execute_some_more_opcodes()" function Every few thousand
   instructions, it returns.  {It 'comes up for air, otherwise it
   would 'drown'}

b) If things look ok, ie: No errors, breakpoints, etc, ie: it is just
   comming up for air, I monitor some other simple flags to see if I
   should stop, or not, and make some calls to ui_loop_hook(),
   notice_quit() and Tcl_DoOneEvent(). Then execute more opcodes.

the majic is "Tcl_DoOneEvent()"

Because I call that, I can simulate buttons being pressed, a touch
screen and all that sort of stuff this way.

to handle the SIO simulation, I do some small setup in tcl (ie: the
"socket -server" function), and then pass the socket handle [called a
channel-handle in tcl] to a C function. In the C function I use it as
a parameter to "Tcl_CreateChannelHandler()" along with a callback
function.

Now that the channel has a "handler" Tcl_DoOneEvent() calls my
"callback" when it discovers incomming data in the socket. In the
callback, I convert the channel handle into an "int" token for the low
level read() call.

to tx data, I do basically the same thing, and but call write()

Works quite nicely.

Sadly, I do not get true simulation (ie: serial Interrupts do not
occur at intervals based on programed baud rate). I'm not after that,
I'm after something that runs close enough...

-Duane.