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.