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.
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.
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.
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.
>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?
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
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.
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).
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.
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.
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.
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?
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 :-)
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.
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?
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.
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?
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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"
>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?
>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"
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.
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?
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?
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 ....
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 ? )
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
voidsetup(){
4
pinMode(pinLED,OUTPUT);
5
}
6
7
voidloop(){
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
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!
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
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.
>( 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.
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.
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?
Thread beobachten
Seitenaufteilung abschalten