USB-Deskriptoren anpassen: Den Gerätenamen des Leonardo ändern

USB-Deskriptoren anpassen – genauer: den Gerätenamen eines Arduino Leonardo (ATmega32U4) zu ändern – ist eine der beliebtesten Modifikationen für HID-Projekte, Makro-Pads und eigene Controller. Der praktische Nutzen ist offensichtlich: Statt eines generischen Eintrags wie „Arduino Leonardo“ erscheint im Geräte-Manager, in Game-Listen oder in Tools wie USBView ein klarer, eigener Name (z. B. „Studio Macro Pad“ oder „Sim-Rig Button Box“). Gleichzeitig ist das Thema technisch sensibel, weil der Leonardo sein USB-Verhalten direkt aus dem Sketch und dem verwendeten Core ableitet. Ein unbedachter Eingriff kann dazu führen, dass sich das Board nicht mehr wie erwartet meldet, Ports wechseln oder Windows Treiberzuordnungen durcheinanderbringt. In diesem Artikel lernen Sie, wie Sie USB-Deskriptoren anpassen, um den Gerätenamen des Leonardo zu ändern – sauber, nachvollziehbar und updatefest. Dabei unterscheiden wir zwischen dem „schnellen“ Ansatz (boards.txt im installierten Core bearbeiten) und dem professionellen Ansatz (eigenes Board-Package im Sketchbook anlegen). Außerdem klären wir, was sich wirklich ändern lässt (Product/Manufacturer Strings, ggf. VID/PID) und wo Grenzen liegen (pro Gerät eindeutige Namen, Bootloader-Name, rechtliche Aspekte). Als Ausgangspunkt eignen sich Diskussionen zur Änderung von USB_PRODUCT/USB_MANUFACTURER in der AVR-Core-Struktur, etwa im Arduino Forum und in Issues rund um USBCore.cpp und boards.txt.

Was ist der „Gerätename“ beim Arduino Leonardo überhaupt?

Wenn Sie den Arduino Leonardo per USB anschließen, identifiziert er sich gegenüber dem Betriebssystem über Standard-USB-Deskriptoren. Für den sichtbaren Namen sind vor allem zwei Dinge relevant:

• Product String (Produktname): Der Text, der häufig als Gerätename angezeigt wird (z. B. „Arduino Leonardo“).
• Manufacturer String (Hersteller): Herstellerangabe (z. B. „Arduino LLC“ oder „Arduino“ je nach Core/Version).

Diese Strings sind Teil der USB-String-Deskriptoren. Beim Leonardo stammen sie typischerweise aus dem verwendeten Arduino AVR Core und werden beim Kompilieren in den USB-Stack übernommen. Daher ist es so verbreitet, den Namen über Einträge wie build.usb_product und build.usb_manufacturer in der boards.txt zu steuern. Praktische Anlaufstellen, die genau diesen Zusammenhang erklären, sind beispielsweise Community-Anleitungen und Diskussionen zur Anpassung in boards.txt oder USBCore.cpp.

Wichtige Unterscheidung: Bootloader-Name vs. Sketch-Name

Beim Leonardo gibt es zwei „USB-Welten“:

• Bootloader-Modus: Während des Upload-Fensters meldet sich der Bootloader (Caterina) oft mit einem eigenen USB-Profil. Dadurch kann unter Windows ein anderer Port bzw. ein anderes Gerät erscheinen.
• Normalbetrieb (Sketch): Danach meldet sich der Leonardo mit dem USB-Profil, das Ihr Sketch (bzw. der Core) definiert.

Das ist wichtig, weil eine Änderung des Gerätenamens in der Regel den Sketch-Betrieb betrifft – nicht zwingend den Bootloader. Wenn Sie beim Upload einen anderen Gerätenamen sehen als im Betrieb, ist das normal. Wer tiefer in Caterina eintauchen möchte, findet den Leonardo-Bootloader als HEX-Datei im offiziellen AVR-Core-Repository, z. B. unter Caterina-Leonardo.hex.

Warum der „schnelle Hack“ oft Probleme macht

Der schnellste Weg ist, die boards.txt im installierten Arduino-Core zu bearbeiten (z. B. im Arduino-IDE-Installationsverzeichnis). Viele How-tos beschreiben genau das: Name/Manufacturer/PID/VID direkt im Arduino-Core ändern, neu kompilieren, hochladen – fertig. Eine typische Beschreibung dieses Ansatzes findet sich z. B. hier: Arduino: Change Device’s VID/PID/Name.

In der Praxis hat dieser Weg drei Nachteile:

• Nicht updatefest: IDE- oder Core-Updates überschreiben Ihre Änderungen.
• Globaler Effekt: Sie ändern das Verhalten für alle Boards dieser Core-Installation, nicht nur für ein Projekt.
• Fehleranfällig: Ein Tippfehler oder falsches Escaping kann den Build oder die USB-Enumeration stören.

