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