The problems seems to be that the when a user queues a JTAG operation, it is encoded as a command. The possible commands are scan, statemove, pathmove, runtest, reset, end_state, and sleep. These commands are used in the generic code to determine whether the state moves are allowed and for generic validation, but then are passed to the drivers. Each driver then has the same block of code that figure out which command is next in the queue, consults a state lookup table for each command, and then does some work to build up the bytes to send to the interface.
If we instead kept all the state handling in the generic JTAG code and the driver model was based around states, much of the duplicated code would go away. The generic code would deal with breaking a command into the appropriate state movements and the driver could be passed an array of JTAG state changes. That still keeps the overall number of function calls to the driver down while making the driver much simpler.
Thoughts? -- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
