On Wed, May 13, 2009 at 10:29 AM, David Brownell <[email protected]> wrote:
> On Tuesday 12 May 2009, Ųyvind Harboe wrote:
>> I've been thinking about whether some helper fn's to
>> use 32 bit arrays instead of 8 bit input/output might make sense.
>
> Why 32 bits instead of e.g. just plain "unsigned long"?
We're talking about bits to be clocked in/out not integers as such...
32 bits is just a convenient size that works well on 32 & 64 bit hosts.
Below is the current 32 bit version of clocking out drscan's. This has
been implemented for quite some time now and is exploited by
embedded hosts for ARM7/9 memory DCC writes...
>From jtag.h:
/* jtag_add_dr_out() is a version of jtag_add_dr_scan() which
* only scans data out. It operates on 32 bit integers instead
* of 8 bit, which makes it a better impedance match with
* the calling code which often operate on 32 bit integers.
*
* Current or end_state can not be TAP_RESET. end_state can be TAP_INVALID
*
* num_bits[i] is the number of bits to clock out from value[i] LSB first.
*
* If the device is in bypass, then that is an error condition in
* the caller code that is not detected by this fn, whereas jtag_add_dr_scan()
* does detect it. Similarly if the device is not in bypass, data must
* be passed to it.
*
* If anything fails, then jtag_error will be set and jtag_execute() will
* return an error. There is no way to determine if there was a failure
* during this function call.
*
* This is an inline fn to speed up embedded hosts. Also note that
* interface_jtag_add_dr_out() can be a *small* inline function for
* embedded hosts.
*
* There is no jtag_add_dr_outin() version of this fn that also allows
* clocking data back in. Patches gladly accepted!
*/
static __inline__ void jtag_add_dr_out(jtag_tap_t* tap, int
num_fields, const int* num_bits, const u32* value,
tap_state_t end_state)
Example:
u32 values[1];
int num_bits[1];
values[0]=new_scan_chain;
num_bits[0]=jtag_info->scann_size;
jtag_add_dr_out(jtag_info->tap,
1,
num_bits,
values,
TAP_INVALID);
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
