Ø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. > > The following code is using u8 arrays: > > scan_field_t fields[2]; > > u32 instruction; > u8 instruction_buf = instruction; > > buf_set_u32(out_buf, 0, 32, flip_u32(out, 32)); > > fields[0].tap = jtag_info->tap; > fields[0].num_bits = 1; > fields[0].out_value = &instruction_buf; > fields[0].in_value = NULL; > > fields[1].tap = jtag_info->tap; > fields[1].num_bits = 32; > fields[1].out_value = out_buf; > fields[1].in_value = NULL; > > jtag_add_dr_scan(2, fields, TAP_INVALID); > > 32 bit version: > > scan_field_t32 fields[2]; > > fields[0].num_bits = 1; > fields[0].out_value = &instruction; > fields[0].in_value = NULL; > > fields[1].num_bits = 32; > u32 tmp2=flip_u32(out, 32) > fields[1].out_value = tmp2; > fields[1].in_value = NULL; > > /* this API supports only a single tap, which covers all(?) > jtag_add_dr_scan()'s today. */ > jtag_add_dr_scan32(jtag_info->tap, 2, fields, TAP_INVALID); > > > The second one here is a little bit more straightforward... No > mysterious messing about u8 arrays.... > > > The idea behind the the u8 * and buf stuff is to handle host endianness.
I cannot really see the need. Yes it takes a little while to learn, but any work where you stuff bits into the drscan chain needs a lot of careful consideration. The present way of doing this is clear, not very difficult to understand so what IS the problem ? Regards Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
