On Fri, May 8, 2009 at 1:55 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote:
>
>>>>> Did you look at jtag_add_dr_scan_now()  implemenation?
>>>>>
>>>>> It calls jtag_execute_queue_noclear(), so we *can* use stack variables
>>>>> here for in_value.
>>>>>
>>>>>
>>>>>
> This is basically:    jtag_add_dr_scan_now()  == jtag_add_dr_scan +
> jtag_execute_queue , we have that in the cortex code where it is called
> "atomic". Plus reporting the first and not the last error ?? And the API
> has become more difficult to understand.
>
> So every dr_scan with a return value calls execute_queue, not a
> performance problem for parport where roundtrip is more or less
> nonexistent. But for USB roundtrip ??

An out/in scan is still asynchronous and can be built into a
single long scan.

> If we read a memory block of 1k 32 bit words that must be bit or byte
> swapped, what happens then ?

I admit that I have more homework to do on this one than I thought,
but I promise to attend to it and I'm confident that the end result
will be better overall.

If you could point me to the worst example  you can think of where
you believe there will be a lot of extra roundtrips, I'll start
with that one. Ideally this would be backed by profiling...

Perhaps an idea to add a profiling feature to the jtag API where the
jtag_execute_queue() and jtag_xxx_now() sites are mapped out
w.r.t. where they cause the most roundtrip waiting?

-- 
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to