Hallo, auf welche Schnittstelle sollte man setzt? UART RS-232 COM-Port (Serial Port) FTDI I2C Der Anschluss sollte natürlich zukunftssicher sein, insbesondere Treiber für Windows 7/8. Welche Erfahrungen habt ihr und was könnt ihr empfehlen?
Ich verwende dafür den FT232. Habe es schon Problemlos mit Win7 und Win8 eingesetzt.
Für Controller mit USB halt USB und für die ohne einen USB UART Converter, da gibts ja einige.
Nachtrag: heinz schrieb: > RS-232 > COM-Port (Serial Port) An neuen PC oft nicht vorhanden heinz schrieb: > I2C Braucht auch irgendeinen Adapter-Chip
:
Bearbeitet durch User
Hallo Zusammen, ich setze seit längerem die FTDI Module erfolgreich ein. Die gibt es für einen MAX BAustein bzw. für 3,3 oder 5,0 Volt. Der Vorteil liegt darin dass der Treiber in Windows 7 ind Windows 8 direkt enthalten ist, und die Gehäuse den bisherigen Sub-D-Gehausen entsprechen. Das Modul wird über ein Mini-USB Kabel mit dem PC verbunden. Die Module gibt es bei RS-Components. http://www.ftdichip.com/Products/Modules/USBRSxxx.htm DB9-USB Modules DB9-USB-M Full Speed USB to 1-Port RS232 level UART module that can replace an RS232 Level UART DB9 male connector DB9-USB-F Full Speed USB to 1-Port RS232 level UART module that can replace an RS232 level UART DB9 female connector DB9-USB-D3-M Full Speed USB to 1-Port 3.3V level UART module that can replace 3.3V level UART DB9 male connector DB9-USB-D3-F Full Speed USB to 1-Port 3.3V level UART module that can replace 3.3V level UART DB9 female connector DB9-USB-D5-M Full Speed USB to 1-Port 5V level UART module that can replace 5V UART DB9 male connector DB9-USB-D5-F Full Speed USB to 1-Port 5V level UART module that can replace 5V UART DB9 female connector
Super, dass es so schnell Antworten gibt. Werde mit mal die FTDI Bausteine näher ansehen...integrierte Treiber ersparen einem unter Windows natürlich viel Arbeit.
Gerne, beachte bitte Stecker und Buchsen. Ich setze eigentlich bei Controllern nur buchsen ein. hier wären noch Beispiele bei RS: RS Nummer: 715-8531 RS Nummer: 751-1197 RS-Nummer: 751-1184
heinz schrieb: > Hallo, > auf welche Schnittstelle sollte man setzt? > UART > RS-232 > COM-Port (Serial Port) > FTDI > I2C > > Der Anschluss sollte natürlich zukunftssicher sein, insbesondere Treiber > für Windows 7/8. Welche Erfahrungen habt ihr und was könnt ihr > empfehlen? Am besten sind Geräte, die eine Standard-USB-Klasse wie HID oder CDC implementieren. Dafür hat jedes Betriebssystem schon passende Treiber dabei. Es gibt zB den Microchip MCP2200. Das ist quasi ein vorprogrammierter PIC18F14K50, der einen USB-Seriell-Adapter implementiert. Während Du bei FTDI noch spezielle Treiber brauchst, ist der MCP2200 ein CDC Device, das Du an einen Mac oder eine Linux-Kiste anschließen kannst, und das sofort funktioniert, weil CDC eben eine Standard USB-Klasse ist. Windows möchte noch ein INF-File sehen, nutzt dann aber den eingebauten Treiber. Der MCP2210 ist ein USB-SPI Adapterchip, der USB-seitig als HID erkannt wird und damit auch ohne extra Kerneltreiber funktioniert. Wenn Du keine großen Ansprüche hast, ist ein USB-HID das unkritischste. Zweite Wahl sind andere Standard-USB-Geräteklassen, und gerätespezifische USB-Geräte, wenn es keine andere Möglichkeit gibt. FTDI ist keine schlechte Wahl, aber Du musst eben vorher einen extra Treiber installieren, und dann musst Du schauen, welcher USB-seriell-Port Deiner ist. Wenn Du eine eigene VID/PID nehmen willst (um Verwechselungen mit anderen USB-Kabeln auszuschließen), wollen 64-Bit Windows-Systeme eine Treibersignatur sehen, die Du von Microsoft kaufen musst. (TEUER!) Bei HID brauchst Du das nicht. Für Dich als Programmierer ist das etwas mehr Aufwand, für den User später dafür aber idiotensicher. Einstecken, warten bis erkannt, zugehörige Applikation starten, funktioniert. fchk
Frank K. schrieb: > sofort funktioniert, weil CDC eben eine Standard USB-Klasse ist. Windows > möchte noch ein INF-File sehen, nutzt dann aber den eingebauten Treiber. Wobei unter neueren Windows-Versionen meines Wissens auch hier eine digitale Signatur erwartet wird und Kosten verursacht. Ergänzend zu HID+CDC kann man evtl. auch auf WinUSB einen Blick werfen (kann unter anderen Betriebssystemen per libusb angesprochen werden): http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799(v=vs.85).aspx#what_is_a_winusb_device
Meiner Meinung nach geht nur USB. COM-Schnittstelle findet man ansich garnicht mehr bei aktuellen PCs und Druckerport (LPT) ist bei Laptops auch kaum noch vorhanden. Da bleibt dann nicht mehr viel. Firewire hat sich auch nich richtig durchgesetzt. Alternativ ginge noch Ethernet (Lan/W-Lan), gerade wenn das zu steuernde Gerät zentral und nicht "tragbar" ist. Zuletzt wäre noch Bluetooth, doch als Schnittstelle zum PC würde ich dann doch USB nehmen. Ist dann auch gleich mit 5V/1A max. bestrombar.
Frank K. schrieb: > Am besten sind Geräte, die eine Standard-USB-Klasse wie HID oder CDC > implementieren. Dafür hat jedes Betriebssystem schon passende Treiber > dabei. Ja, nur ist Windows nicht in der Lage, CDCs ohne beschreibende *.inf-Datei anzusprechen -- warum auch immer.
Rufus Τ. Firefly schrieb: > warum auch immer.. Nun ja, bei CDC, also mehr oder weniger allgemeinen Kommunikationsgeräten gibt es theoretisch ne Menge Varianten und Versionen und es hat sich offenbar bei Microsoft keiner die Mühe gemacht, alle nach Standard in Frage kommenden Geschmacksrichtungen aller Hersteller in den mitgelieferten INF's einzutragen. Stattdessen erwartet man dort, daß jemand, der ein Kommunikationsgerät in den Handel bringt, dessen zugehörigen Software-Senf mit dazuliefert. Aber mal ein Wort zu den hier vielgerühmten HID's: Ich finde, das ist eine elendige Einschränkung im Vergleich zu einem CDC. Einen virtuellen COM Port kann fast jedes Programm öffnen und darüber Daten austauschen, aber für HID geht das überhaupt nicht, das ist entweder ne ungewünschte Konkurrenz zu Maus und Tastatur oder ein Spezialport, mit dem NUR das Programm was anfangen kann, das man selber dazugeschrieben hat. W.S.
W.S. schrieb: > Aber mal ein Wort zu den hier vielgerühmten HID's: Ich finde, das ist > eine elendige Einschränkung im Vergleich zu einem CDC. Einen virtuellen > COM Port kann fast jedes Programm öffnen und darüber Daten austauschen, > aber für HID geht das überhaupt nicht, das ist entweder ne ungewünschte > Konkurrenz zu Maus und Tastatur oder ein Spezialport, mit dem NUR das > Programm was anfangen kann, das man selber dazugeschrieben hat. Das ist durchaus Absicht. Viele Geräte kann man auch nur mit dem Programm benutzen, was dafür gedacht ist. Mein Blick fällt gerade so ein ELV DDS-Generator, wo die Schwachmaten auch irgend so einen USB-seriell-Chip reingesetzt haben, der erst mit wüsten Drohungen zur Mitarbeit überzeugt werden konnte, plus irgendeinen kleinen AVR. AVRs mit eingebauter USB-Hardware existierten damals schon. Das ist ein Beispiel für ein Gerät, was ohne die mitgelieferte Software nicht bedienbar ist. Und HID ist in dieser Hinsicht idiotensicher. Der dumme User kann da einfach nichts verkehrt machen, und das ist auch gut so, denn sonst hast Du nachher ganz schnell mehr Supportaufwand, als Du haben willst. fchk
Das Problem mit der ansonsten wirklich universellen USB-Schnittstelle ist das Treiber-Gefruzzel. Zwar stellt z.B. FTDI inzwischen für beinahe jede Plattform (Win, Mac, Linux) Treiber bereit, aber was ist mit Andriod, iOS oder ... was auch immer? Ich plädiere (sofern der verwendete MC das hergibt) für ETHERNET. Notfalls mit einem Lantronix XPort (oder änhlichem). Ethernet-Treiber sind von vorne herein in jedem OS enthalten und absolut plattform-unabhängig. Da muss der Hersteller keinen Treiber liefern, man muss nämlich gar keinen installieren - ist das nicht ein gewaltiger Unterschied? Hinzu kommt die nahezu unbegrenzte mögliche Entfernung zwischen den Komponeneten - nicht nur, wie bei USB, gerde mal ein par Meter. Auch die Protokolle sind programmtechnisch wesentlich einfacher umzusetzen (falls gewollt). Leute baut mehr Netzwerk in eure Geräte, DAS ist professionell!
Ich denke auch dass das Absicht ist, um mehr von CDC wegzulenken. Wenn man Software schreibt ist es auch etwas blöd, das man dort eigentlich nur eine Liste der COM-Ports anzeigen kann und den Nutzer das richtige Gerät auswählen lassen muss. Ob da der Nutzer immer schnallt ob sein Gerät jetzt COM3, COM4 oder COM6 ist? Bei HID oder WinUSB kann man problemlos nach Vendor-ID/Product-ID/etc. filtern, bei (virtuellen) COM-Ports maximal über APIs des Herstellers des USB-Adapters oder über irgendwelche Flickschustereien. Bei der .inf für CDC kann man immerhin noch den DisplayName setzen.
Ich bevorzuge auch HID. Eine passende Software muss ich zu 80-90% eh schreiben. Und dann is HID wegen ohne Treiber und Filterung nach VID/PID aus meiner Sicht besser als CDC. Mit Ethernet hab ich leider noch nichts gemacht, reizt mich aber auch. Aber für ein einzelnes Gerät (z.B. SPI-PC-Schnittstelle oder per PC steuerbare PWM-Ausgänge) am Platz nehm ich doch lieber USB.
Michael Skropski schrieb: > Mit Ethernet hab ich leider noch nichts gemacht, reizt mich aber auch. > Aber für ein einzelnes Gerät (z.B. SPI-PC-Schnittstelle oder per PC > steuerbare PWM-Ausgänge) am Platz nehm ich doch lieber USB. Dafür bietet sich ein PIC18F67J60 an. Der hat Ethernet MAC und PHY gleich eingebaut, man kann direkt die RJ45-Buchse mit integriertem Übertrager an den Chip anschließen. Damit hat man eine wirkliche Single-Chip-Lösung, die auch nicht aufwändiger ist als eine USB-Lösung. Es gibt keine einfachere, kleinere und billigere Lösung, ein Ethernet-Gerät zu bauen. fchk
Ne. Es wird auch ein PIC sein, wenn ich mit Ethernet beginne. Ich bin am planen einer Home-Automation und die Zentraleinheit wird wohl Ethernet haben. Eine Extra-Platine für die Konfiguration der Module wird dann aber mit USB laufen. Das find ich so toll bei den neuen PICs mit USB. Manche haben die D+ & D- Leitung da, wo auch die ICSP Clock- & Datenleitung ist. Mit einer 5poligen Mini- oder MikroUSB-Buchse kann man so den PIC flashen (mit Adapterkabel zum PICKIT) und danach gleich Versorgen und die Kommunikation zwischen PC und PIC realisieren. Sollte die USB-Funktion nicht nötig sein, kann man die Buchse nutzen, um ein Netzteil anschließen zu können.
Meine Rangfolge ist diese: 1) Ethernet: Weil man keinen Treiber braucht und praktisch alle Computertypen und Betriebsysteme unterstützt werden. Programmierung des Mikrocontrollers ist schwierig, aber wenn man den Dreh erstmal raus hat, kann man den Basis-Code immer wieder kopieren. 2) USB-UART: Weil da ein bisschen Stromversorgung inclusive ist Treiber je nach Betriebsystem und Chip leicht verfügbar oder gar nicht nötig sind. Allerdings geht das nur mit wenigen Mobilen Geräten (Handies, Tablets). 3) Bluetooth SPP: Für mobile Geräte besser als USB, denn das geht wieder ohne Treiber.
Hallo, da bin ich voll bei Frank. Die PICs sind da absolut einfach handzubahen. Der TCPIP-Stack ist sehr umfangreich. Die Anbindung über einen lantronix xport ist auch recht einfach, aber deutlich teurer als eine Lösung über einen PIC. Ganz egal für welches Interface man sich entscheidet, man sollte zumindest über Grundlagen im Bereich Hardware und Software besitzen, und nicht frustriert sein, wenn etwas nicht auf Anhieb funktioniert.
Alles was man heutzutage per Kabel an den PC hängt darf ruhig USB oder Ethernet sein. Bei USB bietet sich ein Gerät der HID Klasse an. Die Hardware und Firmware gibt es z.B. von Microchip: PIC18F14K50. Atmel hat bestimmt was Ähnliches. Eine Auswahl an PC-Treibern dafür gibt es hier: http://www.mikrocontroller.net/articles/USB_HID_Host_Treiber
Einziger Nachteil von USB direkt auf dem Mikrocontroller. USB hat an ein paar Stellen Timeouts von 50ms. Und die Routinen sind recht umfangreich - möchte man nicht in eine ISR packen. Die Hauptschleife muss so angelegt sein, dass sie regelmässig die USB Schnittstelle pollt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.