On Wed, Nov 25, 2009 at 8:54 PM, David Brownell <davi...@pacbell.net> wrote:
> On Friday 20 November 2009, Ųyvind Harboe wrote:
>> > 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.
>
> Today's interface is built around the concept of a queue.

ZY1000 has a hardware queue or FIFO depending on jargon.
The current OpenOCD model allows the queue to be implemented
either in hardware or in software.

Now the most used OpenOCD minidrvier is *dreadfully* inefficient, but
it doesn't have to be that way. It would be perfectly possible to rewrite
the minidriver for driver for the USB dongles to build queues more
along the lines that the zy1000 does.

However do some profiling and you'll discover that it's a red herring.
The only thing that matters on a PC is to reduce the # of roundtrips
for USB. *Possibly* it might be worthwhile to send of USB commands
*asynchronously* to building them. E.g. when doing a DCC upload,
then *nothing* goes out of the USB port until the *entire* DCC sequence
(megabytes possibly) is put together. Admittedly on a PC it probably
takes << 1 sec to create that queue so there is little or nothing to
be gained.


> The thing which permits synchronous execution is having
> that queue be implicit, with a handful of explicit flush
> points called jtag_execute_queue().

As is documented the jtag_execute_queue() command serves
another *crucial* role. It returns an error if any of the jtag_add
commands asynchronous or synchronous caused an error.
All the jtag_add_xxx() commands return void(there is an
exception as always but that may go).

> It might be worth exploring which way to go.  Nothing is
> currently reusing the queues -- it's not possible since
> they are hidden!! -- but as others have pointed out, it'd
> be a win to be able to do that instead of constantly needing
> to reallocat and reinitialize the same command queues.

This is a misunderstanding and a red herring. Look at the
definition of jtag_add_dr_out()(exists and used today)
and jtag_add_dr() in the oharboe/jtag32api branch.

If you have a hardware fifo, then you can be looking at
*two pokes* to execute a  jtag_add_dr_out(). Really!

If you need asynchronous execution, then two
pokes to execute a jtag_add_dr_out() just can't
be beat.  Look at the arguments to jtag_add_dr_out(),
they are variable so there is nothing that can be
"built once" there.


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