On Thursday 14 January 2010, Øyvind Harboe wrote:
> > +struct tms_command {
> > + /** How many bits should be clocked out. */
> > + unsigned num_bits;
> > + /** The bits to clock out; the LSB is bit 0 of bits[0]. */
> > + uint8_t *bits;
>
> Tiny comment:
>
> Use uint32_t here, rather than 8 bits. Why 8 bits?
Mostly because the relevant patterns for switching between SWD
and JTAG modes are on the order of
50+ all-ones bits
16-bit pattern
50+ all-ones bits
So while it's easy to express that in terms of bytes and be obviously
correct, using 32-bit numbers is pretty unnatural.
Plus, notice the second patch ... that "cable helper" library thing
has always worked with a single 8-bit byte, not 32-bit integers.
> There is no
> big/small endian issue here, lsb is shifted out first.
I'm not sure what you mean by that. The reason there's no endianness
issue is that it's specified in the interface as a simple bit array,
using little endian encoding. Using 32-bit words would be a way to
introduce endianness issues, not remove them...
> The only reason I mention this is because I'd like to see the rest of
> the jtag api move away from 8 bit vectors to something more sensible
> (32 really).
I suppose I'm still thinking in terms of straight bit vectors being
the most natural interchange format for such stuff ... byte pointer
with count-of-bits.
The originator of a bit vector is of course free to align it however
they like. And it might be reasonable to require that the pointer be
aligned to some boundary.
Plus, I didn't want to couple this interface to needing a rewrite of
the entire JTAG layer bit vector interface ... ;)
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
