Dick Hollenbeck wrote: > Magnus, > > I think we are talking past each other. There are nouns used in your > sentences that need to be defined. > > For example search below for "state_move". Its meaning is not > clear. We need to take MUCH more time and articulate what problem we > are even talking about let alone what problem we are trying to solve. > there is a high level jtag_state_move function
> The problem I solved with the Jeff Williams patch is the wasting of > clock cycles. Maybe another thread can be started for stable states. > It was discussed elsewhere last week and the consensus was that stable > states were the only endpoints that you can count on because clock > cycles are not always halt-able on all cables. > Having a complete shortest path table will waste no extra clock cycles, and some target people want the freedom to create weird paths, let them have it ! > I do not want this side tracked discussion to be an impediment to > getting my work done yesterday and today accepted. My head will > explode. What I accomplished is to put in place a platform for > experimentation of shorter TMS sequences. And diligent state > transition logging. The first was a favor to Jeff, the 2nd is > mandatory to do troubleshooting for me. > I want your work to be accepted !!!!! Now !!! I like it :) We also get an interface where access to paths are through function calls, not array lookups, excellent. The we test it on all target and interface hardware. Then we can without breaking anything add the possibility to use the same framework to look up other paths, if that is needed for specific tagets or interfaces. Best regards, Magnus _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
