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: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Martin Davey
Sent: Thursday, May 12, 2011 3:08 PM
To: Øyvind Harboe
Cc: openocd-development@lists.berlios.de
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
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
