USB mittels COM-Befehlen programmieren

Hi,

ciao - Thomas

Wunderbar.

USB-RS232 Adapter kaufen, Treiber installieren, den erzeugten COM-Port in deiner Komponente verwenden, fertig.

Hi!

FT232R ->

mfg Jan

Hallo Wolfgang,

Genau so mach ich das auch. klappt sogar mit bitmanipulationen auf den einzelnen Leitungen. Nur das eben mit den USB-typischen Zeiten. Unter ein paar ms sollte man da nicht zugreifen wollen. Neuerdings haben wir ein paar Problemchen mit USB-Seriell-Wandler mit dem ark3116 Chip. Da scheinen die Treiber für Windoof nicht so stabil zu sein. Wenn alles nach Plan klappt geht alles, aber wehe man schließt z.B. Hyperterm, solange noch Daten vom µC gesendet werden, dann ist ein kompletter Neustart von Windoof fällig, vorher geht mit der Schnittstelle nichts mehr. Mit den Prolific-Chips gabs keine Probleme, obwohl die IMHO vom Chip selbst identisch sein sollten. Also aufgepasst und gut getestet!

Marte

Wolfgang Weinmann schrieb:

Das ist keine gute Idee. Wie kommt dein Programm mit welche Schnittstelle der Comportredirector vergeben hat? Von Hand eingeben? Was ist wenn der Benutzer für irgendwas ein gleichen USB Wandler verwendet?

Warum nimmst du nicht einfach die fertigen Treiber von FTDI oder Silabs, bindest das in dein Programm ein und gut ist. Ich glaube FTDI haben auch was für Delphi.

Alles andere ist üble Bastelei, die man keinen Kunden zumuten kann. Es sei denn du brauchst das nur für dich, aber das schrubst da ja nicht.

lantronix ?

Metabastler schrieb:

oder besser Tomatensalat?

Moin Wolfgang,

Wolfgang Weinmann schrieb:

Ich habe so etwas mal mittels Handykabel gemacht. Zum Beispiel USB-Kabel für Siemens SL-45 (Nokia geht aber auch bei bestimmten Typen, musst halt nur darauf achten, dass der Wandler im Stecker oder im Kabel ist) von ebay für ca. 3-4 Euronen samt Treiber-CD. Im USB-Stecker ist der Wandler schon drin, beim Einstöpseln wird der Treiber angefordert und ein virtueller COM-Port angelegt, den man dann wie einen normalen COM-Port ansprechen kann (ich hab es mit Profan² gemacht

TX vom USB-Kabel habe ich dann einfach mit RXD des Controllers verbunden. Die Anschlussbelegung muss man halt selbst rausfinden, da sie immer anders ist. Den Handystecker kann man ja abschneiden und durch einen eigenen ersetzen oder halt das Kabel direkt am Gerät anbringen. Ich empfehle, darauf zu achten, dass das Kabel abgeschirmt ist (können die meisten ebay-Höker allerdings selten vorweg zusichern). Mit jeder Lieferung bekommt man u.U. auch ein anderes Kabel, obwohl fürs gleiche Handy. Ein weiteres "Problem" ist halt, dass verschiedene Kabel eventuell auch verscheidene Treiber benötigen. Bei einer Großserienfertigung kann es hier Nachschubprobleme geben. Einfach ist es jedenfalls und als Bastellösung sehr günstig.

HTH + Grüße

Kai

det?

Gru=DF

Wolfgang

Wolfgang Weinmann schrieb:

Zur Klarstellung: FTDI ist ein Hersteller von USB/RS232-Konverterbausteinen, früher bekam man mit diesem Baustein aufgebaute Konverterdongle auch im Elektronikmarkt, allerdings sind die dort mittlerweile von Prolific-Chips verdrängt worden.

FTDI-Chips erfreuen sich allerdings weiterhin bei Leuten großer Beliebtheit, die die USB-Seriell-Konvertierung direkt in ihr Gerät einbauen wollen, weil die Bausteine leicht (z.B. bei Reichelt) erhältlich sind.

Neben dem FT232, einem reinrassigen USB-Seriell-Konverter, gibt es auch noch den FT245, der sich dem PC gegenüber auch als serieller Port vorstellt, in Wirklichkeit aber über eine parallele Busschnittstelle verfügt.

Für die FTDI-Bausteine gibt es einerseits herkömmliche VCP-(Virtual Com Port)-Treiber, die sich wie eine normale serielle Schnittstelle ansprechen lassen, andererseits aber auch spezielle Treiber, die bestimmte Vorteile bieten (v.a. beim FT245), deren Programmierschnittstelle aber auch dokumentiert ist.

Alles klar?

Gruß Henning

So ganz raff ich das nicht. Was ich gedacht habe: Ein VCP ist ein Treiber, der es softwaretechnisch erm=F6glicht eine "normalen" seriellen Port zu programmieren und der den realen USB-Port am PC ansteuert. Auch beim Datenempfang habe ich im PC scheinbar einen COM-Port - in Wirklichkeit hat der VCP-Treiber den Dateneingang am USB auf einen scheinnbaren COM-Port umgesetzt.

Das dachte ich.

Das h=E4tte aber zun=E4chst gar nichts mit einem FTDI-USB-USART Konverterchip zu tun. (Nat=FCrlich kann der an den USB angeschlossen werden und ich kann dann ein Ger=E4t mit USART somit am PC mit USB betreiben)

Aber wenn ich mich bei FTDI usw. durchlese, habe ich immer den Eindruck der Treiber hat was mit dem Chip zu tun. Also h=F6rt der Treiber nicht an dem USB-Port auf und interessiert sich nicht, was daran angeklemmt ist, sondern er kommuniziert mit dem USB-USART Konverter.

Uns wenn das so ist, dann vermute ich mal, brauche ich immer einen bestimmten Treiber f=FCr einen bestimmten Konverter ....

Reime ich mir das richtig zusammen?

Gru=DF

Wolfgang

Ja. Genauso wie du verschiedene Treiber für verschiedene USB-Drucker (USB-Papier-Konverter) brauchst du verschiedene Treiber für verschiedene USB-RS232-Konverter.

Auf der Applikationsseite kannst du den USB-Papier-Konverter und den USB-RS232-Konverter dann unabhängig vom Treiber immer auf die gleiche Art ansprechen (als Printer- oder COM-Gerät)

Es ist also wichtig, ob du

a) selbst ein Gerät bauen willst das nach außen USB anbietet aber im innern den Controller mit RS232 ansteuert (was Andreas R. wohl vermutet hat) oder

