Dick Hollenbeck wrote:
> 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?
>
That is ok, reset is a special case and if is called because we have
lost sync with the controller tap state due to some communications
error ... then 5 is needed.
> 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> );
>
Right, or
Clock out path: for (bitcount=0; bitcount<path_length; ...
Pad: while bitcount < bitswewant repeat last ...
Regards,
Magnus
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
