mikrocontroller.net

Forum: PC-Programmierung Com-Schnittstellen auflisten ?


Autor: Stefan Seegel (phunky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

weiß jemand wie man unter Windows an die installierten COM
Schnittstellen auflisten kann ? Also z.B. COM1, COM2, COM4, COM16...

Gruß
Stefan

Autor: Ralf Altmann (warpnine)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Geräte-Manager...

Ralf

Autor: Stefan Seegel (phunky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähm, ich meinte in einem Programm, hätte ich vielleicht dazu schreiben
sollen, aber wir sind ja auch im Forum "PC-Programmierung"...

Stefan

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

System.IO.Ports.SerialPort.GetPortNames() ist dein Freund. Und dann war
da noch http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
:-)

Matthias

Autor: Stefan Seegel (phunky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, Zaunpfahl...

Ich versuchs noch etwas genauer:
Ich möchte über die WIN32-API abfragen, welche serielle Schnittstellen
im System vorhanden sind (wie schon festgestellt sieht man selbige auch
im Gerätemanager).
Matthias: Dein Beispiel sieht glaube ich nach Java aus, kann ich leider
nicht.

Ok, hoffe es klappt mit dieser Beschreibung...
Stefan

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stehen in der Registry unter:
HKEY_LOCAL_MACHINE\Hardware\DeviceMap\SerialComm

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

nö. Das ist aus der .NET 2.0 Klassenbibliothek.

Eine Möglichkeit besteht z.B. darin alle möglichen Ports mittels
CreateFile zu öffnen und das Ergebnis passend auszuwerten. Eine andere
Möglichkeit wäre z.B. in der Registry bei
HKEY_LOCAL_MACHINE\Hardware\DeviceMap\SerialComm vorbeizuschauen. Da
sind auch alle COM-Ports aufgelistet.

Matthias

Autor: T.Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht bei der Lösung mit "direkt" in Registry nachschauen.

Esgibt COM-Ports die sich dort nicht verewigen. Beispiel dafür
Infrarotanschluß, Bluetooth oder sonstige "virtuelle" COM-Ports.

Die erste Möglichkeit mit "CreateFile()" alle Ports kurz zu öffnen
und wieder zu schließen braucht leider etwas Zeit (256 mal bei XP).

Die dritte Möglichkeit ist in den SetupDi<XXX> Funktionen

Die vierte ist alle "symbolischen Links" herauszusuchen die
"COM<Nr>"

viel Spaß !

Gruss

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

also die FTDI-Chips mit ihrem virtuellen COM-Port tauchen ganz normale
in der Registry auf.

Matthias

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Esgibt COM-Ports die sich dort nicht verewigen. Beispiel dafür
Infrarotanschluß, Bluetooth oder sonstige "virtuelle" COM-Ports."

Sorry, aber das ist schlichtweg falsch. Sobald diese virtuellen
Schnittstellen sich am PC anmelden erscheinen sie auch dort.

"Die erste Möglichkeit mit "CreateFile()" alle Ports kurz zu öffnen
und wieder zu schließen braucht leider etwas Zeit (256 mal bei XP)."

Das kann unerwünschte Nebeneffekte auf andere Geräte haben. Warum weiss
ich leider auch nicht, aber diese Methode blockiert/entzieht wohl
manchen Geräten die Schnittstelle

Autor: T.Stütz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu "also die FTDI-Chips mit ihrem virtuellen COM-Port tauchen ganz
normale in der Registry auf."

Diese binden sich auch korrekt ein (werden Enumeriert)

zu "Sorry, aber das ist schlichtweg falsch. Sobald diese virtuellen
Schnittstellen sich am PC anmelden erscheinen sie auch dort."

Das Problem ist aber meist das diese, noch nicht sichtbaren COM-Ports
schon "belegt" sind. Bsp. du installierst ein USB-Ser (FTDI) dieser
sucht sich z.B: COM3 raus und meldet sich auch damit an. Jetzt kommt
dein Bluetooth-Gerät auch mit COM3 => wer gewinnt ?

oder onboard-Modems tragen sich nie unter "SerialDevices" ein obwohl
selbige als "COM5" ansprechbar sind.

Ich bin schon länger auf der suche nach der wirklich richtigen Methode
bin für alles offen.

Gruss

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Bsp. du installierst ein USB-Ser (FTDI) dieser
sucht sich z.B: COM3 raus und meldet sich auch damit an. Jetzt kommt
dein Bluetooth-Gerät auch mit COM3 => wer gewinnt ?"

Der erste.
Lustig wird es, wenn man zwei gleiche FTDI ICs mit gleichem EEPROM
anschließt. Dann gibt es z.B. 2x COM3, der aber nur 1x gelistet wird,
aber sich 2x öffnen lässt.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann auch ohne CreateFile einfachst testen, ob ein Port existiert
oder nicht:

BOOL PortExists(UINT_PTR PortNumber)
{
    TCHAR Name[MAX_PATH];
    wsprintf(Name, TEXT("COM%u"), PortNumber);
    QueryDosDevice(Name, NULL, 0);
    return(GetLastError() == ERROR_INSUFFICIENT_BUFFER);
}

Das Durchsuchen der Registry ist jedenfalls die schlechteste Lösung,
damit könnte ich nicht mehr ruhig schlafen. Die SetupDi-Funktionen sind
doch prima, was spricht denn dagegen?

Autor: Stefan Seegel (phunky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@T.Stütz:
Habe mal eben in meine Registry geschaut, mein OnBoard-Modem steht da
als COM4 drin...

@René:
Warum ist das Extrahieren aus der Registry die schlechteste Lösung?
Nachdem was ich hier gelesen habe ist die schlechteste Lösung das
Abklappern von COM1..COMX, weil langsam und evtl. Seiteneffekte.

>Die SetupDi-Funktionen sind doch prima, was spricht denn dagegen?

Das ist deutlich mehr Aufwand als ein einfaches Abfragen der Registry
bzw. der "Abklappermethode".

Ich glaube ich werde mich für die Registrymethode entscheiden, aber
erstmal sehen was hier noch kommt...

Gruß und Danke für alle bisherigen und kommenden konstruktiven
Beiträge!

Stefan

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum ist das Extrahieren aus der Registry die schlechteste Lösung?

Das Registry-Layout könnte sich in der nächsten Version ändern, ohne
das Du vorher gefragt wirst. Deswegen verwende ich zum Einsammeln von
Informationen garantiert niemals direkt die Registry, wenn ich eine
gute Alternative habe. In diesem Falle kannst Du sogar noch die für
Dich am Besten geeignete Methode aussuchen.

> Nachdem was ich hier gelesen habe ist die schlechteste Lösung das
> Abklappern von COM1..COMX, weil langsam und evtl. Seiteneffekte.

Naja, so langsam ist das Abklappern nun auch wieder nicht. Jedenfalls
dann nicht, wenn Du auf CreateFile verzichtest. Und was meinst Du mit
Seiteneffekten? Sprichst Du von Benedikts kaputter Hardware?

> Das ist deutlich mehr Aufwand als ein einfaches Abfragen der
> Registry bzw. der "Abklappermethode".

Das sehe ich eigentlich nicht so, jedenfalls nicht so deutlich. Das ist
allenfalls ungewohnt, beim ersten Mal.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich beziehe mich auf diesen udn folgende Beiträge
http://www.mikrocontroller.net/forum/read-8-155472...
(Nicht nur Benedikts 'kaputte' Hardware hatte damit Probleme)
Die Beiträge sind entstanden, nachdem ich genau diese abklappern
Methode für das Suchen der Schnittstellen verwendet habe

Wegen Registry: Ich hab gerad mal nachgeschaut und schon unter Win98
gabs die besagten Einträge. Aber Die SetupDi-Funktionen kannte ich
bisher garnicht. Mit welcher würde man denn die Schnittstellen finden
können?

@Rene:
Die QueryDosDevice klappt aber nur, wenn auch alle Schnittstellen sich
ordentlich einen COMx-Namen geben. Sobald eine aus diesem Namensschema
ausbricht wird sie nicht mehr gefunden.

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Beiträge sind entstanden, nachdem ich genau diese abklappern
> Methode für das Suchen der Schnittstellen verwendet habe

Abklappern ohne CreateFile?


> Wegen Registry: Ich hab gerad mal nachgeschaut und schon unter Win98
> gabs die besagten Einträge.

Sicherer für die Zukunft wird es dadurch aber auch nicht.


> Aber Die SetupDi-Funktionen kannte ich bisher garnicht. Mit welcher
> würde man denn die Schnittstellen finden können?

Da braucht es natürlich mehrere Funktionen, mindestens:
SetupDiGetClassDevs
SetupDiEnumDeviceInterfaces
SetupDiGetDeviceInterfaceDetail
SetupDiDestroyDeviceInfoList

Mit SetupDiGetDeviceRegistryProperty gibt es noch nette Informationen
wie z.B. den FriendlyName, den man gut im UI gebrauchen könnte.


> Die QueryDosDevice klappt aber nur, wenn auch alle Schnittstellen
> sich ordentlich einen COMx-Namen geben.

Richtig, ich wäre jetzt aber auch nicht auf die Idee gekommen, etwas
anderes haben zu wollen. Gibt es denn COM-Ports, die nicht COM heißen
aber wie COM funktionieren?

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Abklappern ohne CreateFile?

Obwohl das damit eigentlich gar nicht zusammenhängen kann. Dir wird
beim Abklappern ganz einfach irgendwo ein kleiner aber wirkungsvoller
Fehler unterlaufen sein.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist, wie soll man bei abklappern mit CreateFile etwas falsch
machen? Der Code sah prinzipiell genauso aus, wie der für
QueryDosDevice, nur mit CreateFile und entsprechendem Test auf
Fehlerrückgabe. Mir ist auch schleierhaft, was da nicht ging...


Ich hab gerade mal etwas mit den SetupDi-Befehlen rumgespielt. Schlecht
ist diese Möglichkeit sicherlich nicht und für alle, die nicht selber
die Hilfe wälzen wollen hier der Code:
  dmsg("Start SetupDi\n");
    HDEVINFO devinfo = SetupDiGetClassDevs( &GUID_DEVINTERFACE_COMPORT,
NULL, NULL, DIGCF_DEVICEINTERFACE | DIGCF_PRESENT );
    
  if ( devinfo == INVALID_HANDLE_VALUE )
  {
    dmsg("DevInfo failed\n");
    return;
  }

  DWORD mem_index = 0,
      req_size = 0;
  int res;
  SP_DEVICE_INTERFACE_DATA devinfo_data;
  PSP_DEVICE_INTERFACE_DETAIL_DATA pdevinfo_detail;

  ZeroMemory( &devinfo_data, sizeof( SP_DEVICE_INTERFACE_DATA ) );
  devinfo_data.cbSize = sizeof( SP_DEVICE_INTERFACE_DATA );

    while ( SetupDiEnumDeviceInterfaces( devinfo, NULL,
&GUID_DEVINTERFACE_COMPORT, mem_index, &devinfo_data ) )
  {
    dmsg("Enum Devs index=%d\n",mem_index);

    res = SetupDiGetDeviceInterfaceDetail( devinfo, &devinfo_data, NULL,
0, &req_size, NULL );
    dmsg("First call: res=%d reqsize=%d\n", res, req_size );

    pdevinfo_detail = (PSP_DEVICE_INTERFACE_DETAIL_DATA)(new char[
req_size + 1 ]);
    ZeroMemory( pdevinfo_detail, req_size+1 );
    pdevinfo_detail->cbSize = sizeof( SP_DEVICE_INTERFACE_DETAIL_DATA );

    res = SetupDiGetDeviceInterfaceDetail( devinfo, &devinfo_data,
pdevinfo_detail, req_size, NULL, NULL );
        
    dmsg("2nd call: res=%d text=\"%s\"\n", res,
pdevinfo_detail->DevicePath );

    delete pdevinfo_detail;
    ZeroMemory( &devinfo_data, sizeof( SP_DEVICE_INTERFACE_DATA ) );
    devinfo_data.cbSize = sizeof( SP_DEVICE_INTERFACE_DATA );
    mem_index++;
  }
  SetupDiDestroyDeviceInfoList( devinfo );

Die Frage, die jetzt noch bleibt, ist, wie finde ich (ohne Registry,
denn damit gehts einfach) heraus, was sich genau hinter
\\?\usb#vid_067b&pid_2303#5&3ad090d&0&1#{86e0d1e0-8089-11d
0-9ce4-08003e301f73}
verbirgt?

Autor: René König (king)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit SetupDiGetDeviceRegistryProperty gibt es noch nette Informationen
wie z.B. den FriendlyName, den man gut im UI gebrauchen könnte.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genauso etwas hatte ich gesucht. Werd ich morgen mal probieren! Danke
für die kleine 'Nachhilfestunde' ;)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> > Die QueryDosDevice klappt aber nur, wenn auch alle Schnittstellen
> > sich ordentlich einen COMx-Namen geben.
>
> Richtig, ich wäre jetzt aber auch nicht auf die Idee gekommen,
> etwas anderes haben zu wollen. Gibt es denn COM-Ports, die
> nicht COM heißen aber wie COM funktionieren?

Ja. ISDN-Karten der Firma Eicon ("Diva") werden mit einem Treiber
geliefert, der "virtuelle Modems" zur Verfügung stellt, die als
\\.\DiPort0 angesprochen werden können. Ein Mapping auf COM-Namen
ist zwar auch möglich, aber nicht zwingend.
Verwendet man diese speziellen Namen, kann man sich wenigstens sicher
sein, nicht doch versehentlich mit falscher Hardware zu kommunizieren.
Nein, für das "gelbe vom Ei" halte ich diese Idee auch nicht.

Autor: Tobi H. (tobi-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nächstes Problem: SetupDiGetDeviceRegistryProperty liefert zwar eine
Menge Infos aber leider nichts der Art COMx. Der User Friendly Name ist
z.b 'Kommunikationsanschluss (COM1)'
Die benötigte Eigenschaft (PortName heißts in der Reg) ist nicht damit
zugreifbar. Schade, sonst wäre das wirklich praktisch gewesen :/

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.