Forum: Mikrocontroller und Digitale Elektronik STM32 Arduino


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus (Gast)


Lesenswert?

Für den STM32F103 gibt es eine sehr einfache Möglichkeit, diesen mit der 
Arduino-IDE zu programmieren. Man braucht eigentlich nur einen seriellen 
Adapter:
http://grauonline.de/wordpress/?page_id=1004

Da ich einen Haufen STM32 Boards mit anderen Typen als dem STM32F103 
herum liegen habe, würde ich auch diese auf die mit der Arduino IDE 
programmieren.

Hat das jemand schon mal gemacht?

Die Boards habe ich meistens auf der Embedded umsonst bekommen und 
wollte die immer mal in Betrieb nehmen, kam aber nicht dazu.

von STM STM STM (Gast)


Angehängte Dateien:

Lesenswert?

Markus schrieb:
> Hat das jemand schon mal gemacht?

Nein ich nicht. Ich mache lieber die direkte Methode über
eine geeignetere IDE.

Markus schrieb:
> wollte die immer mal in Betrieb nehmen, kam aber nicht dazu.

Dann mach es doch jetzt, wenn du schon die Frage hast.

Grundsätzlich wirst du nur die Boards/Prozessoren zuverlässig
programmieren können die in der Boards-Liste auftauchen.

Siehe Bild.

von Markus (Gast)


Lesenswert?

Hmm, von den STM32F103 werden ziemlich viele unterstützt.
Was ist eigentlich der Unterschied von einem STM32F103 zu einem 
MapleMini?

von e-d (Gast)


Lesenswert?


von Markus (Gast)


Lesenswert?

Kann es sein, dass das günstige BluePill-Board
http://wiki.stm32duino.com/index.php?title=Blue_Pill

das gleiche wie der Mable Mini ist
https://www.leaflabs.com/maple

nur ohne USB-Bootloader?

von STM STM STM (Gast)


Lesenswert?

Markus schrieb:
> nur ohne USB-Bootloader?

Alle haben einen Bootloader, und zwar einen den du gar nicht
löschen kannst weil er fest in den Chip eingebrannt ist.

von Christopher J. (christopher_j23)


Lesenswert?

Nein, es gibt Unterschiede beim Pinout und der Peripherie. Lediglich der 
verbaute Controller ist quasi gleich (F103C8T6 und F103CBT6). Der C8T6 
ist lediglich auf 64KB Flash "umdeklariert" aber hat in Wirklichkeit 
auch 128KB. Das Maple kann man ohne weiteres  mit DFU-Bootloader und als 
USB-Client betreiben, das Bluepill kann nur entweder oder weil die 
Möglichkeit zur USB-Reenumeration fehlt.

STM STM STM schrieb:
> Alle haben einen Bootloader, und zwar einen den du gar nicht
> löschen kannst weil er fest in den Chip eingebrannt ist.

Das ist aber ein serieller Bootloader und kein USB-BL.

: Bearbeitet durch User
von Markus (Gast)


Lesenswert?

>das Bluepill kann nur entweder oder weil die
>Möglichkeit zur USB-Reenumeration fehlt.

Könnte man nicht einfach den Maple-USB-Boodloader auf die BluePill 
flashen?
Dann sollten doch beide die selbe Funktion haben, oder?

von Christopher J. (christopher_j23)


Lesenswert?

Nein, man kann nicht einfach so den Maple-USB-Bootloader auf die 
BluePill flashen, weil für die Reenumeration nicht nur Software, sondern 
auch Hardware notwendig ist, genauer gesagt gibt es auf dem Maple-Board 
ein paar Transistoren dafür und die fehlen auf dem BluePill Board (das 
meinte ich mit Peripherie ist anders). Es gibt aber für das BluePill 
auch einen USB-Bootloader und dann kannst du darüber flashen. Näheres 
findest du im Wiki: 
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader

von chris (Gast)


Lesenswert?

Hier gibt es einen guten Artikel zur Installation des STM32F103 mit 
Debugger:
http://hackaday.com/2017/03/30/the-2-32-bit-arduino-with-debugging/

von chris (Gast)


Lesenswert?

Arduino Benchmark:

Im folgenden wird exakt der gleiche FFT-Code von hier

https://github.com/kosme/arduinoFFT

mit leicht veränderter Main-Loop
1
void loop()
2
{
3
  double cycles = (((samples-1) * signalFrequency) / samplingFrequency); //Number of signal cycles that the sampling will read
4
  for (uint8_t i = 0; i < samples; i++)
5
  {
6
    vReal[i] = int8_t((amplitude * (sin((i * (Theta * cycles)) / samples))) / 2.0);/* Build data with positive and negative values*/
7
  }
8
9
  long start=micros();
10
  
11
  FFT.Compute(vReal, vImag, samples, FFT_FORWARD); 
12
  FFT.ComplexToMagnitude(vReal, vImag, samples); 
13
  double x = FFT.MajorPeak(vReal, samples, samplingFrequency);
14
  
15
  long stopTime=micros();
16
  
17
  Serial.print("calculation time in us: "); Serial.println(stopTime-start);
18
  
19
  delay(2000); /* Repeat after delay */
20
}

