µC via USB an PC anbinden

Hallo,

ich möchte mit Hilfe eines externen Chips eine Anbindung eines PC an einen µC realisieren (SPI). Eine Möglichkeit wäre der FTDI2232, der PC-seitig als COM-Port erscheint - aber der belegt zu viel Platz in der Schaltung.

Als Alternative habe ich den MAX3420E gefunden, der allerdings sehr flexibel ist und mit ein paar Endpoints zur Verfügung stellt, mit denen ich dann arbeiten kann.

Allerdings möchte ich PC-seitig nicht allzuviel programmieren müssen - idealerweise nur eine .inf-Datei, die ein Mapping erstellt zwischen meinem Gerät (VID/PID) und einem evtl. bereits vorhandenen Treiber, dessen Endpoint-Kombination ich dann übernehmen müßte. Kann mir dazu jemand ein paar Tips geben? Viel mehr als einen IN- und einen OUT-Endpoint dürfte ich dafür ja eigentlich nicht brauchen müssen, oder?

TIA,

Thomas

Reply to
Thomas Rachel
Loading thread data ...

Am 12.05.2010 10:59, schrieb Thomas Rachel:

Kannst du den µC via RS232 anbinden? Dann würde ich den FT232 enpfehlen. Ausser IC brauchst du nur etwas Hühnerfutter (3xC, evtl. noch ein C und L) und die Anbindung ist fertig. Treiber auf der PC-Seite kommt von FT, den mußt du nur ein mal programmieren mit dem FT-Tool und das Ganze läuft ziemlich transparent als serielle Schnittstelle. Und groß ist das Ding wirklich nicht. Ich packe den kompletten Converter + einen OC-Schalter in einen normalen USB-Stecker rein.

Waldemar

Reply to
Waldemar Krzok

Am 12.05.2010 11:29, schrieb Waldemar Krzok:

Ist im bisherigen Design so gelöst, allerdings wollen wir umsteigen auf eine synchrone Anbindung. UART ist bei höheren Geschwindigkeiten ja doch relativ empfindlich...

Eine Möglichkeit wäre der 245, aber für parallele Anbindung ist auch wenig Platz,daher der Wunsch nach SPI.

Danke dennoch für Deine Antwort!

Thomas

Reply to
Thomas Rachel

Am 12.05.2010 11:32, schrieb Thomas Rachel:

ich habe es nie probiert, aber theoretisch könnte man die Anbindung im Bit-Bang-Mode des FT232R probieren. Allerdings müßte man einen SPI-Driver auf der PC-Seite programmieren. Der FT232R hat freie IOs, man müßte allerdings vom PC aus mit den Beinen wackeln. Etwas umständig.

Vielleicht fällt mir noch was ein.

Waldemar

Reply to
Waldemar Krzok

Am 12.05.2010 11:42, schrieb Waldemar Krzok:

Das wäre an sich kein Problem - wir verwenden in der Vorgängerversion die FTDI-Library, da hätte man auch Zugriff auf Bitbanging. SPI zu programmieren wäre da nicht so problematisch.

Was mir da mehr Sorgen bereitet, wäre das USB-Framing, das die Sache dann vermutlich etwas wangsam machen dürfte - ich kann ja pro Frame (d.h. pro ms) max. 1 "Banging-Kommando" übertragen, oder?

Thomas

Reply to
Thomas Rachel

Thomas Rachel schrieb:

Hallo,

was ist am UART bei höheren Geschwindigkeiten realtiv empfindlich? Bei R232 Pegeln darf das Kabel nicht zu lang sein aber mit RS485 ist da genug Reserve bis zu Megabaud.

Bye

Reply to
Uwe Hercksen

Ich dachte, es geht um 'ne Verbindung zwischen Chips auf dem gleichen Board? Da kann man auch die vollen 3MBit, die der FT232R kann ohne Probleme nutzen..

Reply to
Thomas Kindler

Am 12.05.2010 10:59, schrieb Thomas Rachel:

Welcher uC wird denn benutzt?

--
Mit freundlichen Grüßen

Frank-Christian Krügel
Reply to
Frank-Christian Krügel

Am 12.05.2010 11:53, schrieb Uwe Hercksen:

