STM32

Wechseln zu: Navigation, Suche

STM32 ist eine Mikrocontroller-Familie von ST mit einer 32-Bit ARM Cortex-M0/M3/M4 CPU. Diese Architektur ist speziell für den Einsatz in Microcontrollern neu entwickelt und löst damit die bisherigen ARM7-basierten Controller weitestgehend ab. Den STM32 gibt es von ST in unzähligen Varianten mit variabler Peripherie und verschiedenen Gehäusegrößen und -formen. Durch die geringe Chipfläche des Cores ist es ST möglich, eine 32 Bit-CPU für weniger als 1 € anzubieten.

Blockdiagramm STM32F103xC/D/E

STM32-Familien[Bearbeiten]

Bisher gibt es sieben STM32-Familien:

  • STM32F0
    • Cortex M0
    • Mikrocontroller zum Einstieg
    • Bis 48MHz
  • STM32F1
    • Cortex M3
    • Bis 72MHz
    • Verschiedene Unterfamilien:
      • Connectivity line
      • Performance line
      • USB Access line
      • Access Line
      • Value line
  • STM32F2
    • Cortex M3
    • Bis 120MHz
    • Wie die STM32F1 Serie, Camera-Interface, 32-Bit Timer, Crypto-Engine...
  • STM32F3
    • Cortex M4F
    • DSP und FPU
    • Bis 72MHz
    • Fast 12-bit 5 MSPS and precise 16-bit sigma-delta ADCs
    • Touch sensing controller (TSC)
  • STM32F4
    • Cortex M4F
    • DSP und FPU
    • Bis 180MHz
    • Bis zu 2MB Flash
  • STM32L1
    • Cortex M3
    • Low Power
    • mit LCD Treiber
    • Bis 32MHz
  • STM32W
    • Cortex M3
    • BIS 24MHz
    • RF-MCU

Hier eine Übersicht zum Auswählen eines STM32Fxxx

Features[Bearbeiten]

  • Cortex-M0 / Cortex-M3 / Cortex-M4F Kern (mit FPU)
  • 16KB ... 2MB Flash-ROM
  • 4KB ... 256KB SRAM
  • 2KB ... 16KB EEPROM (STM32L)
  • SDRAM-Controller bei den STM32F42xxx und STM32F43xxx, bis 512 MByte externer SDRAM addressierbar
  • 512 one-time programmable Bytes(STM32F2/4)
  • Gehäuse 20 ... 216 Pins als TSSOP, QFN, LQFP und BGA
  • Derzeit sind über 370 STM32 Derivate/Varianten verfügbar
  • Bis 72MHz CPU-Takt, bis 120MHz beim STM32F2xx, bis 168/180 MHz beim STM32F4xx, wobei eine spezielle prefetch-hardware bis 120/168 MHz eine Geschwindigkeit erzielen soll, die 0 Wait-States entspricht. Der CPU-Takt wird über einen Multiplikator aus dem internen RC-Takt oder einem externen Quarz-Takt abgeleitet.
  • Externes Businterface (nur bei Gehäusen ab 100 Pin und nur bei STM32F4, STM32F2 und STM32F1 Performance line)
  • LCD Treiber für 8x40 Punkte (nicht beim STM32F2xx)
  • TFT Treiber bei STM32F429 / STM32F439
  • Spannungsbereich 1,65 ... 3,6V, nur eine Betriebsspannung nötig
  • Temperaturbereich bis 125 °C
  • Bis zu 168 IOs, viele davon 5V-tolerant
  • Interner, kalibrierter RC-Oszillator mit 8MHz (16MHz bei STM32F2/F4xx)
  • Externer Quarz
  • Real Time Clock mit eigenem Quarz und separater Stromversorgung
  • Bis zu 16 Timer, je Timer bis zu 4 IC/OC/PWM Ausgänge. Davon 2x Motion Control Timer (bei STM32F103xF/G), (bis zu 32 PWM Ausgänge)
  • Systick Counter
  • Bis zu 3 12-Bit AD-Wandler mit insgesamt 24 AD-Eingängen, integrierter Temperatursensor, Referenzspannung Vrefint und VBatt Spannungsmessung (STM32F4xx)
  • Bis zu 2 12-Bit DA-Wandler (bis zu 3 beim STM32F3xx)
  • Bis zu 2 DMA Controller mit bis zu 12 Kanälen (16 beim STM32F2/4xx)
  • Bis zu 2x I²C
  • Bis zu 5x USART mit LIN, IrDA und Modem Control (bis zu 8 beim STM32F2/F4xx)
  • Bis zu 3x SPI (bis zu 6 beim STM32F4xx)
  • Bis zu 2x I²S
  • Bis zu 2x CAN
  • Hardware CRC Unit, bei der STM32F3xx Serie mit einem einstellbaren Polynom
  • Unique device ID register (96 Bits)
  • RNG - Random Number Generator (STM32F2/4xx)
  • Cryptographic Processor (CRYP) (STM32F2/4xx)
  • Hash Processor (HASH) (STM32F2/4xx)
  • Kamera-Interface (DCMI) (STM32F2/4xx)
  • USB 2.0 Full Speed / OTG
  • USB 2.0 Hi Speed OTG mit extra PHY-Chip (STM32F2/4xx)
  • SDIO Interface (z.B. SD-Card Reader)
  • Ethernet
  • Watchdog mit Window-Mode
  • Jedes Peripheriemodul ist separat einschaltbar, wodurch sich erheblich Strom sparen lässt
  • JTAG und SWD (Serial Wire Debug) Interface
  • Bis zu 6 Hardware-Breakpoints für Debuggen
  • und vieles mehr . . .

