Hi,
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.
On Sat, Jan 26, 2013 at 11:45 PM, CeDeROM <[email protected]> wrote:
> On Sat, Jan 26, 2013 at 11:25 PM, CeDeROM <[email protected]> wrote:
> > Integration part on the OpenOCD side is really small and simple (but
> > smart I guess) - AP/DP Reads/Writes are calling LibSWD routines when
> > SWD Transport is selected. When JTAG Transport is selected everything
> > happens as before. LibSWD use Interface Transfer/Bitbang routines to
> > manipulate electricity. I have additionally packed all ARM_DAP calls
> > into Interface Feature, so Interface can use different Features to
> > perform JTAG, SWD-LibSWD or its own SWD, or other tricks.
>
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.
>
> This is possible because ARM Target was already using separate DP/AP
> READ/WRITE functions. So it was necessary to swap the calls depending
> on the transport and create calls that will talk swd. Also generic
> bitbang/transfer needs to be implemented on the interface. Any
> interface that provides transfer/bitbang methods shall be able to talk
> swd using libswd.
>
> 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?).
>
> 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.
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. Neither solves the
architectural problems coming from adding a separate protocol to the
jtag-centric core of OpenOCD. Your arguments that goes "but it couldn't be
done better the way OpenOCD works today" is a clear indicator that you've
done things in the wrong order. Nothing wrong with that, you work with what
you get the most out of. But your attitude of "merge this as it is so I can
continue, I won't change it" makes it a waste of time, because that won't
happen. In any case, it's a better waste of time than watching TV.
As it looks now, you seem to have patched up the architecture where needed
to force in LibSWD. And in order to merge your SWD work, we'll also have to
accept those architectural decisions that you've made without discussion,
thereby stifling other efforts in the area.
/Andreas
------------------------------------------------------------------------------
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
