On Wed, 2009-04-22 at 09:01 -0500, Dick Hollenbeck wrote: > Magnus Lundin wrote: > > The only reason I can think of for a specic numbering is that it might > > optimize the gate design in a hardware implementation of the tap state > > engine. But this is not a problem for us so thats OK. If we want to > > follow JTAG documentation standards (ARM ane IEEE) in our code then the > > state names should also change like: > > > > TAP_DREXIT2 --> TAP_EXIT2_DR > > etc > > (this will have a greater impact ... ) > > > > Name changes: > > Luke warm on this *name* change.
The EXIT2_DR form is how it appears in most documentation I have seen, so I think there is value with these changes. But, yeah, IEEE could have done better. I gave this some thought; a simple script might be the best approach. It would automatically produce and apply a series of 16 or 17 incremental patches, one for each symbol that needs renaming. This approach would help reduce collisions with working copies, as anyone with outstanding patches could run the script on their WC _before_ doing an 'svn up' through the relevant commits. It seems like this would be faster and cleaner to manage the process than other approaches, but I posting it here for consideration and feedback. > Value changes: > > This *should* be safe (as a goal), but I would be only about 90% sure > that it is at this moment. I tried to move the code in the direction > of switch()es instead of arrays which where were dependent on array > index values matching symbol values. But I do not know that all such > situations were corrected. So I think we should keep an open eye on > this change for awhile, and keep the goal in mind. This was one of my concerns, but it's in tree now. Heads up everyone! If nothing else, I think this can serve as both motivation and means to find and fix any remaining places where there are problems. > > > and finally > > > > TAP_INVALID is used in the target code to mean "TAP DONT CARE" so > > calling it invalid is a bit misleading. > > > > There are places in the code where we have a don't care, and elsewhere > an invalid or initial undefined state. So we would need two symbols to > be perfect. With that would come unnecessary complexity. The current > symbol might be good enough. While their semantics may be the same today, I see no reason to assume that will always be the case. It seems like "nuanced" error reporting would not be possible without two symbols, but what else? If we do want to distinguish them from one another someday, the existing symbol is sufficiently unique to allow quick grep-based hacking. Whether or not we keep TAP_INVALID, I vote for TAP_UNKNOWN instead of TAP_DONT_CARE. > I wish to remind the team that next week I will be working on the ft2232 > driver. This is with or without the patch from Duane. That is my time > slot, and it is not movable due to some manufacturing test schedules > that I have to meet for a new ARM board we are making: Nifty. Will you get a chance to take a look at the revised High-Speed device patch that I posted recently? Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
