> 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

Reply via email to