On Mon, Jan 28, 2013 at 7:03 PM, Tomek CEDRO <[email protected]> wrote: > We have two choices now I guess: > > 1. Add my commits and mark ft2232 obsolete, then make last release of the > 0.x.y series and start working on 1.x.y series, where is no ft2232 driver > and we have Adapter layer implemented as well as others internals > reorganization. This gives a working solution to the people straight away. > We put a thick line on the past and set course for future. This must happen > one day, why not today. I prefer this approach and suggest this all the > time. > > 2. We reject/waste all my current work on swd and continue to work on 0.x.y. > I will work directly on modification of Adapter layer, interface and > transport to fix the internals and the additional outcome would be the swd > transport working. This will not give working solution to the users for next > few months or years, a lot more commits will show up than I have now > proposed, lots of them will be a regression for some time. Patches should be > sent directly to gerrit rather than on be worked on a separate fork until > goal is achieved. You seem to prefer this one..? >
I tried to stay clear of this discussion since I am not an expert in terms of the OpenOCD internals and your libswd codes. But just my two cents here. I think both of your two proposal are not that practical in the near future. My suggestion: 1) Let Spen finishes his work on re-organizing your patches and let is be a testing branch of OpenOCD. It will add libswd as the middle man. Freddie can choose to publish the code snapshots and Windows binary for this branch so that more people can use it. 2) Have a more though discussions on how to improve the architecture of OpenOCD to deal with more transport mechanism (JTAG, SWD, etc), how to re-organize the codes, etc. Don't start your efforts without some consensus from other contributors, I think you now know that code drop usually does not work for open source projects like OpenOCD. >From what I read, I tend to agree some of Andreas' points. 1) libswd as a middle layer : I tend to agree that it is better to avoid this if possible. 2) I tend to think maybe it is easier to get swd patches working and accepted into the main line if you touch on the specific adapters which supports SWD, eg, FT2232 based, J-Link, Versaloon, etc. Portions of your libswd codes can be used as a starting point for the adapter drivers to help SWD work. If it can be abstracted into a common header file, that would be helpful. But as a middle man between the target and adapter, I feel it is too intrusive and may take a long time to get accepted (if ever). -- Xiaofan ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
