On Fri, Nov 20, 2009 at 19:05, Øyvind Harboe <oyvind.har...@zylin.com> 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... 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. >> 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. > > The current JTAG calls should be invoked on the interface rather > than assuming a single global instance. This is covered by todo.txt > section today as an architectural improvement. 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. >> 3. Break up jtag_add_dr_scan etc. >> >> This works best in tandem with (2). The general idea is not to pass >> one array of scan fields but to pass them in separate function calls >> (which would mimic, but replace the ones in (1)). To output a 7 bit >> field the caller just hands the value to the function and doesn't >> bother about allocating space. To turn jtag_add_?r_scan inside out >> like this requires its states to be kept somewhere so that >> plausibility checks and bypassing can be done. The local copy of the >> jtag_command_queue would be ideal for that (although it would also >> work by adding even more global variables). The caller then does >> something like this: >> >> jtag_queue_t * q = jq_alloc_queue(); > > I'm very much against *forcing* interfaces to implement a queue > in memory. It should be possible to execute the commands > synchronously. The existance of a queue would make the code > *much* less efficient on embedded devices. Where is the bottleneck in this case? Latency, memory consumption, cpu load or something else? > Did you look at jtag_add_dr_out() which exists today? git format-patch d14b6ca0^...d14b6ca0 Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
