I've been pondering if an esthetic change to the JTAG API would
be useful.
The idea is to implement this as a helper fn.
Consider:
fields[0].tap = jtag_info->tap;
fields[0].num_bits = 3;
buf_set_u32(&out_addr_buf, 0, 3, ((reg_addr >> 1) & 0x6) | (RnW & 0x1));
fields[0].out_value = &out_addr_buf;
fields[0].in_value = NULL;
fields[1].tap = jtag_info->tap;
fields[1].num_bits = 32;
buf_set_u32(out_value_buf, 0, 32, outvalue);
fields[1].out_value = out_value_buf;
fields[1].in_value = NULL;
jtag_add_dr_scan(2, fields, TAP_INVALID);
vs.
jtag_add_dr_scan64(jtag_info->tap, 32+3,
((reg_addr >> 1) & 0x6) | (RnW & 0x1))|
(outvalue<<32)),
TAP_INVALID);
/* allow sending out up to 64 bits */
extern void jtag_add_dr_scan64(jtag_tap_t* tap, int bits, u64 outdata,
tap_state_t endstate);
W.r.t. data scanned in, the current API fares a bit
better as oftentimes only some of the bits scanned in
are needed and then often placed into different
locations and post processing and asynchronous
operation makes the current api a bit better in for
the data in the input direction.
Now... I'm not super keen on this particular implementation / details,
but perhaps it will spark some ideas out there.
--
Ø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
