FTDI ft232rl - mehrere Chips an einem Bus

[Simon T. (narfinus)]

Hallo zusammen,

ich würde gern eure Meinung zu meiner geplanten Umsetzung einer PCB 
hören.

Ausgangslage:
Ein Kollege möchte seine entwickelten Alogithmen am PC mit denen auf 
einer Embedded-Plattform laufenden vergleichen. Da ein kompletter 
Durchlauf auf der mehrere Tage dauern würde, soll parallelisiert werden.

Der erste Ansatz war/ist die Verwendung von 8 Nucleo-Boards und alles 
über UART<->USB Kabel mit dem PC verbunden.
Der gesamte Aufbau wäre jedoch deutlich sauberer (und günstiger) wenn 
einfach eine eigene Platine mit 8 Controllern und FTDI-Chips verwendet 
werden würde.

Mein Ansatz ist nun folgender:
- Eine Platine im Europaformat mit
   - 8x STM32H7
   - 8x FTDI FT232
   - 1x USB A Buchse an Rückseite
   - Stromversorgung über Hohlstecker an Rückseite
   - Ein paar Status-LEDs an Frontseite
   - JTAG-Interface Abgriff an Frontseite (Daisy-Chaining)
- Einbau in ein Metallgehäuse für Europaplatinen

Fragen zum FTDI-Chip:

- Verhält der rohe Chip sich äquivalent zu den TTL-Kabeln?
https://de.farnell.com/ftdi/ttl-232r-3v3/kabel-usb-ttl-pegel-seriell-umsetzung/dp/1329311
Die nötigen Treiber scheinen dieselben zu sein.

- Können alle 8 Chips gleichzeitig booten ohne das der Windows-Treiber 
Probleme bei der Erkennung bekommt?

- Der FT232RL hat die Terminierungs-Widerstände integriert. Könnte man 
trotzdem diese 8 Teilnehmer "in Serie" routen. Ein sternförmiger Abgang 
von der USB-Buchse scheint mir schwierig umzusetzen zu sein. Leider 
finde ich in der Literatur keine Angaben zum Thema USB-Routing bei 
mehreren Teilnehmern auf einer PCB.

Danke und Gruß

[Michael R. (mr-action)]

Zum letzten: Du brauchst einen USB Hub auf deiner Platine...

[Mike R. (thesealion)]

Ist USB nicht nur eine 1 zu 1 Verbindung?

Wenn du mehrere Chips an den Bus anschließen willst musst du über einen 
HUB gehen (oder einen FTDI Chips mit mehreren RS232 Interfaces)

[Sebastian R. (sebastian_r569)]

In den Kabeln ist auch nur der Chip.

USB ist ein Point-to-Point-Bus, also maximal ein Teilnehmer pro Bus, 
dementsprechend muss ein USB-Hub dazwischen.

Wie parallel muss es sein? Bzw. wie schnell braucht es die Daten?

Ich würde fast dazu tendieren, die UART-Seite mit Schieberegistern auf 
die 8 Boards zu verteilen. Der FT232 hat ein paar GPIOs, die man dazu 
verwenden kann, die Schieberegister für Rx und Tx weiterzuschalten.

[Rufus Τ. F. (rufus)]

Statt acht FT232 könnte man auch vier FT4232 verwenden, dann braucht man 
nur noch zwei USB-Host-Ports.

[fchk (Gast)]

Rufus Τ. F. schrieb:
> Statt acht FT232 könnte man auch vier FT4232 verwenden, dann braucht man
> nur noch zwei USB-Host-Ports.

s/vier/zwei/

Jeder FT4232H hat 4 UARTs.

Als USB-Hub nimmst Du z.B. den hier:
https://www.microchip.com/wwwproducts/en/USB82512

[Mike R. (thesealion)]

Oder einen zusätzlichen STM32H7 und mit dem 8 virtuelle Comports per USB 
erstellen.
(einige dann in Hardware und den Rest in Software realisiert)

[Rufus Τ. F. (rufus)]

fchk schrieb:
> s/vier/zwei/

War gemeint, irgendwas hat mich da gerade abgelenkt.

[Simon T. (narfinus)]

Oh man, danke euch für den Hinweis:

Da sucht man ewig nach Infos für mehrere Teilnehmer und übersieht das 
USB eh Ende-Zu-Ende ist.

