From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14839 invoked by alias); 22 Feb 2002 17:30:01 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 14668 invoked from network); 22 Feb 2002 17:29:59 -0000 Received: from unknown (HELO earth-out.franklin.com) (63.88.59.82) by sources.redhat.com with SMTP; 22 Feb 2002 17:29:59 -0000 Received: from saturn.franklin.com (IDENT:root@saturn.franklin.com [192.9.200.2]) by earth-out.franklin.com (8.9.3/8.9.3) with ESMTP id MAA15790 for ; Fri, 22 Feb 2002 12:29:57 -0500 Received: from mercury.franklin.com (IDENT:root@mercury.franklin.com [192.9.200.250]) by saturn.franklin.com (8.9.3/8.9.3) with ESMTP id MAA05232 for ; Fri, 22 Feb 2002 12:29:56 -0500 Received: (from duane@localhost) by mercury.franklin.com (8.9.3/8.9.3) id MAA17271; Fri, 22 Feb 2002 12:29:59 -0500 Date: Fri, 22 Feb 2002 09:30:00 -0000 Message-Id: <200202221729.MAA17271@mercury.franklin.com> From: Duane Ellis To: insight@sources.redhat.com In-reply-to: (message from Keith Seitz on Fri, 22 Feb 2002 07:42:48 -0800 (PST)) Subject: Re: External Program interaction with Insight Reply-to: duane_ellis@franklin.com References: X-SW-Source: 2002-q1/txt/msg00144.txt.bz2 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.