auf einem Arduino Uno und einem STM32F103 ( BluePill ) mit der Arduino 
IDE compiliert

Arduino Uno ( Atmega328, 16 Mhz )
=================================

calculation time in us: 24020

Sketch uses 6,162 bytes (19%) of program storage space. Maximum is 
32,256 bytes.
Global variables use 753 bytes (36%) of dynamic memory, leaving 1,295 
bytes for local variables. Maximum is 2,048 bytes.


BluePill ( STM32F103, Cortex M3, 72 MHz )
=========================================

calculation time in us: 5859

Sketch uses 18,272 bytes (27%) of program storage space. Maximum is 
65,536 bytes.
Global variables use 4,092 bytes (19%) of dynamic memory, leaving 16,388 
bytes for local variables. Maximum is 20,480 bytes.

von m.n. (Gast)


Lesenswert?

chris schrieb:
> Im folgenden wird exakt der gleiche FFT-Code von hier

Ob Dein "exakt" auch zutrifft?
Beim AVR wird mit float (32 Bit) gerechnet und beim F103 vermutlich mit 
double (64 Bit).

von chris (Gast)


Lesenswert?

Naja, das exakt bezog sich auf den Source Code.
Aber es ist ein guter Hinweis, ich habe schon es was mehr als Faktor 4 
in der Geschwindigkeit bei sehr rechenintensiven Anwendungen erwartet.

Die Frage ist: welcher Benchmark wäre besser?

Warum sie beim AVR das double Format gleich wie das float Format gemacht 
haben, habe ich nie verstanden. Wer ein double verwenden will, soll ein 
double haben, auch wenn es mehr Speicher und Rechenzeit kostet.

von chris (Gast)


Angehängte Dateien:

Lesenswert?

Hier eine andere Version mit "int".
Gut, beim AVR ist "int" 16 bit und beim Arm ist "int" 32 bit.

Arduino Uno ( Atmega328, 16 Mhz )
=================================

FFT number of samples: 256
calculation time in us: 33424

Sketch uses 7,742 bytes (24%) of program storage space. Maximum is 
32,256 bytes.
Global variables use 1,074 bytes (52%) of dynamic memory, leaving 974 
bytes for local variables. Maximum is 2,048 bytes.

BluePill ( STM32F103, Cortex M3, 72 MHz )
=========================================

FFT number of samples: 256
calculation time in us: 7640

Sketch uses 20,592 bytes (31%) of program storage space. Maximum is 
65,536 bytes.
Global variables use 4,608 bytes (22%) of dynamic memory, leaving 15,872 
bytes for local variables. Maximum is 20,480 bytes.

von m.n. (Gast)


Lesenswert?

chris schrieb:
> Hier eine andere Version mit "int".
> Gut, beim AVR ist "int" 16 bit und beim Arm ist "int" 32 bit.

Nimm doch bitte auch beim AVR int32_t (oder long). Erst dann kann man 
vergleichen und dann zeigt sich auch der deutliche 
Geschwindigkeitsunterschied bei den Berechnungen.

von Bernd K. (prof7bit)


Lesenswert?

Christopher J. schrieb:
> weil für die Reenumeration nicht nur Software, sondern
> auch Hardware notwendig ist, genauer gesagt gibt es auf dem Maple-Board
> ein paar Transistoren dafür und die fehlen auf dem BluePill Board

Ist das bei allen STM32 so daß in der USB-peripherie auf dem Chip ein 
paar Bauteile vergessen wurden oder nur bem F103?

: Bearbeitet durch User
von Dauergast (Gast)


Lesenswert?

Bernd K. schrieb:
> Ist das bei allen STM32 so daß in der USB-peripherie auf dem Chip ein
> paar Bauteile vergessen wurden oder nur bem F103?

Auf dem Chip wurde gar nichts vergessen.

Auf den als "Minimum System Development Board Module" verkauften und 
allgemein "Bluepill" bzw. "Redpill" genannten Boards fehlt die Hardware, 
die ein An-/Abstecken am USB (wie beim Maple-Board) simuliert. Damit 
geht der originale Maple-Bootloader nicht, aber es gibt andere 
Bootloader bzw. die Möglichkeit, über seriell bzw. ST-Link zu flashen, 
also kein Problem.

Ein Problem dieser Boards ist nur, daß der USB-Pullup 10k statt 1k5 groß 
ist, was bei manchen USB-Hosts zu Problemen führt. Muß man halt ändern, 
am Rechner der "Entwicklers" ging es wohl. Vielleicht gibt es die Boards 
ja mit 1k5, wenn die drölfundneunzig Mio. Stück mit 10k abverkauft sind. 
Oder die Kiste mit den 10k 0602 in Shenzhen aufgebraucht ist.

