Re: [Openocd-development] OpenOCD becoming an Eclipse TCF Agent

[Austin, A. <Ale...@sp...>]

From what I understand, what this would allow such
a stackup as:

Component          Provides
----------------------------
ARM Core           JTAG
Openocd            TCF (addresses only)
GDB                TCF (interprets symbol table,
                        handles soft breakpoints)
My_rtos_xlator     TCF (knows where to find thread
                        state tables)
Oprofile           TCF (keeps statistics of thread
                        and function runtimes)
Eclipse            GUI with full knowledge of thread
                       state and profiling info

You could pull out My_rtos_xlator and still have
access to function-specific profiling. You could pull
out the oprofile layer if you don't need it. You could
write My_rtos_xlator in a platform-agnostic manner with
GDB and openocd translating it to support whichever
target the rtos is running on.

-----Original Message-----
From: ope...@li... [mailto:ope...@li...] On Behalf Of Martin Davey
Sent: Thursday, May 12, 2011 3:08 PM
To: Øyvind Harboe
Cc: ope...@li...
Subject: Re: [Openocd-development] OpenOCD becoming an Eclipse TCF Agent

On 12/05/2011 20:22, Øyvind Harboe wrote:
> So OpenOCD would have a TCF TCP/IP server that would  feed output/input
> from DCC?
>
> Why is code required on the target?
>
>
>
As I understand it, you can run an agent on the target, or the agent 
could be like OpenOCD and bridge between the JTAG and TCF connnection.

The communication between TCF and the Agent is JSON.

Extra services like target discovery etc would make the whole thing very 
slick.
_______________________________________________
Openocd-development mailing list
Ope...@li...
https://lists.berlios.de/mailman/listinfo/openocd-development