Rick Altherr wrote:
> Now that I've read through code for all the JTAG interface drivers
> (including the 2 new ones), it seems that every single driver does
> mass duplication of the JTAG state machine handling. The state
> machine is defined as part of the JTAG standard (although it does
> allow for extension) and all of the uses in the driver seem to be due
> to the driver interface rather than the driver doing something unique.
> 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.
The queuing of commands is awkwardly done. UrJTAG is reworking the API
at this time also, but their starting point is far cleaner than
OpenOCD's. So even with a better cable driver API, they are not
I suggest working in proposal form rather than in code modification
mode, and share that proposal document with UrJTAG and see if a
consensus can be reached. Then the drivers can be shared at that
point between the two projects. A simple *.h file that has doxygen
compatible comments would be a fine document to embody a proposed new
cable driver API.
See this document:
All we need is functionality similar to BDI_DoJtag() in the PDF above.
If there was a driver API like that, then the other stuff can be written
on top of that, in any language. I would personally be doing a swig
layer to *in process* Python ASAP if there was a cable driver API worth
The cable driver API in OpenOCD is atrocious.