I'm interested in your design,
which I suppose can be modified to the FT232BM,
which suffers from the sae problems.

Stef Mientki

jyaron wrote:
> The FTDI system is extremely sensitive and injecting a simple 4vpp 500ns
> transient onto a USB line causes their system to de-enumerate.
> 
> Total cable disconnection and reconnection/re-enumeration is req'd to
> re-establish.
> 
> Their gargabe is not robust at all. I lost thousands of dollars and months
> fixing their sh**.
> 
> I have a galvanic/opto isolation design which is working so far on problem
> hubs (typ. in Dell and Compaq garbage computers) with 5 meter cables in an
> industrial environment.
> 
> I am willing to give anyone interested this design which took me months of
> stress and experimentation to design.
> 
> 
>

I'm interested in your design.
Please email me.

Regards,

John Strupat


"jyaron" <mb1@yashu.com> wrote in message
news:70e1d17a3a96d7a976b97a2981f4b041@localhost.talkaboutelectronicequipment
.com...
> The FTDI system is extremely sensitive and injecting a simple 4vpp 500ns
> transient onto a USB line causes their system to de-enumerate.
>
> Total cable disconnection and reconnection/re-enumeration is req'd to
> re-establish.
>
> Their gargabe is not robust at all. I lost thousands of dollars and months
> fixing their sh**.
>
> I have a galvanic/opto isolation design which is working so far on problem
> hubs (typ. in Dell and Compaq garbage computers) with 5 meter cables in an
> industrial environment.
>
> I am willing to give anyone interested this design which took me months of
> stress and experimentation to design.
>
>
>

<abduln@gmail.com> schrieb im Newsbeitrag
news:1130188954.668299.145130@g49g2000cwa.googlegroups.com...
> Here is the response from FTDI:
>
> The data corruption/missing data will occur because at power up, the
> device connected to FIFO could toggle the RD/WR lines, this causes the
> internal buffer pointers to advance or load garbage data. To
> synchronise the FIFO do something like the following:

Strange, i can't remember any problems with PWREN#. If i remember correctly
i had no pullup on PWREN#.

What i had where multiple edgs on RD/WR while (RESET# == high) and (PWREN#
== high). These where NOT caused by the uC but definitely by the FT245. I
could also see them on the scope with RD/WR floationg and even with
pull-ups to VCC_USB on RD/WR.

If my memory serves me right part of the problem is that RD/WR are
pulled-up (by the FT245) before they are pulled-down because the "pull-down
option" is set in the EEPROM.

You can see it here: http://www.openprog.org/files/oszi/PWREN_RD_1.jpg


From my point of view there are multiple design flaws in the FT245:

- IOs should not be pulled-up until the EEPROM is read and the "pull-down
option" is evaluated.

- IMHO it does not make any sense to power PWREN# from VCC_IO. It would be
much better if VCC_IO could be switched with PWREN#.

- the FIFO should be reset on (or shortly after) the falling edge on
PWREN#.

Bertolt

jyaron wrote:
> I have a galvanic/opto isolation design which is working so far on problem
> hubs (typ. in Dell and Compaq garbage computers) with 5 meter cables in an
> industrial environment.
>
> I am willing to give anyone interested this design which took me months of
> stress and experimentation to design.

I am interested...
Regards
Rocky

The FTDI system is extremely sensitive and injecting a simple 4vpp 500ns
transient onto a USB line causes their system to de-enumerate.

Total cable disconnection and reconnection/re-enumeration is req'd to
re-establish.

Their gargabe is not robust at all. I lost thousands of dollars and months
fixing their sh**.

I have a galvanic/opto isolation design which is working so far on problem
hubs (typ. in Dell and Compaq garbage computers) with 5 meter cables in an
industrial environment.

I am willing to give anyone interested this design which took me months of
stress and experimentation to design.

Here is the response from FTDI:

The data corruption/missing data will occur because at power up, the
device connected to FIFO could toggle the RD/WR lines, this causes the
internal buffer pointers to advance or load garbage data. To
synchronise the FIFO do something like the following:

1)       Send a character repeatedly to the FIFO (say 'A').
2)       The device connected to the FIFO should echo this character
back to the FIFO
3)       When the FIFO starts receiving 'A's it then sends an
'AB'
4)       Again the external device should then echo back the 'AB'
5)       When the FIFO receives the 'AB' your external device is
synchronised with the FIFO.

The synchronisation of the FIFO is particularly needed if the external
device powers up after the FT245 device.

If you can power up the micro before the FT245 or exactly at the same
time you may be able to avoid the problem. Essentially you need to
ensure the RX/WR pins are not toggled when you are not attempting to
read or write data.

"Andreas Hadler" <Andreas.Hadler@t-online.de> wrote in message 
news:rmvml1hkcimj72pqeg14bje88iajab0fp8@4ax.com...
> You've seen Meindert and me mentioning silabs (the artist formerly
> known as cygnal :-)? Their USB/232 worked for me.

That's a serial port interface, and I don't have a serial port.
Seems a pointless bottleneck in my application.

The module I use is a FIFO interface: just hurl bytes at it and use a pair 
of handshake lines, very fast.

K.

"Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote:

>"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote:
>
>[snip FTDI not admitting or fixing hardware]
>
>Thanks for the tip off.
>

>Anybody know any products similar to FTDI USB modules, but without the 
>problems?

You've seen Meindert and me mentioning silabs (the artist formerly
known as cygnal :-)? Their USB/232 worked for me. 

Andreas
-- 

Learn from the mistakes of others. You won't live long enough to make
all of them yourself.

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> wrote:

[snip FTDI not admitting or fixing hardware]

Thanks for the tip off.

I hate it when tech support people fob us off with the usual excuses.

I recall a stepper/servo motor controller chip feature refusing to work, and 
their techies taking weeks to get round to talking to their software guys 
before they confessed they'd run out of ROM and not implemented it. Nobody 
had do

I politely but firmly read them the riot act...

Anyway, on my to do list: add capacitor work-arounds, and look for more 
robust chips.

Anybody know any products similar to FTDI USB modules, but without the 
problems?

TIA, K.