Øyvind Harboe wrote: >> 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. > Hm. I do not have a complete view of the proposed API, but does it really *force* you to implement a queue?
It looks to me you only have to have a queue structure, which is used to hold state across multiple calls (maybe it should have a different name?). You don't *have* to queue the commands, right? So if you have a hardware queue, the queue struct may be mostly unused by your interface implementation, and every add_... call simply stashes the arguments into your hardware queue. Please correct me if I overlooked something (which is entirely possible). cu Michael _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