Die Toleranzen beim Timing. Oder liege ich falsch?

Wenn die Clock des µC und die des Wandlers nicht hinreichend genau übereinstimmen, kann es zu Übertragungsfehlern kommen. Und je höher die Geschwindigkeit, umso geringer sind die absoluten Toleranzen.

Es sei denn, ich drehe - was ich aber eigentlich auch vermeiden wollte - die Taktfrequenz des Controllers hoch, um genauer zu werden. Oder ich stelle mich µC-seitig fest und verwende PC-seitig einen "krummen" Baudratenwert. Auch nicht so wirklich schön; SPI würde mir wirklich besser gefallen.

Eigentlich wolle ich im Bereich 2-max. 4 MHz arbeiten. SPI arbeitet oftmals bei f(µC)/4; der UART kommt meistens nicht so hoch, zumindest nicht mit Norm-Datenübertragungsraten.

Wir arbeiten eher mit kurzen Leitungen (Leiterbahnen; Länge max. 1-2 cm). Das sollte kein Problem darstellen - wie gesagt, das

Thomas

Reply to
Thomas Rachel

Am 12.05.2010 11:50, schrieb Thomas Rachel:

etwas schneller gehts schon. Ich glaube, ich habe 10kHz geschafft, trotzdem sehr lahmarschig im Vergleich zu RS232. Damit hatte ich keine Probleme, die RS232-Strecke ist ja nur ein paar mm lang, vom µC zum FT232R, weiter geht es ja per USB. Mein Kollege benutzt es mit 920kbps und es läuft sehr stabil.

Waldemar

Reply to
Waldemar Krzok

Am 12.05.2010 11:29, schrieb Waldemar Krzok:

Das hab ich eben noch vergessen: der FT232 fällt aus einem anderen Grund noch flach: "connect" (Pullup an D+) darf erst stattfinden, nachdem wir getestet haben, ob wir an einem "Charging Port" hängen.

(Siehe dazu

formatting link
- da wird beschrieben, wie ein Test auf "erlaubtes Viel-Strom-Ziehen" (insbesondere für Netzgeräte) durchgeführt wird).

