Wie wird der ATmega32U4-Chip über USB erkannt?

Ich habe einen ATmega32U4-Chip, der auf einer Platine verdrahtet und über USB an einen PC angeschlossen werden kann. Wenn dies erledigt ist, erkennt Windows 10 (wenn die richtigen Treiber installiert sind) das Gerät als ATmega32U4-Chip.

Was ist im Chip dafür verantwortlich, auf den USB-Anschluss zu reagieren? Wie funktioniert das genau?

  • Ist das auch ein sogenannter Bootloader, der im Flash gespeichert ist?
  • Ist es Software von Atmel, die im Flash gespeichert ist? Denn was würde dann passieren, wenn ich den Flash-Speicher neu beschreibe? Wäre es dann für Windows nicht mehr erkennbar?

Antworten (2)

Auf einem Mikrocontroller wie dem ATmeaga32u4 sind diese USB-Pins mit etwas spezieller Hardware verbunden, um die USB-Signalisierung zu verarbeiten. Aber diese Hardware erledigt im Grunde nur die Elektronik, sie steuert nicht, welche Daten gesendet oder empfangen werden. Und es müssen Daten gesendet und empfangen werden, um das Gerät zu identifizieren und aufzuzählen. Wenn sich keine Software auf dem Chip befindet, werden keine Daten gesendet und der Chip wird überhaupt nicht aufzählen. Windows wird wahrscheinlich melden, dass "eines der an diesen Computer angeschlossenen USB-Geräte eine Fehlfunktion hat", aber es wird es möglicherweise überhaupt nicht erkennen.

Aber die Chips kommen normalerweise ab Werk mit einem DFU-Bootloader drauf (obwohl auch komplett leere und anders programmierte Chips erhältlich sind). Der DFU-Bootloader identifiziert sich selbst als Gerät der DFU-Klasse und gibt dem PC auch eine Hersteller-ID (VID) und eine Produkt-ID (PID). Der PC durchsucht dann seine Liste von Treibern, um einen zu finden, der behauptet, diese VID und PID zu unterstützen. Sie haben vermutlich Atmel Flip installiert, das einen Treiber enthält, und der Treiber weiß, dass diese VID/PID einen ATmega32u4 mit DFU-Bootloader bedeuten. Also lädt Windows diesen Treiber und der Treiber teilt Windows mit, dass es sich um einen ATmega32u4 handelt.

Vermutlich will man mit dem Chip auf Dauer etwas anderes machen. Sie müssen es also mit Ihrer eigenen Anwendung programmieren. Sie können (und wollen) den Bootloader und Ihre Anwendung nicht gleichzeitig ausführen. Sie können sie jedoch beide auf dem Chip belassen und mit einem speziellen Code, Sicherungseinstellungen oder durch Ziehen eines Stifts auf Masse während des Zurücksetzens hin und her schalten. Dies ist großartig für die Entwicklung, da dieser Bootloader verwendet werden kann, um eine neue Kopie Ihrer Anwendung hochzuladen. Es ist auch praktisch, wenn Sie Kunden in Zukunft Firmware-Upgrades durchführen lassen möchten.

Aber während Ihre Anwendung läuft, läuft der Bootloader nicht. Der Bootloader kann also die Aufzählung nicht durchführen, kann die VID/PID nicht an den Computer weitergeben usw. Stattdessen muss Ihre Anwendung all dies tun. Und es ist kompliziert. Aber die gute Nachricht ist, dass es Bibliotheken gibt, die das meiste für Sie erledigen. Die häufigste heißt LUFA . Sie müssen auch Ihre eigene VID/PID kaufen/auswählen und einen Treiber für Ihr Gerät schreiben.

Danke für die zusätzlichen Informationen! Als ich also meine eigene kompilierte .HEX-Datei in den ATmega32u4-Flash geschrieben habe, habe ich normalerweise den werkseitigen Standard-Bootloader nicht gelöscht? Wie könnte ich den Bootloader (wieder) aktivieren, damit Windows den Chip wieder erkennt (und ich somit wieder ein anderes Programm darauf flashen könnte)?
Wenn Sie den Chip mit einem Programmiergerät programmieren, gibt es normalerweise die Option "zuerst löschen". Wenn das aktiviert ist, wird der Bootloader gelöscht, wenn nicht, dann nicht. Wenn Sie mit dem Bootloader programmieren, löscht er sich nicht. Wenn der Bootloader noch vorhanden ist, können Sie ihn starten, indem Sie 1) die BOOTRST-Sicherung setzen, 2) den HWB-Pin während eines Resets auf Masse ziehen (erfordert HWBEN-Sicherung) oder 3) einen JMP-Befehl in Ihrer Anwendung ausführen. Siehe atmel.com/Images/doc7618.pdf
@JackB. Der DFU-Bootloader wird nicht gelöscht, wenn Sie vor dem Programmieren über die DFU „zuerst löschen“. Der Bootloader befindet sich in einem geschützten Satz von Seiten und Sie müssen einen ICSP verwenden, um die Schutzsicherungen zu löschen. Die DFU-Dokumentation wurde aktualisiert, siehe hier: atmel.com/Images/doc7745.pdf

Auf Mikrocontrollern müssen Sie also Firmware schreiben, die USB handhabt, und dazu gehört auch, auf Pakete vom Host zu reagieren, die nach Dingen wie Anbieter- und Produkt-IDs fragen.

Auf Ihrem Mikrocontroller läuft also eine Software, die gemäß dem USB-Standard mit Ihrem PC kommuniziert.

Die Chancen stehen gut, dass dies ja eine Bootloader-Firmware ist, die von atmel vorgeflasht wurde - der Grund ist einfach, dass Sie ein Gerät bauen und es dann schnell programmieren können. Super praktisch für die Produktion!

Ob sich dieser Bootloader im vom Benutzer beschreibbaren Speicher befindet und unter welchen Umständen er beim Start ausgeführt wird, hängt sehr stark davon ab. Das Datenblatt und die Benutzerhandbücher Ihres Geräts enthalten Einzelheiten dazu. Suchen Sie nach Bootloader, USB und möglicherweise „DFU“, dem USB-Profil für Firmware-Uploads.