From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26965 invoked by alias); 14 May 2005 14:54:58 -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 26600 invoked from network); 14 May 2005 14:54:46 -0000 Received: from unknown (HELO jade.franklin.com) (63.88.59.83) by sourceware.org with SMTP; 14 May 2005 14:54:46 -0000 Received: from monster.franklin.com (monster [192.9.200.226]) by jade.franklin.com (8.12.10+Sun/8.12.10) with ESMTP id j4EEsdiF028945; Sat, 14 May 2005 10:54:39 -0400 (EDT) Received: from monster.franklin.com (localhost.localdomain [127.0.0.1]) by monster.franklin.com (8.12.11/8.12.10) with ESMTP id j4EEsMof014327; Sat, 14 May 2005 10:54:22 -0400 Received: (from duane@localhost) by monster.franklin.com (8.12.11/8.12.11/Submit) id j4EEsMot014323; Sat, 14 May 2005 10:54:22 -0400 Date: Sat, 14 May 2005 14:54:00 -0000 Message-Id: <200505141454.j4EEsMot014323@monster.franklin.com> From: Duane Ellis To: fnasser@redhat.com CC: insight@sources.redhat.com In-reply-to: <4285211A.6030904@redhat.com> (message from Fernando Nasser on Fri, 13 May 2005 17:50:18 -0400) Subject: Re: Current Status of Insight Reply-to: duane_ellis@franklin.com References: <1115992411.3092.ezmlm@sources.redhat.com> <4284CB51.1050605@evcohs.com> <20050513171503.GB20585@trixie.casa.cgf.cx> <20050513174549.GC21202@trixie.casa.cgf.cx> <4285211A.6030904@redhat.com> X-SW-Source: 2005-q2/txt/msg00051.txt.bz2 >> Another thing: anyone interested in rewritting the GUI in >> Java? >> Is anyone taking resumes :-) Java sounds interesting... - another feature I can put on my resume :-) >> (although I still think there is no real replacement for >> Tcl). That's the problem. Perhaps explaining why Insight is the killer app for me would be helpful to others. -------------------------------------------------- Insight is really gdb - a very configurable debugger Tk - the gui front end Tcl - the script that binds the two For us - the sum of the parts are a greater benifit. >From a software department management view point I have one debugger that most people can use both on the host environment, the target environment, and in our case, a simulation environment. ie: At the end of the day - the basic commands in GDB work in all 3 environments. -------------------------------------------------- SIMULATION If I factor in simulation - I get an even better bang for my buck. I don't need cycle accurate 100% perfect simulation with all kinds of feed back.... Thats my world. Other worlds are very different. The real feature that the GDB Tcl/Tk combo shines in is simulation. I've done a number of smoke & mirrors front ends for product development. I've also done 95% hardware accurate simulations The truth of it is - GDB's macro language sucks, it is very limited then too - it is very task specific. -------------------------------------------------- MODEL SIM Perhaps if people had a chance to see/use the VHDL simulator from Model Technologies which uses Tcl/Tk as it's front end you'd see what I mean. One of the modelsim examples/tutorial is a traffic light controller. In their case - they are hooking up a (chip) hardware simulation to fancy little lights and buttons. There is great benifit to this - expecially in the embedded software environment. However - the benifit is really only found if and only if the customer is willing or can really make a few scarafices. You can't always do that. Historically - it is hard to convince somebody they should do this. It is like the classic argument - write your design document, then write your code. People don't always see the benifit until it is too late. It also has to do with the size of your customer base and how common are things they are working on... for some items it is not worth it. -------------------------------------------------- IN MY CASE In our case - it works really nicely. Think: PALM simulator which - used GDB but has a completely different GUI front end on it. I did this: Create a tk canvas with a picture of the device. Create tk ovals or rects on the canvas Right over the buttons on the device Create a 'tksim' command implimented in C. Write/bind tcl scripts to those buttons that execute the tksim command, ie: tksim button press $row $col tksim button release $row $col Create a tk Photo on the canvas This becomes the LCD simulation in C - get access to that photo, follow the example in the Tcl/Tk books & docs.. that is all I did. When the simulation writes to memory calculate what pixel that translates to convert the value to RGB and update the photo. Create/bind mouse events on the LCD photo ie: mouse button 1 press & drag becomes nothing more then tksim mouse down $oldx $oldy $newx $newy Now you have a touch screen simulation. To use a different platform or device - it's a different tcl/tk skin, nothing more.... ---------------------------------------- SIMPLE HARDWARE SIMULATION is sometimes enough.. To do simple hardware simulation it requires a little change in the memory read/write simulation functions. For example - GDB's ARMulator has two core functions: PutWord() and GetWord() all memory reads & writes go through these functions. You change them like this: >> ARMword >> GetWord( ..., ARMword address, ARMword data, ... ) >> { >> switch( address ){ >> case SIM_KEYBOARD_STATUS_REG_ADDRESS: >> return simulated_keyboard_fifo_status(); >> break; >> case SIM_KEYBOARD_DATA_REG_ADDRESS: >> return simulated_keyboard_fifo_getkey(); >> break; >> ..... >> } >> ... normal arm code goes here ... >> } ---------------------------------------- Using a HAL layer. In some embeded systems its hard/impossible to simulate. For example - realtime mechanical feedback - ie: Turn on motor, read position feedback, track acceleration... - it depends on what you are doing. It is not always the same as the hardware - you are not bit banging SPI stuff or little serial eproms, or programing a flash memory. But - you can do quite a bit... You can simulate slow ADC voltage inputs with a tcl/tk slider, or an DAC output with a progress bar. We have a fairly good hardware abstraction layer. We either link with the simulation library, or the hardware. Somethings can only be done on the hardware. ---------------------------------------- Java Vrs Tcl - I need a command line. For me - the above is the true benifit of Insight. I believe Java can do the same thing. But what Java does not have - is a command line it is compiled langauge Tcl/Tk - it is some what enherent. ---------------------------------------- PREVIOUSLY - Turn GDB inside out. When this came up previously, somebody made this observation and suggestion: (I forget who) Today - tcl/tk is bolted onto GDB. In effect, GDB is the first class citizen, Tcl/Tk is 2nd class. The suggestion was to turn Insight inside out - and make the GDB commands tcl commands, and tcl objects. The macro ability that Tcl would give GDB is huge. The trick is that the GUI (TK) portion becomes optional. If you've ever done a lot with ModelSim you'll see what I mean. My hunch is - doing exactly that - turing Insight/GDB inside out is probably the better solution. That's my 3.5 cents. -Duane.