Wie geht Win-COM-Kanal auswahl bei PiPico

Windows weist einen freien Platz zu und merkt sich anhand der Geräteseriennummer (wenn denn eine dabei abgeliefert wird) welche.
Wenn die dann noch frei ist gibt's die wieder, sonst wird gewechselt.
Im Gerätemanager kannst du manuell einen zuweisen, das ist der offizielle Weg.
Aber das ist eben PC-spezifisch, d.h. 3 hier ist nicht unbedingt 3 da.

Zum Testen komm ich damit klar.
Wenn ich nun aber ein Win-Programm schreibe (QT), dann soll ich zum Verbindungsaufbau eine Com-Nr angeben. Aber welche, wenn es von der Pico Intent-nr abhängt, die ich nicht kenne.

Rudi schrieb:

da jeder Pico immer den gleichen Kanal wählt.

Ist bei den ATMega32U4 und mit ATMega16U2 Arduinos genauso. Da wird die ChipId verwendet um eine Serialnummer für USB zu generieren.

Bei Anderen würfelt Windows.

Rudi schrieb:

Wenn ich nun aber ein Win-Programm schreibe (QT), dann soll ich zum Verbindungsaufbau eine Com-Nr angeben. Aber welche, wenn es von der Pico Intent-nr abhängt, die ich nicht kenne.

Es gibt eine API Funktion, die alle verfügbaren COM Ports mit Name auflistet. Du könntest den Raspi am Namen erkennen.

Bei QT wäre dazu QSerialPortInfo.description() dein Anlaufpunkt.

Es sollten dir diese Informationen bereit gestellt werden:

• idVendor
• idProduct
• iManufacturer
• iProduct
• iSerial

iSerial ist unique, da diese von der Flash-Chip Serial abgeleitet wird.

Empfehlung: Comportman installieren. Damit kann man die Ports selber zuordnen. Läuft hier seit vielen Jahren. Quelle:

https://www.uwe-sieber.de/ComPortMan.html

MfG. Andreas

Danke, mit QT bin ich erst am Anfang, das wird mein erstes Projekt damit. Ich denke, damit bekomme ich es hin.

Unter Linux sieht die Auswahlliste in einer meiner QT Anwendungen so aus:

1

QStringList getSerialPorts() {

2

    QStringList result;

3

    QString fmt("%1 %2");

4

    foreach(QSerialPortInfo info, QSerialPortInfo::availablePorts()) {

5

        result.append(fmt.arg(info.portName()).arg(info.description()));

6

    }

7

return result;

Das geht auch unter Windows, ich habe nur gerade keinen Screenshot davon parat.

Deine Picos melden sich wahrscheinlich als CDC-ACM an, und Windows vergibt dann COM-Ports.

Kann man auch anders machen. Wenn es nicht um große Datenmengen geht, wäre ein Custom HID eine Möglichkeit. Das ist ein HID, das keine der vordefinierten Klassen (Tastatur, Maus,...) implementiert, sondern eine selbst definierte.

Vorteile:

• Es muss niemals ein Treiber installiert werden.
• Der Benutzer muss nie einen COM-Port auswählen, die Software geht alle HIDs durch und sucht sich selber die passenden aus.
• Kein Fremdprogramm kann versehentlich auf das eigene Gerät zugreifen. Beispiel: Modem als serielle Maus erkennen oder ähnliches.

Nachteile:

• geringere Datenrate
• keine einfache Testmöglichkeit
• eventuell etwas höherer Programmieraufwand.

Codebeispiel: https://github.com/libusb/hidapi

Frank K. schrieb:

Custom HID

Man kann auch ohne HID ein komplett custom USB-Protokoll umsetzen, das hat alle Vorteile von HID und man kann die volle Datenrate von Bulk-Endpoints nutzen. Mit WinUSB braucht man dann ebenfalls keine Treiber nachinstallieren, d.h. auch keine Admin-Rechte nötig.

Ja, ich denke auch dass der HID Vorschlag veraltet ist. Sehe keinen Sinn darin, die Geräteklasse "Human Input devices" für etwas anderes zu missbrauchen.

Niklas G. schrieb:

Frank K. schrieb:

Custom HID

Man kann auch ohne HID ein komplett custom USB-Protokoll umsetzen, das hat alle Vorteile von HID und man kann die volle Datenrate von Bulk-Endpoints nutzen. Mit WinUSB braucht man dann ebenfalls keine Treiber nachinstallieren, d.h. auch keine Admin-Rechte nötig.

Unter Windows ab 8 ja. Bei Linux muss man dann trotzdem noch eine passende libusb nachinstallieren, wenn man die Bibliothek nicht selber nachimplementieren will. Beim Mac weiß ich es nicht, hab ich nie gemacht. HID ist hier einfacher, und oft reicht es auch.

fchk

Am Einfachsten wäre es allerdings einfach auf das zu antworten was der OP gefragt hat. Denn offensichtlich scheint eine bequeme serielle Verbindung völlig ausreichend zu sein.

Und ich kann mir beim besten Willen nicht vorstellen, dass Windows (vielleicht mit etwas manueller Hilfe) nicht in der Lage ist iSerial zu lesen und zu berücksichtigen.

Frank K. schrieb:

Bei Linux muss man dann trotzdem noch eine passende libusb nachinstallieren, wenn man die Bibliothek nicht selber nachimplementieren will.

Naja die zu installieren ist auch kein Hexenwerk, und oft ist sie sowieso vorinstalliert. Im schlimmsten Fall liefert man sie zusammen mit dem Programm aus. Für HID müsste man auch die hidapi Library mitliefern, also kein Vorteil.

Niklas G. schrieb:

Frank K. schrieb:

Bei Linux muss man dann trotzdem noch eine passende libusb nachinstallieren, wenn man die Bibliothek nicht selber nachimplementieren will.

Naja die zu installieren ist auch kein Hexenwerk, und oft ist sie sowieso vorinstalliert. Im schlimmsten Fall liefert man sie zusammen mit dem Programm aus. Für HID müsste man auch die hidapi Library mitliefern, also kein Vorteil.

Die hidapi Library habe ich nie benutzt und auch nicht vermisst.

fchk

Frank K. schrieb:

Die hidapi Library habe ich nie benutzt und auch nicht vermisst.

Also greifst du direkt per HIDRAW zu? Das geht bei komplett eigenen USB-Protokollen genau so. Im Endeffekt baut man sich sein eigenes hidapi oder eben libusb.