Da selbiges geschehen muß, bevor USB-Kommunikation stattfindet, brauche ich eine Möglichkeit, diesen Pullup selbst zu kontrollieren. Diese Möglichkeit bietet mir der 3420 (-> CONNECT, VBGATE, VBUS_DET) ebenso wie der 2232 (-> RSTOUT#). (Ich sehe grade: der 245 hat den nicht, also fällt der auch flach... :-( )

Wie gesagt, der 2232 ist mit seinen 9x9 mm wesentlich größer als der

3420 (5x5 mm + Quarz-Schaltung), sonst würde ich einfach den nehmen...

Thomas

Reply to
Thomas Rachel

Am 12.05.2010 13:42, schrieb Frank-Christian Krügel:

Geplant ist ATxmega A1. Den gibts nur ohne USB - die µC mit USB haben diverse andere Features (2x2 DAC onboard, 7 PWM etc.) nicht, die ich gerne hätte.

Und wenn ich einen µC mit USB nehmen würde, hätte ich im Prinzip dasselbe Problem wie jetzt auch - n Haufen Endpoints und keine Anbindung auf PC-Seite.

Ein Ansatz wäre, das auf

formatting link
Beschriebene anzupassen und zu verwenden...

Thomas

Reply to
Thomas Rachel

Thomas Rachel schrieb:

Hallo,

nein, die Takte müssen beim UART bei niedrigen Frequenzen genauso gut übereinstimmen wie bei hohen. Nehmen wir als Beispiel 8 Datenbits, keine Parity, je ein Start- und Stopbit, das sind zusammen 10 Bits. Der Unterschied der Baudraten auf der Sende und Empfangsseite muß (genügend) kleiner sein als ein halber Takt pro 10 Takte. Wenn also jeder Takt besser ist als 2,5 % Abweichung vom theoretischen Sollwert geht die Übertragung gut. Besser als 1000 ppm zu sein ist mit Quarzen kein Problem. Manche Kombinationen aus Quarz und Baudratengenerator haben allerdings ein Problem wenn man von z.B. 20 MHz ausgeht und nicht von

18,432 MHz, dann werden zwar 300 bis 19200 Baud noch genügend genau getroffen, aber die Frequenzen darüber nicht mehr. Wird auf beiden Seiten ein 18,432 MHz Quarz benutzt hat man dieses Problem nicht, genauso wenn beide Seiten 20 MHz verwenden. Das Problem tritt nur auf wenn auf der einen Seite 20 MHz benutzt wird und auf der anderen 18,432 MHz oder ganzzahlige Vielfache davon. Mit einem Teilerfaktor von 1040 oder 1041 kann man die gewünschte Baudrate von 600 Baud auch bei einem 20 MHz Quarz genügend genau treffen, mit 31 oder 32 geht das für 19200 Baud auch noch, aber darüber nicht mehr.

Bye

Reply to
Uwe Hercksen

Am 12.05.2010 15:30, schrieb Uwe Hercksen:

Stimmt - relativ. Nicht absolut. (Logischerweise.)

ACK.

Eben. Das Problem war bisher eben, daß ich einen FT232R und einen PIC18 jeweils mit internem Oszillator verwendet habe und deren jeweilige Baudratenanpassungsmethode (Teiler) eingesetzt habe. Würde ich beide mit noch einem Quarz versehen, würde es wohl besser gehen. Aber dann kann ich genausogut auch synchron (mit Clockleitung) arbeiten, wäre dann wohl unproblematischer.

Aber wie gesagt - UART ist eh draußen, da sich der Pullup des FT232R AFAICS nicht abschalten läßt.

Thomas

Reply to
Thomas Rachel

Hi Waldemar,

Das mache ich regelmäßig mit USB-Datenkabeln für ältere Händis, die via Ebay eigentlich immer für max. 4 Euronen zu haben sind. Stecker weg und an den µC anschließen. oft bekommt man die 5 V vom USB mgleich mit. Im Zweifelsfall wird der Stecker aufgeschnitten, da lagen bisher immer alle Anschlüsse auf Lötpads herausgelegt. Gängige Chipsätze sind Prolific, OTI, ARK und Silabs. Ich habe alle Treiber auf dem Rechner drauf, es geht also jeder auf Anhieb. Unter Linux sowieso.

Marte

Reply to
Marte Schwarz

Hi Thomas,

Wieso? ich habe ganze nächte mit 200kBd/s aufgezeichnet, ohne dass es zu Problemen gekommen wäre.

Marte

Reply to
Marte Schwarz

Die libusb (auch für win32) kennst du vermutlich schon?

--
Thomas Kindler
Reply to
Thomas Kindler

Am 12.05.2010 19:00, schrieb Thomas Kindler:

Die für win32 noch nicht, danke für den Tip! Das werd ich mir nächste Woche mal anschauen.

Thomas

Reply to
Thomas Rachel

Am 12.05.2010 14:12, schrieb Thomas Rachel:

Wie wärs damit: STM32F105

- 2 ADC

- 2 DAC

- Up to four 16-bit timers, each with up to 4 IC/OC/PWM or pulse counter and quadrature (incremental) encoder input

- USB OTG und viele weitere Schmankerl

Die Libraries von ST sind gut, habe da gute Erfahrungen gemacht. Für den PC gibts die entsprechenden Treiber auf der Webseite von St. Den CDC Treiber haben wir mal kurz eingesetzt, sind dann aber auf HID umgeschwenkt.

Wobei ich nicht weiß, wie groß ein Atmega ist. Der STM32 im LQFP64 Gehäuse hat 10x10mm²

Rolf

Reply to
Rolf Mennekes

du schaffst erheblich mehr. Im syncronen Bitbang-Modus kannst du die vollen

256 Byte Sendepuffer nutzen. Die Ergebnisse landen dann im Empfangspuffer. Allerdings währe ich mit der 1ms vorsichtig. 2-4ms ist schon realistischer.

Ich hab so einen AT89s52 programmer realisiert der mit 17 Pufferbytes ein SPI-Byte überträgt. Du könntest aber auch #RD und #WR verwenden und so den vollen Puffer für Daten nutzen. Die verwendete Bitzahl kannst du ja selbst bestimmen.

--
MFG Gernot
Reply to
Gernot Fink

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.