Hello Andreas :-) Thanks for reading the code and your remarks :-)
On Mon, Jan 28, 2013 at 11:46 PM, Andreas Fritiofson <[email protected]> wrote: >> Isn't LibSWD used in peripheral code of ft2232.c only? > > I don't think so, but I've only gone through some of the patches. From what > I can tell, the target (adi_v5) calls through the "features" abstraction to > anything that provides DAP operations. One of those is the LibSWD wrapper > that passes operations to LibSWD which calls back into the wrapper which > forwards the generated bitstream to the ft2232 driver. The driver is > completely unaware of LibSWD or the high level operations that the bitstream > represents. You can say that LibSWD is the perihperal code of an interface driver, or backwards that LibSWD use interface driver to transfer the bitstream. Generic interfaces such as GPIO, FT2232, bitbang, etc, need LibSWD to produce the bitstream. HLA have its own command set to work with a given transport. This is why Interface Features were introduced. If an interface/adapter does not provide its own SWD feature LibSWD features can be used as default. In this particular case those features are the SWJ DAP operations. I think this is clean elegant and functional solution, and i proved its working :-) > The first part, from the target to inside the wrapper looks rather good. > It's pretty close to how my own thoughts about this have been and I can > definitely see how it can be useful. Although I think it can be taken a > great bit further but I suppose Tomek has just done the bare minimum to get > SWD working. The problem with that is when we build on this we're likely to > need to change things quite dramatically and an already merged LibSWD > implementation would be a maintenance burden. Maybe it's time to split the > architectural work into a separate branch. Thanks :-) I have also proposed that, glad we agree. I guess starting a 1.0.0 branch would be the best solution - we will still have relatively stable 0.x.y branch and "new design" 1.x.y branch :-) If we dont want to split/double the work we can release 0.7.y as the last of 0.x.y and bump y as a bugfixes, while all energy goes to make 1.x.y. > What I don't like about the patches is everything on the "other side" of > LibSWD. The design of LibSWD itself I can't say anything about, as I haven't > looked at the code. And I probably won't, because frankly I'm not very > interested in that part. Please list them exactly so I can refer :-) > Without knowing, I'd guess that jlink, rlink, ulink and "most" other "real" > debug adapters, if they support SWD, has SWD specific commands. MPSSE > naturally doesn't have any since it's a generic command set for any serial > synchronous protocol. What I doubt is that "real" debug adapters have raw > GPIO access... I do know that the CMSIS-DAP standard has high level DAP > operation commands, and it lacks GPIO access. Still, this is not a reason to block bitbang functionality for all interfaces because some of them lack it. For generic interfaces such as GPIO, FT2232, bitbang, etc, it is a must have. For HLA that does not support bitbang, bitbanng-based functions simply wont work, thats it. If its about LibSWD then this is not a problem because HLA have their own SWD commands. If its about other funcitonalities, this is obvious that some interfaces are better than others in some specific tasks. We cannot block functionalities for all interfaces because only some of them does not support them, because this way of thinking gives us really basic reduced functionalities, if any at all.. >> > Adding the transfer/bitbang as an interface API doesn't help with SWD >> > for adapter that doesn't provide access to raw GPIO. So we still need a >> > separate API for those. Two separate API's instead of one? No thanks. >> > Perhaps that's why you needed to add the "features" stuff (which may be >> > a good idea for other reasons). >> >> Isn't FTx232 chip an example of interface that provides access to raw >> GPIO? > > Yes, naturally. So? So, as above - we cannot block ft2232 chips because totally another interface does not provide bitbang. If a function needs a bitbang, it looks for a "bitbang" member of a jtag_interface (or any new design) and when there is NULL function aborts with error. This function can be a Feature as well :-) > Because maybe it's *not* that wanted. By developers. Unpaid developers tend > to work on what they want, not what others want. Personally there's a bunch > of improvements I'd rather see in OpenOCD than SWD. I needed the SWD, so I made it, payed and unpayed :-) If you really dont want the SWD and reorganization then I will start my own project, no problem... I just want the situation clear on what and why :-) My work on LibSWD was an early stage research at first, then I decided to finish it on my own, I have learned a lot meanwhile and this is the only gain for me from this project. If I wanted one-day result I would have simply bought commercial interface and this is what I did at some stage ;-) Starting new project and learning new things is enough motivation for me because I know what I want to do and how, maybe someone will join to help eventually. Some things go too slow for me and I am really tired of that overall. It is really important to have a working result first and then improve efficiency, when that result is well designed then further development is fairly easy. Still results are that thing that counts, this is what I started to understand :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ------------------------------------------------------------------------------ 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