Bei einem Board für €1,89 mit einem Chip, der normalerweise 
€2,67/1000Stk. kostet, kann/muß man mit sowas leben :-)

von Leo C. (rapid)


Angehängte Dateien:

Lesenswert?

m.n. schrieb:
> chris schrieb:
>> Hier eine andere Version mit "int".
>> Gut, beim AVR ist "int" 16 bit und beim Arm ist "int" 32 bit.
>
> Nimm doch bitte auch beim AVR int32_t (oder long). Erst dann kann man
> vergleichen und dann zeigt sich auch der deutliche
> Geschwindigkeitsunterschied bei den Berechnungen.

Hier die Ergebnisse für die reine fft-Funktion ohne Arduino-Umgebung:
1
   text     data      bss      dec      hex  filename
2
    500      256        0      756      2f4  fft-arm-16.o
3
    416      512        0      928      3a0  fft-arm-32.o
4
    998      256        0     1254      4e6  fft-avr-16.o
5
   1812      512        0     2324      914  fft-avr-32.o

Für ARM würde das Ergebnis wahrscheinlich noch besser aussehen, wenn man 
FIX_MPY() weglassen würde.

Details in den Anhängen.

von Bernd K. (prof7bit)


Lesenswert?

Dauergast schrieb:
> "Redpill" genannten Boards fehlt die Hardware,
> die ein An-/Abstecken am USB (wie beim Maple-Board) simuliert.

Also doch auf dem Chip vergessen. Pullups ein und ausschschalten sollte 
die USB-Peripherie eigentlich ohne externes Hühnerfutter und ohne 
wertvolle zusätzliche Pins zu verbrauchen von sich aus können. Wurde das 
bei allen STM32 unterlassen oder ist das ein Einzelfall?

von STM STM STM (Gast)


Lesenswert?

Leo C. schrieb:
> Für ARM würde das Ergebnis wahrscheinlich noch besser aussehen

Besser gesagt das Ergebnis sieht deutlich besser aus ....

.... wenn man bedenkt dass der F103 de facto nur mit 24 Mhz
läuft (3 Wait States für Flash) und nicht wie die Taktangabe
vermuten lässt mit 72 MHz.

von m.n. (Gast)


Lesenswert?

Leo C. schrieb:
> Hier die Ergebnisse für die reine fft-Funktion ohne Arduino-Umgebung:

Nur lassen sich diese Ergebnisse nicht mit den Ergebnissen von Chris 
vergleichen. Insbesondere fehlt die Ausführungszeit.

STM STM STM schrieb:
> Besser gesagt das Ergebnis sieht deutlich besser aus ....
>
> .... wenn man bedenkt dass der F103 de facto nur mit 24 Mhz
> läuft (3 Wait States für Flash) und nicht wie die Taktangabe
> vermuten lässt mit 72 MHz.

Ich weiß nicht, wie auf zu Deiner Aussage kommst. Um das nachzuweisen, 
müßte man die interne Taktfrequenz auf 24 MHz bei 0 Waitstates 
einstellen.
Hast Du das gemacht?

von chris (Gast)


Lesenswert?

Autor: Leo C. (rapid)
>Hier die Ergebnisse für die reine fft-Funktion ohne Arduino-Umgebung:

Danke für die Ergebnisse. Es freut mich, wenn jemand auch mal was macht 
als immer nur zu reden.
Was mich ein wenig wundert: Warum sind die "text" Segmente 
unterschiedlich lang?

Ob die Ergebnisse aus der Arduino-Umgebung aussagekräftig sind, darüber 
lässt sich streiten.
Obwohl: Der Geschwindigkeitsbenchmark wird sich wohl mit anderer 
Einbettung auch nicht ändern. Arduino bietet hier aber die Möglichkeit, 
das ganze auf zig verschiedenen Prozessorarchitekturen ohne größeren 
Aufwand zu testen.

Bei der Codegröße lässt sich aber immerhin eines klar sagen: Die ARM 
User sparen nicht beim Speicherverbrauch.

von STM STM STM (Gast)


Lesenswert?

m.n. schrieb:
> Hast Du das gemacht?

Nein. Ich weiss dass die Annahme nicht sehr genau ist, aber die
Hauptlast der Zugriffe ist nun mal das Flash, und das wird mit
drei Waitstates abgearbeitet, ich habe mir das in einer engen
Schleife auch mal angeschaut. Allerdings mögen da noch Prefetch
Mechanismen die Sache noch etwas beschleunigen (wenn man nicht
einer engen Schleife arbeitet...).

Die 3 Waitstates fürs Flash gibt das Manual vor, ob da noch was
ausserhalb der Spec geht .... weiss ich nicht.

von chris (Gast)


Lesenswert?

