On Dec 11, 2008, at 5:09 PM, Duane Ellis wrote:
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?
A different thread with subject "JTAG Events".
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.
If we can agree how we want it to work, I'll make it happen. I just prefer not to code without a plan.
================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.
The two events that I defined in the other thread are tied to a specific tap. There are definitely other events that apply to the whole chain (TRST and SRST asserted for example). We should handle both cases gracefully.
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.
There is already some infrastructure for this but it uses function pointers rather than Jim_Objs. We could easily make it work.
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.
As do I. But sometimes K.I.S.S. actually turns out to be much more complex than you want.
I think in some ways - we are making this just a tad bit to complicated.
The last bit here is certainly pushing the envelope to allow for future extension. It is complex and probably should not be included in 1.0, but I think it is worthwhile for investigation.
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.
Right, I would expect each protocol to have its own top-level command. It is just that the top-level command serves to create "taps" that are also a top-level object.
In the case of SPI or I2C - I am taking over the flash memory action to force something onto the chip.
Very true, but ultimately, you can think of them as "taps" or "endpoints" that you are communicating with. You could, for example, have the same flash driver be able to work with SPI or I2C variants of the same basic flash chip design.
In stark contrast: In jtag case - I am cooperating with the chip. A big difference.
Hence why at the other side of the pipeline we have targets, plds, and flash.
-Duane.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