Klassisches Baum-Wald-Phänomen :)

Bezüglich verschiedener USB-Lösungen:
Die Anforderung ist, dass nacher auf Windows-Seite 8 COMPORTs existieren 
die jeweils von einer Instanz eines Python-Scriptes angesprochen werden.
Verstehe ich richtig das der FT4232H zwar 4 UARTs bietet, allerdings 
alle über das selbe Terminal angesprochen werden?

Einen extra Transceiver-µC möchte ich nicht einsetzen, das ganze sollte 
ohne extra Software auskommen.


Danke für die Infos

[Rufus Τ. F. (rufus)]

Simon T. schrieb:
> Verstehe ich richtig das der FT4232H zwar 4 UARTs bietet, allerdings
> alle über das selbe Terminal angesprochen werden?

Nein. Das sind vier UARTs, die mit dem normalen Devicetreiber vier 
virtuelle Schnittstellen auf dem Host-Betriebssystem bilden - praktisch 
identisch zu Deiner ursprünglichen Acht-FT232-Lösung.

Unterschiede sind a) der deutlich reduzierte Bauteilaufwand und b) die 
Reihenfolge der Enumeration durch den Devicetreiber, aber das ist 
relativ unwichtig.

Wobei: Was ist für Dich "Terminal"? Dieser Begriff hat so viele 
Bedeutungen, daß ich jetzt einfach mal eine mögliche angenommen habe 
(ein Terminalemulationsprogramm auf Deinem PC).

[Niklas G. (erlkoenig)]

Implementiere doch auf allen STM32 ein USB Device und verbinde diese 
über einen USB-Hub mit dem PC. Das macht vieles einfacher/solider.

Mike R. schrieb:
> Oder einen zusätzlichen STM32H7 und mit dem 8 virtuelle Comports per USB
> erstellen.
Man braucht bei CDC-ACM pro virtuellem Port 3 USB-Endpoints (2x IN, 1x 
OUT). Man muss prüfen ob der Controller genug hat! ggf. macht man es 
ohne CDC-ACM und überträgt die Daten anders aufgeteilt.

Simon T. schrieb:
> Ein Kollege möchte seine entwickelten Alogithmen am PC mit denen auf
> einer Embedded-Plattform laufenden vergleichen

Wie wärs mit qemu o.ä.?

[Simon T. (narfinus)]

Rufus Τ. F. schrieb:
> Nein. Das sind vier UARTs, die mit dem normalen Devicetreiber vier
> virtuelle Schnittstellen auf dem Host-Betriebssystem bilden - praktisch
> identisch zu Deiner ursprünglichen Acht-FT232-Lösung.
>
> Unterschiede sind a) der deutlich reduzierte Bauteilaufwand und b) die
> Reihenfolge der Enumeration durch den Devicetreiber, aber das ist
> relativ unwichtig.
>
> Wobei: Was ist für Dich "Terminal"? Dieser Begriff hat so viele
> Bedeutungen, daß ich jetzt einfach mal eine mögliche angenommen habe
> (ein Terminalemulationsprogramm auf Deinem PC).

Das hört sich gut an. Den FT4232H hatte ich wegen meines Denkfehlers 
bisher ausgeschlossen. Und deine Annahme zum Begriff Terminal is 
vollkommen richtig ;)


Ich hab mal mein aktuelles Konzept in Bild gefasst (siehe Anhang).

Die EEPROMs habe ich mit eingezeichnet, aber die FT4232H sollten auch in 
ihrer Standard-Boot-Konfiguration bereits die UARTs bedienen.
Als USB-Hub-Controller habe ich den USB2502 von Microchip gewählt. Grund 
ist die interne Clock und die "out of the box"-Funktionilität. Auch hier 
ist das EEPROM nicht zwingend notwendig.
Verbunden mit dem USB-A Connector haben wir nun ein sauberes 
Ende-zu-Ende-System.
Versorgung erfolgt über Hohlstecker und DC/DC-Converter. Hier hab ich 
noch ein paar fertig vergossene rumliegen, sollte also kein Thema sein.

Wenn alles so funktioniert wie gedacht sollte alles direkt beim 
Hochfahren laufen, keine weitere Software oder Konfiguration notwendig.

Jemand Einwände oder Anregungen bevor ich mich an den Schaltplan mache?

Simon