Re: Current Status of Insight

[Fernando Nasser <fnasser@redhat.com>]

Duane Ellis wrote:
> 
> 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.
> 

So far so good.


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

Tcl/Tk and Java share this advantages.


 From now on, you are mentioning the advantages of GDB.  It would be the 
same GDB, so whatever GUI we use the god olde GDB will there to provide 
all this.


I think the greatest advantage of Insight is that it is a simple and 
very intuitive User Interface that seems to be unchallenged after all 
these years.

Perhaps it is because it very closely follow the GDB "User Model" 
without trying to add fancy abstractions, nicely named artifacts or 
anything.  It is just a graphical GDB, but still very GDBish.
If you know how to use the GDB command line, you know how to use Insight.


Regards,
Fernando




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

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9