I would suggest removing the fields completely from that layer and replacing them with function calls. For the most common types of data like uint32_t.
scan_start_dr(); scan_tap(struct jtag_tap); scan_field_u32_w(size_t bits, uint32_t value); scan_field_u32_wr(size_t bits, uint32_t value, uint32_t * result); scan_field_buf_w(size_t bits, const void * buf); ... scan_end(); jtag_execute_queue(); etc. The layer below takes all these neatly constructed and allocated fields and copies them anyway. You'd have to switch from an array of fields to a linked list internally, but overall the code would be cleaner. Michael On Tue, Nov 17, 2009 at 22:01, Øyvind Harboe <[email protected]> wrote: > I'm pondering how we could gently in a series of > non-breaking patches prepare the ground for switching from > 8 to 32 bit words in the jtag_add_xxx API. > > The attached patch gets rid of buf_set_u32() when setting > the value of a byte. > > This achieves two things: the code is less obtuse and it > is more evident how we could introduce a new type > that is *currently* uint8_t and later on could be increased to > uint32_t or wider, for the out_value/in_value bit vectors. > > Comments? Protests? > > > > -- > Øyvind Harboe > http://www.zylin.com/zy1000.html > ARM7 ARM9 ARM11 XScale Cortex > JTAG debugger and flash programmer > > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
