On Fri, May 8, 2009 at 2:18 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > Here is my last comment for tonight, promise :) > > Before we had a setup where it was possible to use inhandlers, or to not > use inhadlers and place the corresponding logic in the upper layer. > > Now inhandlers are supposed to be bad, it is dictated that inhandlers > are bad. I know about the potentioal problems for out of scope > variables, but that happens with all asynchronous code. That is never > problem free. And USB interfaces are asynchronous, and distributed > systems even more so. > > One example is that should realy show this is to read a big block of > chars in cortex-m3 code, that is to call the > arm_adi_v5.c;mem_ap_read_buf_packed_u8 with a big block of data. > > Another one (I think) is reading all core registers on ARM7/9, here we > do 16 in scans of a bitreversed scanchain. So this can definetly > affect single stepping with a USB interface.
W.r.t. performance the first order of the day is to profile. Could you get me some numbers about the above? For the sake of argument: if 16 roundtrips was the total # of roundtrips for a step, then I'd have to see real world numbers before I believed that that was observable. I'm pretty confident that the new scheme + a tad of profiling will on the roundtrip problem will yield *better* performance than before. -- Ø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
