> Just to clarify the whole issue once more, my proposal was actually > three different things:
These seem like good directions to explore. I'll suggest the post-0.4.0 development cycle (January++) as a good time to have mergeable code that starts reworking any of this stuff. I don't think 0.4.0 is appropriate for this type of changes, since the relevant issues aren't fully understood and I can't see having those discussions backed by stable code before the expected RC1 code freeze (in under a month). > 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. ... this part might, however, be a thing that could start phasing in sooner. > 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. > > The advantage here is a cleaner modular approach. For example this > makes scripting complex JTAG sequences possible without worrying about > interference from polling. In theory this also allows for the use of > multiple JTAG interfaces. With this approach it is also possible to > offer an asynchronous jtag execution mode (if someone needs such a > nightmare). This calls for a kind of flag day. If it's agreed to be a good thing, having that ready to merge once the next merge window opens seems like it'd be a good strategy: there's enough time between now and then to develop and stabilize most of that code. Øyvind would for example want to make sure he can create queues that are optimized for his the Zylin hardware... Re asynch ... we're in userspace, so the model should be "threads". And the background polling might better be modeled as threads than through a timer interrupt. But that brings in portability problems. - Dave > 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(); > > jq_statemove(q, TAP_IDLE); /* This is just a placeholder for a good > solution to deal with the fact that the initial TAP state is not known > until jq_execute(). */ > > jq_set_tap(q, my_tap); /* set the tap to be implied by the following > functions, until the next jq_set_tap() */ > > jq_ir_scan_start(q); > > jq_field_u32_out(q, 5, some_instruction); > > jq_dr_scan_start(q); > > jq_field_u32_out(q, 7, my_value); > jq_field_u32_outin(q, 3, another_value, &return_value); > > > jq_execute(q); /* callee frees q and associated data */ > > > > Michael > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
