Patrick Wieland wrote:
>> The ftdi-2232-H monitors the RTCK signal on GPIOL4
If you find this pin, its okay. On design I use GPIOL3 ;) The PCB of the
OOCDLink with RTCK support is laying in front of me, but I ran out of
FT2232Hs to assemble it, so I have to wait until I get the ic from the
dis
* autodetection if FS or HS device attachted -> adapt tck max
* enable adaptive clocking if HS device attached and jtag_khz = 0 in cfg (not
tested yet)
Note:
The HS devices are currently only support by the drivers from FTDI and not
from the libftdi. So using libftdi and RTCK support will cause
adds the oocdlink.cfg to target/interface
Index: src/target/interface/oocdlink.cfg
===
--- src/target/interface/oocdlink.cfg (Revision 0)
+++ src/target/interface/oocdlink.cfg (Revision 0)
@@ -0,0 +1,6 @@
+#interface
+interface ft2232
Holger Schurig wrote:
> For example, my Olimex ARM-USB-TINY has ftdic.type == 2 and
> ftdi_read_chipid() == 0xa5abd789.
Okay, they use different number for the chip in the libftdi. I looked
into the git repo and it seems that they do not have support for the new
FTDI devices at the moment.
Joe
Rick Altherr wrote:
> You should be able to handle this like all the other chips that have
> RTCK. They use 'jtag_khz 0'.
I think I need to buy new glasses ;) Thanks for this hint, I saw what
you meant and did it that way.
> form of intelligence in the driver about what device it is talking t
Hi at all,
I'm currently planning the support for the FTDI FT2232H and FT4232H with
OpenOCD. They have some new features and I would like to have some
comments for the implementation.
There are two main features:
- Adaptive Clocking: For this feature I would like to introduce a new
paramete
Pieter Conradie wrote:
> I would also suggest to anyone that designs a new generation FTDI based
> interface that a target voltage monitor be added (a simple comparator may do)
> to report if the target is switched off/not powered, before attempting JTAG
> comms.
I'm currently do that job. The
