Gibt es ein fertiges Projekt, bei dem ein Atmega einen virtuellen USB-COM-Port bereitstellt? Habe hier ein Gerät, das derzeit an einen normalen COM-Port unter Win XP Daten übermittelt (MAX232 zwischengeschaltet). Das ganze soll längerfristig an einem Rechner betrieben werden, der keine echte RS232-Schnittstelle mehr hat. Es werden nur die Leitungen Rx und Tx verwendet. Super wäre, wenn ich einen Atmega (z.b. M88) mit der entsprechenden Software flashen und dazwischenschalten könnte.
Armin schrieb: > Super wäre, wenn ich einen Atmega (z.b. M88) mit der entsprechenden > Software flashen und dazwischenschalten könnte. warum nicht ein USB-Seriel Wandler dazwischenschalten. z.b. CP2104
> Gibt es ein fertiges Projekt, bei dem ein Atmega einen virtuellen > USB-COM-Port bereitstellt? Ja, V-USB zum Bleistift. Aber warum so kompliziert und nicht einfach einen fertigen USB-UART-Wandler nehmen? Iss billiger, zuverlässiger und weniger Aufwand.
VUSB wäre ein Software-USB Stack der auch auf normalen AVRs läuft. Sonst würde sich eher ein µC mit HW-USB angbieten (z.B. Atmega32U4). Billig, sicher und zuverlässig würde ich aber auch zu USB/UARTs wie dem genannten CP oder FTDI FT232 o.ä. raten. Alternativ eine USB/RS232 Adapterkabel... damit sparst du dir jede Art von Anpassung.
Wie soll denn ein ATMega einen virtuellen COM-Port simulieren? Ein virtueller COM-Port ist eine Treiberstruktur innerhalb von Fenst-DOS. Es gibt aber ein paar Firmen (z.B. FTDI), die device driver zu ihren Chips bereitstellen. Sollte so etwas von anderer Seite (z.B. auch Atmel) geben, so wäre es doch nur ein Programm innerhalb des Fensters.
Amateur schrieb: > Wie soll denn ein ATMega einen virtuellen COM-Port simulieren? genauso wie es jeder USB-Seriel Adapter auch kann. > Ein virtueller COM-Port ist eine Treiberstruktur innerhalb von > Fenst-DOS. Unsinn, ein COM-Port ist eine Definierte Treiberschnittstelle innerhalb von Windows. Ob er dabei echt oder Virtuell ist spielt keine Rolle.
VUSB ist nicht 100% USB2 kompatibel, weil es in wesentlichen Punkten gegen den Standard verstößt. Insbesondere mit neuen Windows-Versionen sind Probleme vorprogrammiert. Nimm einfach einen MCP2221. DIL-Bauform erhältlich, treiberlos (Windows will ein .inf sehen, aber kein spezielles Binary), geringer Schaltungsaufwand, und I2C hat der auch noch gleich mit bei. Dafür lohnt kein Stress. Und wenn Du eigenen Code auf dem Chip haben willst: das ist eigentlich ein vorprogrammierter PIC16F1455, der billigste Microcontroller mit zertifiziertem Full Speed USB Hardware Interface. fchk
Frank K. schrieb: > VUSB ist nicht 100% USB2 kompatibel Nichtmal zu USB1.0. Auch da waren schon keine Bulk-Transfers für LowSpeed-Devices erlaubt. Der Punkt ist nur: sie haben trotzdem jahrelang funktioniert, erst die künstliche Kastration der OS-Treiber auf die Vorgaben der Norm fast ohne jeden (technischen) Grund hat dem ein Ende gesetzt. > Nimm einfach einen MCP2221. Das ist trotzdem sicher die bessere Wahl.
OBACHT: das Datenblatt schreibt: Note: MCP2221 supports only eight data bits, No Parity and one Stop bit. Außerdem kann der nur max. 115200 Baud. Ja, normal ist beides kein Problem - ansonsten gibt's den FT232RL.
Zusätzlich ist er einzeln teurer als ein kompletter 201423072973 bei Ebay
Armin schrieb: > Gibt es ein fertiges Projekt, bei dem ein Atmega einen virtuellen > USB-COM-Port bereitstellt? Arduino - IMHO alle, die einen USB-Stecker auf dem Board haben.
Armin schrieb: > Gibt es ein fertiges Projekt, bei dem ein Atmega einen virtuellen > USB-COM-Port bereitstellt? Ja, jedes mit atmega32u2/atmega32u4 kann das. Die Mega32Ux haben eine echte USB-Schnittstelle und lassen sich u.a. als CDC-Serial benutzen
Danke für die vielen Antworten und Ideen! Habe hier zwei USB-to-Serial-Module mit CP2402 und CP2102. Das eine funktioniert gar nicht für die genannte Anwendung (57600/8/N/1) und das andere nur hin und wieder. Die echte serielle Verbindung funktioniert dagegen quasi immer.
Deshalb suche ich eine zuverlässige Lösung, die Tx und Rx vom Gerät auf USB bringen kann. Werde erst mal das mit Attiny45 hier probieren: http://www.recursion.jp/prose/avrcdc/cdc-232.html
Armin schrieb: > Deshalb suche ich eine zuverlässige Lösung, die Tx und Rx vom Gerät auf > USB bringen kann. > > Werde erst mal das mit Attiny45 hier probieren: > http://www.recursion.jp/prose/avrcdc/cdc-232.html genau das ist aber keine zuverlässige Lösung.
Armin schrieb: > Das eine funktioniert gar nicht für die genannte Anwendung (57600/8/N/1) > und das andere nur hin und wieder. Was heißt "funktioniert" nicht? Ist der Windows Gerätemanager zufrieden? Funktioniert ein normales Terminalprogramm damit (z.B. HTerm)? Kommuniziert dein ATmega nicht richtig mit der PC-Software (welche?)?
Armin schrieb: > für die genannte Anwendung (57600/8/N/1) Armin schrieb: > Werde erst mal das mit Attiny45 hier probieren: > http://www.recursion.jp/prose/avrcdc/cdc-232.html Ich sehe grade, das wird nichts:
1 | ATtiny45/85 uses internal RC oscillator and PLL. |
2 | It is calibrated by USB signal when connected. |
3 | UART is implemented by software. |
4 | It is not enough for high speed data transfer. |
5 | If the TxD and the RxD are inverted (rebuild with - |
6 | DUART_INVERT option), you can directly connect to RS-232C line. |
7 | 1200 - 4800bps, 8N1 |
Armin schrieb: > Deshalb suche ich eine zuverlässige Lösung, [...] > Werde erst mal das mit Attiny45 hier probieren: > http://www.recursion.jp/prose/avrcdc/cdc-232.html Warum sollte das jetzt mit einem Baiteil, das keinen USB-Port hat besser funktionieren als mit einem, das einen hat? VUSB ist alles andere als zuverlässig und je neuer das Betriebsystem desto schlechter funktioniert es.
Armin schrieb: > Danke für die vielen Antworten und Ideen! > > Habe hier zwei USB-to-Serial-Module mit CP2402 und CP2102. > > Das eine funktioniert gar nicht für die genannte Anwendung (57600/8/N/1) > und das andere nur hin und wieder. > > Die echte serielle Verbindung funktioniert dagegen quasi immer. Hmm... Meine Glaskugel sagt: Oft versucht man an den Symptomen zu arbeiten, vergisst aber die Ursache.
Wolfgang schrieb: > Was heißt "funktioniert" nicht? Bei meinen eigenen AVR-Projekten mit niedrigen Baudraten bis ca. 9600 funktionieren beide Module gut. > Ist der Windows Gerätemanager zufrieden? Ich denke ja, er meckert jedenfalls nichts an. > Funktioniert ein normales Terminalprogramm damit (z.B. HTerm)? Das eine Modul läuft gut unter H-Therm, das andere nur nach H-Therm-Neustart (Timing-Problem). Armin schrieb: > für die genannte Anwendung (57600/8/N/1) Möglicherweise ist das für beide Module etwas hoch. Erzeugen diese CP2x02-Bausteine ihren Takt aus dem USB-Takt mittels PLL? Ein Quarz haben die jedenfalls nicht auf der Modulplatine.
Won K. schrieb: > Warum sollte das jetzt mit einem Baiteil, das keinen USB-Port hat besser > funktionieren als mit einem, das einen hat? > VUSB ist alles andere als zuverlässig und je neuer das Betriebsystem > desto schlechter funktioniert es. Versuch macht kluch :-) - Attiny hätte ich in der Bastelkiste. Leider ist der aber sowieso zu lahm.
Armin schrieb: > Bei meinen eigenen AVR-Projekten mit niedrigen Baudraten bis ca. 9600 > funktionieren beide Module gut. hat denn deine Schaltung ein Quarz?
Ulrich F. schrieb: > Meine Glaskugel sagt: > Oft versucht man an den Symptomen zu arbeiten, vergisst aber die > Ursache. Was sagt die Glaskugel noch zu den möglichen Ursachen?
Hm, der 20.000-kHz-Quarz vom Gerät (NWT) schwingt mit 20.002.600 MHz (+- 50 Hz). Das kommt mir etwas zu hoch vor...
Armin schrieb: > Was sagt die Glaskugel noch zu den möglichen Ursachen? Oszi/LA zur Hand? Ausmessen, wie lang die 8N1 Frames wirklich sind. Von beiden Partnern! Dann erst ist klar, WO die Baustelle ist. Pegel! Signalform. Einstreuungen. Toleranzen usw.... > (WNT) Wäschereitechnik?
Armin schrieb: > Möglicherweise ist das für beide Module etwas hoch. Der CPC2102 ist bis 1Mbps spezifiziert. Ulrich F. schrieb: >> Habe hier zwei USB-to-Serial-Module mit CP2402 und CP2102. Der CP2402 ist ein 128/64 Segment LCD Driver mit SPI. Vielleicht funktioniert er deshalb nicht als USB-to-Serial-Module ;-) https://www.silabs.com/Support%20Documents/TechnicalDocs/CP2400-1-2-3.pdf
Wolfgang schrieb: > Ulrich F. schrieb: >>> Habe hier zwei USB-to-Serial-Module mit CP2402 und CP2102. Ach wenn ich das nicht gesagt habe, möchte ich dir in der Sache nicht widersprechen.
Sorry, mein Fehler. Sind beide CP2102 (Hätte besser gleich eine Lupe benutzt).
Armin schrieb: > Hm, der 20.000-kHz-Quarz vom Gerät (NWT) schwingt mit 20.002.600 MHz (+- > 50 Hz). ja, 20 THz sind für ein 20MHz-Quarz etwas viel.
>> Möglicherweise ist das für beide Module etwas hoch. > > Der CPC2102 ist bis 1Mbps spezifiziert. Nicht nur das, sogar die Billigstmodule von Amazon funktionieren bis mindestens 500kBd einwandfrei - hab mehrere davon im Einsatz. Ich würde den Fehler daher woanders zu suchen beginnen. Hat der TO möglicherweise Uraltsoftware im Einsatz, die sich doppelblauäugig ein gewisses Echtzeitverhalten am der Seriellen erträumt?
Won K. schrieb: > Armin schrieb: >> Hm, der 20.000-kHz-Quarz vom Gerät (NWT) schwingt mit 20.002.600 MHz (+- >> 50 Hz). > > ja, 20 THz sind für ein 20MHz-Quarz etwas viel. Aber mit 50 Hz doch sehr stabil. Vorteiler nehmen? ;-)
Armin schrieb: > Bei meinen eigenen AVR-Projekten mit niedrigen Baudraten bis ca. 9600 > funktionieren beide Module gut. Such mal in den AVR-Programmen, wo die UART-ISR ausgebremst wird. Oder pollst Du noch?
Won K. schrieb: > Armin schrieb: >> Hm, der 20.000-kHz-Quarz vom Gerät (NWT) schwingt mit 20.002.600 MHz (+- >> 50 Hz). > > ja, 20 THz sind für ein 20MHz-Quarz etwas viel. Danke für den Hinweis, es sind natürlich 20.002.600 Hz gemeint.
m.n. schrieb: > Such mal in den AVR-Programmen, wo die UART-ISR ausgebremst wird. > Oder pollst Du noch? Es ist ein NWT mit Pic16F876. Habe auf die Firmware keinen Einfluss. Mit normalem UART -> MAX232 -> Serielle PC-Schnittstelle geht es problemlos.
Ein Quarz am Pic, dass auf 20,000600 MHz schwingt, bringt auch keine Änderung der CP2102-Problematik.
> Ein Quarz am Pic, dass auf 20,000600 MHz schwingt, bringt auch keine > Änderung der CP2102-Problematik. ..das wären dann 0.003% Abweichung gegen 20MHz - Du bellst den falschen Baum an. Fang doch mal ganz banal an: Halt ein Ossi dran und schau Dir die Signale an.
Ok, ich klemme einen LA als Abhörposten an. Dauert aber ein bisschen...
Angehängte Dateien:
Im Anhang ein "Mitschnitt" der seriellen Kommunikation zwischen PC-Programm und PIC. Oben PC, unten PIC. PC sendet, PIC antwortet nach kurzer Verzögerung, alles gut :O) Gleich folgt ein Bild mit USB-to-UART-Modul (CP2102).
Angehängte Dateien:
Hier ein Bild mit USB-to-UART-Modul (CP2102), wenn die Kommunikation funktioniert.
die beiden Übertragungen sehen recht unterschiedlich aus, da musst du schon ein paar Worte dazu sagen, was man dort sieht.
Abgefahren, jetzt funktioniert das USBtoUART-Modul anscheinend immer. Für den Logic Analyzer musste ich in der Systemsteuerung die Interrupts für LPT und COM "enablen", seitdem funktioniert das Modul klaglos, wie es scheint. Anscheinend hin das irgendwie zusammen. Werde das noch mal eine Weile beobachten...
Armin schrieb: > Für den Logic Analyzer musste ich in der Systemsteuerung die Interrupts > für LPT und COM "enablen", seitdem funktioniert das Modul klaglos, wie > es scheint. > Anscheinend hin das irgendwie zusammen. nein bestimmt nicht. Auf USB hat das keine Auswirkung. Eventuell beeinfluss der LA das Timing auf dein PC und du hast nur ein Softwareproblem.
Peter II schrieb: > die beiden Übertragungen sehen recht unterschiedlich aus, da musst du > schon ein paar Worte dazu sagen, was man dort sieht. Danke für die schnelle Antwort! Das war mir auch aufgefallen. Es ist einfach nur die Standby-Kommunikation, wenn der Pic grade nichts steuert und auf Befehle vom PC wartet.
Armin schrieb: > Das war mir auch aufgefallen. Es ist einfach nur die > Standby-Kommunikation, wenn der Pic grade nichts steuert und auf Befehle > vom PC wartet. bei der ersten Übertragung wird Gleichzeit gesendet und empfangen, bei der 2.nicht. Ist recht ungewöhnlich bei einer einfachen Kommunikation.
Peter II schrieb: > Eventuell beeinfluss der LA das Timing auf dein PC und du hast nur ein > Softwareproblem. "nur" ist gut ;O) Hm, dann muss ich jetzt immer den LA anschließen, damit das timing vom USBtoUART-Modul funktioniert??? Werde das mal im Auge behalten und berichten...
Peter II schrieb: > bei der ersten Übertragung wird Gleichzeit gesendet und empfangen, bei > der 2.nicht. > > Ist recht ungewöhnlich bei einer einfachen Kommunikation. Finde ich auch.
Ach so, den Parallelport hatte ich noch im Bios von ECP/EPP auf EPP umgestellt. Und wie gesagt in der Systemsteuerung die Interrupts für LPT und COM aktiviert. Ob es (in)direkt damit zusammenhängen kann - keine Ahnung. Spontan würde ich sagen nein.
Armin schrieb: > Hm, dann muss ich jetzt immer den LA anschließen, damit das timing vom > USBtoUART-Modul funktioniert??? alternativ den Fehler beheben.
Hast du einen konkreten Verdacht (ausser, dass der LA das Timing beeinflussen könnte)?
Armin schrieb: > Hm, dann muss ich jetzt immer den LA anschließen, damit das timing vom > USBtoUART-Modul funktioniert??? Ich denke eher, das Du damit ein Masseproblem behoben hast das sonst vorliegt.
Won K. schrieb: > Ich denke eher, das Du damit ein Masseproblem behoben hast das sonst > vorliegt. Negativ. Es funktioniert jetzt auch ohne den LA. Ulrich F. schrieb: > Glückwunsch! Vielen Dank! Hier noch mal kurz eine kleine Dokumentation, falls jemand das gleiche Problem haben sollte. Habe in anderem Zusammenhang folgendes am System verändert: - Parallelport im Bios von ECP/EPP auf EPP (bidirektional) geschaltet - die Datei install_giveio.bat (von WinAVR) ausgeführt - im Gerätemanager bei "Druckeranschluss(LPT1)" beim Reiter Anschlusseinstellungen "Jeden dem Anschluss zugewiesenen Interrupt verwenden" angeklickt. Seitdem funktioniert die USB-UART-Kommunikation von der PC-Software WinNWT4 (HFM9) mit dem NWT über verschiedene CP2102-Module reibungslos. Danke an alle hier und viele Grüße!
Armin schrieb: > Danke an alle hier und viele Grüße! naja, mir würde das keine Ruhe lassen. Hast du einen jungfräulichen PC mit dem du es noch mal Testen kannst? Zur not sollte es auch eine VM tun.
Ich hätte auch gerne gewusst, woran es jetzt gelegen hat. Ein anderer Verdacht geht in eine ganz andere Richtung: Wenn das Gerät mit dem PIC abgeschaltet ist, liegt trotzdem eine geringe spannung von knapp 2V auf VCC, weil Kriechströme vom USB-Modul durch die Leitung Tx (bzw. Rx) dort hin gelangen. Diese geringe Spannung stört eventuell beim Einschalten/Initialisieren den PIC (weil der möglicherweise schon vorher irgendwas macht mit der geringen Spannung?!?).
Armin schrieb: > weil Kriechströme vom USB-Modul > durch die Leitung Tx (bzw. Rx) dort hin gelangen Da kriecht kein Strom, der fließt ganz normal aus den USB-5Volt über den TX-Pin in den PIC und da über die Schutzdioden des PortPins auf Vcc. Dein Pic16F876 ist im Datenblatt mit 2-5,5Volt Betriebsspannung angegeben, er war also vermutlich nie wirklich aus.
Won K. schrieb: > Da kriecht kein Strom, der fließt ganz normal aus den USB-5Volt über den > TX-Pin in den PIC und da über die Schutzdioden des PortPins auf Vcc. Sehe ich auch so. > Dein Pic16F876 ist im Datenblatt mit 2-5,5Volt Betriebsspannung > angegeben, er war also vermutlich nie wirklich aus. Oder er hat sich zwischen "aus" und "an" irgendwo verlaufen. Werde das auf jeden Fall alles im Blick behalten - wenn es neue Erkenntnisse gibt, werden sie hier gepostet.
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.