On Monday 15 June 2009, Øyvind Harboe wrote: > > Why not just have an interface that doesn't *care* what word > > size applies underneath? Settling on 32 is better than > > settling on 8 ... but specifying 32 is not necessary. Such > > things tend to cause needless trouble over time. > > I think we need to distinguish between the JTAG API and helper fn's.
So you would say the "JTAG API" is dealing with -- I'm guessing here -- just (a) state transitions/TMS (b) clocking during RUN, and (c) data shifting during IRSCAN/DRSCAN? Plus maybe basic policy for scan entry/exit, to ensure that free-running clocks don't cause un-requested state transitions? That'd be OK. So long as there's a simple representation of the bit arrays to be shifted in/out. Again, that's one thing I like about the Linux framework: it basically takes a pointer to an "unsigned long", and a bit count. > Certainly helper fn's can have this sort of flexibility, but the lower > levels should be more oriented towards being crispely defined and > not killing performance. Right, so they should accept word-aligned data ... since byte-aligned data can be a performance killer. And when I say "word" I mean in the classic sense of machine register/data-move size, so it's 32 or 64 bits on most modern hardware suitable for OpenOCD. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