Struktur der Dokumentation:[Bearbeiten]

Die Dokumentation der STM32 ist im Vergleich zur AVR-Familie umfangreicher und komplexer. Sie teilt sich in mehrere Dokumente auf. Als Beispiel der Dokumentation soll stellvertretend der STM32F103RC genannt werden. Die Seite von ST beinhaltet alle nötigen Informationen passend zu diesem Prozessor.

Diese Dokumente von ST beschreiben den Controller:

  • Im STM32F103xC/D/E Datasheet sind die speziellen Eigenschaften einer bestimmten Modellreihe beschrieben und die exakten Daten und Pinouts aufgeführt, sowie die Zuordnung Chipname - Flash/RAM-Größe. Die Peripheriemodule werden nur aufgeführt, nicht detailliert beschrieben.
  • Im Reference Manual (RM0008) sind alle Peripheriemodule der jeweiligen STM32-Controllerfamilie im Detail beschrieben.
  • Das ARMv7M Architecture Reference Manual beschreibt detailliert den Prozessorkern, wie das Exception Model, die CPU Instruktionen inklusive Encoding, etc.
  • Das STM32 Cortex-M3 Programming Manual ist eine Zusammenfassung des ARMv7M Architecture Reference Manual bezogen auf die STM32.
  • Wer nicht die ST Firmware-Library verwendet, der benötigt zusätzlich das Flash Programming Manual für die Betriebsart des Flash-ROMs, d.h. die frequenzabhängige Konfiguration der Waitstates.

Zusätzlich sollten auch die Errata Sheets beachtet werden. Empfohlen sei auch die Appnote "AN2586 Getting started with STM32F10xxx hardware development". Die jeweiligen Dokumentations-PDFs sind auf der Produktseite von ST eines jeden Mikrocontrollers verlinkt.

Hardware Zugriffs-Libraries[Bearbeiten]

CMSIS[Bearbeiten]

Die CMSIS (ARM® Cortex™ Microcontroller Software Interface Standard) ist eine Library von ARM für den Zugriff auf die herstellerübergreifenden Funktionen des ARM-Cores. Hierzu gehört bei den Cortex-M4F-Cores auch die DSP und Floating-Point Funktionalität. Weiterhin existieren eine Zahl von Helferfunktionen für den NVIC, den Sys-Tick-Counter, sowie eine SystemInit-Funktion, welche sich um die PLL kümmert.

Im Rahmen des CMSIS-Standards (www.onARM.com) wurden die Headerdateien standardisiert, der Zugriff auf die Register erfolgt per Peripheral->Register. Die CMSIS C-Dateien bzw. Header enthalten auch Anpassungen für die verschiedenen Compiler. Die Portierung eines Real-Time-Betriebsystems sollte unter Verwendung der CMSIS, für Chips der verschiedenen Hersteller, stark vereinfacht möglich sein (z.B. einheitliche Adressen für Core-Hardware/Sys-Tick-Counter).