>Bei der Codegröße lässt sich aber immerhin eines klar sagen: Die ARM
>User sparen nicht beim Speicherverbrauch.

Upps, kleiner Interpretationsfehler von mir: Der AVR scheint ja mehr 
Speicher zu brauchen. Jetzt wird's mir noch unklarer.

von Leo C. (rapid)


Lesenswert?

m.n. schrieb:
> Nur lassen sich diese Ergebnisse nicht mit den Ergebnissen von Chris
> vergleichen. Insbesondere fehlt die Ausführungszeit.

Immerhin kann man sie untereinander vergleichen, und liefern dafür klare 
Aussagen. Chris' "Ergebnisse" kann man nicht mal untereinander 
vergleichen. Offensichtlich fügt die Arduino-Umgebung bei stm32 
unverhältnismäßig viel Speicherbedarf hinzu.

von Bernd K. (prof7bit)


Lesenswert?

chris schrieb:
> Upps, kleiner Interpretationsfehler von mir: Der AVR scheint ja mehr
> Speicher zu brauchen. Jetzt wird's mir noch unklarer.

Ist doch logisch. Sobald man mit mehr als 8 Bit rechnet wird der 
generierte Code sofort schmerzhaft umständlich und entsprechend 
langsamer.

Bei der AVR-Variante sieht man auch schön wie allein das Verbreitern von 
16 auf 32 Bit den Codeumfang noch ein zweites Mal verdoppelt während bei 
ARM es bis einschließlich 32 Bit Breite keinen Unterschied macht wie 
breit die Variablen sind.

von Feldstecher (Gast)


Lesenswert?

m.n. schrieb:
> Nimm doch bitte auch beim AVR int32_t (oder long). Erst dann kann man
> vergleichen und dann zeigt sich auch der deutliche
> Geschwindigkeitsunterschied bei den Berechnungen.
Oder: "Nimm doch bitte auch beim ARM int8_t. Erst dann kann man 
vergleichen..."

Fazit: Aepfel und Birnen. Bzw. es kommt wieder auf die konkrete 
Anwendung an.

von chris (Gast)


Lesenswert?

Leo schrieb
>Immerhin kann man sie untereinander vergleichen, und liefern dafür klare
>Aussagen. Chris' "Ergebnisse" kann man nicht mal untereinander
>vergleichen. Offensichtlich fügt die Arduino-Umgebung bei stm32
>unverhältnismäßig viel Speicherbedarf hinzu.

Ein Benchmark ist immer für einen bestimmten Anwendungsfall gut und in 
meinem Benchmark ist das der Test zusammen mit dem Arduino Framework.

Hier geht es auch um die Frage der Portabilität von Code. Eigentlich 
sollte man erwarten, das C relativ prozessorunabhängig ist. Wie man in 
dem FFT-Beispiel oben sieht, werden die Algorithmen meistens aber schon 
auf bestimmte Prozessortypen angepasst. Wie die Verwendung von FixMul in 
der obigen FFT, was gut für den 8Bit AVR aber schlecht für den 32bit ARM 
ist.

Und die Tendenz, dass die ARM-Umgebungen den Code aufblasen ist auch 
klar ersichtlich. Diese Tendenz wurde in einem anderen Thread auch schon 
gefunden:
Beitrag "Re: AVR versus ARM"

Insofern ist mein Benchmark bezüglich Gesamtsystem für meine Zweck 
deutlich aussagekräftiger für meine Zwecke. Insbesondere interessieren 
mich die erzielten Geschwindigkeiten.

von Leo C. (rapid)


Lesenswert?

chris schrieb:
> BluePill ( STM32F103, Cortex M3, 72 MHz )
> =========================================
>
> FFT number of samples: 256
> calculation time in us: 7640

Ich habe das Ganze mal ohne Arduino (mit libopencm3) auf dem gleichen 
Board zum Laufen gebracht. Ähnliches Ergebnis:
1
72MHz HSE: clock cycles: 531345  (7379us)

Der weitaus größte Teil der Zeit geht aber für die Initialisierung der 
Arrays drauf, da dafür 'double sin(double)' benutzt wird.
Hier die Zeit für die Integer FFT-Funktion:
1
72MHz HSE: clock cycles: 42587  (591us)

STM STM STM schrieb:
> Die 3 Waitstates fürs Flash gibt das Manual vor, ob da noch was
> ausserhalb der Spec geht .... weiss ich nicht.

Mein Manual und libopencm3 sagen 2 Waitstates.
Hier einige vorläufige Ergebnisse mit 0 Waitstates bis 24MHz und 2 
Waitstates bei 72MHz:
1
FFT number of samples: 256                                                         
2
 8MHz HSI: clock cycles: 376903  (47112us)                                         
3
24MHz HSE: clock cycles: 377545  (15731us)
4
72MHz HSE: clock cycles: 531345  (7379us)
Leider habe ich einige Zeit gebraucht, um die Clockumschaltung 
absturzfrei hinzubekommen. Eigentlich sollten bei 8 und 24MHz die Anzahl 
Cycles gleich sein. Aber heute habe ich keine Zeit mehr, um der Sache 
weiter nachzugehen.