Für einmalige Tests ist das okay. Für ein dauerhaftes Setup – gerade 2026 mit häufigen Core-Updates – ist ein eigenes Board-Package deutlich sauberer.

Der professionelle Weg: Eigenes Board-Package im Sketchbook anlegen

Die robuste Methode ist, den Arduino AVR Core in Ihr Sketchbook zu „klonen“ und daraus ein eigenes, lokales Hardware-Package zu machen. Genau dieses Vorgehen wird in aktuellen Anleitungen genutzt, um einen Leonardo/Pro Micro mit eigenem USB-Namen zu versehen – ohne das IDE-Installationsverzeichnis anzufassen. Ein Beispiel mit klaren Ordnerpfaden (Windows) ist diese Schritt-für-Schritt-Notiz: Instructions for Adding Custom Naming for Arduino USB Device. Auch im deutschsprachigen Raum wird die Idee beschrieben, ein eigenes Board-Package zu definieren, statt die Installation zu patchen: Arduino Leonardo / Pro Micro mit eigenem Namen.

Grundprinzip des Board-Packages

• Sie kopieren den AVR-Core in einen Ordner unterhalb Ihres Arduino-Sketchbooks (z. B. Dokumente/Arduino/hardware/).
• Sie definieren einen neuen „Board-Eintrag“ (boards.txt), der eigene USB-Strings (und optional PID/VID) setzt.
• Sie wählen in der IDE anschließend Ihr eigenes Board aus (statt „Arduino Leonardo“).

Warum das besser ist

• Updatefest: IDE-Updates überschreiben Ihre lokalen Hardware-Definitionen nicht.
• Projektorientiert: Sie können mehrere Varianten (z. B. „MacroPad“, „ButtonBox“) parallel pflegen.
• Reproduzierbar: Sie wissen genau, welche Änderungen Sie vorgenommen haben.

Welche Einträge sind relevant: usb_product und usb_manufacturer

Für den Gerätenamen sind in vielen AVR-Core-Konfigurationen insbesondere diese Parameter üblich:

• build.usb_product – der Product String (Gerätename)
• build.usb_manufacturer – der Manufacturer String
• build.vid / build.pid – Vendor ID / Product ID (optional, mit Vorsicht)

Dass sich der Product String über boards.txt steuern lässt und andernfalls in Core-Dateien wie USBCore.cpp landet, wird seit Jahren diskutiert, z. B. im Arduino Forum und im Core-Issue-Tracker. Eine Diskussion über die „boards.txt vs. Core-Datei“-Frage finden Sie hier: Custom USB Device name – modifying the core instead of boards.txt. Einen Hinweis, dass USB_PRODUCT/USB_MANUFACTURER im Core gesucht und angepasst werden kann (mit globalem Effekt), finden Sie hier: Giving a Custom Name to the USB Keyboard/Mouse Device (ATmega32U4).

VID/PID ändern: Sinnvoll oder Risiko?

Viele Anleitungen erwähnen neben dem Namen auch eine Anpassung von VID/PID. Technisch ist das möglich, wird aber häufig unterschätzt. Auf Windows kann eine geänderte VID/PID bedeuten, dass Treiberzuordnungen neu erfolgen oder bestimmte Tools das Gerät anders erkennen. Außerdem sind VIDs in der Regel registrierten Herstellern vorbehalten; eigene VIDs sollten nicht „frei erfunden“ werden.

• Empfehlung für die Praxis: Ändern Sie zunächst nur Product/Manufacturer Strings und lassen Sie VID/PID unverändert.
• Wenn VID/PID wirklich nötig ist: Dokumentieren Sie die Originalwerte, rechnen Sie mit neuem Geräteeintrag und testen Sie auf einem Zweitrechner.

Dass Anwender bei Leonardo-Projekten gezielt nach „Welche Zeile in boards.txt ist die richtige?“ für VID/PID suchen, zeigt diese Frage: Change USB VID and PID (Leonardo). Nutzen Sie solche Hinweise, um zu verstehen, wo konfiguriert wird – aber treffen Sie die Entscheidung bewusst und nicht aus Gewohnheit.

Windows 11 Besonderheiten: Cache, Geräte-Manager und „Warum sehe ich den alten Namen noch?“

Unter Windows 11 kann es passieren, dass nach dem Umbenennen weiterhin ein alter Gerätename angezeigt wird. Gründe sind unter anderem:

• Geräteinstanz-Cache: Windows speichert Informationen zu einer Geräteinstanz (VID/PID/Serial/Interface) und zeigt diese weiterhin an.
• Mehrere Interfaces: Der Leonardo kann als Composite Device auftreten (z. B. Serial + HID). Der sichtbare Name kann je nach Untergerät variieren.
• Bootloader-Port: Beim Reset taucht kurz ein anderes Gerät auf (separater Eintrag).

Praktische Vorgehensweise bei „alter Name bleibt“:

• Board abziehen, im Geräte-Manager „Ausgeblendete Geräte anzeigen“ aktivieren und alte Einträge entfernen.
• Danach neu verbinden und prüfen, ob der neue Product String erscheint.
• Bei HID-Geräten zusätzlich in „Geräte und Drucker“ bzw. in den Bluetooth-&-Geräte-Listen kontrollieren, weil dort teils andere Labels genutzt werden.

HID-Projekte (Keyboard/Mouse): Warum ein sicherer Start wichtig ist

Wer den Leonardo umbenennt, macht das häufig für HID-Projekte (Makro-Tastatur, Stream-Controller, Button Box). Gerade dort gilt: Ein fehlerhafter Sketch kann den Upload erschweren oder das Systemverhalten stören. Deshalb sollten Sie vor allem bei Keyboard-/Mouse-Sketches immer mit einem „Arming“-Konzept arbeiten (HID erst nach Tastendruck aktiv) und einen Not-Aus vorsehen. Die offiziellen Arduino-Referenzen geben einen guten Überblick über die Funktionen und die generelle Nutzung: Keyboard-Library und Mouse-Library.

Praktische Sicherheitsmuster

• Arming-Taste: HID-Ausgaben erst nach einem definierten Tastendruck.
• Start-Delay: In den ersten Sekunden nach Boot keine Eingaben senden.
• Kill-Switch: Ein Pin deaktiviert HID dauerhaft, solange er beim Start gehalten wird.

Grenzen und Realität: Pro Gerät ein eigener Name ist nicht „einfach so“ möglich

Ein häufiger Wunsch ist: Mehrere identische Leonardos sollen gleichzeitig angeschlossen sein und jeweils einen anderen Namen tragen („EN57 Door Switches“, „EU07 Power Controller“ usw.). Genau hier stoßen Sie mit dem Standardansatz (boards.txt + USB_PRODUCT) an Grenzen, weil der Name beim Kompilieren/Upload festgelegt wird und nicht dynamisch pro Board ohne zusätzliche Identifikationslogik variiert. Diskussionen zu diesem Thema tauchen immer wieder auf, etwa wenn Nutzer nach „mehrere Boards, unterschiedliche Namen“ fragen: Change board name, multiple boards of the same type.

Was in der Praxis funktioniert:

• Mehrere Board-Definitionen: Sie erstellen mehrere „Boards“ im eigenen Package (z. B. „MacroPad A“, „MacroPad B“) und flashen bewusst unterschiedliche Firmware-Varianten.
• Seriennummer/USB-Serial: Je nach Core/Implementierung kann eine eindeutige Seriennummer Einfluss auf die Geräteinstanz haben. Das ist jedoch deutlich komplexer und nicht in allen Setups sauber unterstützt.

Typische Fehlerquellen beim Anpassen der USB-Deskriptoren

• Änderung an der falschen Stelle: Sie bearbeiten die boards.txt im installierten Core, nutzen aber in der IDE einen anderen Core (Board Manager), sodass sich nichts ändert.
• Unklare Ordnerstruktur in IDE 2.x: Pfade unterscheiden sich je nach Installationsart (Store/ZIP/Standardinstaller) – daher ist der eigene Hardware-Ordner im Sketchbook oft der stressfreieste Weg.
• Bootloader verwechselt: Sie erwarten, dass der neue Name auch im Bootloader-Mode erscheint.
• Windows Cache: Der neue Name wurde korrekt geflasht, wird aber in alten Geräteinstanzen noch nicht aktualisiert.

Rechtlicher und organisatorischer Hinweis: Keine „Spoofing“-Abkürzungen

USB-Deskriptoren anpassen ist legitim, wenn Sie Ihre eigenen Geräte eindeutig benennen oder sauber in Tools integrieren möchten. Problematisch wird es, wenn damit bewusst Identitäten anderer Hersteller imitiert oder Sicherheitsmechanismen umgangen werden sollen. Bleiben Sie daher bei eigenen, klaren Produkt-/Herstellerstrings und ändern Sie VID/PID nur, wenn Sie die Konsequenzen verstehen und die Nutzung rechtlich sauber ist.

Outbound-Links: Vertiefung und verlässliche Referenzen

• Instructions for Adding Custom Naming for Arduino USB Device (Board-Package-Ansatz)
• Arduino Leonardo/Pro Micro mit eigenem Namen (deutschsprachiger Überblick)
• Arduino: Change Device’s VID/PID/Name (boards.txt-basierter Einstieg)
• Arduino Forum: Custom USB Device Name – boards.txt vs. Core
• Arduino Forum: USB_PRODUCT/USB_MANUFACTURER anpassen (ATmega32U4)
• Arduino Stack Exchange: Change USB VID and PID (Leonardo)
• Arduino Forum: Mehrere Boards, unterschiedliche Namen (Herausforderungen)
• ArduinoCore-avr: Caterina-Leonardo Bootloader (Referenzdatei)
• Arduino Referenz: Keyboard-Library (HID-Kontext)
• Arduino Referenz: Mouse-Library (HID-Kontext)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.