On Monday 28 December 2009, Austin, Alex wrote:
The refactor is not to support our patch, just to clean up the ft2232
driver. My comment is in response to something that was said should
probably be done anyway, not specifically to support our device. I
think support for our device could be
On Tuesday 29 December 2009, Laurent Gauch wrote:
The idea of the JTAG and Debug port over FT2232 as with the Amontec
JTAGkey ( now JTAGkey-2, in 2010 JTAGkey-3 ),
So on Friday (2010!) we'll be hearing all about JTAGkey-3! ;)
is to use one port for
JTAG / RTCK / TRST / RESET signal /
-Original Message-
From: David Brownell [mailto:davi...@pacbell.net]
Sent: Wednesday, December 30, 2009 3:17 PM
To: Laurent Gauch
Cc: openocd-development@lists.berlios.de; Austin, Alex
Subject: Re: [Openocd-development] [patch/rfc] Add support for
multiple-ports on FT4232H
On Wednesday 30 December 2009, Austin, Alex wrote:
Would it hurt too much to start out creating a library that wraps
either libftd2xx or libftdi depending on configuration and exposes
the same interface either way?
I suspect it would, but I've not looked at that issue.
On the other hand,
@lists.berlios.de
Subject: Re: [Openocd-development] [patch/rfc] Add support for
multiple-ports on FT4232H
I could probably do this, but supporting the 4232 is time I can bill
to
my company, while driver refactoring is not (yet).
Why should the community take on cleanup
: [Openocd-development] [patch/rfc] Add support for
multiple-ports on FT4232H
I could probably do this, but supporting the 4232 is time I can bill
to
my company, while driver refactoring is not (yet).
Why should the community take on cleanup and refactoring work
to support your company's
The refactor is not to support our patch, just to clean up the ft2232
driver. My comment is in response to something that was said should
probably be done anyway, not specifically to support our device. I
think support for our device could be done without said refactor, but
the code would be
/ -Original Message-
// From: openocd-development-bounces at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[mailto:openocd-
// development-bounces at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development] On Behalf Of
On Wednesday 23 December 2009, Laurent Gauch wrote:
For All:
DO NOT ACCEPT TO CHANGE FT2232.c for mixed channels.
So his RFC plot was successful. :)
For Alex :
PLEASE CREATE A NEW DRIVER !
Hmm, maybe splitting the ft2232.c code into more manageable
chunks would suffice? That's a mess
On Wednesday 23 December 2009, Laurent Gauch wrote:
On Tuesday 22 December 2009, Alex Austin wrote:
I doubt this is the right way to do things, but it hasn't broken
anything yet. This is just providing framework support for an adapter
with reset lines driven by BDBUS instead of ACBUS.
I
I could probably do this, but supporting the 4232 is time I can bill to
my company, while driver refactoring is not (yet).
Why should the community take on cleanup and refactoring work
to support your company's patch?
You may have a tiny problem explaining the community why they
should accept
11 matches
Mail list logo