von Bernd K. (prof7bit)


Lesenswert?

chris schrieb:
> Und die Tendenz, dass die ARM-Umgebungen den Code aufblasen ist auch
> klar ersichtlich.

Umgebungen wie Arduino blasen den AVR-Code ebenfalls auf. Das hat ja 
nichts  mit ARM vs. AVR per se zu tun. Und das Phänomen (oder die 
Tendenz wie Du schreibst) mit dem Softwarebloat gibts ja nicht erst seit 
die ARM-Hersteller sich auf die "Maker" gestürzt haben mit 
Klick-Dein-Programm-Mit-Der-Maus-Zusammen-Umgebungen, dieses Thema ist 
ja schon fast so alt wie es programmierbare Rechenmaschinen gibt.

> Diese Tendenz wurde in einem anderen Thread auch schon
gefunden

Lustig, ausgerechnet in dem Posting das Du verlinkst wird das exakte 
Gegenteil behauptet (und begründet).

Und in dem FFT-Beispiel sieht man ja auch eindrucksvoll wie die 
Vervielfachung der benötigten Maschinenworte (2 oder 4 Stück für einen 
einzigen Integer) bei rechenintensivem Code die Codegröße annähernd 
verdoppelt oder vervierfacht.

Die Erfahrung auch von anderen zeigt daß in der Regel mit ARM allein 
erst mal kein größerer Code einhergeht, eher kleinerer.

von Christopher J. (christopher_j23)


Lesenswert?

Bernd K. schrieb:
> Dauergast schrieb:
>> "Redpill" genannten Boards fehlt die Hardware,
>> die ein An-/Abstecken am USB (wie beim Maple-Board) simuliert.
>
> Also doch auf dem Chip vergessen. Pullups ein und ausschschalten sollte
> die USB-Peripherie eigentlich ohne externes Hühnerfutter und ohne
> wertvolle zusätzliche Pins zu verbrauchen von sich aus können. Wurde das
> bei allen STM32 unterlassen oder ist das ein Einzelfall?

Hmm, ich war da wohl die ganze Zeit auf dem falschen Dampfer und dachte 
diese Transistoren wären unbedingt nötig, weil ich das so auch auf jeder 
erdenklichen Platine so gesehen habe, angefangen von den Olimex Boards 
über die Discovery Boards bis hin zu Maple Mini und ST-Link Clones. 
Scheinbar (und logischerweise) ist dem aber gar nicht so und es geht 
auch mit internen Pullups, zumindest bei manchen Controllern. Hier gibt 
es einen uralten Thread dazu, der vor etwa einem Jahr wieder etwas 
aufgewärmt wurde:
Beitrag "STM32  USB  1k5-Connect-PullUp"

von Markus (Gast)


Angehängte Dateien:

Lesenswert?

Ich bin auf der Suche nach einer passenden Lib für den Neopixelring.
Hat jemand schon so was für den STM32 und Arduino gefunden?

von Markus (Gast)


Lesenswert?

>Hmm, ich war da wohl die ganze Zeit auf dem falschen Dampfer und dachte
>diese Transistoren wären unbedingt nötig,

