Magnus Lundin wrote:
>> It would be nice to get some comments on the 8 bit sequence for entering
>> RESET.
>>
>> I think the reasoning needs to be documented, else we go back to 7 bits?
>>
>
> Agree, or even use shortest path, I think the state transitions should be
> shortest path.
Ok, agreed. I will give each entry a close look with this goal of
shortest path in mind.
Any problems with using five 1s bits for *all* paths to RESET? Or
should we use shortest paths there also in that first column?
I honestly did not look over each entry before submitting the patch, and
was just submitting what Jeff submitted on 3/30.
> If a specific driver needs to use a certain path length or
> issue more than on transition in reset then it easy to pad with extre
> transition within the stable state. We have the bitcounts.
>
Well yes, if I understand you correctly, they can do a test like this to
override what the API returns:
if( get_tap_state()==<blah_start> && <needed_end_state> == <blah_end> )
bit_count = <>;
pad the bits here.
else
bit_count = tap_get_tms_path_len( <blah_start>, <blah_end> );
Dick
> Magnus
>
>
>
>
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
