On Fri, Nov 20, 2009 at 10:43 PM, Michael Bruck <[email protected]> wrote: > On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe <[email protected]> wrote: >>> Just to clarify the whole issue once more, my proposal was actually >>> three different things: >>> >>> 1. Making the use of scan_field safer by providing standard handlers >>> for the most common cases. >>> >>> This not only helps with the readability and reduces trivial >>> copy&paste errors. It also makes it much simpler to rewire the >>> underlying scan_field in a later step. >> >> We can relatively easily do away with the scanfields entirely >> rather than putting lipstick on it... See the branch I was working on >> or jtag_add_dr_out() API for which I'm looking into adding a in_value >> as well as the existing "out_value" that it takes today. > > This still uses an array that needs to be initialized. Your own > embeddedice example patch didn't make use of it...
The example on my harddrive that has been put to pasture makes use of it :-) > And by adding out_value the caller is forced to hold all data in > uint32_t. My suggestion was intended to make (almost) all data types > first class citizens, not just choosing one that is the most commonly > used. The thing that "forces" the users to use 32 bit is the fact that the *target* is 32 bit. It doesn't matter what word size the OpenOCD host CPU is using in the approach I'm suggesting. It works equally well with any *target* word size. > These are two things. The global JTAG device instance and the global > command sequence. The TODO is specific on the device instances, but > not on command queues. The whole point is that whether or not that there *is* an actual command sequence is something that it is up to the interface to implement. Today the interface has that freedom. By exposing the queue explicitly in the calling API you remove the ability to the interface to drop the implementation of a queue. The current JTAG API allows for a hardware queue, which is super efficient. > Where is the bottleneck in this case? Latency, memory consumption, cpu > load or something else? The *current* jtag_add_dr_out() implementation breaks down to *two pokes* if you have a hardware JTAG queue. *Anything* you add on top of that is going to increase performance overhead siginficantly :-) To get a sense of perspective, a single malloc() is orders of magnitude more work that a synchronous jtag_add_dr_out() w/a hardware queue. I've profiled this extensively, so it's no coincidence that I ended up with the particular jtag_add_dr_out() syntax. Notice that the first argument is a constant so with GCC's constant forward propagation, jtag_add_dr_out() really *can* boil down to poking two hardware registers... >> Did you look at jtag_add_dr_out() which exists today? > > git format-patch d14b6ca0^...d14b6ca0 I don't know what you mean by the above against which repository. -- Ø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
