>> but essentially the interface_ layer should be *told*
>> what the TAP state is after a given TMS sequence.
>
> I don't follow. For starters,
>
>> > +int jtag_add_tms_seq(unsigned nbits, uint8_t *seq, enum tap_state t);
>
> does pass a state.
Right I need new glasses... I'll have to apply y
On Sunday 17 January 2010, Øyvind Harboe wrote:
> I have given this patch some more thought and it breaks
> the JTAG API and jtag_add_pathmove() API/driver layer
> in particular.
$SUBJECT includes three patches ... which one do you mean?
Also, in what sense does it "break" anything? As I noted,
I have given this patch some more thought and I breaks
the JTAG API and jtag_add_pathmove() API/driver layer
in particular.
We should discuss more post 0.4(I need to choose battles
before then), but essentially the interface_ layer should be *told*
what the TAP state is after a given TMS sequence
On Thursday 14 January 2010, Øyvind Harboe wrote:
> I'm OK with this patch. I'll follow up on it for zy1000 once you push
> it post 0.5.
>
> I had a *minor* comment about not using 8 bit in bit arrays,
> but my primary concerns have more to do with not disturbing your
> momentum. :-)
:)
OK. FWI
I'm OK with this patch. I'll follow up on it for zy1000 once you push
it post 0.5.
I had a *minor* comment about not using 8 bit in bit arrays,
but my primary concerns have more to do with not disturbing your
momentum. :-)
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25
This is one of several low-level interface changes that will
support SWD ... obviously not for the 0.4 release, but I'm
posting it now as an FYI/RFC.
- Interface level patch: add a call to clock bits out on TMS.
Switching between JTAG and SWD modes involves some magic
sequences here. The
