Ich erforsche derzeit die eingebettete Programmierung mit ARM-Prozessoren. In meiner Klasse für eingebettete Systeme programmieren wir auf einem Atmel SAMD20 (Cortex M0+). Unser Laborhandbuch erklärt ausführlich, wie Sie eine Atmel-Bibliothek verwenden, um auf die Register auf dem Prozessor zuzugreifen, um GPIO-Pins zu steuern.
Was ich in meiner Freizeit zu lernen versucht habe, ist, wie ich mit einem anderen Mikrocontroller alleine aufstehen und laufen kann, obwohl ich weiß, dass der Code etwas anders sein wird. Ich habe über CMSIS gelesen, was eine bequeme Möglichkeit zu sein scheint, mit der Programmierung auf neuen Mikrocontrollern zu beginnen, die denselben ARM-Kern verwenden. Unterschiedliche Siliziumanbieter haben jedoch eine unterschiedliche Anzahl von GPIO-Ports/Peripheriegeräten, die mit dem Mikrocontroller verbunden sind. Wie kann CMSIS die Konsistenz zwischen diesen GPIO-Ports aufrechterhalten, wenn sie sich zwischen verschiedenen Chips unterscheiden? Oder verarbeitet CMSIS keine GPIO-Ports und nur Dinge, die den ARM-Core betreffen?
Wenn letzteres der Fall ist, bedeutet dies, dass ich mir die Datenblätter der Anbieter ansehen muss, um zu verstehen, wie ein bestimmter Mikrocontroller codiert wird? Ich schaue mir gerade STM32-Mikrocontroller an und habe Probleme, irgendetwas zu finden, das ihre Header-Dateien dokumentiert. Ich bin im Moment etwas verloren und überwältigt, daher wäre ich für jeden Rat und jede Richtung dankbar.
Wie @Arsenal sagt, verarbeitet das CMSIS nur die Kernfunktionalität von ARM. Der GPIO wird von den jeweiligen Mikrocontroller-Anbietern implementiert.
Die STM32-Mikrocontroller haben eine ziemlich gute Dokumentation. ST bietet einige Optionen für Geräteheaderdateien, CMSIS-Header, Abstraktionsschichten usw.
Ich empfehle, die Standard Peripheral Libraries von ST herunterzuladen. Die SPL für den STM32F10x finden Sie beispielsweise hier . Es enthält ein großes, von Doxygen erstelltes, verlinktes Dokument, das ihre Header-Dateien abdeckt, sowie viele Teile von Beispielcode.
Ich sollte erklären, dass die SPL der "alte Weg" ist, dies zu tun. Es ist ziemlich leicht und führt nur grundlegende Funktionen zur Verwendung der Hardware aus.
Kürzlich drängt ST Benutzer zu ihrem STM32Cube-Firmware-Entwicklungspaket anstelle der SPL. Es verfügt nicht nur über Header-Dateien und grundlegende Funktionen, sondern auch über USB-Unterstützung, Grafikmodule usw. Es erstellt eine Menge Code für Sie.
Manche Leute lieben es; Einige verwenden hartnäckig weiterhin die SPL. (Ich bin einer der Hartnäckigen). Wenn Sie es möchten, finden Sie hier STM32Cube (für die STM32F1) .
Nein. GPIO sind ein externes Peripheriegerät zum Kern und haben als solches kein standardisiertes Registerlayout oder keine Spezifikation. CMSIS behandelt nur den Kern und die von ARM standardisierten Kernperipheriegeräte.
Normalerweise (heute) stellen die Anbieter eine Hardware-Abstraktionsschicht bereit, die für ihre Modelle spezifisch ist.
Für den STM32 bietet ST die Cube-Umgebung an . Ich kann Ihnen nicht wirklich viel darüber sagen, weil wir es nicht in unseren Produkten verwenden, also hatte ich noch keine Zeit, damit herumzuspielen.
Wenn Sie den Weg gehen, den wir eingeschlagen haben (Bare Metal, eigener HAL), müssen Sie einen Blick in das Referenzhandbuch Ihres spezifischen Geräts werfen, das Errata-Blatt, um Ihnen mitzuteilen, ob Sie einige Hardwarefehler in der Software und das Datenblatt behandeln müssen für Pin-Mappings und andere elektrische Daten.
Die Header für die Peripherie werden oft von der Compiler-Firma und nicht vom Chip-Hersteller bereitgestellt (oder zumindest bemerken Sie es nicht, weil sie mit dem Compiler gepackt sind). Normalerweise halten sich die Überschriften eng an das Namensschema des Referenzhandbuchs. Einige verwenden eine Struktur für ein Peripheriegerät, andere definieren jedes Register als ein eigenes. Die Bits sind normalerweise auch vordefiniert, sodass Sie lesbaren Code schreiben können, ohne wie verrückt Bits zu verschieben.
Sean Houlihane