Roger Clark schreibt dazu in der Bootloader-Wiki:
( https://github.com/rogerclarkmelbourne/STM32duino-bootloader )

"On "generic" boards, the USB reset (to force re-enumeration by the 
host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, 
and driving PA12 low for a short period, before setting the pin back to 
its USB operational mode. This system to reset the USB was written by 
@Victor_pv. Note. It is not guaranteed to work on all "generic" STM32 
boards, and relies on PA12 having a pull-up resistor of around 1.5k - 
however most "generic" boards seem to have this. Its unclear if this 
method to reset the USB bus conforms precisely to the USB standard, but 
it seems to work fine on all PC's and Mac's (and Linux boxes) on which 
its been tested - and seems usable for hobby  non commericial  
non-critical systems."

In dem Repository gibt es jede Menge vorkompilierte Versionen.
Was mich interessieren würde:
- welche ist die richtige für das BluePill Board
- Wird Serial.println dann auch auf USB umgeleitet?

von Schnapszahl (Gast)


Lesenswert?

Die Antwort zu

> - Wird Serial.println dann auch auf USB umgeleitet?

findest Du evtl hier:

http://wiki.stm32duino.com/index.php?title=API#Serial_.26_USB_Serial

von Markus (Gast)


Lesenswert?

>findest Du evtl hier:
Dank dafür. Laut der Beschreibung ist es so, dass die serielle Ausgabe 
bei Verwendung des Bootloaders auf den USB Port geht.

Wie ich festgestellt habe, lässt sich das BluePill Board gut mit den 
ILI9143-Displays verwenden:
Beitrag "Re: 2.2'TFT ILI9340 und Arduino"

von Christopher J. (christopher_j23)


Lesenswert?

Markus schrieb:
> welche ist die richtige für das BluePill Board

Die einzelnen Bootloader sind sortiert nach dem Pin an dem die on-board 
LED hängt, also generic_boot20_pc13.bin ist für LED an PC13, 
generic_boot20_pb0.bin für LED an PB0, usw. Beim BluePill hängt sie - 
meines Wissens immer, evtl. gibt es Abweichungen - an PC13.

von chris (Gast)


Angehängte Dateien:

Lesenswert?

Mittlerweile gibt es auch rudimentäre Unterstützung für das STM32F4 
Discovery:
Beitrag "STM32F4 Discovery Arduino"

Daher ein neuer Benchmark mit FloatingPoint IIR filter.

Arduino UNO ( 16Mhz )
=====================
time/sample us: 127

Sketch uses 3,964 bytes (12%) of program storage space. Maximum is 
32,256 bytes.
Global variables use 1,312 bytes (64%) of dynamic memory, leaving 736 
bytes for local variables. Maximum is 2,048 bytes.

STM32F4 BluePill ( 72MHz )
==========================
time/sample us: 16

Sketch uses 9,772 bytes (14%) of program storage space. Maximum is 
65,536 bytes.
Global variables use 3,184 bytes of dynamic memory.


STM32F4 Discovery
==================

time/sample us: 4

Sketch uses 18,540 bytes (1%) of program storage space. Maximum is 
1,048,576 bytes.
Global variables use 14,712 bytes of dynamic memory.


Nimmt man den den Arduino Uno als Referenz ergibt sich also folgends:

MCU          speed factor
Atmega328    1
STM32F103    8
STM32F4      32

Beim Discovery weiss ich den MCU-Clk nicht. Vielleicht 168MHz?

von Kai (Gast)


Lesenswert?

Bitte erklaert der Welt kurz, welche Libraries mit dem STM32 in der 
Arduino IDE genutzt werden koennen. Ich finde dazu praktisch nichts. Die 
Seite http://wiki.stm32duino.com/index.php?title=Category:Libraries ist 
praktisch leer. Koennen alle Arduino-Libs genutzt werden? Worauf kommt 
es an?

Wenn es keinen Library-Support gaebe 
(https://www.arduino.cc/en/reference/libraries), haette es doch keine 
Vorteile gegenueber z.B. EM-Bitz?

Danke euch!

von STM STM STM (Gast)


Lesenswert?

Kai schrieb:
> haette es doch keine Vorteile gegenueber z.B. EM-Bitz?

Es hat keine Vorteile.

Kai schrieb:
> Bitte erklaert der Welt kurz, welche Libraries mit dem STM32 in der
> Arduino IDE genutzt werden koennen.

Warum fragst du nicht dort in der Arduino-Ecke wo die
Einbindung für den STM32F103 herkommt?

von STM STM STM (Gast)


Lesenswert?

Kai schrieb:
> Koennen alle Arduino-Libs genutzt werden?

Ja, wenn sie keine Einschränkungen gelistet haben.

Kai schrieb:
> Worauf kommt es an?

Was die Spezifikation der jeweiligen Lib aussagt. Es
gibt einfach welche die (auch sehr) speziell sind, andere
eben ganz allgemein ....

von Kai (Gast)


Lesenswert?

Ok danke. Ich schau's mir mal an.

von Markus (Gast)


Lesenswert?

So ganz einfach ist das nicht mit den Libraries. Und zwar aus 
verschiedenen Gründen.
Zum einen beinhalten die Libraries manchmal Hardware-spezifsche Routinen 
wie z.B. zeitkritische Routinen, die auf den jeweiligen Prozessor 
zugeschnitten sind. Hier mal der Adafruit Neopixel-Treiber:

https://github.com/adafruit/Adafruit_NeoPixel/blob/master/Adafruit_NeoPixel.cpp

Man sieht, dass sich dort Assembler für die AVR-Prozessoren befindet, 
aber über "#defines" wird auch der ESP8266 unterstützt ( Ich suche noch 
nach einer Unterstützung für die STM32F4 ).

Zum anderen gibt es verschiedene Arduino-STM-Entwicklungslinien.
Eine wurde von Roger Clark, einem Australier begonnen und setzt auf die 
ehemalige "Maple" Bibliothek auf. Die andere Entwicklungslinie wird seit 
kurzem aktiv von STM selbst getrieben ( wird aber auch von Roger 
unterstützt ) und wenn man in dieser Library schaut

https://github.com/stm32duino/Arduino_Core_STM32F1/blob/master/cores/arduino/libstm32f1/digital_io.c

sieht man dort Haufenweise HAL-Aufrufe.
( Vielleicht kann einer der STM-Kenner was dazu sagen, soweit ich es 
verstehe gibt es hier auch einen Kampf zwischen CMSIS und HAl ? )

von Kai (Gast)


Lesenswert?

Hallo nochmal,

ich versuche gerade, das ganze zum Laufen zu kriegen, scheitere aber am 
Programmieren über Bootloader.

- Arduino 1.6.12 scheint die letzte, erwähnte Version zu sein (ich hatte 
es zunächst mit der aktuellen probiert)

- Die Installation des board-support für ARM-Arduinos nicht vergessen, 
sonst kann nicht kompiliert werden: 
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation

- Der Bootloader muss offenbar seriell oder mit ST-Link separat geflasht 
werden, nicht aus der Arduino IDE

- Die Arduino-IDE kann dann aber per ST-Link flashen (ggf. gut getimed 
den Reset drücken)

- Der bootloader enthält nur DFU, in den "Sketches" ist die serielle 
Schnittstelle enthalten -> einen "Sketch hochladen", dann taucht das 
Gerät auf (bei mir "Maple Serial (COM x)") [habe Treiber aus 
Unterverzeichnis installiert, sonst nur "Maple" oder "Maple 003"]
1
#define pinLED PC13
2
3
void setup() {
4
  pinMode(pinLED, OUTPUT);
5
}
6
7
void loop() {
8
  digitalWrite(pinLED, HIGH);
9
  delay(1000);
10
  digitalWrite(pinLED, LOW);
11
  delay(1000);
12
}

Leider scheitert es trotzdem:
1
Sketch uses 12,892 bytes (19%) of program storage space. Maximum is 65,536 bytes.
2
Global variables use 2,816 bytes of dynamic memory.
3
maple_loader v0.1
4
Resetting to bootloader via DTR pulse
5
Searching for DFU device [1EAF:0003]...
6
dfu-util - (C) 2007-2008 by OpenMoko Inc.
7
Couldn't find the DFU device: [1EAF:0003]
8
This program is Free Software and has ABSOLUTELY NO WARRANTY

Der Bootloader geht jedoch, wenn sonst kein "Sketch" enthalten ist.

Also der Reset via DTR funktioniert offenbar nicht.

Oder ich habe den Bootloader überschrieben...

1
Sketch uses 12,892 bytes (19%) of program storage space. Maximum is 65,536 bytes.
2
Global variables use 2,816 bytes of dynamic memory.
3
maple_loader v0.1
4
Resetting to bootloader via DTR pulse
5
Reset via USB Serial Failed! Did you select the right serial port?
6
Searching for DFU device [1EAF:0003]...Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
7
8
9
Found it!
10
11
Opening USB Device 0x1eaf:0x0003...
12
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0  Upload to Flash 0x8002000"
13
Setting Configuration 1...
14
Claiming USB DFU Interface...
15
Setting Alternate Setting ...
16
Determining device status: state = dfuIDLE, status = 0
17
dfuIDLE, continuing
18
Transfer Size = 0x0400
19
bytes_per_hash=257
20
Starting download: [##################################################] finished!
21
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
22
error resetting after download: usb_reset: could not reset device, win error: The system cannot find the file specified.
23
Done!
24
Resetting USB to switch back to runtime mode

Der Bootloader wird nun ausgeführt, aber das USB-Gerät wird nicht auf 
DFU umgeschaltet (1eaf:003) sondern bleibt Com-Port (1eaf:004 -> Maple 
Serial).

Den 10k Widerstand R10 
(https://developer.mbed.org/users/hudakz/code/STM32F103C8T6_Hello/) habe 
ich mit || 10k || 2k2 auf 1k5 heruntergeteilt

https://github.com/rogerclarkmelbourne/STM32duino-bootloader
1
Additionally the bootloader now works with "generic" STM32F103 boards, which do not have the additional USB reset hardware which all Maple, and Maple mini boards have.
2
3
On "generic" boards, the USB reset (to force re-enumeration by the host), is triggered by reconfiguring USB line D+ (PA12) into GPIO mode, and driving PA12 low for a short period, before setting the pin back to its USB operational mode. This system to reset the USB was written by @Victor_pv. Note. It is not guaranteed to work on all "generic" STM32 boards, and relies on PA12 having a pull-up resistor of around 1.5k - however most "generic" boards seem to have this. Its unclear if this method to reset the USB bus conforms precisely to the USB standard, but it seems to work fine on all PC's and Mac's (and Linux boxes) on which its been tested - and seems usable for hobby / non commericial / non-critical systems.

Hah! Direkt am PC geht es. Offenbar ein Timing-Problem, durch ein Hub 
verursacht! Wer eingerichtet ist, um den Bootloader selber zu bauen, 
könnte das evtl. mal ausprobieren und die Wartezeit raufsetzen..

Viel Erfolg!

von Markus (Gast)


Lesenswert?

Danke für diesen ausführlichen Beitrag.
Ich habe das BluePill Board mit dem STM32F103 bisher immer mit einem 
USB-Seriel Adapter verwendet und damit programmiert.

Der Vorgang war dabei so:
1. Reset am BluePill drücken
2. dann mit ARDUINO IDE seriell flashen

Funktioniert eigentlich ganz gut.

Welche der drei STM32 Varianten Source-Code Varianten verwendest Du?

1. Die Maple Version
https://github.com/rogerclarkmelbourne/Arduino_STM32
2. Die Version von ST
https://github.com/stm32duino
3. solch eine Version
https://github.com/danieleff/STM32GENERIC

von Markus (Gast)


Lesenswert?

Hier habe ich gerade eine ausführliche Beschreibung zur Installation des 
Bootloaders gefunden:

http://www.stm32duino.com/viewtopic.php?f=22&t=1958#p26088

von Kai (Gast)


Lesenswert?

Ich kenne "die anderen" nicht, also die hier: 
https://github.com/rogerclarkmelbourne/Arduino_STM32

Jegliche Erfahrung mit STM32 hilft natürlich, dann ist z.B. das Flashen 
des Bootloaders mit ST-Link (Discovery-Board oder 2$ Klon) keine Hürde.

von Schang (Gast)


Lesenswert?

>( Vielleicht kann einer der STM-Kenner was dazu sagen, soweit ich es
>verstehe gibt es hier auch einen Kampf zwischen CMSIS und HAl ? )

Kein "Kampf".

CMSIS ist von ARM für die core-spezifische Peripherie, HAL für die von
ST definierte.
Sie ergänzen sich.

von Markus (Gast)


Lesenswert?

>Sie ergänzen sich.
Ah, danke.

Im STM-Arduino Forum basteln sie viel mit diesem Board:

http://www.ebay.de/itm/Core407V-STM32F407VET6-STM32-Cortex-M4-Entwicklungskit-Board-Core-Board-Modul-/272501793801?hash=item3f725f6409:g:lcwAAOSw5cNYZLH2

Für knapp 11 Euro auch ziemlich günstig aber mit deutlich mehr Dampf als 
dem  BluePill Board.

von Markus (Gast)


Lesenswert?

Gerade gefunden: Benchmarks AVR gegen STM32F103

http://www.stm32duino.com/viewtopic.php?f=3&t=76

Der erste Test kommt beim Dhrystone Benchmark auf einen

Faktor von ~6

von Kai (Gast)


Lesenswert?

Traurig ist ja, dass die IDE (1.6.12) es offenbar nicht hinbekommt, den 
seriellen Port zu managen (wenn der "Serial Monitor" läuft):
1
processing.app.SerialException: Error opening serial port 'COM5'.
2
  at processing.app.Serial.<init>(Serial.java:125)
3
  at processing.app.Serial.<init>(Serial.java:66)
4
  at processing.app.SerialMonitor$3.<init>(SerialMonitor.java:93)
5
  at processing.app.SerialMonitor.open(SerialMonitor.java:93)
6
  at processing.app.AbstractMonitor.resume(AbstractMonitor.java:110)
7
  at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2226)
8
  at processing.app.Editor.access$2400(Editor.java:77)
9
  at processing.app.Editor$DefaultExportHandler.run(Editor.java:2204)
10
  at java.lang.Thread.run(Thread.java:745)
11
Caused by: jssc.SerialPortException: Port name - COM5; Method name - openPort(); Exception type - Port not found.
12
  at jssc.SerialPort.openPort(SerialPort.java:167)
13
  at processing.app.Serial.<init>(Serial.java:114)
14
  ... 8 more
15
Error opening serial port 'COM5'.

Aber für erste Tests und einfache Sachen ist es vielleicht ganz 
brauchbar.

von Markus (Gast)


Lesenswert?

Ist das bei den neueren IDEs anders? Bisher war ich es immer gewohnt, 
erst das Monitor-Fenster zu schließen und dann wieder zu flashen.

Nach meinen ersten Tests funktioniert Arduino STM-Version auch mit den 
neueren IDEs hat aber den ernsthaften Nachteil, dass die Pinnummerierung 
dort über Nummern statt dem Portnamen wie z.B. PC13 gemacht ist.

von Markus (Gast)


Lesenswert?

Gerade habe ich noch ein Nucleo STM32L476 in der Bastelkiste gefunden.

Die Arduino IDE funktioniert damit super. Es gibt eine virtuelle 
serielle Schnittstelle, so das man auch das analogReadSerial Example 
aufprobieren kann ( Der ADC hat laut Datenblatt 5MSPs, aber ob der 
Arduino das kann? ).

Bei dem Board funktioniert auch das Programmieren mittels Mass-Storage. 
Die IDE legt dann ein Bin-File auf dem virtuellen Laufwerk des 
STM-Boards ab und damit ist das Board programmiert.

Was ich mich frage: kann man auch von STM aus auf die Daten zugreifen 
und dann vielleicht Dateien mit dem C-Programm lesen?

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.