Forum: Mikrocontroller und Digitale Elektronik Erfahrungen mit Micropython?


von Sheeva P. (sheevaplug)


Lesenswert?

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

von Noch so ein Webefuzzi (Gast)


Lesenswert?

Also Leute, für Grassroots Marketing dürft ihr keine Werbetexter nehmen. 
So klappt das nicht.

von Sheeva P. (sheevaplug)


Lesenswert?

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"

von rmu (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von mad 4. (mad474)


Lesenswert?

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!

von Sheeva P. (sheevaplug)


Lesenswert?

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/

von Stefan K. (stefan64)


Lesenswert?

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

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

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

von mad 4. (mad474)


Lesenswert?

Sheeva P. schrieb:
> ... mit welcher Frequenz toggelt ein Pin ...

Sekundentest mit getoggelter LED auf pyboard an USB-Port:
1
PYB: sync filesystems
2
PYB: soft reboot
3
Micro Python v1.3.9-44-gb5a790d on 2015-02-08; PYBv1.0 with STM32F405RG
4
Type "help()" for more information.
5
>>> def togglePerformance():
6
...     stop = pyb.millis() + 1000
7
...     count = 0
8
...     while pyb.millis() < stop:
9
...         pyb.LED(1).toggle()
10
...         count += 1
11
...     print("Counted: ", count)
12
... 
13
>>> togglePerformance()
14
Counted:  39715
15
>>> togglePerformance()
16
Counted:  39720
17
>>> togglePerformance()
18
Counted:  39718
19
>>>

wie zu sehen im Normalbetrieb, also ohne inline assembler :)

Welchen Wert erzielt ein C-Programm auf STM32F4?

: Bearbeitet durch User
von Dr. Sommer (Gast)


Lesenswert?

mad 4. schrieb:
> Welchen Wert erzielt ein C-Programm auf STM32F4?
1
volatile bool run = true;
2
volatile uint32_t result = 0;
3
4
int main () {
5
  NVIC_EnableIRQ (TIM2_IRQn);
6
  NVIC_SetPriority (TIM2_IRQn, 0);
7
8
  RCC->APB1ENR |= RCC_APB1ENR_TIM2EN;
9
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN;
10
11
  GPIOD->MODER = GPIO_MODER_MODER15_0;
12
  GPIOD->ODR = 0;
13
  GPIOD->OSPEEDR = GPIO_OSPEEDER_OSPEEDR15_0 | GPIO_OSPEEDER_OSPEEDR15_1;
14
  GPIOD->OTYPER = 0;
15
  GPIOD->PUPDR = 0;
16
17
  __enable_irq ();
18
19
  TIM2->PSC = 84000000 / 10000 - 1;  // 10 kHz
20
  TIM2->DIER = TIM_DIER_UIE;
21
22
  TIM2->CR1 = 0;
23
  TIM2->ARR = 9999; // 1 Hz
24
  TIM2->CR1 = TIM_CR1_CEN | TIM_CR1_URS;
25
  TIM2->EGR = TIM_EGR_UG;
26
  TIM2->CR1 = TIM_CR1_CEN;
27
28
  uint32_t count = 0;
29
  while (run) {
30
    GPIOD->BSRR = (1 << 15);
31
    GPIOD->BSRR = (1 << 31);
32
    ++count;
33
  }
34
  result = count;
35
36
37
  while (1) {
38
    asm volatile ("wfi");
39
  }
40
}
41
42
// 1 Hz
43
extern "C" void TIM2_IRQHandler () {
44
  if (TIM2->SR & TIM_SR_UIF) {
45
    TIM2->SR = ~TIM_SR_UIF;
46
47
    run = false;
48
  }
49
}
Auf dem STM32F407VG Discovery Board ausgeführt, bei 168MHz Taktfrequenz, 
mit GCC und -Os kompiliert.
Mit dem Debugger "result" ausgelesen: 21000001

von Hans (Gast)


Lesenswert?

Hehe, Pintoggeln, der ultimative Benchmark für Mikrocontroller :-)

von mad 4. (mad474)


Lesenswert?

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

von Dr. Sommer (Gast)


Lesenswert?

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.

von Simon S. (-schumi-)


Lesenswert?

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)..

: Bearbeitet durch User
von Dr. Sommer (Gast)