b) ein Gerät bauen willst das nach außen RS232 anbietet und über einen Elektromarkt-Adapter an USB angeschlossen werden soll (was ich vermute ;-) ) In letztem Fall installiert der Anwender den Treiber des Elektromarkt-Adapters und hat dann einen "normalen" COM Port den deine Anwendung wie gewohnt verwenden kann.

nen

) )

Also ich denke es ist der Fall B:

Ich m=F6chte einen Mikrocontroller mit USART an den PC anschlie=DFen. Da die serielle Schnittstelle am PC eher verschwindet und ich aber kein gro=DFartiger Windows und USB Programmierer bin und ich froh bin, wenn ich mir f=FCr die Applikation eine Delphi Oberfl=E4che zusammengeklickt bekomme, suchte ich eine f=FCr mich m=F6glichste Variante:

PC-Oberfl=E4che unter Delphi, Kommunikation nach au=DFen mit VCP, USB/RS Umsetzer am USB und dort an RS-Seite wieder der Mikrocontroller.

Somit habe ich unter Delphi "nur" einen COM-Port anzusprechen und denke, da=DF das der einfachste Weg ist.

Gru=DF

Wolfgang

Das ist bei A und B gleich.

Der unterschied zwischen A und B ist ob dein selbstgebasteltes Gerät eine USB oder eine RS23-buchse hat. Softwaretechnisch am PC kannst du beide fälle gleich behandeln.

Aber für A muss er selbst einen passenden Treiber (des Herstellers des Konverterchips) mitliefern und installieren lassen, bei B fällt es in den Verantwortungsbereich des Users ob/wie er einen COM-Port bereit stellt :-)

Andreas Koch schrieb:

Der Com-Port-Treiber für die ftdi-Chips ist bei den meisten aktuellen Betriebssystemen schon dabei: Unter Linux garantiert und unter Windows XP AFAIK auch. Falls nicht, wird er sicher bei der Erkennung neuer Hardware (USB-Seriell-Konverter gefunden) nach Anfrage aus dem Web nachgeladen.

Die Beschaltung ist supersimpel (Die Bausteine werden direkt aneinandergeklatscht), und wenn man den Microprozessor mit dem vom FTDI ausgegebenen Takt (z.B. 12MHz) taktet, entfällt auch der Quarz.

Für FTDI-232RL und ATMEGA8 kann ich gerne auch einen Schaltplan mailen.

Gruß, Jürgen

einen

;-) )

Es ist der Fall b). Wenn ich das richtig verstehe, programmiere ich zun=E4chst auf dem PC eine serielle Schnittstelle. Der Treiber tritt zu dem Zeitpunkt noch nicht auf den Plan. Ich kann das Programm auch =FCbersetzen und auch betreiben, wenn ich solch einen VCP-Treiber installiert habe.

Wenn ich meine Mikrocontrollerschaltung an den Kunden ausliefere bekommt er doch das PC-Programm und sonst nichts. Der Kunde kann dann den Treiber, den er f=FCr seinen USB-RS232 Konverter ben=F6tigt installieren und somit mit meinem PC-Programm, seinem Treiber und seinem Konverter auf meine Mikrocontrollerschaltung mit USART zugreifen. Sagt jetzt bitte ja ....

Gru=DF

Wolfgang

Ja, sag' ich doch :-) Du baust ein RS232-Gerät und ob der Kunde einen normalen oder einen USB-RS232-Port hat betrifft nur den Kunden und nicht dein Programm.

(Auch wenns oben schon erwähnt wurde sag ichs sicherheitshalber nochmal: Das trifft nur zu solange es um normalen Datentransfer über die beiden Datenleitungen geht. Für rumspielen an den Steuerleitungen mit irgendwelchen genauen Timings sind USB-Ports unbrauchbar)