Die CMSIS ist im Download der ‎STM32 Standard Peripheral Library enthalten. Die Compiler-Hersteller liefern eine jeweils zur ihrer Tool-Version passende bzw. geprüfte Library (incl. CMSIS) aus. Diese Libs können, gegenüber den Downloads beim Chip-Hersteller, auch ältere Version beinhalten.

‎STM32 Standard Peripheral Library[Bearbeiten]

ST bietet für jede Controller-Familie eine umfangreiche zur CMSIS passende Peripherie-Bibliothek. Alle Funktionen um die Peripherie zu benutzen sind gekapselt in einfache Strukturen und Funktionsaufrufe. Somit muss man sich nicht selbst um die Peripherie-Register kümmern. Diese Library und ihre Dokumentation setzen das grundlegende Verständnis der Funktion des jeweiligen Peripheriemoduls voraus, wie es die o.a. Referenz und diverse Appnotes vermitteln. Die Library beinhaltet außerdem für fast jede Peripherie mehrere Beispiele. Für die USB Schnittstelle gibt es noch eine extra Library, genauso wie für Ethernet.

Auf der "Design Resources" Seite der Produktseite von ST eines jeden STM32 Mikrocontrollers kann die Library für den jeweiligen Controller heruntergeladen werden, z.B. hier für den o.g. STM32F103RC.

Library für STM32F4xx: STSW-STM32065 STM32F4 DSP and standard peripherals library

Programmierung[Bearbeiten]

Zur Programmierung der STM32 gibt es verschiedene Möglichkeiten, sowohl kommerzielle proprietäre als auch mit Freier Software.

Der GCC (in seinen verschiedenen Binärdistributionen) ist der einzige ARM Compiler der C++11 unterstützt.

Freie Software/Freeware[Bearbeiten]

Selber zusammenstellen[Bearbeiten]

Man nehme...:

  • Eine Entwicklungsumgebung nach Wahl:
  • Einen C,C++ Compiler:
  • Programmiersoftware zum Flashen des Target:
    • OpenOCD unterstützt viele Debug/Programmier-Adapter (Linux, Windows)
    • Texane stlink funktioniert gut mit den ST-Link Adaptern wie sie zB. auf den STM32 Discovery Boards zu finden sind (Linux)
    • Turtelizer2 oder andere JTAG Programmieradapter
    • Bei Verwendung eines Segger J-Link, den Segger GDB-Server in Verbindung mit dem beim GCC mitgelieferten GDB (Linux, Windows)

Komplette IDE's[Bearbeiten]

Andere Programmiersprachen[Bearbeiten]

  • Mecrisp-Stellaris, eine native Forth-Implementation für ARM Cortex M0/M3/M4. Es werden bereits mehrere STM32 Targets unterstützt und neue Portierungen sind herzlich willkommen. Auch Chips von TI und Freescale sind im aktuellen Paket enthalten.

Kommerzielle Umgebungen[Bearbeiten]

Tutorials für diverse Tool-Kombinationen[Bearbeiten]

Windows,Linux, Eclipse + Yagarto/CodeSourcery + OpenOCD/ST-Link

Programmieradapter[Bearbeiten]

  • SEGGER J-LINK / J-TRACE für u.a. alle ARM7/9/11, Cortex-M0/M1/M3/M4/A5/A8/A9/R4 als NonComercial J-LINK-EDU für ca. 60,- zu haben, läuft in µVision, IAR, GDB (Linux & Windows über einen eigenen GDB-Server), Keil, ...
  • Keil ULINK-ME, ULINK2, ULINK pro
  • ST-LINK, ST-LINK/V2
  • Jedes STM32 Discovery board hat einen ST-Link für Programmierung/Debugging per SWD on-board, welcher auch für eigene STM32 Target Hardware benutzt werden kann (ca. 12,- bis 19,-€, je nach Typ).
  • Raisonance RLink
  • Amontec (Achtung: keine Reaktion auf Bestellung, Telefon, Email...)
  • H-JTAG Personal Edition für ca. 60,- zu haben, läuft mit ADS, SDT, IAR, Vision und RVDS
  • iTag für 50.- bei Amazon zu bestellen, oder als Eigenbau version (offenes Design) läuft mit der freien winIDEAiTag version (siehe oben)