Lesenswert?

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.ä.

von mad 4. (mad474)


Lesenswert?

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 :)

von asd (Gast)


Lesenswert?

> 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...

von mad 4. (mad474)


Lesenswert?

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?

von mad 4. (mad474)


Lesenswert?

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.
29
===     t2 = pyb.Timer(2, prescaler=41999, period=0x0fffffff)
30
===     count = _counter()
31
===     print("Counted: ", count)
32
=== 
33
>>> togglePerformance()
34
Counted:  11975506
35
>>>

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

von Rasputin (Gast)


Lesenswert?

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 :-)

von Rasputin (Gast)


Lesenswert?

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...

von mad 4. (mad474)


Lesenswert?

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/boards
https://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!

: Bearbeitet durch User
von Marc (Gast)


Lesenswert?

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ß

von oberlehrer (Gast)


Lesenswert?


von mad 4. (mad474)


Lesenswert?

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!

: Bearbeitet durch User
von mad 4. (mad474)


Lesenswert?

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ß!

von rmu (Gast)


Lesenswert?

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.

von pythomane (Gast)


Lesenswert?

mad 4. schrieb:
> Kleiner portierbarer Python-Editor müsste eigentlich auch irgendwo schon
> existieren. Kenne aber keinen.

OnBoard-Editoren für MicroPython:

1. https://github.com/pfalcon/pyedit/blob/master/editor.py
2. https://github.com/robert-hh/Pyboard-Editor

von staatsanwalt (Gast)


Lesenswert?

Dr. Sommer schrieb:
> STM32F407VG ... bei 168MHz ... ausgelesen: 21000001
1
volatile bool run = true;
2
volatile uint32_t result = 0;
3
4
int main () {
5
  NVIC_EnableIRQ (TIM2_IRQn);
6
  NVIC_SetPriority (TIM2_IRQn, 0);
7
8
  RCC->APB1ENR |= RCC_APB1ENR_TIM2EN;
9
  RCC->AHB1ENR |= RCC_AHB1ENR_GPIODEN;
10
11
  GPIOD->MODER = GPIO_MODER_MODER15_0;
12
  GPIOD->ODR = 0;
13
  GPIOD->OSPEEDR = GPIO_OSPEEDER_OSPEEDR15_0 | GPIO_OSPEEDER_OSPEEDR15_1;
14
  GPIOD->OTYPER = 0;
15
  GPIOD->PUPDR = 0;
16
17
  __enable_irq ();
18
19
  TIM2->PSC = 84000000 / 10000 - 1;  // 10 kHz
20
  TIM2->DIER = TIM_DIER_UIE;
21
22
  TIM2->CR1 = 0;
23
  TIM2->ARR = 9999; // 1 Hz
24
  TIM2->CR1 = TIM_CR1_CEN | TIM_CR1_URS;
25
  TIM2->EGR = TIM_EGR_UG;
26
  TIM2->CR1 = TIM_CR1_CEN;
27
28
  uint32_t count = 0;
29
  while (run) {
30
    GPIOD->BSRR = (1 << 15);
31
    GPIOD->BSRR = (1 << 31);
32
    ++count;
33
  }
34
  result = count;
35
36
37
  while (1) {
38
    asm volatile ("wfi");
39
  }
40
}
41
42
// 1 Hz
43
extern "C" void TIM2_IRQHandler () {
44
  if (TIM2->SR & TIM_SR_UIF) {
45
    TIM2->SR = ~TIM_SR_UIF;
46
47
    run = false;
48
  }
49
}
ergibt bei mir anstatt der versprochenen 21MHz nur gut 14MHz.

Gestehe! Das war ein stm32f7... ;-)

von Dr. Sommer (Gast)


Lesenswert?

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?

von Friedrich K. (Gast)


Lesenswert?

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.

von Friedrich K. (Gast)


Lesenswert?

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.

von Friedrich K. (Gast)


Lesenswert?

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.

von mad 4. (mad474)


Angehängte Dateien:

Lesenswert?

@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? ;-)

von Dr. Sommer (Gast)


Lesenswert?

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...

von mad 4. (mad474)


Lesenswert?

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!

von chris_ (Gast)


Lesenswert?

>:-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.

von Friedrich K. (Gast)


Lesenswert?

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.

