> Just to clarify the whole issue once more, my proposal was actually > three different things: > > 1. Making the use of scan_field safer by providing standard handlers > for the most common cases. > > This not only helps with the readability and reduces trivial > copy&paste errors. It also makes it much simpler to rewire the > underlying scan_field in a later step.
We can relatively easily do away with the scanfields entirely rather than putting lipstick on it... See the branch I was working on or jtag_add_dr_out() API for which I'm looking into adding a in_value as well as the existing "out_value" that it takes today. > 2. Eliminating the global variable jtag_command_queue. > > The existing jtag_add_... commands would remain similar but would > operate on a local copy of the queue. jtag_execute_queue then receives > the pointer to that local copy as parameter instead of using > jtag_command_queue. The last user then disposes of the command queue. This assumes that there is a queue at all. It should be up to the interface to implement a queue if that is what is needed. The current JTAG calls should be invoked on the interface rather than assuming a single global instance. This is covered by todo.txt section today as an architectural improvement. > 3. Break up jtag_add_dr_scan etc. > > This works best in tandem with (2). The general idea is not to pass > one array of scan fields but to pass them in separate function calls > (which would mimic, but replace the ones in (1)). To output a 7 bit > field the caller just hands the value to the function and doesn't > bother about allocating space. To turn jtag_add_?r_scan inside out > like this requires its states to be kept somewhere so that > plausibility checks and bypassing can be done. The local copy of the > jtag_command_queue would be ideal for that (although it would also > work by adding even more global variables). The caller then does > something like this: > > jtag_queue_t * q = jq_alloc_queue(); I'm very much against *forcing* interfaces to implement a queue in memory. It should be possible to execute the commands synchronously. The existance of a queue would make the code *much* less efficient on embedded devices. Did you look at jtag_add_dr_out() which exists today? -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development