Hallo, ich beschäftige mich grad ziemlich neu mit dem Thema rs232 auf usb-Wandlung. Ein bestehendes Produkt soll nämlich von rs232 auf USB Anschluss geändert warden. Es gibt ja unzählige Adapter/Konverter-Module, die dies bewerkstelligen, allerdings wird hierbei auf Host-Seite immer ?! ein virtueller Com-Port erzeugt. Und genau das soll nicht passieren ! Einfach aus dem Grund dass der Treibersupport für virtuelle com Ports in Zukunft nicht sicher gestellt ist und das Gerät soll auch noch mit Windows "12" über USB lauffähig sein. Ich hab nun versucht heraus zu bekommen, ob das mit den üblichen USB UART IC's a la FT232R möglich ist. Ich steig da aber nicht ganz durch, kenn mich damit nicht aus. Kann mir jemand sagen wie ich das am einfachsten hinbekomme ? µC mit UART ist auf der zu änderen Platine vorhanden. Reicht nun so ein einfacher IC wie z.b. der FT232R aus um USB zu realisieren ohne, dass ein virtueller Com Port installiert wird ?!?! Danke !
:
Verschoben durch Moderator
> Und genau das soll nicht passieren ! > Einfach aus dem Grund dass der Treibersupport für virtuelle com Ports in > Zukunft nicht sicher gestellt ist und das Gerät soll auch noch mit > Windows "12" über USB lauffähig sein. Irgendwie scheint mir dein Vorhaben etwas dumm. Die Hersteller benutzen virtuelle Comport weil DU dann keinen Treiber programmieren musst. Wenn dir aber danach ist, dann kannst du ja einfach die VID aendern und heute schon was eigenes programmieren. Und sollte es irgendwann mal keine Comport mehr geben dann programmierst du dir eben dann einen eigenen Treiber. Allerdings bin ich mir ziemlich sicher das du das aussterben des Comport nicht mehr erleben wirst. Ohne Comport wuerde Windows naemlich komplett aus industriellen Anwendungen verschwinden. Was glaubst du wohl was RS422, RS485, Modbus, HART usw. ist? Gut, da will sowieso keiner Windows, aber sie muessen ja wenigstens den Anschein wahren. Olaf
Ich kann mich meinem Vorredner nur anschliessen. Wenn es keine USB-to-Serial mehr gibt, ist Windows aus der Industrie draussen. Geh davon aus, dass der USB-to-Serial bleibt. In meinem Fall, saemtliche Nicht-Simulationen benoetigen den Serial Port. Alternativ, bau einen Ethernet-to-Serial. Der benoetigt auch keinen Treiber
Du kannst die FT232 auch über einen eigenen Treiber ansprechen. Schau mal hier: http://www.ftdichip.com/Drivers/D2XX.htm Das Interface ist eigentlich ganz brauchbar zu programmieren und macht unter Windows gefühlt weniger Ärger als die VCP-Lösung. Max
Sorry für die späte Antwort und erstmal danke für eure Meinungen. Ich habe auch gelesen, dass virtuelle Com-Ports wohl noch eine Weile bestehen bleiben. Trotzdem sollen in meinem Fall Alternativen gefunden werden, USB auch ohne Installation eines VCP zu ermöglichen. Das soll einfach als Machbarkeitsstudie dienen und den Aufwand beschreiben, der dafür nötig ist. Habe ich das nun soweit richtig verstanden, dass ich z.b. den FT232 benutzen kann und dafür dann mit Hilfe der D2xx "Treiber" eine eigene Lösung schreiben kann ? Gibt es vielleicht noch andere Möglichkeiten ? Danke euch !
Max schrieb: > USB auch ohne Installation eines VCP zu ermöglichen Egal, was du nimmst: einen eigenen Treiber kannst du dir immer selbst zimmern. Mit allem, was dazu gehört natürlich (bei Microsoft also dann wohl irgendeine Zertifizierung/Registrierung, damit der Nutzer den Treiber überhaupt installieren darf). Allerdings bleibt natürlich dann die Frage, wie eine Applikation denn überhaupt auf deinen Treiber zugreifen soll? Der Vorteil der virtuellen seriellen Schnittstellen ist ja gerade, dass die Schnittstelle aus Applikationssicht so aussieht, wie bislang eine serielle Schnittstelle aussah. Du kannst natürlich auch einen USB-fähigen Microcontroller benutzen und dann auf den Zug „If your OS'es only generic USB driver is for class HID, ever device looks like a human-interface device.“ aufspringen …
Und dann musst du permanent die Treiber weiterentwickeln. Microsoft ändert bei jedem Windows Rechtemanagement und Zertifizierung. Bei Linux ändern sich plötzlich irgendwelche internen Details.
Kein Name schrieb: > Bei Linux ändern sich plötzlich irgendwelche internen Details. Bei unixoiden Systemen (Linux, *BSD, Solaris, OSX) gibt's einen generischen USB-Treiber, und man kann den ganzen Salat komplett im Userland in der Applikation handhaben (via libusb). Um den Treiber muss man sich dann gar nicht weiter kümmern, höchstens noch um die Rechtezuweisung. Nur beim Redmonder OS gibt es sowas leider nicht. (Bei Android bin ich mir gerade auch nicht ganz sicher, wie das dort aussieht.)
Jörg Wunsch schrieb: > Bei Android bin ich > mir gerade auch nicht ganz sicher, wie das dort aussieht. Bein Android kann auf jeden Fall die App direkt auf das OTG zugreifen (wenn man ihr permissions gibt). Über die Langzeitstabilität der API kann ich nicht viel sagen (gibts meines Wissens erst seit 4.0). Ich würde evtl. einfach CDC nehmen, das ist von dem USB-Interface simplest und (anders als die FTDIs) komplett dokumentiert. Man kann also im Falle eines GAUs (das Wunsch-OS macht keine Serials mehr) einfach selber eine Lösung rumwickeln (und bis dahin über eine .inf Datei den Windows-Treiber einbinden).
Jörg Wunsch schrieb: > Nur beim Redmonder OS gibt es sowas leider nicht. Doch, das gibt seit einiger Zeit auch da. Einerseits mit libusb-win32, und andererseits auch mit offizieller Segnung aus Redmond, da heißt das ganze WinUSB. http://sourceforge.net/apps/trac/libusb-win32/wiki http://msdn.microsoft.com/en-us/library/windows/hardware/ff540196%28v=vs.85%29.aspx
@ Max D... Kannst du die Lösung mit CDC eventuell für blutige Anfänger auf dem Gebiet von USB noch ein bisschen ausführen ? was wird hard- und softmaremäßig benötigt um das zu realisieren ? - der vorhandere µC ist ein ATmega 16-16au. - der RS232 soll nicht mehr benutzt werden, Redesign der Platine ist erlaubt.
Hallo. Falls ATxmega128A3U eine Option fuer dich ist, ggf. magst du dir mal http://matrixstorm.com/avr/avrstick/ ansehen. Fuer das Board habe ich ein Beispielcode: http://vps.matrixstorm.com:1114/bideavr/simpleusbterm.html bzw. http://matrixstorm.com/avr/avrstick/examples/USBtoUARTs/release/00.01/ Die USB UART Implementierung ist ueber die CDC Klasse realisiert. (Und alles USB Zeugs abstrahiert auf einen Filestream und 2 Funktionen.) Im meinem Sprachgebrauch handelt es sich zwar dennoch um einen "virtuellen COM Port" - allerdings braucht man dafuer keine Treiber. Bei CDC handelt es sich um eine Standard USB Deviceklasse. Windows braucht lediglich ein paar Zeilen INF-Datei, "der Form halber". Auf der Seite habe ich es "Treiber" genannt, der eigentliche Treiber ist wohl aber "usbser.sys" deines Windows. MfG
Stephan hat das meiste schon geschrieben. CDC ist quasi der "Standard" für USB-Serial Ports. Abhängig davon wie "professionell" deine Lösung sein soll hast du zwei Optionen: Wenn es nur ein Einzelstück sein soll (und du keine Abnahme willst): http://www.obdev.at/products/vusb/prjdetail.php?pid=11 da emuliert ein tiny85 ein CDC-Device. Dabei verletz er jedoch einige USB-Spezifikationen, funktioniert aber eigtl. mit allem auf dem Markt. Ist halt schnell und einfach, aber im Endeffekt Pfusch... Wenn es "richtig" gemacht werden soll: http://www.fourwalledcubicle.com/LUFA.php Läuft auf allen AVRs mit echtem USB-Interface und macht die CDC-Emu "richtig". Du könntest sogar Mega16 durch ein Tochterboard mit TQFP (gibt keine DIPs mit USB) und USB-Buchse ersetzen. Inspiration wie man das Interface dann nutzt kannst du dir ja aus den Examples in dem dl holen ;). €dit: seh grade du hast nen AU Typen, also wohl bereits tqfp, geht wohl kein tochterboard
:
Bearbeitet durch User
Hi, Max schrieb: > Gibt es vielleicht noch andere Möglichkeiten ? Du könntest auch einfach statt eines "Spezial-IC" der FTxxx Familie einen µC mit USB Schnittstelle als Wandler einsetzen. Das hätte den Vorteil das du zukünfitg alle änderungen am Interface rein über die Software machen kannst ohne die Hardware zu verändern. Also jetzt für den Schnellen Start legst du mit CDC los das ja auf absehbare Zeit noch gut unterstützt ist, kannst aber jederzeit auf eine Deviceklasse mit eigenen Treibern -nur durch änderung der SW- wechseln. Bei der Klasse hast du dann sogar die freie Wahl. Ausserdem ist das teilweise sogar günstiger als der Einsatz von den FTxxx. (Der FTxxx ist ja im Prinzip auch nichts anderes als ein Maskenprogrammierter µC mit USB Port...) Welchen µC du dabei nimmst ist erst einmal relativ egal, das würde ich von der Verfügbarkeit, dem Preis sowie der Frage ob es bereits fertige Applikationen zur freien Nutzung gibt abhängig machen. Ich ahbe in kommerziellen Entwicklungen für scolche Zwecke schon öfter den PIC18F14K50 (je nach Stückzahl auch 18F13K50) eingesetzt. Der kostet in der SSOP Version in der 100er Staffel unter 1,30 Euro /pcs. (Einzelstück um 1,80). Dafür gibt es von Microchip direkt eine fertige Anwendung die man nur aufspielen muss und man hat bereits einen (CDC) USB-Serial Wandler! Für andere USB Klassen gibt auch vorgefertige Lösungen die man sich dann anpassen kann. Samt Treibervorlagen. Als Alternative zu den 13K50 könnte man mittlerweile auch zu den PIC18F25K50 greifen. Diese haben den Vorteil das sie im gegensatz zu den 18F1xK50 auch für USB Betrieb keinen Quarz mehr brauchen. Kosten aber 30ct. mehr. (Ich habe hier seit längerer Zeit schon welche auf dem Tisch liegen, aber selbst damit noch nichts gemacht) Neben den µC Pics gibt es noch viele weitere ebenso geeignete µC, aber dazu sollen andere dann Vorschläge schreiben. Ich bin mit den µC gut zu frieden, zumal man da sogar eine !Individuelle! VID/PID kostenlos von Microchip bekommt wenn man die gewerblich einsetzt. Auch kommen die Applikationen direkt von Microchip und sind kommerziell unbeschränkt nutzbar! (so lange man halt mit Microchip µC arbeitet natürlich) Gruß Carsten P.S.: Es wurde ja schon geschrieben, aber eigendlich kann man es gar nicht oft genug schreiben: Nur wegen der langfristigen Unterstützung von VCP/CDC die finger zu lassen ist eher Kontraproduktiv. Derzeit sieht es so aus als wenn diese Anwendungen noch lange native von Windows unterstützt werden. Wenn du was ganz eigenes machst musst du ab sofort und vermutlich für jede neue Version wieder eigene Treiber komplett selbst schreiben. Allenfalls könnte man darüber nachdenken statt VCP/CDC eine andere native unterstützte Geräteklasse zu wählen. HID wird für einfache Messgeräte und ähnliches auch öfter verwendet. Mit einem "universellen" µC hättest du da ja die freie wahl. Auch zu einem späteren Zeitpunkt ohne HW Änderung jerzeit!
Ich hab hier vor kurzem eine passende wiki-Seite angelegt: http://www.mikrocontroller.net/articles/Kommunikation_%C2%B5C_und_PC/Smartphone
Rufus Τ. Firefly schrieb: > Einerseits mit libusb-win32, Da hat man dann nur auch wieder die Probleme mit Treiberzertifizierung und all sowas. > und andererseits auch mit offizieller > Segnung aus Redmond, da heißt das ganze WinUSB. Das kannte ich allerdings noch nicht. Sowas könnte doch in der Tat ein Modell für den TE sein: man nimmt sich einen Controller, der USB an Board hat. Auf dem kann man sich ein beliebiges custom device implementieren, hängt ihm den WinUSB-Treiber um den Hals, und redet aus der Applikation heraus dann direkt mit ihm.
Jörg Wunsch schrieb: > Da hat man dann nur auch wieder die Probleme mit Treiberzertifizierung > und all sowas. Nein: > Vista/7/2008/2008R2 64 bit are supported from version 1.2.0.0 > since a Microsoft KMCS accepted digital signature is embedded > in the kernel driver libusb0.sys.
Super Leute ! Danke für die zahl- und hilfreichen Antworten ! Ich werde mir eure Vorschläge jetzt erstmal genauer anschauen ;)
Rufus Τ. Firefly schrieb: > Vista/7/2008/2008R2 64 bit are supported from version 1.2.0.0 since a > Microsoft KMCS accepted digital signature is embedded in the kernel > driver libusb0.sys. Überredet. ;-) Ich habe mich offenbar eine Weile nicht mehr mit dem Thema beschäftigt. Das letzte Mal, als ich damit (im Rahmen von AVRDUDE und AVaRICE) zu tun hatte, gab's derlei Komfort noch nicht. Also um so besser dann.
Hallo nochmal, bin mit den verschiedenen Lösungen mal zum Cheffe gegangen. Plötzlich heißt es, dass Layoutänderungen jeglicher Art nicht erlaubt sind. Es soll "irgendwas" zwischen den jetzigen DB9 Stecker im Deckel des Gehäuses und der Elektronik...(das war vor 2 Wochen noch nicht der Fall). Der olle ATMega16-16AU muss also drin bleiben. Kein Austausch für µC mit integriertem USB. Nur der DB9-Stecker darf entsprechend für einen USB-Connector getauscht werden, ansonsten soll die Platine so bleiben wie sie ist. Am besten scheint mir ich überzeug ihn, dass das ganze Vorhaben Blödsinn ist. Aber für den Fall, dass er damit nicht zufrieden ist, was bleiben mir denn da jetzt noch für Möglichkeiten ? USB muss doch physikalisch auf irgendeine Weise auf das Board gebracht werden ?!
Max schrieb: > Nur der DB9-Stecker darf > entsprechend für einen USB-Connector getauscht werden, ansonsten soll > die Platine so bleiben wie sie ist. Dann bietet sich das hier an: http://www.ftdichip.com/Products/Modules/USBRSxxx.htm (etwas nach unten scrollen zu "DB9-USB Modules")
Bei FTDI gibts Adapter, die in das Pinout eines DB9 passen. Perfekt für Cheffe. Dann noch im Treiber den Haken für VCP rausnehmen und es erscheint kein COM mehr. Dann kannst du über o.g. D2XX zugreifen
Max schrieb: > Aber für den Fall, dass er damit nicht zufrieden ist, was bleiben mir > denn da jetzt noch für Möglichkeiten ? Software-USB (wie beispielsweise V-USB) bliebe dir noch, braucht aber auch ein paar Voraussetzungen: eine der beiden Datenleitungen muss an einen interruptfähigen Pin, du brauchst einen Widerstand, der das Gerät als lowspeed-USB gegenüber dem Host ausweist, und der Takt muss zumindest aus einem Keramikresonator stammen, oder man muss mit dem RC-Oszillator deutlich über 16 MHz gehen, was für den alten ATmega16 den garantierten Betriebsbereich verlässt.
Kauf einfach so ein USB-RS232-Kabel und erzähl Cheffe der Com-Port der auftaucht wäre ein Bug in Windows ^^
Max schrieb: Hi, > Kein Austausch für µC mit integriertem USB. > Der olle ATMega16-16AU muss also drin bleiben. Das der jetzige µC drin bleibt war bei MEINEM Vorschlag (PIC18F13K50) ja auch erst einmal so gedacht. Also den PIC zusätzlich zum normalen µC einsetzen wie man auch einen FTxx verwenden würde. Nur mit mehr Freiheiten bei der Konfiguration. Wobei man bei absoluter Platznot mit einem FT230 im QFN16 und erst recht dem FT234 im DFN10 Gehäuse noch etwas kleiner werden könnte als es mit den PIC möglich ist! Die Vorgabe das der jetzige µC bleiben soll ist aus meiner Sicht im Übrigen durchaus verständlich. Da lohnt ein Ersatz nur wenn Ihr wirklich hohe Stückzahlen produziert. Ansonsten holt Ihr die Entwicklungsmehrkosten nie wieder raus. So ein Programm ist ja nicht mal eben so umgestellt, da müssen zwei Funktionen miteinander verheiratet werden und dann muss getestet, getestet, getestet und dokumentiert werden. Falls die andere Firmware auch noch umfangreich und Zeitkritisch ist können schnell alleine für die Endgültige Firmware 1 - x Mannwochen raus werden.! (Natürlich nicht wenn die Schaltung nur einfachste Funktionen erfüllt) Dagegen ist man mit dem einfachen dazwischenpflanzen eines ConverterIC innerhalb eines Tages durch! > Plötzlich heißt es, dass Layoutänderungen jeglicher Art nicht erlaubt > sind. > Es soll "irgendwas" zwischen den jetzigen DB9 Stecker im Deckel des > Gehäuses und der Elektronik...(das war vor 2 Wochen noch nicht der > Fall). > [...] > Nur der DB9-Stecker darf entsprechend für einen USB-Connector getauscht > werden, ansonsten soll die Platine so bleiben wie sie ist. Werde hier noch einmal genauer... Wie ist das jetzt mit dem Seriellen Stecker? ISt der Steckel aussen am Gehäuse befestigt und dann geht eine Leitung auf die Platine? So wie es vor langer Zeit (AT Zeiten) mal mit der jeweils zweiten RS232 Buchse im PC war? Mit der Folge das wirklich ÜBERHAUPT NICHTS an der Platine geändert werden soll? ODer aber ist doch ein Winkelstecker montiert und du darfst in dem Bereich wo der montiert ist änderungen vornehmen aber den ganzen Rest sollst du in Ruhe lassen. (Das ist je nach Stückzahl durchaus verständlich...)? Im ersten Fall würde dir keine andere Wahl bleiben als mit einer zusatzplatine zu arbeiten . Evtl kann man die wenigsten auf einen jetzt schon für RS232 vorhandenen Pfostenstecker o.ä. auf der Hauptplatine aufstecken/Auflöten. Sonst Irgendwo im GEhäuse verbauen mit allen mechanischen Problemen was oft im Pfusch endet und wo man gleich ein USB Adapterkabel nehmen könnte... Wenn du zumindest die Minimalen Änderungen im Bereich des Steckers vornehmen kannst, dann würde ich halt mal schauen ob der Platz nicht doch reicht. Mit etwas Glück kann das gut klappen! Im Notfall kannst du mit 3x3mm + dem Platz für den USB Anschluss selbst selbst (Buchse, Kabel oder Pfostenleiste) auskommen! Das "größere" Layoutänderungen bei einem bestehenden und funktionierenden Produkt nur für die Umstellung der Schnittstelle nicht gemacht werden sollen ist im übrigen wie beim µC Tausch durchaus häufiger üblich. (Und gut verständlich). Aber das wirklich absolut NICHTS verändert werden darf würde mir schon zu denken geben. Ausser die Fa hat noch ettliche Kilo an Leiterplatten auf lager. Dann macht das schon Sinn. In allen anderen Fällen aber würde mich das am "Verstand" gewisser Personen zweifeln lassen. Christian R. schrieb: > Bei FTDI gibts Adapter, die in das Pinout eines DB9 passen. Perfekt für > Cheffe. Dann noch im Treiber den Haken für VCP rausnehmen und es > erscheint kein COM mehr. Dann kannst du über o.g. D2XX zugreifen Diese Adapter sehen auf dem ersten Blick praktisch aus, aber wenn man nach dem Preis schaut wird einem schlecht. Falls es sich nicht um ein Gerät handelt das nur in absoluten Kleinststückzahlen mit hohen Gewinnmargen gebaut wird dürfte "Cheffe" Max diesen Vorschlag um die Ohren hauen! Der Mehrkostenfaktor gegenüber einem Wandler-IC liegt bei >10! Jörg Wunsch schrieb: > Software-USB (wie beispielsweise V-USB) bliebe dir noch, braucht aber > auch ein paar Voraussetzungen: eine der beiden Datenleitungen muss an > einen interruptfähigen Pin, du brauchst einen Widerstand, der das > Gerät als lowspeed-USB gegenüber dem Host ausweist, und der Takt muss > zumindest aus einem Keramikresonator stammen, oder man muss mit dem > RC-Oszillator deutlich über 16 MHz gehen, was für den alten ATmega16 > den garantierten Betriebsbereich verlässt. V-USB kostet aber für kommerzielle Anwendungen auch Geld und ist dabei wohl die schlechteste aller Alternativen. Von den Vorraussetzungen die du schon geschrieben hast bedeutet das auch wieder einen massiven Eingriff in das bestehende Programm mit allen Folgen. Also genau der Zeitintensivste Schritt um danach die schlechtmöglichste Lösung zu finden! Dann doch deutlich lieber eine ordentlich befestigte Zusatzplatine irgendwo im Gehäuse! Gruß Carsten
:
Bearbeitet durch User
Angehängte Dateien:
-
RS232.PNG
160 KB
Guten Morgen wieder... um die Frage zu der DB9-Buchse kurz zu beantworten. Ja, also die Buchse ist im Gehäusedeckel verbaut und dann mit nem Flachbandkabel auf der Platine versteckt. Wurde glaube ich gemacht weil auf dem Deckel eine Folientastatur sitzt, die soweit ich weiß auch nur auf diese Weise angeschlossen werden kann. Die Idee mit den fertigen FTDI Adaptern hatte ich auch schon, auch wenn der Preis wirklich nich ganz ohne ist. Es geht aber wie gesagt nur darum, 1-2 "sinnvolle" Lösungen anzubieten. Es ist völlig OK wenn später gesagt wird "wird nicht gemacht weil zu teuer etc.". Allerdings ist mir da nun aufgefallen, dass die PIN-Belegung für den DB9 Stecker nicht dem RS232 Standard entspricht, wodurch diese Lösung dann schon wieder weg fällt ?! Ich häng euch mal ein Teil vom Datenblatt an. Das scheint mir extra für das Handterminal "angepasst" worden zu sein.
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.