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
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?