von pythomane (Gast)


Lesenswert?

chris_ schrieb:
> Hätte Micropython z.B. eine FFT als Funktion

Hier: https://github.com/peterhinch/micropython-fourier

nur so auf die Schnelle ;-)

von Friedrich K. (Gast)


Lesenswert?

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:
1
import pyb, stm
2
3
@micropython.asm_thumb
4
def loop(r0):    # r0 has loop count
5
    movwt(r1, stm.GPIOA)    # Use A0
6
    add(r1, stm.GPIO_BSRRL)
7
    movw(r2, 1)       # r2 has mask for setting A0
8
# loop
9
    b(loopend)
10
    label(loopstart)
11
    strh(r2, [r1, 0])  # output high
12
    strh(r2, [r1, 2])  # output low
13
    label(loopend)
14
    sub(r0, 1)
15
    bcs(loopstart)
16
# endloop
17
18
19
def main():
20
    x1_pin = pyb.Pin('X1', pyb.Pin.OUT_PP)
21
    start = pyb.millis()
22
    loop(10000000)
23
    time = pyb.elapsed_millis(start)
24
    count = round(20e9 / time) # 2 toggles per iteration
25
    print('Counted: {:10,} toggles/s (ASM), {} MHz, (time={}ms)'.format(count, count/2E6, time))

von Friedrich K. (Gast)


Lesenswert?

Kleiner Schreibfehler: natürlich 28 Mio Toggles/s. Und im Flash wären es 
7 Taktzyklen also 24 MHz.

von Friedrich K. (Gast)


Lesenswert?

#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.
1
import pyb, stm
2
3
@micropython.viper
4
def togglePerformance():
5
    start = pyb.millis()
6
    bsrr = ptr16(stm.GPIOA + stm.GPIO_BSRRL)
7
    cnt = 1000000
8
    while cnt:
9
        bsrr[0] = 1 << 13
10
        bsrr[1] = 1 << 13
11
        cnt -= 1
12
    time = pyb.elapsed_millis(start)
13
    count = round(2e9 / time) # 2/Zyklus
14
    print("Counted:", count)
15
16
Counted: 16666667
Also 16,7 Mio Toggles/s bzw. 8,35 Mhz.

von mad 4. (mad474)


Lesenswert?

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

von Friedrich K. (Gast)


Angehängte Dateien:

Lesenswert?

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.
1
import pyb, stm
2
3
@micropython.viper
4
def togglePerformance():
5
    bsrr = ptr16(stm.GPIOA + stm.GPIO_BSRRL)
6
    cnt = 1000000
7
    while cnt:
8
        bsrr[0] = 1
9
        bsrr[1] = 1
10
        cnt -= 1
11
    
12
13
def main():
14
    x1_pin = pyb.Pin('X1', pyb.Pin.OUT_PP)
15
    start = pyb.millis()
16
    togglePerformance()
17
    time = pyb.elapsed_millis(start)
18
    count = round(2e9 / time) # 2 toggles per iteration
19
    print('Counted: {:10,} toggles/s (ASM), {} MHz, (time={}ms)'.format(count, count/2E6, time))
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.

von Friedrich K. (Gast)


Angehängte Dateien:

Lesenswert?

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.

von avr (Gast)


Lesenswert?

Irgendwie kommen mir 12 Takte zu viel vor. Kannst du mal die 
Speicherzugriff auf die IO-Register trennen? Also statt strh strh sub, 
strh sub strh.

von Friedrich K. (Gast)


Lesenswert?

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:
1
@micropython.asm_thumb
2
def toggleASM(r0):    # r0 has loop count
3
    movwt(r1, stm.GPIOA)    # Use A0
4
    movw(r2, 1)       # r2 has mask for setting A0
5
# loop
6
    label(loopstart)
7
    strh(r2, [r1, stm.GPIO_BSRRL])  # output high
8
    sub(r0, 1)
9
    strh(r2, [r1, stm.GPIO_BSRRH])  # output low
10
    bcs(loopstart)
11
# endloop

von oberlehrer (Gast)


Lesenswert?


von Friedrich K. (Gast)


Lesenswert?

Sorry, Tippfehler. Da bin ich wohl "mit der Maus abgerutscht". Ich 
meinte natürlich ARM-Datenblatt, ARM 100166_0001_00_en, Link 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100166_0001_00_en/index.html, 
Kapitel 3.3.1

