I agree with Andreas that we need to define API and organization first, then code in the last place...
Transport is very very good idea and I have used it with my own implementation of the mpsse functions in ft2232 interface, but new mpsse is even better. Transport works, its great idea - see http://repo.or.cz/w/openocd/libswd.git/shortlog/refs/heads/openocd-201106-development-libswd-0.4-release I am still working on the transport part and the SWD on top of the fresh openocd head. In the previous one I just deleted ugly adiv5_swd.c and this solved all problems. But if I did right now it could break existing code/solutions... >From the Transport perspective it is essential to have two generic transport functions on the Interface port, and some additional operations that may help solving problems with the Target: 1. "transfter" that would transfter in/out bytestream on mosi/miso/tdo/tdi lines of the interface from/to char array. This will allow to perform packed transfer operations and it will be faster than sending single bits. This should be "must have" for an interface. 2. "bitbang" that would allow to set/reset/read state of a gpio pin of an interface. If will allow driving port states from TCL but more important switch buffers for half-duplex transports like SWD. This should be "must have" for a interface. 3. Additional list of "Features" registered at runtime that may help transport or target operations. Why 3 is very important: +because it will give transport independence and leave generic interface driver very clean simple and elegant. +because some drivers (like ft2232) cannot do transport on their own, so they need dedicated transport infrastructure (like libswd) to generate and analyze bistream for them, while some other drivers (like versaloon) can do transport on their own far better. I can try out this approach on my fork. I will define "Features" list on the current jtag_driver driver and those features will contain pointers to functions that perform operations on a target (i.e. dp_read) by an Interface. If some transport is selected (i.e. SWD) it will check if Interface have necessary Features and mark to use them if so. These Features will be the interface between Interface - Transport - Target. For Versaloon or other intelligent devices such DP_READ from Target layer will simply pass the call by transport to Feature if an Interface and return the result. In case of FT2232 Tranport layer is essential because it will convert Target DP_READ call intro bistream that will be transported by a "Transfer" and "Bitbang" functions at its base. In short words Interface->Features will be the bridge between Transport and the Interface. In case of intelligent interfaces it will only get information from Target layer and the Features will be defined by the Interface driver itself. In case of dummy drivers Features list will contain functions defined by Tansport to perform desired operations using only two generic Interface's functions "transfer" and "bitbang"... this should solve the current problem between intelligent and dummy drivers that are supposed to run different transports and the same transports in different manner. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
