spen> Generally i like the addition of the tcl scripting to openocd.
spen> [but sometimes it goes to far]

oyvind> Being able to debug OpenOCD without getting into Tcl is a goal for
oyvind> me and I believe the change does keep that capability reasonably 
intact.

I agree with both of you. There is a fine line - that is often gray and 
hard to see.

I have a good tool - but - I need to do what a small script would do.

Simple example: wiggle some gpios - and or wait for something. Mostly - 
a straight line script does the job - POKE memory and sleep. But at some 
point  you sort of need an "if" statement.

Example - my board might have a special "GPS" chip - or an LCD 
controller or a camera interface. Having the ability to display the 
register contents would be great! But there is no way to do this in GDB. 
Getting that added to GDB is impossible.

This "second TCL remote interface" [Charles Hardin's recent email] that 
is aimed specifically at "remote control" has huge potential. Can you 
name a debugger that will display a region of memory as a jpeg? or BMP? 
What about one that will draw a chunk of data as a wave form?

Yes, JTAG is slow - but something is better then nothing.

Using that "2nd remote control interface" to and a script to wiggle pins 
- and suck data out of the target (the reverse too) - one could easily 
whip up an image processing plug in for eclipse. In fact a smart chip 
maker would love to give you a tool that helps you use his chips. Or - 
maybe it is a non-eclipse standalone tool - that talks this new "remote 
interface protocol." - BUT - it would plug into openocd - without 
breaking GDB! The simple rule would be: Only one tool can talk to the 
target at a time - ie: tell GDB to STOP before uploading images is an 
easily rule to understand and accommodate - and code for.

Ditto for "OS-Plugins"

That idea scales further then any of us - and lets people work 
independent of openod. It would a great benefit to nail that protocol 
down - now. And - specify rules of how others could create "target 
local" additions in nice clean ways that will not interfere with others.

Spen, You are right, Insight has its problems. Perhaps the biggest is 
-it came before its time. And was far too integrated. What really sucked 
was - having to debug the script - in the debugger with another 
debugger. Yuck! That is a true night mare.

-Duane.








_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to