In der Regel haben die JTAG Adapter einen 20-Poligen Stecker, den man direkt auf die Demo-Boards, die auch einen 20-Poligen JTAG-Anschluss haben, einstecken kann. Die Pinbelegung ist genormt, siehe Artikel JTAG. Die Discovery-Boards haben keinen seperaten JTAG-Stecker, aber zumindest für das STM32F4 Discovery kann man sich leicht einen Adapter Pinheader->JTAG Stecker selber bauen.

Andere JTAG Adapter wie z.B. der ULink von Keil funktionieren nur mit dem Keil Compiler.

Programmieradapter Open-Source[Bearbeiten]

Der Controller hat auch einen fest eingebauten Boot-Lader. Damit läßt er sich auch über eine gewöhnliche serielle Schnittstelle programmieren, ohne dass man einen JTAG-Adapter benötigt. Dies erfordert ggf. entsprechende Konfiguration über die BOOTx-Pins und/oder die Option-Bytes, und ein Programm wie stm32flash.

Demo-Projekte[Bearbeiten]

Debug- und Trace-Interface (CoreSight™ Debug and Trace Technologie)[Bearbeiten]

Übersicht über beide Funktionalitäten und den Schnittstellen: http://www.keil.com/support/man/docs/ulink2/ulink2_cs_core_sight.htm

Die Coresight-Debug-Architektur ermöglicht ein nicht-invasives Debugging, d.h. es können während des Betriebes (meistens) ohne Beeinflussung des Prozessors Daten vom Speicher gelesen und in selbigen geschrieben werden.

Debugger Funktionen[Bearbeiten]

Der Debugger-Teil besitzt drei Funktionen:

  • Run Control: z.B. Programm-Start, Stopp und Einzel-Schritte.
  • (Program) Break Points: Ein Programm hält an, wenn der Programm Counter eine bestimmte Programm-Adresse erreicht.
    • Die maximale Anzahl der gleichzeitig möglichen Break Points ist begrenzt (z.B. 6 bei einem STM32).
    • Die Anzahl der Break Points ist nahezu unbegrenzt, wenn ein Debugger über den Memory Access (s.u.) sogenannte Flash Break Points unterstützt. Dabei wird ein geladenes Programm im Flash umprogrammiert, um den Debugger anzuhalten. Diese Funktionalität ist meistens ein kostenpflichtiges Zusatz-Feature des Debugger-Herstellers.
    • Beinhaltet keine Data Watch Funktionalität, welche im Trace-Teil (DWT) realisiert wird.
  • Memory Access: Lesen und Schreiben von Speicheradressen.
    • Diese Funktionalität beinhaltet keine direkte Flash-Programmierung. Der Programmiervorgang für einen Flash ist herstellerspezifisch und muss von dem verwendeten Debugger unterstützt werden.

Trace Funktionen[Bearbeiten]

Die Trace-Funktionalität wird in drei Funktionen aufgeteilt:

  • ETM (Embedded Trace Macrocell): Optional, nicht jede CPU besitzt diese Hardware (Kostenfaktor, Austattung).
  • ITM (Instrumentation Trace Macrocell): Über diesen Kanal kann ein vereinfachtes Trace des Core ermöglicht werden, sowie "printf-ähnlich" Daten über den ITM Channel 0 geschickt und im Debugger ausgegeben werden.
  • DWT (Data Watchpoint & Trace Unit):
    • Data Watch: 4 Access-Break-Points ( z.B. der Debugger bleibt stehen, wenn das Programm auf einen Speicher zugreift oder der Wert einer Variablen einen bestimmten Wert annimmt).
    • Trace Unit: Programmverlauf (durch Lesen des Program Counters) und Interrupt Aufrufe verfolgen, sowie Zeitmessungen.

