c't-Lab

Für größere Datenmengen ist der OptoBus ja nicht unbedingt die beste Wahl ... um das zu verbessern, suche ich nun nach einer anderen Lösung für meine eigenen Projekte. Ich denke USB ist am geeignetsten da es für nahezu alle wichtigen OS Treiber gibt und der Anschluß am µC meist recht simpel ist und sich die paar Leitungen zwischen USB-IC und µC relatiev einfach galvanisch trennen lassen (Optokopler) ...

Jetzt zu meiner Frage ... wer kennt einen gut verfügbaren Baustein, der möglichst hohe Datenraten schafft und per SPI oder seriell am µC angeschlossen wird ... Soweit ich gelesen habe sind die Bausteine von FTDI nicht so dolle wenn es um hohe Datenraten geht.

Hi,

der USB-Baustein ist wahrscheinlich nicht so der Flaschenhals wie die interne Verarbeitung im AVR. Generell läuft das bei meinen Firmwares über Interrupt mit einem recht bescheidenen Buffer (128 Bytes) im RAM, zusätzlich zur Schnittstellen-Queue des Controllers (bei neueren wie dem Mega644 deutlich größer als beim Mega32). Da der Controller in der Regel noch andere, zum Teil umfangreiche IRQs zu bedienen hat (Wandler etc.), kam ich bei meinen Experimenten selten über 115 kBd hinaus.

Erfahrene c't-Lab-Nutzer können einmal folgendes zur deutlichen Verringerung der Latenz bei mehreren Modulen probieren: Alle Optobus-Ein- und Ausgänge über einen Verteiler sternförmig (einzelne Treiber für die Sendeleitung, "Wired OR" bei den Empfangs-Optokopplern) verdrahten, nicht mehr hintereinander. Das funktioniert ähnlich RS-485 hervorragend, so lange die Geräte nur dann Ergebnisse senden, wenn sie explizit gefragt werden (also keine Trigger-Freigaben, nicht gleichzeitig an mehreren PM8 bedienen, keine Wildcard-MainCh mit "*"). Man muss in der Firmware allerdings das Wiederaussenden des Befehls verhindern, wenn dem Modul der MainCh nicht passt (Tip an die fleißigen C-Programmierer: evt. ein ReSendEnable mit OPT-Parameter einführen, damit das Modul beide Betriebsarten kann).

Entschuldige ... ich hatte vergessen zu erwähnen, daß meine Projekte mit einem ARM µC (AT91SAM7xxx) werkeln werden ... der hat zwar bereits USB eingebaut läßt sich dann aber nicht mehr galvanisch trennen, darum ein externes IC dafür.

Gruß .. Lennart

Lennart hat geschrieben:... daß meine Projekte mit einem ARM µC (AT91SAM7xxx) werkeln werden ... der hat zwar bereits USB eingebaut läßt sich dann aber nicht mehr galvanisch trennen, darum ein externes IC dafür.

Es gibt doch IC's zum galvanischen Trennen von USB-Verbindungen (z.B. der ADuM4160 / habe ich aber nirgends im Einzelhandel gefunden). Der kann bis USB-1.1-FullSpeed (12MBit/Sec.). Wäre das eine Möglichkeit ?

Außerdem gibt es doch inzwischen die ATmegas auch mit USB-Schnittstelle (z.B. ATmega32U4). Hat damit schon jemand Erfahrung ? (Die muss man ja immer in 100ter-Packungen nehmen)

Gruß !
Patrick

das ist ja das problem ... ich möchte natürlich weder extrem schwer beschaffbare exoten benutzen noch ne familienpackung von irgend nem IC bestellen müssen ... das von dir erwähnte IC hab ich auch schon gefunden, aber auch keinen Händler gefunden der das ding zu normalen Preisen vertreibt.

Lennart hat geschrieben:Jetzt zu meiner Frage ... wer kennt einen gut verfügbaren Baustein, der möglichst hohe Datenraten schafft und per SPI oder seriell am µC angeschlossen wird

Von MAXIM gibts den MAX3420. Der kostet als Sample nichts. Bei mir wartet der seit einem halben Jahr darauf, einen USBN9604 zu ersetzen.

Soweit ich gelesen habe sind die Bausteine von FTDI nicht so dolle wenn es um hohe Datenraten geht.

Bis 1.5MBit/s gibts da eigentlich kein Problem. Unter Windows kann gegebenenfalls die Default-FIFO-Wartezeit stören. Die kann man aber reduzieren.

Gruß
amd-65