On Sun, Jan 27, 2013 at 3:54 AM, Andreas Fritiofson <[email protected]> wrote: > I didn't really want to get into this discussion as I have lots to say on > the matter, but not very much time to put it into words. There are so many > mails with bits I'd like to reply to so it's hard to get a consistent point > through. I'll just reply to a random mail, because I feel I have to say > something.
Hello Andreas :-) Your voice is very important as you are the author of new MPSSE driver, so you can also propose a better API for the interface :-) > I'm not fond of the idea of cramming an external library into the internal > interfaces of OpenOCD. I simply don't see what business LibSWD has in the > path from target to adapter. Sure a library such as LibSWD may be useful as > a helper library *inside* an adapter driver, to convert high level > operations to bitstreams. That is, for the few adapter types that are able > to use it (ftdi adapters and parport/bitbang, any else?). Your current > patches add LibSWD as a middle layer in OpenOCD, something I've ranted on > before that we should *get rid of* in OpenOCD, not add more. Then get rid of JimTCL as well, libusb, libftdi, etc ;-) >> Current jtag_interface was only using flush() to flush jtag commands >> into the hardware. This made all interfaces jtag-only. Adding >> bitbang/transfer methods makes it possible to implement virtually any >> protocol on the interface. > > > That's a bit narrow-minded. I can think of a bunch of imaginary "protocols" > that cannot be reasonably implemented over that API (any asynchronous > protocol for example, say the ubiquitous UART). And even if SWD happens to > be a match, doesn't make it a suitable API for a SWD adapter (as I've said > before). In other words, just because it's *possible* to implement something > over a certain API doesn't mean that it's a *good* API for that something. > The number of debug protocols in use today are very few, and even fewer of > them are likely to be usable by a open source tool. In that light, it makes > no sense to make the adapter API protocol-agnostic. The pathetic performance > numbers I've seen mentioned *may* be indicative of the unsuitability of the > "lowest-common-denominator" transfer/bitbang API (why design in a > bottleneck?). And here I got disappointed by your way of thinking. I want to create something generic and versatile. You say I am narrow minded and give bad example of what cannot be implemented with transfer (i.e. UART that can be perfectly implemented that way). You only give "thats bad" with no real alternative, I was expecting something a bit more constructive from you... >> I have looked at the new MPSSE driver and it has already everything >> required to work with LibSWD Transport - transport and bitbang. Still >> I dont know how this relates to the jtag_interface. Did you change >> Interface desing? Is there any consistent Interface API in OpenOCD? Is >> it jtag_interface? > > Yes, jtag_interface is the high level interface (adapter) API. But it sucks, > and I'm trying hard to replace it with a better one. Unfortunately, your SWD > work makes it even worse, despite your saying that your changes are > non-invasive. They simply aren't. They may not change the operation of > OpenOCD, but they certainly change (or set precedent for further development > of) the architecture. And I'm not sure I like (or know) the direction it's > heading. What is the change? What is the new design? Where is the specification for a new Interface for OpenOCD? You have cloned some MPSSE commands and made interface for them in OpenOCD, this increases performance and will increase performance for LibSWD as well, but how does that relate to new Interface or Adapter API?? Btw. your approach with flush() given for a specific protocol is the biggest pain of the current OpenOCD design. Interfaces can only flush() jtag. I don't think this is a good solution, its a blocker. > All in all, I think it's crazy to develop yet another SWD solution in the > current architecture (which I've also said before). If the goal is to get > SWD support at any cost you could have used (or built on) any of the other > three (3!) existing implementations: my own (from 2008!) for ft2232, Simon > Qian's for versaloon and finally the ST-Link. Show me "your" implementation from 2008, tell me why its not working yet, why its not in the OpenOCD, why I could not use it back then? Simon's solution needs dedicated interface, ST-Link solution requires dedicated interface. My solution is working, its free, open, and works with any interface. ..and it looks like my time is wasted again Andreas - you did not give even one example on how things could be done better, show how they can work better, give an example of new organization, just complain... :-( 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
