i'm working with a JTAG cable atm which has a slight quirk to it. basically, it cant handle dangling shift states. iow, it cant move through the JTAG state machine one bit at a time. if you want to set the IR to BYPASS, you would send all 5 bits in one go rather than telling the cable to shift out one bit at a time.
in practical terms, this isnt a big deal as most of urjtag operates in
this way. it bundles up the data to send out before giving it all to
the cable driver to process. there are two major points though where
this causes a problem:
- part detection in src/tap/detect.c:urj_tap_detect_parts()
- idcode reading in src/tap/idcode.c:urj_tap_idcode()
so in the part detection, rather than doing:
for (i = 0; i < chlen; ++i) {
- shift just one bit
- check the bit
- if bit is valid, shift out 31 more bits
}
this cable has to do one big shift of (chlen * 32) bits
to support this behavior, what i'm thinking is we extend the cable
driver structure with a "quirks" field. then specific drivers can
fill this out with their own quirks an in common code, we check the
specific quirk bit. the PoC patch is attached. anyone have better
ideas than this ?
-mike
urjtag-quirky-cable.patch
Description: Binary data
------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________ UrJTAG-development mailing list UrJTAG-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/urjtag-development
