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. > > Thoughts?
Yes. Also: 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 content. 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: http://www.abatron.ch/fileadmin/user_upload/products/pdf/bdiacc.pdf 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 its salt. The cable driver API in OpenOCD is atrocious. Dick _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
