On Wed, Jan 16, 2013 at 5:48 PM, Spencer Oliver <[email protected]> wrote: > I am going through your changes now, i have already mentioned some of > the issues on gerrit. > At minimum we need a rebase, but i am also after a second opinion on > some of the changes, mainly effecting the transport
Transport had to be changed that way and moved into Interface Features to allow both backward compatibility and new designs. TRANSPORT function right now it to find and use proper Interface FEATURES on a selected INTERAFCE to make TARGET communication possible. Interface can define its own ARM DAP FEATURES that works on a high level (HLA?) or can use default ones (i.e. LibSWD for interface that does not provide its own arm dap features but provide Transfer and Bitbang methods)... I think this is simple, elegant and expandable solution. > and additional jtag_interface for swd (ft2232_swd). This is becuase of internals mess - jtag_interface is a global variable that holds the interface configuration, so the name must remain that way for the moment, as the current design hardwires interface and jtag. I have just created separate interface object so existing interfaces can work with no change, while new drivers can utilize ft2232_swd interface object and their own layout (i.e. ktlink_swd). The problem is the layout - if we have one interface, how would we know if layout is for JTAG or SWD? Also the problem is unclear program flow and initialization sequence - for ft2232_swd initialization works, for ft2232 I get core dump because interface initialization want to setup reset on a target (interface?) that does not yet exist... I have tried to tie together jtag_interface into one inteface, but this is not possible at the moment without additional and complex work - if we join those interfaces we need to create additional handlers for interface layout, layout delection, layout verification, and layout deny, probably all interfaces would need to have separate init functions defined. This is not the goal - the goal is to have new functionality with backward compatiblity, this was achieved by creating additional interface. This was the most elegant solution I could think of with no bigger internals reorganization. This is why I want to get into internals reorganization right now... and you can test the SWD functionalities meanwhile :-) Also again I dont want to rebase a lot my commits because that would destroy changes order. I have worked on them for few months to be as clear as possible. Changes are now coherent with the commits timeline. If we start to mess with the timeline, changes will get unclear, things stop working, and I dont want to do that. To start the next step (internals reorganization) I need to have my commits included, which seems delayed. if we get such delays on each commit with reorganization nothing will happen, this is why I prefer to work on a local fork and new branch not to mess with the current relase line... Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