Die ST-Unterlagen schweigen sich über die Taktzyklen aus.

von Dr. Sommer (Gast)


Lesenswert?

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.

von oberlehrer (Gast)


Lesenswert?

oberlehrer schrieb:
> bitte s/AVR/STM

bitte s/s\/AVR\/STM/s\/AVR\/ARM/g

Im übrigen guter Thread, Danke, Weitermachen.

von Mobau (Gast)


Lesenswert?

Es zählt nicht immer wie schnell jemand läuft, sondern ob er elegant und 
flexibel unterwegs ist....

von Sheeva P. (sheevaplug)


Lesenswert?

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. ;-)

von Friedrich K. (Gast)


Lesenswert?

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.

von avr (Gast)


Lesenswert?

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.

von Friedrich K. (Gast)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

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...

von mad 4. (mad474)


Lesenswert?

Wieder zurück, Beiträge gelesen, Programme nachgefahren und weiter 
herumexperimentiert. Die Ergebnisse kann ich wie folgt bestätigen:
1
>>> main()
2
Viper: 18,518,518 toggles/s,   9.26 MHz, 18 Clock Cycles/iter
3
ASM:   28,169,014 toggles/s,   14.1 MHz, 12 Clock Cycles/iter
4
>>>

Vielen Dank - insbesondere @Friedrich K. - für den hervorragenden 
Unterricht.
MfG

: Bearbeitet durch User
von Friedrich K. (Gast)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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!

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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?

von chris_ (Gast)


Lesenswert?

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.

von John Doe (Gast)


Lesenswert?

chris_ schrieb:
> Gerade habe ich die Sourcen von Micropython ein wenig angeschaut:
> https://github.com/micropython/micropython/blob/ma...
>
> 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.

Naja, das war ein mit 100.000 Pfund finanziertes Kickstarter Projekt:
https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot

Nichtsdestotrotz eine ordentliche Leistung.

Sein aktuelles Kickstarterprojekt: Micropython auf dem ESP8266. Das ist 
dann wirklich interessant: Sauber implementiertes Micropython auf einem 
$3-Board mit WLAN.

https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot

von Vincent H. (vinci)


Lesenswert?

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.
1
mp_obj_t mp_obj_new_type(qstr name, mp_obj_t bases_tuple, mp_obj_t locals_dict);
2
static inline mp_obj_t mp_obj_new_bool(mp_int_t x) { return x ? mp_const_true : mp_const_false; }
3
mp_obj_t mp_obj_new_cell(mp_obj_t obj);
4
mp_obj_t mp_obj_new_int(mp_int_t value);
5
mp_obj_t mp_obj_new_int_from_uint(mp_uint_t value);
6
...

Kann ich jene Funktionen etwa folgendermaßen in eigenem C-Code nutzen
1
STATIC mp_obj_t mymodule_hello(void) {
2
  printf("Hello world!\n");
3
  return mp_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.
1
#define mp_const_none (MP_OBJ_FROM_PTR(&mp_const_none_obj))


/edit
Ein kurzer Test offenbart dass das so funktioniert... das mulmige Gefühl 
beim Wörtchen "new" sämtliche Verantwortung abzugeben bleibt allerdings. 
:D

: Bearbeitet durch User
von Vincent H. (vinci)


Lesenswert?

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.
1
// Provide translation for legacy API
2
#define MP_OBJ_IS_SMALL_INT mp_obj_is_small_int
3
#define MP_OBJ_IS_QSTR mp_obj_is_qstr
4
#define MP_OBJ_IS_OBJ mp_obj_is_obj
5
#define MP_OBJ_IS_INT mp_obj_is_int
6
#define MP_OBJ_IS_TYPE mp_obj_is_type
7
#define MP_OBJ_IS_STR mp_obj_is_str
8
#define MP_OBJ_IS_STR_OR_BYTES mp_obj_is_str_or_bytes
9
#define MP_OBJ_IS_FUN mp_obj_is_fun
10
#define MP_MAP_SLOT_IS_FILLED mp_map_slot_is_filled
11
#define MP_SET_SLOT_IS_FILLED mp_set_slot_is_filled

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.