rick> As my other patch shows, such a mechanism simplifies interacting
with a JTAG route controller, so the mechanism would already be in place.
I missed that - where is this at?
duane> {taps as objects}
rick> [name space is the real issue]
Agreed.
As for the more general "taps - as objects" - that can happen when
someone wants to write that code.
================
As for "jtag events" - I think perhaps there could be a series of "jtag
events" not exactly bound to a tap.
That might be a simpler and perhaps more effective solution. Why? I say
that because all of the other taps
are tied together via the tap chain in some way. I suspect we'll hit
wacky problems.
We could for example create a command:
"jtag newevent [--append] EVENTNAME EVENTBODY."
That would execute the the EVENTBODY based on some event that occurs =
note: the that means "all taps" not one specific tap.
> Doing this should also make adding other protocols like SWJ, I2C, and
> SPI easier. The tap objects can be a generic struct that contains a
> type identifier. This type would indicate which protocol it uses and
> also indicates the other members of the struct. Then, each protocol
> would have a top-level command similar to the "jtag" command. That
> command would have a "newtap" subcommand that takes the appropriate
> operands for that protocol. Then when creating a target, the tap is
> specified. The target could inspect the tap to determine if it can
> use a tap of that type. That would provide sufficient decoupling
> between the protocols and the targets to allow new protocols to be
> introduced with relative ease.
I like the the "K.I.S.S." principle.
I think in some ways - we are making this just a tad bit to complicated.
SPI should be it's own first class command, and there is no way I would
want to mix JTAG + SPI at the same time.
In the case of SPI or I2C - I am taking over the flash memory action to
force something onto the chip.
In stark contrast: In jtag case - I am cooperating with the chip. A big
difference.
-Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
