On Wed, Feb 25, 2009 at 5:42 PM, Laurent Gauch
wrote:
>>
>> >/ Maybe the check should be put back anyway, even when we know that
>> />/ it takes 7 or less steps in case someone changes the code later.
>> />/
>> />/
>> /No doubt that check is needed, or
>>
>> a function rewrite which changes tms to
> Since I am a dummy, I have experience with "APIs for Dummys".
No problem. If you think it's useful for OpenOCD, feel free to
massage it into the way you want it working. If not, just drop
it :-)
___
Openocd-development mailing list
Openocd-developmen
>
>
> >/ Maybe the check should be put back anyway, even when we know that
> />/ it takes 7 or less steps in case someone changes the code later.
> />/
> />/
> /No doubt that check is needed, or
>
> a function rewrite which changes tms to bit a bit vector, and then
> "bits" (which BTW should be cal
> Maybe the check should be put back anyway, even when we know that
> it takes 7 or less steps in case someone changes the code later.
>
>
No doubt that check is needed, or
a function rewrite which changes tms to bit a bit vector, and then
"bits" (which BTW should be called bitcount to make
> 1) A bad assumption is made in the above code that the number
> of bits is 7 or less. The above code should be changed to
> work with more than 7 bits or at least report the error if
> bits argument is greater than 7.
I had proven that you can reach from every state to every state
in 7 or les
As Dick pointed out, trunk has a way to log _every_ tap state
transition including the moves generated as part of a move to a non-
adjacent state. Now, I would be happy to see improvements in the
state transitions so that we don't do 7 moves on every transition.
Rick
On Feb 24, 2009, at 1
>> void ft2232_tms(int bits, char tms)
>> {
>>MYTRACE("ft2232_tms(%d, 0x%02x)", bits, (quint8)tms);
>>for (int i=0; i>bool t = tms & (1 << i);
>>current_state = tap_state_transition(current_state, t);
>>MYVERBOSE(" tms %d, advance to
Hello Holger
I was looking into the jtag tms_seq code and I am convinced your
function would be more usefull
and would allow us to better understand the code overall. While debugging
I even this the openocd state machine should simply follow what happens
in such low level functions.
On Fri, Feb
tap_state_transition() calculates the next state given a current
state and a TMS setting.
The attached function jtag_move_to() calulates the TMS bits given
a *ANY* current state and a *ANY* goal state. It could be used in
OpenOCD to replace the tms_seqs[][] table.
Currently, OpenOCD always sends