Einige der Trace-Funktionalitäten können über die JTAG-Schnittstelle angesprochen werden. Die schnelle Trace-Funktionalität (mit 4 bit Parallel-Port) steht nur mit der erweiterten DEBUG + ETM Schnittstelle zur Verfügung. Im Gegensatz zum Debugger-Teil (Run Control, Break Points und Memory Access) werden Trace-Funktionen nicht von allen Debuggern unterstützt. Debugger mit der vollen Trace-Funktionalität kosten deutlich mehr.

Die Aktivierung des parallelen Trace-Ports erfordert, je nach CPU Hersteller, zusätzliche Debugger-Makros für die Aktivierung und Port-Freischaltung. Zusätzlich sind die Schnittstellenauswahl und Einstellung (Frequenzen) im Entwicklungs-Tool (IDE) wichtig, um erfolgreich den Programm-Verlauf "tracen" zu können.

Debug und Trace-Schnittstellen[Bearbeiten]

Als Debug Interface stehen zwei Varianten zur Auswahl:

  • JTAG: Dafür sind mindestens 6 Steuerleitungen nötig. Unterstützt Device Chaining: Mehrere verbundene Geräte können mit einem Debugger/Programmer gleichzeitig angesteuert werden.
  • SWD (Serial Wire Debug): Hier mindestens 2 Steuerleitungen (3 mit SWO, zzgl GND und 3,3V). Die SWD Schnittstelle ist in der Regel schneller und kann auch Funktionen aus dem Trace-Teil beinhalten (z.B. ITM, dafür wird der SWO-Pin benötigt). Device Chaining ist mit dieser Schnittstelle nicht möglich.


Standard-JTAG Steckerbelegungen: http://www.keil.com/support/man/docs/ulink2/ulink2_hw_connectors.htm

Der 10polige JTAG-Stecker von mmvisual[Bearbeiten]

mmvisual hat mit dieser Steckerbelegung die Standard JTAG Schnittstelle erweitert:

Ich habe diesen Part in den Artikel JTAG verschoben. Hinzu gekommen ist die Adapterplatine 10-Polig auf Standard JTAG 20 Polig mit TTL/V24 Wandler. Siehe hier.

Hardware-Beschaltung[Bearbeiten]

Der STM32 benötigt für den Betrieb nur (Minimalbeschaltung):

  • VCC 2..3,3V (je nach Typ)
  • AVCC 2..3,3V (sehr wichtig, der STM32 lässt sich ohne diese Spannung nicht programmieren)
  • GND
  • Reset Pin 100nF nach GND (ein Pull-Up Widerstand von ca. 40k ist intern vorhanden)
  • Boot-Pins

ansonsten nur ein paar einzelne Cs 100nF an VCC/GND.

Um Programmieren zu können wird entweder noch die serielle Schnittstelle (Programmieren über den vorprogrammierten Bootloader) oder JTAG oder die SWD Schnittstelle benötigt.

Bootmodi[Bearbeiten]

Unterschiedliche Bootmodi lassen sich mittels der PINs BOOT0 und BOOT1 auswählen . Siehe Application Note AN2606. Ausser F1 besitzen neuere Familien ein SYSCFG_MEMR Register. In dieses Register kann man die gewünschten Boot0/1 Werte schreiben und nach einem Core-Reset (!= System_Reset) startet der Prozessor im gewünschten Mode. Eine Neu- bzw. Deinitialisierung der Peripherie empfiehlt sich!

Boot from FLASH[Bearbeiten]

Startadresse wird von 0x08000004 geladen

BOOT0 Lo
BOOT1 X 

Boot from SRAM[Bearbeiten]

PC Startadresse wird an 0x200001E0 direkt angesprungen.

BOOT0 Hi
BOOT1 Hi

Da der interne FLASH der stm32f1x laut Datenblatt nur für 1000 Schreibvorgänge ausgelegt ist, kann mittels BOOT0 (High) und BOOT1 (High) auch aus dem zuvor mit dem Debugger (JTAG/SWD) beschriebenen SRAM booten. Hierbei gilt zu beachten:

