On Tuesday 23 February 2010, Laurent Gauch wrote:
> I think you are confusing the notion of Interface, Layout and Channel.
Don't mis-attribute that confusion... isn't it FTDIchip.com which
produces products where each "channel" has it own "USB interface"?
And thus the libftdi header, "ftdi.h" has these definitions:
enum ftdi_interface
{
INTERFACE_ANY = 0,
INTERFACE_A = 1,
INTERFACE_B = 2,
INTERFACE_C = 3,
INTERFACE_D = 4
};
int ftdi_set_interface(struct ftdi_context *ftdi, enum ftdi_interface
interface);
I understand it's MS-Windows which introduced the "A", "B" ... notation
for these USB interfaces; USB itself uses numbers there.
Agreed that if I were defining those C programming interfaces, I would
use the term "channel" there, to match FTDIchip.com documentation. But
on the other hand, since there's a one-to-one correspondence between the
USB interfaces and channels, I don't see any confusion beyond wanting to
know how to get at what the FT4232 docs refer to as "Channel C", in a
programming interface that doesn't mention channels anywhere.
I took a look at a recent version of the proprietary D2XX interface,
and its header doesn't expose a distinct notion of "channel" either.
Looks like maybe it's coupled to USB interfaces too, but there was
no (programming) interface which referenced USB interfaces either.
> The Layout defines how a Channel is used.
To be more precise, it defines how "Channel A" is
used, not how "a channel" is used. THere's no good
model of "channel" in that code, in the sense that
channels can be switched.
But that's the problem which is being addresssed by this patch.
It's decoupling that inappropriately tight coupling, so that
other channels (packaged as distinct USB interfaces) can be used
to construct what OpenOCD calls (confusingly) a JTAG Interface
without a needless requirement for different methods.
That is, there are two facets of the notion "layout":
* At a hardware level ... routing a bunch of signals from some
particular FTx232 "channel" to serve specific logical roles.
Inside OpenOCD, this knowledge is embadded in procedures.
* From Tcl config scripts ... that a specific combination of
FTx232 "channel" plus signal routing is used.
Without this patch, those two distinct facets of the concept
are always jammed together, even when the hardware has made a
clean distinction between them.
> The FT2232 C D and FT2232 H provides two Channels, each Channel can be
> opened separately and can receive their own handle (ID).
Agreed those would better be named "channel", not "interface" the way
the current libftdi does.
And maybe the new struct member should call it "channel" too, to match
the hardware documentation. Even if it would sometimes need to be
initialized with symbols like "INTERFACE_B" and such.
> The selection of the Channel A or Channel B MUST not be defined in the
> layout structure-> you could use the same layout on channel A and B.
> Amontec is working on an new Amontec JTAG key using two JTAG interfaces,
> one JTAG interface on Channel A and one JTAG interface on Channel B for
> an internal FPGA configuration!
Come to think of it ... "interface" is one of those words which is
worth avoiding outside of *very* carefully defined contexts, all of
which are prefixed by an adjective.
For example, is one talking about a "USB Interface"? Or a interface
in some particular programming language? (How about in languages
with an interface construct that uses "interface" as a keyword that
flags one particular flavor of interface?) How about a hardware
interface? USB is an interface technology. Systems can have many
USB ports, and sometimes distinct "USB interface" abstractions.
Those ports can be connected to products from different vendors, all
of which implement the same functional interface. Need I go on???
> For the selection of Channel A or Channel B, you have to modify your
> specific Open /. Init functions and NOT the layout definition ;-)
> Modifying the Layout definition for Channel selection will make a lot of
> confusions !
Call it "channel" in the struct ... sure.
But did you notice how the two "JTAG Interfaces" defined in this
patch series do in fact use the same signal layout with two different
channels (A and B)?
This patch is specifically about ensuring that the same open/init
logic can be reused ... letting that facet of a "JTAG interface"
be clearly distinguished from the notion used in Tcl scripts to
distinguish different physical products.
- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
