On Friday 12 March 2010, simon qian wrote:
> Sounds wonderful. :-)
I was hoping you'd like it ... I know you'd like to be able to
use more Versaloon capabilities through OpenOCD.
> Note that SRST isn't ONLY used in JTAG or SWD, AVR_ISP
> will also need control over SRST line, many other MCUs may
> need it too, because it's basic signal in MCUs.
Right; point being, "not JTAG-specific.
> How about make SRST a "transport" and can generate a
> reset event. Then, Cortex-M3 target will need JTAG+SRST
> or SWD+SRST "transports".
> But problem will be that SRST and TRST will not be able to
> be handled in one command, because TRST belongs to JTAG.
> Compromise Maybe that JTAG/SWD can handle SRST and
> meanwhile there exists a SRST "transport".
Debug support for Cortex-M3 doesn't need SRST; there are
NVIC operations which remove that requirement.
My current plan is to just make SRST support be an
debug adapter ("Interface" facility, as distinct from
JTAG support as we practical. (Which for now isn't as
much as I'd like.)
>
> Moreover, I think maybe more than one "transports" can be
> validated on one target. For example, "transport" for debug port
> and "transport" for trace port can be validated at the same time.
Some day, maybe. supporting two transports at once is a complex
concept. coordinating asynchronous actiivties like that is racey
(and thus error prone). I'd rather avoid such stuff in userspace;
kernel code has the synchronization primitives needed, but they are
a huge portability problem for userspace. and I haven't seen a need
for it yet.
(Trace port support is an interesting thing to plan for though.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