VTOR auf die NVIC Tabelle im SRAM vor dem auslösen des ersten Interrupts remappen.
Um ein vergleichbares Startverhalten zum FLASH zu erreichen, empfiehlt es sich,
0xF1E0F85F an 0x200001E0 zu schreiben. Diese implizite Ausführung von "ldr.w pc,
[pc, #-0x01E0]" beim Start erzwingt ein laden der Startadresse von 0x20000004.

Boot from SYSMEM (RS232, CAN und USB)[Bearbeiten]

PC Startadresse wird von 0x1FFFF004 geladen

BOOT0 Hi
BOOT1 Lo

Ab F2 gibt es auch ein SYSCFG_MEMRMR Register. Schreibt man hier den Wert für "System Flash" und macht einen Corereset (keinen Systemreset), so landet ,man auch im Bootloader, unabhängig von dem wert der Boot Pins.

Auch ohne JTAG lässt sich ein STM32 programmieren (Bootloader-Aktivierung). Dabei stehen, je nach CPU-Typ, verschiedene Möglichkeiten zur Verfügung:

  • RS-232 (bisher alle STMs)
  • USB (alle USB fähigen CPUs > F103)
  • CAN (wie USB nur in bestimmten MCUs)

3 zusätzliche Verbindungen müssen auf dem Board gepatcht werden. Für einen Test geht es auch mit Tastern für RESET und BOOT0.
RESET=RTS (L-aktiv)
BOOT0=DTR (H-aktiv)
BOOT1=LOW

Details sind hier im Forum: STM32 Programmiertool

Tools für den Download über den STM32-Bootloader:

Bewertung[Bearbeiten]

Vorteile[Bearbeiten]

Vorteile gegenüber ARM7:

  • Interrupt-Controller jetzt Teil des Prozessors (als Core Peripheral), die Vector Table ist jetzt eine echte Vektortabelle, keine Sprungliste wie bei ARM7. Durch Automatismen zwischen Core und NVIC (auto register save r0..r3, lr, sp, pc) bei Interrupt Entry wird eine deutlich schnellere Ausführungszeit bei Interrupts erreicht. Der Interrupt Code muss sich nicht mehr selbst um die Sicherung der o.g. Register kümmern und eine besondere Konfiguration der Handler im Compiler entfällt. Sind vor Beendigung einer ISR (d.h. Rücksprung zum User Code) weitere Interrupts pending, so werden diese ausgeführt, ohne dass eine komplette pop-push-sequenz der Register notwendig ist. Schön beschrieben ist es hier im Insider's Guide unter 2.4.5 / Seite 20.
  • Thumb-2 Befehlssatz, deutlich schneller als Thumb-1 und ebenso kompakt
  • Weniger Pins für Debugging benötigt durch SWD
  • Mehr Hardware Breakpoints machen debuggen einfacher
  • Software ist einfacher weil die Umschaltung zwischen ARM Mode und Thumb Mode wegfällt

Vorteile gegenüber LPC1700 und LPC1300:

  • Flexiblere Gehäuseformen mit mehr Peripherie bei kleinen Gehäusen
  • FW-Lib für alle STM32 gleich, alle AppNotes/Demos beziehen sich auf diese eine FW-Lib was die Entwicklung der eigenen Applikation sehr beschleunigt.
  • Genauerer und flexiblerer ADC, insbesondere gegenüber LPC1300
  • Flexiblere Varianten der Peripherie >> bei weniger einen deutlichen Preisvorteil
  • ab 0,85 EUR (Stand 2010) Allerdings gibts den LPC1100 mit Cortex-M0 schon ab 0,65 $!

Vorteile gegenüber SAM3/4:

  • Fast alle Pins sind 5-Volt tolerant.

Vorteile gegenüber anderen "Kleinen" wie z.B. PIC, Atmel usw.

  • nahezu gleicher Preis bei Hobby Anwendungen
  • 32 Bit ohne Umwege in Assembler rechenbar
  • Schnelle direkte Offset-Adressierung ermöglich effizienten Zugriff auf Stack-Variablen, lokal gespeicherte Flash-Konstanten, struct/Array-Elemente
  • Einfache einheitliche Adressierung des gesamten Adressraums, d.h. Pointer auf Peripherieregister, RAM & Flash können exakt gleich behandelt werden, keinerlei Banking/Umschalt-Mechanismen erforderlich auch bei großem Flash/RAM
  • Interrupt-Prioritäten und Prioritätsgruppen
  • Effiziente Pointerarithmetik da Registerbreite=Adressbreite
  • bessere Peripherie wie USB, Ethernet, Vielzahl an Timern
  • der ARM-Core hat eine höhere Taktfrequenz und kann gleichzeitig mehr in weniger Takten berechnen
  • Hardware-Division, bei einigen FPU zur effizienten float-Berechnung
  • Mit größerem Flash/RAM verfügbar
  • Code kann direkt aus dem RAM ausgeführt werden, Speicherschutz und privilegierter Ausführungsmodus können "Kernel"- vor "Anwendungs"-Code schützen, somit wird das dynamische Nachladen von Anwendungen aus externem Speicher effizient & sicher möglich
  • ... und weitere 1000 Punkte ...

Links

Nachteile[Bearbeiten]

Nachteil gegenüber LPC1700:

  • STM32F1xx: nur 72 MHz statt 100 MHz (LPC1759: 120 MHz) Taktfrequenz; STM32F2xx hat diesen Nachteil nicht (ebenfalls 120MHz, STM32F4xx mit 180MHz)
  • Der LPC1700 besitzt deutlich mehr Mechanismen, um die Auswirkung der Waitstates des Flash-ROMs auf Code- und Datenzugriffe zu reduzieren und das bedeutet mehr Performance bei gleicher Taktfrequenz. Beim STM32F2 entfällt dieser Nachteil wohl aufgrund des ART Accelerators.
  • Alle LPC1xxx haben 32 Bit Timer. Bei den STM32 haben das nur die STM32F2xx (2 Stück)
  • I2S Einheit von ST hat keinen FIFO und im 24/32Bit Modus müssen 2x16Bit Halbwörter übertragen werden. Wobei allgemein bei neuen ARM Prozessoren die vorhandenen DMA-Kanäle (basierend auf eigenen BUS-Kanälen und Speicherzugriffen) FIFO in beliebiger Größe bedeutet.

Nachteil für Hobby-Anwender

  • Nicht direkt "Steckbrettauglich", da kein DIL Gehäuse verfügbar. Der ebay-Shop dipmicro führt jedoch sehr günstige Lötadapter für Umsetzung von LQFP48 auf DIP48. QFP64 in 0.5mm Pinabstand und nicht 0.8mm wie AVR. Von NXP gibt es Cortex-M0 µC im DIL Gehäuse.
  • Viel Peripherie, Clocks müssen alle richtig eingestellt werden, ggf. Anpassung des Startup Codes usw.

Errata, Tipps und Tricks[Bearbeiten]

Hardware[Bearbeiten]

  • AD-Wandler PA0: Im Errata steht, dass hier Fehler in der Wandlung entstehen könnten, also einen anderen Pin verwenden.
  • CAN-Bus PD0/PD1: Remap geht erst ab der 100-Pin-Version. Steht im RM0008 unter 9.3.3.: "CAN1 alternate function remapping". Alle Infos von RM0008 9.3.x sind interessant
  • CAN und USB sind bei der F1 Serie nur bei der "◦Connectivity-Line" gleichzeitig nutzbar. Siehe Datenblätter.
  • Mit internem RC-Oszillator kann die CPU mit maximal 64MHz betrieben werden. Mit einem externen Quarz sind dann 72MHz möglich.
  • Für USB Betrieb muss die CPU mit 48MHz oder 72MHz betrieben werden (bei STM32F1xx).
  • Der Idle Interrupt vom Usart wird zwar ausgelöst, aber nicht vom entsprechenden Statusflag angezeigt
  • Der DMA fängt beim aktivieren immer von vorn an zu zählen, auch wenn er nur kurz angehalten wurde
  • STM32F2xx hat kein Flash Size Register, bei STM32F4xx ist zwar ein flash Size Register beschrieben, kollidiert aber in der Adresse mit einem anderen Register
  • Derivate mit internem EEPROM und nur einer Speicherbank haben das "Feature" bei write/erase des Data-Flashes (EEPROM) einen kompletten stall der code execution zu verursachen (inkl. ISR's, DMA). Desgleichen bei write/erase des internen Flash (ISP-routinen, EEPROM-Emulation).
  • Der I2C hat diverse Fehler, welche im Errata des jeweiligen Modells (z.B. STM32F105xx and STM32F107xx Errata sheet ) zu finden sind. Workarounds hierzu finden sich in der Application Note AN2824. Am Besten benutzt man jedoch die I2C Communication peripheral application library (CPAL) von ST (STSW-STM32127)
  • weitere undokumentierte Features
  • Interrupt-Flags in Statusregistern der diversen Peripherals wie der Timer müssen zu Beginn (bzw. möglichst weit vor dem Return) der ISR zurückgesetzt werden, da die ISR sonst eventuell 2x ausgeführt wird (Siehe STM32 FAQ und Forum).

Software[Bearbeiten]

GCC[Bearbeiten]

Um den GCC direkt zu verwenden (zB. mit selbstgebautem makefile), falls man das nicht von einer Entwicklungsumgebung machen lässt, siehe zunächst ARM GCC. STM32-spezifisches ist:

  • Wird die STM32 Standard Peripheral Library und ein Quarz verwendet, so muss noch per Präprozessor-Definition die Frequenz des Quarzes angegeben werden mittels z.B. -DHSE_VALUE=8000000 für 8MHz (wie auf dem STM32F4 Discovery).
Startupcode & Linkerscript[Bearbeiten]
  • Damit der compilierte Code an den richtigen Stellen im Controller landet (d.h. dem Flash) muss man dem Linker ein Linkerscript mitgeben. Dies geht per "-T pfad_zum_linkerscript.ld" an den Linker-Befehl. Im Archiv der STM32 Standard Peripheral Library befindet sich ein Beispiel-Linkerscript für die Atollic TrueSTUDIO IDE, dieses kann direkt mit dem GCC verwendet werden. Beispielsweise für den STM32F4 befindet sich das Script im Pfad "/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Project/STM32F4xx_StdPeriph_Templates/TrueSTUDIO/STM324x7I_EVAL/stm32_flash.ld" des Archives.
  • Damit beim Starten die richtigen Initialisierungen vorgenommen werden (wie globale Variablen und bei C++ Konstruktoren globaler Objekt-Instanzen) muss als erstes ein Startupcode laufen, der dann die main()-Funktion aufruft. Der Startupcode ist meistens in Assembler geschrieben, C-Code ist aber auch möglich. Im Archiv der STM32 Standard Peripheral Library befindet sich ein Beispiel-Startupcode für die Atollic TrueSTUDIO IDE, dieser kann direkt mit dem GCC verwendet werden. Beispielsweise für den STM32F4 befindet sich der Code in Assemblerform im Pfad "/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Libraries/CMSIS/Device/ST/STM32F4xx/Source/Templates/TrueSTUDIO/startup_stm32f40xx.s" des Archives. Der Assemblercode kann per arm-none-eabi-as (Flags s.o.) assemblisiert werden, die resultierende .o -Datei normal mitgelinkt.

Zusammen bieten die beiden Dateien der Anwendung ein Standard-C-Interface, d.h. man kann wie gewohnt globale Variablen verwenden und seinen Code in die main()-Funktion schreiben.

Tipps für Umsteiger von Atmel/PIC/8051[Bearbeiten]

  • Prozessortakt hat unterschiedliche Taktquellen und eine PLL.
  • Alle Peripheriemodule haben einen extra Clock, den man aktivieren muss.
  • Wenn man z.B. einen UART benutzen möchte, so muss man den Clock vom UART, Alternate Function IO (AFIO) und dem GPIO-Port aktivieren.
  • Ansonsten hat man nahezu doppelt so viele Möglichkeiten in den Peripheriemodulen.
  • Interrupt-Flags müssen in der ISR selber gelöscht werden
  • Forum zu Interrupts vs. Events

Errata vom STM32F4xx die nicht im Errata von ST stehen[Bearbeiten]

Bezugsquellen[Bearbeiten]

Controller[Bearbeiten]

Versand Europaweit im endasmedia.ch Shop

Versandhäuser für Privatpersonen

Gewerblich liefern natürlich viele wie EBV, Mouser, Farnell, Digikey usw...

Evaluation Boards[Bearbeiten]

Weblinks, Foren, Communities, Tutorials[Bearbeiten]