Hallo,
dank eines Freundes bin ich gestern auf http://micropython.org/
gestoßen: einen winzigen Python-Interpreter, der für den Betrieb auf
einem kleinen ARM-Board optimiert ist. Wenn Du das schon einmal
ausprobiert hast und etwas zu Deinen Erfahrungen damit sagen magst,
würde ich mich freuen.
Vor allem interessieren mich Fragen wie:
- Ist das stabil und robust?
- Wie steht es um die Performance?
- Welche Features hast Du benutzt?
- Hast Du damit bereits Projekte umgesetzt? Was für welche?
- Ist es Deiner Meinung nach dazu geeignet, Jugendliche an Elektronik
und Programmierung heranzuführen?
Vielen Dank!
Beste Grüße,
Sheeva
Noch so ein Webefuzzi schrieb:> Also Leute, für Grassroots Marketing dürft ihr keine Werbetexter nehmen.> So klappt das nicht.
Das ist sicherlich richtig, aber ich bin gar kein Werbetexter -- wie Du
mit einem Blick auf zum Beispiel diesen Beitrag von mir [1] sehr schnell
selbst herausfinden dürftest. Und ich habe mit diesem Projekt auch nicht
mehr zu tun, als daß ich es interessant finde und versuche, ein paar
Informationen von Leuten zu bekommen, die damit schon Erfahrungen
gemacht haben. Insofern habe ich einfach nur versucht, mir die üblichen
Verdächtigen durch betont freundliche Formulierungen und konkrete Fragen
zu ersparen.
Schade, daß das bei Dir wie ein Werbetext ankommt. Allerdings glaube ich
nicht, daß der Preis für die Dinger ein Budget einen Texter hergibt. ;-)
[1] Beitrag "Re: C++ auf default Red Hat Enterprise Linux 5"
Sheeva P. schrieb:> Hallo,>> dank eines Freundes bin ich gestern auf http://micropython.org/> gestoßen: einen winzigen Python-Interpreter, der für den Betrieb auf> einem kleinen ARM-Board optimiert ist. Wenn Du das schon einmal> ausprobiert hast und etwas zu Deinen Erfahrungen damit sagen magst,> würde ich mich freuen.
ich habs einmal für ein nucleo board gebaut, geflasht (denke es war ein
stm32f411), mit der Kommandozeile gespielt und mit der LED geblinkt.
stell mir vor dass das ganz praktisch ist um schnell mal z.b. ein
spi-gerät anzutesten, ohne da viel C-code basteln zu müssen.
mehr erfahrung hab ich nicht damit.
rmu schrieb:> ich habs einmal für ein nucleo board gebaut, geflasht (denke es war ein> stm32f411), mit der Kommandozeile gespielt und mit der LED geblinkt.>> stell mir vor dass das ganz praktisch ist um schnell mal z.b. ein> spi-gerät anzutesten, ohne da viel C-code basteln zu müssen.>> mehr erfahrung hab ich nicht damit.
Deinen Ausführungen entnehme ich, daß Dein Experiment damals zumindest
funktioniert hat und daß man Mikropython auch auf anderer als der dort
vorgestellten Hardware benutzen kann. Gut zu wissen, vielen Dank.
MicroPython wird bei mir auf STM32F401 und STM32F405 seit 2 Jahren und
auf CC3200 seit 3 Monaten privat eingesetzt. Wetterstation, Suntracker f
PV-Anlage, Servoansteuerungen, Sounderzeugung, div. Sensoren auslesen.
Für mich Nichtprogrammierer eine schnell erlernbare Sprache. Keine
Toolchain/kein Kompilieren. Python ist quasi (RT)OS auf dem Chip.
Programmieren/Testen/Debuggen mit Terminal und Editor.
> - Ist das stabil und robust?
ja und ja, zT 2 Jahre Dauerbetrieb
> - Wie steht es um die Performance?
Frage etwas unspezifisch. Software-Entwicklung hochperformant möglich.
> - Welche Features hast Du benutzt?
Features? Python Module/Bibliotheken? Siehe
http://docs.micropython.org/en/latest/> - Hast Du damit bereits Projekte umgesetzt? Was für welche?
siehe oben
> ... geeignet, Jugendliche an Elektronik und Programmierung heranzuführen?
unbedingt!
> ... man Mikropython auch auf anderer ... Hardware benutzen kann ...
Brandaktuell:
https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot
Darauf habe ich lange gewartet. Die Jungs sind gut. Habe keine Aktien.
Bin zufriedener User.
MfG!
mad 4. schrieb:> MicroPython wird bei mir auf STM32F401 und STM32F405 seit 2 Jahren und> auf CC3200 seit 3 Monaten privat eingesetzt. Wetterstation, Suntracker f> PV-Anlage, Servoansteuerungen, Sounderzeugung, div. Sensoren auslesen.> Für mich Nichtprogrammierer eine schnell erlernbare Sprache. Keine> Toolchain/kein Kompilieren. Python ist quasi (RT)OS auf dem Chip.> Programmieren/Testen/Debuggen mit Terminal und Editor.>>> - Ist das stabil und robust?> ja und ja, zT 2 Jahre Dauerbetrieb
Super, danke, genau das wollte ich wissen.
>> - Wie steht es um die Performance?> Frage etwas unspezifisch. Software-Entwicklung hochperformant möglich.
Ok, da hast Du Recht. Fragen wir mal so: mit welcher Frequenz toggelt
ein Pin, wenn der Controller nichts anderes macht? Wie hoch kann man die
Baudrate der UARTs setzen, welche Geschwindigkeiten sind mit SPI und I2C
möglich, welche Samplerates schafft der ADC, ... sowas eben?.
>> - Welche Features hast Du benutzt?> Features? Python Module/Bibliotheken? Siehe> http://docs.micropython.org/en/latest/
Ich meinte jetzt eher: UART, SPI, I2C, CAN, Timer, ADC und DAC.
>> ... geeignet, Jugendliche an Elektronik und Programmierung heranzuführen?> unbedingt!
Prima, dann werd' ich mal bestellen.
>> ... man Mikropython auch auf anderer ... Hardware benutzen kann ...> Brandaktuell:> https://www.kickstarter.com/projects/214379695/mic...
Ja, habe ich auch gesehen und bin angelegentlich auch über das hier [1]
gestolpert. Finde ich beides sehr interessant.
[1] https://openmv.io/
Hallo Sheeva,
ein Kollege von mir benutzt das gerade für einen Testaufbau. Er ist
ziemlich begeistert. Was er alles für Features nutzt, kann ich Dir am
Montag schreiben. Das Ganze läuft bei ihm auf einem ST-Evalboard (eines
dieser 10€-Teile).
Gruß, Stefan
Sheeva P. schrieb:> Vor allem interessieren mich Fragen wie:>> - Ist das stabil und robust?> - Wie steht es um die Performance?> - Welche Features hast Du benutzt?> - Hast Du damit bereits Projekte umgesetzt? Was für welche?> - Ist es Deiner Meinung nach dazu geeignet, Jugendliche an Elektronik> und Programmierung heranzuführen?
Ich hab mir letztes Jahr das original MicroPython Board gekauft.
Funktioniert super, und das flashen ist dank DFU-Bootloader sehr
einfach.
Da das original Board doch etwas sehr teuer ist wie ich finde, ist man
z.B. mit einem STM32F4-Discovery (~11€) besser bedient. Kostet weniger
und hat mehr Pins, etc. Ich hab es auch geschaft die SD-Karte beim
STM32F4-Discover+Erweiterungsboard zu nutzen.
Das ganze ist angenehm einfach zu benutzen.
Ich hab es mir bisher aber einfach nur angeschaut, weil ich es
interessant fand. Wirklich was damit gemacht, hab ich noch nicht.
Ich hab lediglich ausprobiert mal direkt logfiles auf die SD-Karte bzw.
den internen Speicher zu schreiben. Hat problemlos funktioniert. Fand
ich echt spitze.
Ich hab die Firmware auch selber kompiliert und aufgespielt (unter
Linux). Dank makefiles alles kein hexenwert.
ABER:
Das ganze ist natürlich keine Rakete. Wenn man damit etwas umsetzt
sollte man darauf achten. Jenachdem was man macht, sinkt die Performance
bis zu Faktor 100 im vergleich zu C/C++.
Siehe hier: https://github.com/micropython/micropython/wiki/Performance
Aber ja, ich denke MicroPython ist sehr gut dazu geeignet Jugendliche an
Elektronik und Programmierung heranzuführen.
Und bei der Programmierung bekommt man auch schnell ergebnise. Python
eben :)
Weiterer Nachteil neben der Performance:
Wenn etwas nicht funktioniert, wegen Syntaxfehler etc. bekommt man das
teilweise nicht mit, weil der Stacktrace bei weitem nicht so ist, wie
man es von Python auf dem PC gewohnt ist.
Was ich ebenfalls nicht ganz so pralle finde:
FAT32 für die SD-Karte, in einem System das man doch schonmal hart
ausschaltet. Ich denke, da könnte es vielleicht mal probleme gebe.
Wenn ich MicroPython irgendwie bewerten müsste, würde ich sagen:
8 von 10 Punkten.
Der Preis vom original Board ist einfach zu hoch (mit Versandkosten).
Umgerechnet hat mich das kleine Ding ca. 50€ gekostet.
Dafür ist die Programmierung dank Python sehr leicht.
Und wenn man was spezielles braucht, so kann man das ganze ja in C/C++
implementieren und dann als Modul verfügbar machen.
Sehr schön finde ich, dass das Projekt auf Python 3 aufbaut!
Anschauen lohnt sich! :)
Eine Liste der Unterstützden Boards findet sich im MicroPython-Wiki:
https://github.com/micropython/micropython/wiki/Boards-Summary
Einfach mal in das GitHub-Repo reinschauen:
https://github.com/micropython/micropython
Grüße
Dr. Sommer schrieb:> Mit dem Debugger "result" ausgelesen: 21000001
O.k., Faktor 500, bin nicht unbeeindruckt. Werde für einen faireren
Vergleich mal versuchen, ohne Bremsklötze (USB u.a.) auszukommen.
Vielleicht lässt sich durch Ausführung von bytecode- bzw. frozen code
auch Teile des REPL vermeiden. Bin jetzt auch keinesfalls der Python
bzw. MicroPython-Crack. Hilfestellung daher gerne akzeptiert.
Man beachte aber auch den Faktor-5-Unterschied bei den LOC :P
mad 4. schrieb:> Man beachte aber auch den Faktor-5-Unterschied bei den LOC :P
Naja, nur weil dein Python eine Library dabei hatte die das alles
kapselt. Wenn ich eine entsprechende Library in C(++) schreibe, sieht
der aufrufende Code genauso kurz aus... Wird ja z.B. bei Arduino so
gemacht.
Also ich würd mich jetz aber an den Pin-toggle-Bechmarks auch nicht
aufhängen. Im Prinzip gibt es ja zwei Einsatzszenarien:
- Man ist Anfänger und Python+libs fällt einem leichter als C(++)
- Man ist Profi, hat ein größeres Projekt und möchte sowiso ins
high-level
Bei ersterem ist die Pin-toggle-Performance wohl in den allerseltensten
Fällen ein limitierender Faktor. Bei zweiterem
- Benutzt man fürs Toggeln sowiso PWM (und die restliche
Hardwareausstattung ebenso)
- Wirklich interessant wird Python ja, wenn es um komplexe
Stringmanipulationen, Mathematische- & Sortieraufgaben,
Dateimanipulationen und solcherlei Dinge geht. Eben immer dann, wenn
Python schon jede Menge passender Bibliotheken mitbringt. Und die sind
ja sehr schnell, da in (vermutlich) C geschrieben und natürlich von
Leuten mit entsprechender Erfahrung programmiert. Von daher glaube ich,
dass ein großes Projekt mit Python verfasst nicht recht viel langsamer
sein dürfte wie in C.
Wenn es nur um schnellstmögliches Bitschubsen oder einfacheres
Datencrunchen mit hoher Geschwinigkeit geht wird C(++) natürlich eine
viel bessere Wahl sein.
Ich werds mir auf jeden Fall mal anschauen. Python find ich super für
high-level Programmierung, und C auf dem STM32 hat mich nicht so recht
getaugt (ganz im Gegensatz zu den klassischen AVRs)..
Simon S. schrieb:> Wirklich interessant wird Python ja, wenn es um komplexe> Stringmanipulationen, Mathematische- & Sortieraufgaben,> Dateimanipulationen und solcherlei Dinge geht. Eben immer dann, wenn> Python schon jede Menge passender Bibliotheken mitbringt.
Aber solche Bibliotheken gibt's für C(++) ja auch. Ich würde fast sogar
behaupten, dass es dafür die meisten Bibliotheken überhaupt gibt. Nur
dass die nicht alle vorinstalliert sind und man sie sich zusammen suchen
muss, würde ich nicht als großes Argument zählen lassen... Tatsächlich
sind die von dir genannten Bibliotheken in Standard-C++ enthalten. Nur
die Dateimanipulationen werden wohl erst in der nächsten Version
vollständig sein, aber für Mikrocontroller verwendet man wohl eh lieber
FatFS o.ä.
Dr. Sommer schrieb:> Naja, nur weil dein Python eine Library dabei hatte die das alles> kapselt. Wenn ich eine entsprechende Library in C(++) schreibe ...
Warum soll ich auf Modul verzichten, wenn es built-in ist? Auch das ist
hier doch Thema.
Apropos C(++): War es nicht bis vor wenigen Jahren so, dass über das
(++) im Zusammenhang mit Mikrocontrollern gar kräftig die Nase gerümpft
wurde? Warts ab, in 5 Jahren laufen alle mit Python :)
> Warts ab, in 5 Jahren laufen alle mit Python :)
Dann hat man den selben Effekt wie auf dem PC: In 5 Jahren braucht's
einen 168MHz, 32Bit uC mit 192kByte RAM um das zu tun was heute mit
einem 8MHz 8bitter mit 1kByte RAM geht...
Simon S. schrieb:> würd mich jetz aber an den Pin-toggle-Bechmarks auch nicht aufhängen.
Klar, wir vergleichen hier Obst mit Obstler.
> Wenn es nur um schnellstmögliches Bitschubsen oder einfacheres> Datencrunchen mit hoher Geschwinigkeit geht wird C(++)> natürlich eine viel bessere Wahl sein.
Viel? Wieviel, wenn schnelles Bitschubsen bei Bedarf inline (und
interaktiv) auch zur Verfügung steht?
Dank einiger Fachleute (Quelle unten) sieht es im
Toggle-Frequenz-Wettbewerb nun etwas weniger prekär aus. Alle Tests mit
Board bei 168MHz Taktfrequenz am USB-Port meines Rechners im
Picocom-Terminal.
Angefangen mit inline Assembler, der bislang schnellsten Version (thanks
Dave!):
1
MicroPython v1.6-4-g2bd758f on 2016-02-02; PYBv1.0 with STM32F405RG
2
Type "help()" for more information.
3
>>>
4
paste mode; Ctrl-C to cancel, Ctrl-D to finish
5
=== @micropython.asm_thumb
6
=== def _counter():
7
=== mov(r0, 0)
8
=== movwt(r1, stm.GPIOA) # LED(1) is A13
9
=== add(r1, stm.GPIO_BSRRL)
10
=== movw(r5, 1 << 13) # r5 has mask for BSRR register
11
=== movwt(r2, stm.TIM2)
12
=== ldr(r3, [r2, stm.TIM_CNT])
13
=== movw(r4, 2000)
14
=== add(r4, r4, r3) # r4 is our ending count
15
=== # loop
16
=== label(loop)
17
=== strh(r5, [r1, 0]) # Turn the LED on
18
=== add(r0,1) # increment counter
19
=== strh(r5, [r1, 2]) # Turn the LED off
20
=== add(r0,1) # increment counter
21
=== ldr(r3, [r2, stm.TIM_CNT])
22
=== cmp(r3, r4)
23
=== bls(loop)
24
===
25
=== def togglePerformance():
26
=== # Setup a timer to increment twice per millisecond
27
=== # Timer 2 runs at 84 MHz, so we divide by 42000 and when the count
28
=== # gets to 2000 then one second will have passed.
Es folgt eine Version im sogenannten Viper-Mode (führt ARM-Thumb direkt
aus, umgeht die C-Runtime) unter Verwendung von Pointers fürs toggeln
(thanks Damien!):
1
=== @micropython.viper
2
=== def togglePerformance():
3
=== count = 0
4
=== stop = int(pyb.millis()) + 1000
5
=== millis = pyb.millis
6
=== odr = ptr16(stm.GPIOA + stm.GPIO_ODR)
7
=== while int(millis()) < stop:
8
=== odr[0] ^= 1 << 13 # PA13 = LED_RED
9
=== count += 1
10
=== print("Counted: ", count)
11
===
12
>>> togglePerformance()
13
Counted: 534300
14
>>>
Hier die Version im sog. Native-Mode (übersetzt Python-Byte-Code in
ARM-Thumb-Code):
1
=== @micropython.native
2
=== def togglePerformance():
3
=== stop = pyb.millis() + 1000
4
=== count = 0
5
=== millis = pyb.millis
6
=== toggle = pyb.LED(1).toggle
7
=== while millis() < stop:
8
=== toggle()
9
=== count += 1
10
=== print("Counted: ", count)
11
===
12
>>> togglePerformance()
13
Counted: 223468
14
>>>
Und zum gemütlichen Schluss, meine etwas verbesserte pure MicroPython
Version:
1
=== def togglePerformance():
2
=== stop = pyb.millis() + 1000
3
=== count = 0
4
=== millis = pyb.millis
5
=== toggle = pyb.LED(1).toggle
6
=== while millis() < stop:
7
=== toggle()
8
=== count += 1
9
=== print("Counted: ", count)
10
>>>
11
>>> togglePerformance()
12
Counted: 132606
13
>>>
Viel zu lesen, schuldig. hoffentlich ist für jeden etwas dabei. Keine
schlechten Ergebnisse, wie ich finde - eventuell sogar noch
verbesserungsfähig.
MfG
_____________________________________________________________
Quelle: http://forum.micropython.org/viewtopic.php?f=2&t=1349
Na das ist mal was tolles. Danke für den Link zu MicroPython! ich bin
grade mit dem Smartphone unterwegs und lese hier mit, ich habe mir also
den Source noch nicht angeschaut. Aber was mich jetzt echt interessiert:
Gibt es einen Interaktiven Mode, wo ich über einen UART mittels
Terminal ein Python-Progrämmchen schreiben kann?
Ich finde: wenn man das mit mcurses verheiratet, womit man einen
einfachen Texteditor bauen könnte, dann wäre das echt toll. Man könnte
quasi die Software direkt auf dem Target schreiben :-)
Achja, was ich mich auch noch frage: ist es wohl möglich das auch auf
anderer Hardware (einem eigenbau-Board) laufen zu lassen? und ggf. in
ein anderes Projekt zu integrieren...
Rasputin schrieb:> Gibt es einen Interaktiven Mode
Bin etwas verwirrt. Also jawohl, im selbigen habe ich oben die ganzen
scripts verfasst. Lese doch bitte nocheinmal in Ruhe den Thread durch.
> wo ich über einen UART
Das ist auch möglich. USB ist aber ganz praktisch.
> mittels Terminal ein Python-Progrämmchen schreiben kann?
Im Terminal hänge ich doch die ganze Zeit herum. Bitte lese doch
nocheinmal in Ruhe ...
> ... ist es wohl möglich das auch auf anderer Hardware ...
Weiter oben gibt es ein Link zu den bis heute erfolgten Portierungen.
Hier ist er nocheinmal:
https://github.com/micropython/micropython/wiki/Boards-Summary
Wie gesagt, lese doch nocheinmal in Ruhe ... nix für ungut.
MfG!
Edit:
Hier stehen die Konfigurationsdateien für Hardware, auf die bisher
portiert wurde:
https://github.com/micropython/micropython/tree/master/stmhal/boardshttps://github.com/micropython/micropython/tree/master/cc3200/boards
Dies ist etwas spezifischer, als der zuvor genannte Link. Es gibt aber
auch noch unkommunizierte/inoffizielle Portierungen. Im übrigen wird in
absehbarer Zeit in Reihe von ESP8266-Boards dazukommen!
Hallo,
im Prinzip alles schon gesagt:
Phyton
Arduino
.net Micro Framework
Schaffen einen einfachen Zugang zur Materie, insbesondere wenn man
" schnell ein Konzept testen will"
aber:
Was ist an "Standard C" und "Toolchain" nun schlimm?
Nix, meiner Meinung nach.
Und was ist an den anderen Lösungen schlimm (Phyton...)
Auch nix.
Aber: Vergleich von Äpfeln und Birnen
Ich fand beispielsweise, das .net auf STM32F4 nicht schlimm oder weniger
performant ist, nur die Verschwendung an Resourcen nur um .net auf STM32
überhaupt betreiben zu können fand ich schade.
Ich komme eigentlich aus der Programmierung von Windows Systemen (C#)
Zunächst fand ich die Idee, die selber Entwicklungsumgebung und Sprache
zu Verwenden spannend.
Am Ende haben mich aber die Einschränkungen dazu bewogen,
Microcontroller wieder in C zu programmieren.
Warum erzähle ich das so ausführlich:
Meiner Meinung nach kann einem die eingangs gestellte Frage niemand
beantworten, nur jeder für sich.
Oder anders: Wenn ich Phyton prima finde und mit den Lösungen zufrieden
bin, warum soll ich dann unzufriedener werden nur weil es andere sind ?
Gilt auch für Arduino,........
Gruß
Rasputin schrieb:> ... über einen UART mittels Terminal ein Python-Progrämmchen schreiben> kann? Ich finde: wenn man das mit mcurses verheiratet, womit man einen> einfachen Texteditor bauen könnte, dann wäre das echt toll. Man könnte> quasi die Software direkt auf dem Target schreiben :-)
War etwas spät für mich gestern. Sorry. Habe wohl jetzt erst kapiert:
Terminal (iSv Shell) und Editor sollen auf Board bzw. MCU laufen!?
Kleine Shell kann ich schon mal empfehlen:
https://github.com/dhylands/upy-shell
(Autor ist auch der Assembler-Beitragende von oben)
Kleiner portierbarer Python-Editor müsste eigentlich auch irgendwo schon
existieren. Kenne aber keinen.
MfG!
Dr. Sommer schrieb:> mad 4. schrieb:>> Welchen Wert erzielt ein C-Programm auf STM32F4?> Auf dem STM32F407VG Discovery Board ausgeführt, bei 168MHz Taktfrequenz,> mit GCC und -Os kompiliert.> Mit dem Debugger "result" ausgelesen: 21000001
I möchte keiner Person zu nahe treten, aber darf ich um
prüfbare/glaubhafte Bestätigung der Angaben bitten?
Im Voraus vielen Dank und Gruß!
Simon S. schrieb:> Also ich würd mich jetz aber an den Pin-toggle-Bechmarks auch nicht> aufhängen. Im Prinzip gibt es ja zwei Einsatzszenarien:>> - Man ist Anfänger und Python+libs fällt einem leichter als C(++)> - Man ist Profi, hat ein größeres Projekt und möchte sowiso ins> high-level>> Bei ersterem ist die Pin-toggle-Performance wohl in den allerseltensten> Fällen ein limitierender Faktor. Bei zweiterem>> - Benutzt man fürs Toggeln sowiso PWM (und die restliche> Hardwareausstattung ebenso)
genial an dem µpython ist die interaktivität, man kann mal "auf die
schnelle" was ausprobieren und ändern ohne unmengen an c/c++ code
herauswürgen zu müssen.
Sheeva P. schrieb:> Fragen wir mal so: mit welcher Frequenz toggelt> ein Pin, wenn der Controller nichts anderes macht? Wie hoch kann man die> Baudrate der UARTs setzen, welche Geschwindigkeiten sind mit SPI und I2C> möglich, welche Samplerates schafft der ADC, ... sowas eben?.
baudrate, SPI und I2C sollten von python unabhängig sein. weiss nicht
wies gemacht ist, aber vernünftigerweise benutzt man dabei DMA, da ist
dann wenig python involviert. ebenso beim ADC.
staatsanwalt schrieb:> ergibt bei mir anstatt der versprochenen 21MHz nur gut 14MHz.>> Gestehe! Das war ein stm32f7... ;-)
Nö! Was ist denn an den 21 MHz so unglaubwürdig? 168MHz Prozessortakt /
21MHz Ausgabetakt = 8 Takte pro Schleifendurchlauf. Mehr sollten doch
wohl die zwei "Store"-Instruktionen nicht brauchen! Hast du vielleicht
ohne Optimierung kompiliert, den ART nicht eingeschaltet, nicht alle
Takte auf Maximum gestellt?
Das ist eine interessante Diskussion. Zu den ermittelten Zeiten per
C-Programm habe ich eine Frage: Hat das einer von Ihnen mal unabhängig
vom Programmcode verifiziert, z.B. durch Messung am Port D15? Da sollte
das Signal ja anliegen.
Vielleicht noch mal zur Erläuterung, weshalb ich frage. Ich habe das
nachgestellt mit einer simplen Endlos-Schleife und per Oszilloskop
gemessen. Ich sehe aber 4 Takte pro Store-Befehl, plus 2 für den Branch,
im Summe 10 Takte. Da im obigen Programm außer den Store Befehlen ja
noch der Increment und die Abfrage auf Ende enthalten ist, werden dort
mehr Instruktionen benötigt. Was mich andererseits wundert ist die
Aussage im ARM Datenblatt, welche für Store 2 Taktzyklen angibt.
Erfahrungen anderer wären da hilfreich.
Der Effekt ist hier erklärt;
http://forum.micropython.org/viewtopic.php?f=2&p=8384#p8384
Der Unterschied besteht darin, ob das Programm im Flash oder im SRAM
liegt. Flash ist wohl schneller, laut STM32F4 Programming Manual wg. der
Nutzung separater Bus'e für Code & Daten. Im obigen Beispiel macht das
wohl die 4 Clock-Zyklen aus für die Ausgaben auf GPIO.
@Dr. Sommer, staatsanwalt, Friedrich K.
Danke für Motivationshilfe!
Zwischenstand in MicroPython (d.h. ohne Inline-asm)
mit
- Verwendung schnellerer BSRR-Register
- Frequenzhochrechnung nach 1.000.000 Zyklen
(was u.a. Vergleichsoperation einspart)
1
MicroPython v1.6-4-g2bd758f on 2016-02-02; PYBv1.0 with STM32F405RG
2
Type "help()" for more information.
3
>>>
4
paste mode; Ctrl-C to cancel, Ctrl-D to finish
5
=== @micropython.viper
6
=== def togglePerformance():
7
=== start = pyb.millis()
8
=== bsrrl = ptr16(stm.GPIOA + stm.GPIO_BSRRL)
9
=== bsrrh = ptr16(stm.GPIOA + stm.GPIO_BSRRH)
10
=== for _ in range(1000000):
11
=== bsrrl[0] = 1 << 13
12
=== bsrrh[0] = 1 << 13
13
=== time = pyb.elapsed_millis(start)
14
=== count = round(2e9 / time) # 2/Zyklus
15
=== print("Counted:", count)
16
===
17
>>> togglePerformance()
18
Counted: 6711410
19
>>>
also immerhin knapp 7Mhz (!)
Angehängt Foto des Setups in Arbeit.
MfG
PS:
@Sheeva
Sind wir noch im Thema? ;-)
mad 4. schrieb:> Zwischenstand in MicroPython (d.h. ohne Inline-asm)> mit> - Verwendung schnellerer BSRR-Register> - Frequenzhochrechnung nach 1.000.000 Zyklen> (was u.a. Vergleichsoperation einspart)
ich behaupte ja das ist geschummelt, denn das sieht jetzt genauso aus
wie der C-Code, und da hätte man auch gleich C nehmen können...
Dr. Sommer schrieb:> ich behaupte ja das ist geschummelt, denn das sieht jetzt genauso aus> wie der C-Code, und da hätte man auch gleich C nehmen können...
:-D ... muss jetzt ins Bett. Werde aber in den nächsten Tagen meiner
Empörung lautstark Ausdruck geben!
>:-D ... muss jetzt ins Bett. Werde aber in den nächsten Tagen meiner>Empörung lautstark Ausdruck geben!
Dieser angenehm zu lesende Thread erfreut mich sehr. So gewählte
Ausdrucksweisen findet man selten hier.
Ich möchte mir einen kleine Zusatzanmerkung erlauben: Die dargestellten
Untersuchungen zur Pin-Toggle-Geschwindigkeit geben eine gute Übersicht
über die Leistungen der unterschiedlichen Programmierweisen.
Interpretersprachen entfachen ihre größte Leistungsfähigkeit dann, wenn
sie in die Sprache eingebaute Funktionen großer Komplexität verwenden.
Hätte Micropython z.B. eine FFT als Funktion fest eingebaut und würde
diese im Programm hauptsächlich verwendet, nähert sich die
Ausführungsgeschwindigkeit des Programms immer mehr dem C-Pendant.
Noch ein Hinweis: In den jeweiligen Vergleichen steckt ein Fehler.
Während in den Python Programmen die Flankenwechsel gezählt werden,
zählen die C-Programme volle Schleifen mit je zwei Flankenwechseln. Zum
korrekten Vergleich muss man also entweder die Werte der
Python-Programme halbieren oder die Werte der C-Programme verdoppeln.
Damit wird der Abstand natürlich wieder viel größer.
Darüber hinaus bleibt es ein Vergleich von Äpfeln mit Birnen, wie weiter
oben schon mal geschrieben. Jede Sprache hat ihre optimalen
Anwendungsgebiete. Wenn's schnell gehen muss, an der Grenze der
jeweiligen Architektur, bleibt es bei compilierten Sprachen bzw.
Assembler. Wenn es nicht ganz so schnell gehen muss, kann man auch
Python weit ausreizen, ohne den Sprachkontext zu verlassen. Ich für
meinen Teil habe viel gelernt.
@Sheeva: Die Diskussion hat sich von der ursprünglichen Frage weit
entfernt. Aber meine Antwort zu Ihrer Frage: Ja, das kann man nehmen.
Das Board selbst ist recht robust (wg. 5V-Toleranz), der Preis geht, und
ist vergleichbar mit den 'offiziellen' Arduinos. Die Alternative bleibt
Arduino. Die einfachen (China-) Boards gibt es ab 5€, und die Community
ist immens, mit ganz vielen Beispielen. Die Einstiegsschwelle zum Lernen
ist vergleichbar, wenn nicht niedriger.
Noch ein Nachtrag: in gemischter Python/Assembler Implementierung
erreicht man dann die 14MHz bzw. 18 Mio Toggles, bei Ausführung im RAM.
Im Flash wären es dann 4 Taktzyklen weniger, ergibt 21 MHz. Hier der
Beispielcode:
#mad474: die von Ihnen zitierte Python-Variante läuft ein bisschen
schneller, wenn man die Schleife statt mit range() 'zu Fuß' codiert,
z.B. als while-Schleife, und nur einen Pointer benutzt.
Aus Hotel ohne uPy-Ressourcen in Kurzfassung:
Friedrich K. schrieb:> Noch ein Hinweis: In den jeweiligen Vergleichen steckt ein Fehler.> Während in den Python Programmen die Flankenwechsel gezählt werden ..
Peinlich. Jawohl. Danke für Klarstellung.
> Noch ein Nachtrag: in gemischter Python/Assembler Implementierung> erreicht man ... 28 Mio Toggles/s
Hui, das sieht sehr gut aus! Bin auf Nachvollzug gespannt.
> Python-Variante läuft ein bisschen schneller, wenn man die> Schleife statt mit range() 'zu Fuß' codiert, z.B. als while-Schleife,> und nur einen Pointer benutzt.
Sehr fein. Dachte bereits in diese Richtung. Ehre womöglich wieder
hergestellt.
Vielen Dank für Unterstützung. Habe noch einiges zu lernen.
MfG
Man glaubt es kaum: es geht noch was. Der Wechsel zu Port A0 hat es
etwas verbessert. Diese Unterschied ist allerdings in der
Assembler-Version nicht zu beobachten. Ich hatte nur gewechselt, um mit
dem Oszilloskop ein schöneres Bild zu haben.
Counted: 18,691,588 toggles/s (ASM), 9.345794 MHz, (time=107ms)
Also: Vorteil C/RAM zu Python/RAM Faktor 1.5, C/Flash zu Python/RAM
Faktor 2.25! Interessant ist, dass der positive Puls genauso lang ist
wie in der Assembler-Variante. Die zusätzliche Zeit steckt also in der
Schleifenverwaltung.
Zum Thema lernen: Bei Python stecke ich selbst noch in den
Kinderschuhen. Ich probiere halt rum.
Letzte Version der Programme, Ergebnis bei 100 Mio Durchläufen, SYSTICK
und USB Interrupt enabled, dadurch sind die Werte ca. 0.25% zu niedrig:
Viper: 18,618,506 toggles/s, 9.31 MHz, 18 Clock Cycles/iter
ASM: 27,929,060 toggles/s, 14 MHz, 12 Clock Cycles/iter
Listing im Anhang.
Hab ich. Erstaunlicherweise ändert das nichts, nicht mal das Timing auf
dem Oszilloskop. Der positive Puls ist immer noch 4 Clock-Zyklen lang.
Ich hätte erwartet, dass der länger wird. Offenbar benötigt der
sub-Befehl keine zusätzlichen Zyklen. Laut AVR-Datenblatt sollte der
strh-Befehl zwei Taktzyklen dauern. Nach anderer Aussage gilt das nur
dann, wenn das Programm im Flash läuft. Die Routine sieht jetzt so aus:
Takte zählen ist beim Cortex-M problematisch, da dieser eine Pipeline
hat und je nach dessen Zustand ein Befehl länger oder kürzer sein kann,
insbesondere die load/store Befehle. Dazu kommt dann noch dass der
Prozessorbus nicht sofort reagieren muss, z.B. durch DMA belegt sein
kann, oder eben der Speicher selbst langsam ist (wie der Flash). Durch
eventuelle Caches (wie der ART) wird das dann noch ungenauer. Beim
Cortex-M7 kommt dann noch der L1-Cache, die Branch Prediction, und die
Superskalarität dazu. Daher ist es schwer vorherzusehen, wie lange die
Instruktionen tatsächlich brauchen. Daher verwendet man ja auch
C-Compiler, die den Code (mehr oder weniger) gut so optimieren, dass die
Pipeline den effizient verarbeiten kann.
mad 4. schrieb:> Sind wir noch im Thema? ;-)
Zwischenzeitlich war ich ein paar Tage in den Niederlanden, um vor dem
närrischen Treiben zu fliehen. Aber jetzt bin ich wieder da, lese die
Beiträge und freue mich sehr darüber. Vielen Dank Euch allen!
Im Laufe des Tages möchte ich noch auf einige Beiträge eingehen, zuerst
möchte ich aber alles gelesen haben. ;-)
Beim Scrollen an den Anfang dieser Unterhaltung fiel mir dann auf, dass
die Python-Variante um den Faktor 468 schneller geworden ist, und
genauso viel oder wenig Hochsprache ist wie die C-Variante. Danke an
alle Helfer, hier und im MicroPyhton-Forum.
Der Gewinn für mich in diesem Spiel ist, dass damit PyBoard wieder eine
Alternative für ein bestimmtes Vorhaben ist, einen intelligenten
Adapter, bei dem ich sonst Teensy 3.2 vorgezogen hätte. Ich muss jetzt
noch mal in's Detail gehen. Python hätte hier ganz klar den Vorteil,
ohne eine spezielle Entwicklungsumgebung auskommen zu können. Editor,
Serial-Terminal und USB reichen, und das ist ja selbst auf einem Tablet
oder SmartPhone machbar. Und selbst den Editor kann man ja auf dem
PyBoard vorhalten (siehe oben), auch wenn das wegen der Probleme mit den
konkurrierenden Sichten von PyBoard und Host auf's Filesystem immer
wieder Überraschungen gibt.
Friedrich K. schrieb:> genauso viel oder wenig Hochsprache ist wie die C-Variante.
nicht wirklich. Das ist assembler code in python gegenüber c-Code. Mit
LTO kann man in C übrigens das ganze auf einer abtrahierten Ebene
schreiben (ähnlich wie in Phyton am anfang) und hat die gleiche
Geschwindigkeit.
Man kann sich vieles Schönreden. Aber einen überzeugenden Vorteil
gegenüber C++ mit der STL und Boost sehe ich nicht. Das sind effektive
Bibliotheken mit einer mächtigen Sprache. Und schnell ist es auch ohne
dass man überhaupt assemblercode anfassen muss.
Ich meinte nicht die Assmbler-Funktione toggleASM, sondern die
python-Funktion toggleViper, die in ähnlicher Weise wie das C-Beispiel
vordefnierte hardwarenahe Datentypen benutzt. Das sind einfach zwei
verschiedene Methoden und mit der Viper-Variante muss ich gerade nicht
Assembler verwenden.
Zum Thema schönreden: ich benutze beide Sprachen. Es kommt immer auf den
Kontext an, was in Summe günstiger ist. Und zu günstig gehört auch die
tägliche Nutzung, Anpassung, Anforderungen an die jeweilige schnell
wechselnde Umgebung, Kommunikation an die jeweiligen Nutzer, Vorlieben
der Nutzer, etc.. Mehr Auswahl ist da immer besser.
Friedrich K. schrieb:> Python hätte hier ganz klar den Vorteil,> ohne eine spezielle Entwicklungsumgebung auskommen zu können. Editor,> Serial-Terminal und USB reichen, und das ist ja selbst auf einem Tablet> oder SmartPhone machbar.
Aber möchte man sich das wirklich antun? Nur ein paar Zeichen auf einmal
sichtbar, kann das überhaupt Auto-Vervollständigung, Refactoring,
Unterstützung für git usw.? Das sind doch Dinge auf die ich auf keinen
Fall verzichten möchte, und für die ich mir lieber eine richtige
Entwicklungsumgebung auf dem PC installiere...
Vielen Dank für die Blumen. Auch ich habe im Verlauf der Diskussion viel
gelernt. Mein Dank geht daher an alle Beteiligen, insbesondere Dr.
Sommer für das C-Beispiel.
Kaj G. schrieb:> Da das original Board doch etwas sehr teuer ist wie ich finde, ist man> z.B. mit einem STM32F4-Discovery (~11€) besser bedient. Kostet weniger> und hat mehr Pins, etc. Ich hab es auch geschaft die SD-Karte beim> STM32F4-Discover+Erweiterungsboard zu nutzen.
Das schaue ich mir näher an, danke für den Hinweis.
> Ich hab die Firmware auch selber kompiliert und aufgespielt (unter> Linux). Dank makefiles alles kein hexenwert.>> ABER:> Das ganze ist natürlich keine Rakete. Wenn man damit etwas umsetzt> sollte man darauf achten. Jenachdem was man macht, sinkt die Performance> bis zu Faktor 100 im vergleich zu C/C++.
Natürlich, das ist mir klar. Python ist seit etwa zehn Jahren meine
Feld-, Wald- und Wiesenskriptsprache, und ich finde es spannend, Python
auf einem Mikrocontroller zu sehen. Daß ich keine Performance-Wunder
erwarten darf, ist mir durchaus klar, aber zwischen "unbenutzbar
langsam" und "für nicht-zeitkritische Projekte geeignet" ist ja noch
ziemlich viel Raum. ;-)
> Aber ja, ich denke MicroPython ist sehr gut dazu geeignet Jugendliche an> Elektronik und Programmierung heranzuführen.
Prima, dann werd' ich mir mal zwei von den Boards bestellen und auch
zwei von den STMs. Allerdings finde ich es schön, daß die Pyboards sehr
klein sind, so daß man sie auch in ein Modellauto oder -boot einbauen
kann, zum Beispiel um ein Blaulicht nachzurüsten. Das ist für meine
Zielgruppe, zwei 12-jährige Jungs, vielleicht spannender als nur mit
LEDs zu blinken. ;-)
Nochmals vielen Dank für Deinen tollen Beitrag!
mad 4. schrieb:> Sheeva P. schrieb:>> ... mit welcher Frequenz toggelt ein Pin ...>> Sekundentest mit getoggelter LED auf pyboard an USB-Port:
Cool, danke. Knapp 40 kHz -- das ist mehr, als ich erwartet hätte.
mad 4. schrieb:> Dank einiger Fachleute (Quelle unten) sieht es im> Toggle-Frequenz-Wettbewerb nun etwas weniger prekär aus. Alle Tests mit> Board bei 168MHz Taktfrequenz am USB-Port meines Rechners im> Picocom-Terminal.
Genial, vielen Dank! Sehe ich das richtig, daß der einzige Unterschied
zwischen dem "Native Mode" und Deinem verbesserten "pure Micropython"
der Decorator ist?
Gerade habe ich die Sourcen von Micropython ein wenig angeschaut:
https://github.com/micropython/micropython/blob/master/py/runtime.c
Der Code ist ziemlich umfangreich und er scheint vor allem von Damien P.
George in Cambridge programmiert worden zu sein. Ich finde es ziemlich
beeindruckend, dass jemand allein so viel schafft.
Kennt sich zufällig jemand mit dem Schreiben von "Modules", sprich dem
Erstellen von aus MicroPython aufrufbarem C-Code, etwas aus?
In obj.h stehen ab Zeile 626 eine Reihe von Prototypen für das Erstellen
von Objekten.
Kann ich jene Funktionen etwa folgendermaßen in eigenem C-Code nutzen
1
STATICmp_obj_tmymodule_hello(void){
2
printf("Hello world!\n");
3
returnmp_obj_new_int(42);
4
}
oder is das ein Blödsinn?
Es gibt im Netz leider erstaunlich wenig Info über das Schreiben von
eigenen Modulen und die offizielle Doku zeigt ausschließlich Funktionen,
die mp_const_none (eine Konstante) zurückgeben.
/edit
Ein kurzer Test offenbart dass das so funktioniert... das mulmige Gefühl
beim Wörtchen "new" sämtliche Verantwortung abzugeben bleibt allerdings.
:D
Kurze Warnung an jener Stelle. Mit der letzten MicroPython Version haben
sich eine Reihe Macros geändert. In der obj.h gibts eine Übersetzung für
die legacy API.