Hello Gary :-) On Tue, Aug 23, 2011 at 3:43 PM, Gary Carlson <gcarl...@carlson-minot.com> wrote: > I think the solution with high-level interfaces is to allow them to do their > bitstream magic directly if they have that capability and for low-level > interfaces turn to libswd or other future libraries for other transports. I > have doubts about the feasibility of trying to make most high-level > interfaces behave like low-level devices. This would most certainly be a > problem for jlink and I suspect for others as well. Personally I think that > path is a non-starter.
Sure thing this is why asked you what API design would fit best the high-level interfaces still to be common to low-level interfaces :-) Also think that using low-level libraries on high-level interface will allow to use transports that this interface does not support :-) This is why I created transfer and bitbang, but they are only implemented for FT2232 at the moment, I want to work out the RLink but I am critically overloaded with work so I will get to that probably in October :-) > Ideally from my perspective the best solution would be to have each dongle > -- regardless of the manufacturer -- behave like a high-level device at the > OpenOCD driver level using a common unified API that enumerates what > capabilities it supports but leaving each driver to decide how to handle > "bit-blasting" activities under the hood. In the case of a high-level > device like jlink, most of the driver code would provide pass-thru + > necessary glue logic (pretty much what it does now). For low-level devices, > this could call on existing libraries like libswd or even new ones for > future transports. At the moment there was only jtag_interface structure that had execute() function performing data flush from jtag command queue into hardware in a manner specific to a hardware. This is jtag only and leaves no other option for other transports except we create execite_jtag() execute_swd() and other functions that will flush data from transport specific queue. This would result in having separate subsystem for each transport, which is messy, and that was the reason I have created generic transport and bitbang functions that can be used by any transport or tcl function. Each interface should have this implemented anyway. This way we only need to create small module for transport that would act as bridge between openocd_target and hardware_target. > The question is how to do this without making a mess in existing code > currently heavily-invested in jtag. I think whatever the API looks like > needs to maintain backward compatibility with the existing approach by > either providing a superset-based API or alternatively support both a legacy > and advanced API. See above :-) I try to be as less invasive as possible but the current design is already messy and not easily extensible :-P The OpenOCD needs general restructurization and cleanup by diviging code into clean modules using common API you are right. I have given this task some months but it was too much work so I suspended it, I can take care of it after SWD if working because this is my main goal at the moment :-) We should use one common context and divide code into modules responsible for specific tasks like interface, transport, target, flash, cpu, os, core, etc. Now all this seems to be put in one place, so it needs really dedicated piece of work :-) > Since you have spent a lot more time thinking about this then I have, what > is your ideal API scheme in light of the various realities mentioned above? > I haven't fiddled in the bowels of OpenOCD much outside the driver level so > my ideas may have other problems when tested against reality. The transfer and bitbang allows some basic routines to work on the bus between interface and target DAP/TAP therefore I think all interfaces should have this obligatory, maybe not efficient (i.e. one bit per command, or no bitbang at all if interface sets directions automaticaly), but this would allow some fallback into working solution with all future OpenOCD functionalities, not only limited to those provided by interface logic/commandset. This dedicated functionalities would be interface specific and will provide superior efficiency compared to this generic stuff of course. I would have to take a look at example command set of high-level interface command set, maybe there is some tutorial on this? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
