Hi, ich hab mir vor kurzem den USB-UART Converter bei Conrad gekauft: http://www.conrad.de/ce/de/product/197326/MINI-USB-TO-UART-CONVERTER Nun hab ich ein paar Probleme überhaupt eine Verbindung herzustellen. Ich hab zunächst den Converter beschaltet, sprich GND,Vcc angeschlossen, TXD 3,3V an TTL Driver Input und zum Test RXD an TXD. Auf der beigelegten Kompaktdisk ist, warum auch immer, nichts drauf, also hab ich den Coverter einfach en den USB-Port meines Notebooks angeschlossen. Daraufhin wurde von Windows 7 recht schnell ein Treiber gefunden und installiert. Als Terminalprogramm wollte ich eigentlich SnoopyPro verwenden, allerdings komme ich hier nicht weiter. Ich hab null Plan was jetzt zu tun ist. Muss man den Converter iwie mit SnoopyPro verbinden? Und wie soll das gehen (unter USB Devices finde ich nur eine Liste mit für mich völlig unverständlichen Angaben...). Kann mir bitte jemand weiterhelfen? Danke Gruß Luke
Guck mal im Gerätemanager unter Serielle Schnittstellen bzw. comports. Dann zieh den USB-Seriell-Wandler einfach raus. Welcher com Port verschwindet ? Das ist dein Com Port mit dem du dich verbinden kannst.
Lade dir mal hterm herunter und starte es bei abgestöpseltem Adapter. Öffne die Liste der verfügbaren COM-Ports in hterm und merke sie dir. Wenn du dann den Adapter anstöpselst drückst du auf das "R"(refresh) neben der Liste in hterm. Jetzt sollte ein weiterer COM-Port dazu gekommen sein. Das sollte er sein. Falls nicht: - Was für ein Chipsatz ist auf dem Wandler FT232 oder CP1xx?
mein nachbar hat sich nach frustrierenden versuchen ne cardbus/pcmcia karte zugelegt. die ging sofort. da hat man ne echte rs232 schnittstelle. mein bastel pc hat alle nötigenn schnittstellen on board... usb2 , lpt , rs232 da hat man die auswahl und weniger bis keinen frust. mfg
Ist hTerm nicht nur für serielle Ports? Ich habe leider keine seriellen; nur USB-Ports. Die Suche im Gerätemanager ergab COM 18, der Port ist mit "Silicon Labs CP210x USB to UART Bridge (COM18)" beschriftet. Als Ort wird Port_#0004.Hub_#0004 angegeben. Bleibt noch die Frage wie man sich jetzt mit diesem Port verbindet.?
>Ist hTerm nicht nur für serielle Ports?
Das, was du da gekauft hast, IST ein serieller Port! Der wird bloß über
USB-Chip und speziellem Treiber simuliert.
Luke schrieb: > Ist hTerm nicht nur für serielle Ports? Ich habe leider keine seriellen; > nur USB-Ports. Die Suche im Gerätemanager ergab COM 18, der Port ist > mit "Silicon Labs CP210x USB to UART Bridge (COM18)" beschriftet. Als > Ort wird Port_#0004.Hub_#0004 angegeben. Bleibt noch die Frage wie man > sich jetzt mit diesem Port verbindet.? Das macht das Programm auf dem PC wie bei jedem anderen COM-Port auch, außer es weiß nicht, wie mit Port-Nummern größer 9 umzugehen ist. http://support.microsoft.com/kb/115831 Funktioniert die Software nicht mit Port-Nummern > 9, kann die Port-Nummer noch im Gerätemanager festgelegt werden: Dort Silicon Labs ... auswählen -> Eigenschaften -> Erweitert
Andreas schrieb: >>Ist hTerm nicht nur für serielle Ports? > > Das, was du da gekauft hast, IST ein serieller Port! Der wird bloß über > USB-Chip und speziellem Treiber simuliert. Ich meinte das in Bezug auf die Ports des PCs, bzw Notebooks
Also ich hab mir mal hTerm runtergeladen und damit lies sich die Bridge wirklich finden und auch verbinden (zumindest der COM18 Port). Wenn ich jedoch etwas sende, bekomme ich keine Antwort(eigentlich müsste ich das selbe zurückbekommen was ich geschrieben habe; TXD an RXD)
UART = serielle Schnittstelle
Dein PC hatte bisher keine, nur USB. Jetzt hast Du USB <-> UART
(=serielle Schnittstelle = COM18 bei Dir).
Jedes Programm, das eine serielle Schnittstelle bedienen kann/will, kann
jetzt über den USB-Wandler auf eine virtuelle serielle Schnittstelle
zugreifen.
> Ich meinte das in Bezug auf die Ports des PCs, bzw Notebooks
Wie sonst?? Ein Gerät mit serieller Schnittstelle bekommt durch den
Umsetzer keinen USB-Port! (sowas geht nur für gaaanz wenige Anwendungen
mit gaaaanz speziellen Umsetzern)
unn wech
Bernhard
Luke schrieb: > Also ich hab mir mal hTerm runtergeladen und damit lies sich die Bridge > wirklich finden und auch verbinden (zumindest der COM18 Port). Wenn ich > jedoch etwas sende, bekomme ich keine Antwort(eigentlich müsste ich das > selbe zurückbekommen was ich geschrieben habe; TXD an RXD) Wow, ok. Die Baudrate wurde noch nicht übernommen, jetzt läufts. Danke an alle :).
Bernhard Spitzer schrieb: > UART = serielle Schnittstelle > Dein PC hatte bisher keine, nur USB. Jetzt hast Du USB <-> UART > (=serielle Schnittstelle = COM18 bei Dir). > Jedes Programm, das eine serielle Schnittstelle bedienen kann/will, kann > jetzt über den USB-Wandler auf eine virtuelle serielle Schnittstelle > zugreifen. > >> Ich meinte das in Bezug auf die Ports des PCs, bzw Notebooks > Wie sonst?? Ein Gerät mit serieller Schnittstelle bekommt durch den > Umsetzer keinen USB-Port! (sowas geht nur für gaaanz wenige Anwendungen > mit gaaaanz speziellen Umsetzern) > > unn wech > Bernhard hmm ja. Sorum betrachtet macht das sogar Sinn ^^
Waahnsinn 15 Euro!!! Die kauf ich in der Bucht für 1,90 das Stück und dann haben die noch gleich die praktische "USB-Stick-Form". Mit den dummen treibt man wohl die Welt um.... gruß cyblord
cyblord ---- schrieb: > Die kauf ich in der Bucht für 1,90 das Stück Der arme Conrad muß doch auch irgendwie leben ...
Habe gerade welche für Euro 2,15 das Stück bei ebay gekauft. http://www.ebay.de/itm/1pcs-USB-2-0-to-TTL-UART-6PIN-Module-Serial-Converter-CP2102-STC-PRGMR-/251039347548?pt=LH_DefaultDomain_0&hash=item3a731c735c Der Conrad Preis ist echt unverschämt.
Hallo, ich hätte da noch eine weitere Mögllichkeit anzubieten, die dir evt. gefallen könnte. Kommt natürlich darauf an ob du das mit deinem Gehäuse vereinbaren kannst. Klick mich ;) http://www.tim-erler.de/USB_UART2.php LG Tim
Wenn du den Wandler in hterm findest und hast Rx und Tx am Wandler gebrückt, dann muss das was du sendest auch direkt wieder im Empfangspuffer und an hterm landen. Wähle mal als Baudrate so 9600, um ganz sicher zu gehen. Wenn das nicht der Fall ist, dann ist definitiv etwas faul. Die Treiber aus der Windows-Datenbank für den Cypress-Chip sollten eigentlich problemlos laufen. Manchmal gibt es Ärger mit virtuellen Bluetooth-Com-Ports oder so, aber das ist mir immer nur früher unter WinXP begegnet. Seither arbeite ich auch nur noch mit dem FT232 von FTDI, der macht genau das gleiche. Die Treiber und Empfangsstufen sind sehr unempfindlich und machen sogar fliegende Verdrahtung bei 512k mit. Wenn du also nach einer Alternative schaust, dann hol dir einen fertigen mit FT232-Chipsatz (z.B. 251044332173) und achte darauf, dass du zwischen 3,3V und 5V Pegel wählen kannst. Auch ich finde den Conrad-Preis ganz schön happig. Da kriegst du ja schon fast einen USBprog für. Die neue Version hat sogar ständig parallel einen virtuellen COM-Port->UART aktiv (allerdings schon wieder der CP210x). Da du aber jetzt das Problem schon hast und das Teil wahrscheinlich nicht zurückgeben wirst, musst du erstmal mit der Brückung von Rx und Tx weiterprobieren. Schau mal ob du es mit neuen Treiber oder eben alten Treibern von hier - http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx - zum laufen bringen kannst. Treiber komplett runterschmeißen, neu drauf und ggf. mal COM-Port auf einen niedrigeren, nicht benutzten Port, setzen. Auch wenn in der Auswahlliste in den Eigenschaften des CP210x (verwendet) steht, kannst du meistens auf diesen COM-Port gehen, wenn im Gerätemanager unter "Anschlüsse LPT/COM" der Port gerade nicht verwendet wird. Dann das gleiche Spiel bei gebrücktem Rx/Tx in hterm bei 9600baud wieder probieren und evtl neu starten. @Tim's Eigenwerbungs-Board: Das Layout ist die abgespeckte FTDI-Appnote. Verpass ihm wenigstens noch einen Jumper zur Wahl zwischen 3,3V und 5V am VCCIO für die Pegelwahl. Außerdem sollte man zwischen direkter Speisung und Speisung über eine Schottky wählen können bzw. gleich über eine Schottky speisen, damit das Zielboard auf keinen Fall in den USB-Anschluss "zurückschießen" kann. Daher gerne auch Strombegrenzende Widerstände an Rx/Tx, wenn mal wieder jemand nicht über kreuz angeschlossen hat. Außerdem schadet RTS/CTS nicht, da man es toll für zusätzliche Steuersignale mißbrauchen kann und den Oszillatorausgang kann man sowohl direkt als Clock-Basis im Zielboard nehmen, oder als "Rescue-Clock" bei verfusten Atmegas. Mit den CBUSx kann man auch noch nette Sachen machen, aber die braucht man eigentlich nicht. Am mini-USB-Stecker über Pin4 nicht USB-OTG auf "Host" setzen, mach mal die Verbindung an der 4 zu GND weg, sollte aber am normalen USB-A PC-Port nichts ausmachen. Schau dir mal die Layouts von USBprog und Ulrich Radigs FT232-Board an.
Ich hatte eigentlich auch vor mir selbst einen USB Uart Converter mit FT232 zu bauen, da wäre wenigstens ein Hardware Handshake möglich. Allerdings hat das aus bestimmten Gründen ziemlich lange gedauert. Darauf hab ich dann das erst beste genommen, was iwie passte. Ich hätte allerdings noch eine andere Frage: Kennt jemand eine gute Quelle/Anleitung/Tutorial wo erklärt wird,wie man in einer PC-Anwendung (am besten C++) mit dem µC über die Bridge kommunizieren kann?
Luke schrieb: > Kennt jemand eine gute Quelle/Anleitung/Tutorial wo erklärt wird,wie man > in einer PC-Anwendung (am besten C++) mit dem µC über die Bridge > kommunizieren kann? Annähernd jedes Beispiel, in dem beschrieben wird, wie eine serielle Schnittstelle angesteuert wird.
Die meisten C-Programme greifen dann doch auf C# und .NET zurück und das macht keinen Spaß. Unter Windows ist der Zugriff auf die serielle Schnittstelle insgesamt sehr ätzend. Wenn du mal irgendwann mit Delphi oder Pascal Berührungspunkte hattest und nur eine flinke kleine Bedienoberfläche mit ein paar Buttons brauchst, dann bist du mit Lazarus oder Delphi zusammen mit der Synaser-Library unter Windows ganz gut beraten. Sonst würde ich es erst gar nicht manuell in C++ probieren, sondern gleich unter Visual Studio 2010+ in C# auf die Serial Port Communications Toolbox zurückgreifen.
René B. schrieb: > Die meisten C-Programme greifen dann doch auf C# und .NET zurück und das > macht keinen Spaß. Das dürfte kein einziges C-Programm tun, da hast Du wohl was durcheinandergebracht. C-Programme nutzen üblicherweise mehr oder weniger direkt die Win32-API, und die ist ausreichend dokumentiert, und es gibt ausreichend funktionierende Beispiele dafür. Plattformunabhängig bekommt man das auch mit C++ (echtem C++, nicht dieser MS-Perversion namens "C++/CLI") hin, so z.B. hiermit https://iftools.com/opensource/ctb.en.php
Hi > Unter Windows ist der Zugriff auf die serielle >Schnittstelle insgesamt sehr ätzend. Übertreibe mal nicht. Das bischen DCB-Gedödel und CreateFile ist nun wirklich nicht die Welt, wenn man es verstanden hat. MfG Spess
spess53 schrieb: > Hi > >> Unter Windows ist der Zugriff auf die serielle >>Schnittstelle insgesamt sehr ätzend. > > Übertreibe mal nicht. Das bischen DCB-Gedödel und CreateFile ist nun > wirklich nicht die Welt, wenn man es verstanden hat. > > MfG Spess /sign Die Windows Api mit CreateFile funktioniert wunderbar. gruß cyblord
@rufus Was ich meinte ist natürlich, dass ihn ähnlich gewohnter Umgebung zu C heute in halbwegs verständlicher Weise in C# unter Nutzung von .NET die serielle Kommunikation komfortabel abgewickelt werden kann. Konkret die Klasse "SerialPort" in "System.IO.Ports". Wenn man sich aber mal das geknödel anschaut, wenn man es direkt mit der Windows-API in C/C++ machen möchte, dann ist das echt kein Spaß mehr um mal schnell was runter zu tippen und am laufen zu haben. Und wenn das Programm mal abstürzt hängt der Port und oft hilft nur ab und wieder anstöpseln. Zu WinXP-Zeiten manchmal sogar nur ein Neustart. Unter Linux ist die serielle Kommunikation in C/C++ auch ohne POSIX-termios bequem zu handhaben und gut verständlich, wenn man dann mal versucht das ganze als "self-documenting-code" unter Windows zu machen, ist das gelinde gesagt "gewöhnungsbedürftig". Daher lieber auf was vorgefertigtes zurückgreifen. Die SynaSer-Lib läuft unter Windows und Linux, allerdings eben in FreePascal, was für eine einfache Anwendung mit ein paar Konfig-Buttons unter Lazarus/Delphi dicke genügt. Wenns unter Windows sein muß, dann lieber C#/.NET-"SerialPort"-Klasse s.o.
Ich würde am liebsten mit Qt programmieren; ich hab allerdings keine Ahnung ob das die Verwendung von anderen System wie zb der WinAPI ausschließt... Ich bin auf der Seite von Silicon Labs noch auf USBXpress gestoßen. Lässt sich das als Kommunkationsmittel benutzen?
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.