On Sun, Jan 27, 2013 at 5:33 PM, Freddie Chopin <[email protected]>wrote:
> W dniu 2013-01-27 17:09, Andreas Fritiofson pisze:
> > Well neither of those are middle-layers. And only Jim is entangled into
> > the inner workings of OpenOCD, the rest are used in peripheral code,
> > i.e. inside the adapter drivers, which is completely fine.
>
> 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.
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.
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.
> > But we don't *need* generic and versatile. We need an API that is strict
> > and to the point and a perfect match for the protocol it's modelling.
> > Resorting to a lowest-common-denominator between SWD and some other
> > imaginary protocol that no-one can yet foresee the use of in a debug
> > environment, completely hides the high level operations emitted from the
> > target, from the code which is talking to hardware to execute them: the
> > adapter driver. This is what I mean by a middle-layer. LibSWD acts as a
> > funnel or filter that converts useful information to a form that is
> > gibberish to all but a certain class of adapters. I want the target code
> > to talk essentially directly to the adapter driver.
>
> Is there any better API for such thing?
Of course there is. SWD defines a number of basic operations, exactly those
should be represented in the API. Now after going through part of the
complete patchset as a whole it seems like the DAP operations already *are*
the API. The organization is better than I thought yesterday. If Tomek had
been clear about that then at least I would have been more willing to
review the changes early. I don't remember a single mail describing the
overall concept and architecture, but instead a lot of the
LibSWD/transfer/bitbang stuff that I'm not very interested in and I don't
agree with. In fact the patch may be importance-wise something like 50%
architecture, 30% generic SWD and 20% LibSWD/transfer/bitbang.
> Most OpenOCD adapters don't have
> any "magic" commands for SWD, so it will be raw GPIO anyway...
>
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.
I don't know for sure any other adapters that provide GPIO access other
than ftdi and parport/direct gpio.
> > 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?
> As a general note - it we would build a list of "wanted features" for
> OpenOCD I guess SWD would be nr 1 for now. That's why I just don't
> understand why noone's interested in implementing that...
>
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.
/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
