> A simple approach is this:
>
> Step 1: Define a set of commands we expect to be uniform for all platforms.
> And document their expected interface.
This is already started in target/readme.txt.
> For example - a standardized set of GPIO or ADC - what every the may be.
> And - "VENDOR SPECIFIC" rules.
>
> Step 2: We create a small TCL script - that is always loaded - which does
> nothing more then throw errors
> This is an example of the GPIO command.
>
> proc gpio { HELP } {
> error { "No GPIO command defined for this chip\n"
> "Or the chip specific TCL file has not been loaded or does not
> exist\n"
> "Try looking in in \${src}/chips/MAKER/FAMILY/NAME.tcl\n"
> "If you want to create one - see the docs file <SOMEHWHERE>"
> }
> }
tcl/commands.tcl is always executed. It is the intention that these
sort of commands are defined in that file.
>
> Step 3: When the <CHIPFILE> is loaded the above "dummy-gpio command" is
> quietly released by Jim.
>
> =======
>
> Øyvind> Once there are some polymorph proc's defined, I'd like to update
> the Zylin
> Øyvind> Embedded CDT to support them. This will allow showing and even
> modifying
> Øyvind> peripherals from a GDB GUI frontend.
>
> This should use the interface Charles is creating.
I don't want to set up anything else but the GDB connection, more hazzle
for the user, so I'd like to do any communication using the GDB
monitor command.
Would that be a problem?
Asynchronous callbacks is the only problem I see, but by polling intermediately
that could be handled.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
