On Sat, Nov 21, 2009 at 2:09 PM, Michael Schwingen
<[email protected]> wrote:
> Øyvind Harboe wrote:
>>> 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.
>>
> Hm. I do not have a complete view of the proposed API, but does it
> really *force* you to implement a queue?

The important point is that the queuing of JTAG commands
can be done in hardware today, with no overhead.

We want to keep the actual queue implementation something
completely internal to the interface implementations.



-- 
Ø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

Reply via email to