Erfahrungen mit Micropython?

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"

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

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?

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

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

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

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.

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

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!

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

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

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!

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

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

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

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?

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

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