Forum: Mikrocontroller und Digitale Elektronik Micropython und Esp32 statt Arduino ?


von Reiner D. (dollreiner)


Lesenswert?

Bloß mal so ein Gedanke :

Es geht im Prinzip um Modellbau, aber mit GPS, Controller, 
Waypoint-Navigation, usw. Alles was fliegt oder fährt oder schwimmt.

C++ objektorientiert unter Code::Blocks ist mein Standard.
Ardunio-IDE kann man auch machen.

Jetzt der Gedanke : ein ESP32 kann das ja auch alles, wenn ich das 
richtig sehe. Interrupt-Handling, Hardwaretimer, I2C-Bus, all das 
HW-Zeug.
Aber anders als den Arduino (ATmega) kann ich da in (micro-) Python 
spielen.

Schlechte Idee ?

von Sebastian R. (sebastian_r569)


Lesenswert?

Reiner D. schrieb:
> Aber anders als den Arduino (ATmega) kann ich da in (micro-) Python
> spielen.
>
> Schlechte Idee ?

Wenn du eine neue/andere Programmiersprache verwenden möchtest, keine 
schlechte Idee.

Reiner D. schrieb:
> C++ objektorientiert unter Code::Blocks ist mein Standard.
> Ardunio-IDE kann man auch machen.

der ESP32 ist komplett und sehr gut im Arduino-Ökosystem eingebunden und 
sehr, sehr viele Bibliotheken sind für den ESP32 portiert und die 
Arduino IDE unterstützt auch die ESP32-Toolchain.

Wenn du Erfahrungen mit C++ und dem Arduino-Ökosystem hast, kannst du 
dabei bleiben. Wenn du es in Micro-Python machen willst, mach es.

von D. F. (Firma: EDF) (derdan)


Lesenswert?

Da stimme ich dem Sebastian zu.

von Reiner D. (dollreiner)


Lesenswert?

Das hört sich ja sehr positiv an.

Es geht mir ausschließlich um Python, die Hardware-Leistung ist völlig 
egal, da ist der Arduino schon überdimensioniert. Die paar Ruder, 
Winden, Motoren und Sensoren sind Kindergarten. Und "Nachhaltigkeit" 
oder "Resourcenschonung" ist bei Controllern ja kein Thema ;-)

Wahrscheinlich ist die Bastelei "bare silicon" aber schwieriger, ich 
denke z.B. einen Timer auf Registerebene zu steuern wird beim ESP 
schwieriger sein als auf dem ATmega.

von Monk (Gast)


Lesenswert?

Reiner D. schrieb:
> Aber anders als den Arduino (ATmega) kann ich da in (micro-) Python
> spielen.

Ich hatte mir mal einen Codey-Rocky zum spielen gekauft. Das ist ein 
ESP32 mit Python. Es funktioniert, hat mir aber keinen Spaß gemacht. Die 
Performance war einfach grotten-schlecht, kann man nicht mit PC 
vergleichen.

Reiner D. schrieb:
> Die paar Ruder, Winden, Motoren und Sensoren sind Kindergarten.

Wenn du dich da mal nicht irrst. Wenn ein Antriebsmotor je nach Lust und 
Laune mal mehr mal weniger zu weit Läuft (in Größenordnung von 0.x 
Sekunden) kann das schnell nerven. Vor allem wenn man von C Programmen 
Antwortzeiten in Bereich einstelligen Millisekunden gewohnt ist.

> ich denke z.B. einen Timer auf Registerebene zu steuern wird beim
> ESP schwieriger sein als auf dem ATmega.

Den ESP32 soll man gar nicht auf Registerebene programmieren. Das merkst 
du schnell, wenn du mal nach der dazu nötigen Doku suchst. ESP32 
programmiert man mit dem IDF. Dort sind alle Hardwarefunktionen in 
handlichen C Funktionen abstrahiert.

von Norbert (der_norbert)


Lesenswert?

Zur Zeit habe ich hier ein System welches einen konstanten Strom von 
Daten verarbeitet. Genauer gesagt 166667 (1/6 Million) Daten pro 
Sekunde. Die Daten werden über zwei DMA Kanäle eingeschaufelt und dann 
mehrfach statistisch ausgewertet und weiter verarbeitet.

Zusätzlich finden IRQ gesteuerte Arbeiten statt, welche im 
Sub-Millisekunden reagieren. Das alles mit Micropython, da musste ich 
noch nicht einmal den eingebauten ARM Assembler benutzen. Ebenso wenig 
den zweiten Kern.

Also entweder der ESP32 ist gänzlich untauglich, oder die miserable 
Performance liegt an etwas anderem.

von Reiner D. (dollreiner)


Lesenswert?

Jetzt mal langsam. Interruptstrukturen vorhanden, aber keine harte 
Echtzeit möglich ? Irgendwie widerspricht sich da was ...

Natürlich braucht man zur HW-Steuerung  harte Echtzeit, unter 1ms.
Servos z.b. zappeln sonst bei PPM-Ansteuerung.

Aber wenn ich HW-Timer habe, kann das doch kein Problem sein.

Vielleicht ein Mißverständnis : es soll kein Multitasking-BS drauf 
laufen ;-)

von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Jetzt mal langsam. Interruptstrukturen vorhanden, aber keine harte
> Echtzeit möglich ? Irgendwie widerspricht sich da was ...

Nee, tut's nicht.
Es gibt zwei Typen von Interrupts. Die ›Hard‹ Interrupts sind im 
niedrigen µs Bereich angesiedelt. Da kann man problemlos auf Hardware 
Ereignisse reagieren und auch weitere auslösen.
Dann gibt es die ›Soft‹ Interrupts (geringfügig langsamer) welche mit 
der Python Architektur direkt zusammen arbeiten und zum Beispiel 
Objektmanipulationen wie an Listen, Dictionaries usw. ermöglichen.
Und selbstverständlich kann man aus den ›Hard‹ Interrupts direkt Soft 
Interrupts zur weiteren Verarbeitung verkettet folgen lassen.
Insgesamt kann man logischerweise nicht so schnell sein wie eine 
Assembler-Routine, aber einige hunderttausend ›Hard‹ Interrupts pro 
Sekunde stellen kein Problem dar.

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Suche im Web scheint darauf hinzudeuten, daß die "Standard"-Pytho 
Werkzeuge dafür wirklich ungeeignet sind. Die Timer-Klasse läßt z.B. die 
Clock-Periode nur in ms kalibrieren, das ist viel zu langsam.

Konkret gefragt : wenn ich Aktionen im microSekunden - Raster brauche, 
läßt sich das in Python realisieren ? (Vergleiche ATMega : 1 
mikroSekunde Auflösung ist drin bei 16 Mhz Takt).

von Monk (Gast)


Lesenswert?

Monk schrieb:
> Vor allem wenn man von C Programmen Antwortzeiten in Bereich
> einstelligen Millisekunden gewohnt ist.

Reiner D. schrieb:
> Interruptstrukturen vorhanden, aber keine harte Echtzeit möglich ?
> Irgendwie widerspricht sich da was ...

Ich hatte dabei nicht das Interrupthandling im Sinn, sondern dass der 
Quelltext insgesamt viel langsamer abgearbeitet wird, als ein 
compiliertes C Programm. Zum Beispiel das Abschätzen des Bremsweges um 
exakt am gewünschtem Punkt sanft zum Stillstand zu kommen.

von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> (Vergleiche ATMega : 1
> mikroSekunde Auflösung ist drin bei 16 Mhz Takt).

Wenn du eine Million mal pro Sekunde etwas jeweils innerhalb von 16 
Taktzyklen erledigen willst (ca. 8 bis 10 Assembler Befehle), dann ist 
Micropython vermutlich nicht das richtige Werkzeug. Aber auch beim AVR 
dürften nach Interrupt Entry und Exit nicht mehr viel übrig bleiben.

Je nachdem welche Aufgabe mit dieser Herangehensweise gelöst werden 
soll, ist aber der ESP32 vermutlich ebenfalls nicht der richtige µC.

PS. Die 1ms für Timer ist natürlich Quatsch, wie so vieles im Internetz.

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> Zum Beispiel das Abschätzen des Bremsweges um
> exakt am gewünschtem Punkt sanft zum Stillstand zu kommen.

Ach du meine Güte, ach du meine Güte…

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Ach du meine Güte, ach du meine Güte…

Geht es etwas konkreter?

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> Norbert schrieb:
>> Ach du meine Güte, ach du meine Güte…
>
> Geht es etwas konkreter?

Gerne.

Mit so etwas fürchterlich Komplexem braucht's natürlich immer gleich 
eine Viertel Stunde und man kann dem µC beim Rechnen die Schnürsenkel 
zubinden. Die Bits bewegen sich dabei bestenfalls wie kalter Teer.
Wenn man auf Turbo schaltet bis der Chip glüht, dann kann Micropython 
möglicherweise sogar bis zu zwei Zahlen pro Woche addieren.


Hast du eigentlich gelesen was ich weiter oben zur Performance 
geschrieben habe?

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Mit so etwas fürchterlich Komplexem braucht's natürlich immer gleich
> eine Viertel Stunde und man kann dem µC beim Rechnen die Schnürsenkel
> zubinden.

Ich schrieb 0.x Sekunden. So schnell bindet sich niemand die Schuhe.

Du kannst nicht ernsthaft abstreiten, daß der yPython Interpreter 
erheblich langsamer arbeitet, als ein compiliertes C Programm.

Deine maßlos maßlose Übertreibung hoch 1024 ist sehr extrem albern. 
Merkst du das jetzt?

von Reiner D. (dollreiner)


Lesenswert?

Ein anderes Forum gibt diese Info :

If you are hoping for a callback to run with anything approaching 
microsecond resolution you need to use a Pyboard or similar. Interrupts 
on ESP32 are soft IRQ's and are subject to latency which can run to 
milliseconds, especially on SPIRAM boards, On a Pyboard latency is on 
the order of 15μs

Ich kapier' zwar nicht, was das Board ändert. Aber 15us sind eigentlich 
schon
zuviel. Wo ist jetzt da eigentlich der Unterschied ? Der ESP hat doch 
eine viel höhere Taktfreuenz als der ATMega, und ein Hadware-Timer auf 
dem Chip belastet doch den Rechenkern nicht : wieso soll da keine 
hochauflösende Timerstruktur möglich sein ? Bei 160 Mhz Sytemclock wären 
doch Zeitauflösungen weit unter der Mikrosekunde drin ??

von Robert B. (crolexx)


Lesenswert?

Reiner D. schrieb:

> Es geht mir ausschließlich um Python, die Hardware-Leistung ist völlig
> egal, da ist der Arduino schon überdimensioniert. Die paar Ruder,
> Winden, Motoren und Sensoren sind Kindergarten. Und "Nachhaltigkeit"
> oder "Resourcenschonung" ist bei Controllern ja kein Thema ;-)


Wasn das für ein Boot/Flieger der mal so nebenbei einen 20AH-Akku 
mitschleppt damit seine "> Winden, Motoren und Sensoren" + der ESP32 
funktionieren?


> oder "Resourcenschonung" ist bei Controllern ja kein Thema ;-)

du hast noch nie einen ESP32 mit Akku betrieben, oder?

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> Du kannst nicht ernsthaft abstreiten, daß der yPython Interpreter
> erheblich langsamer arbeitet, als ein compiliertes C Programm.

Das ist überhaupt nicht die Frage und du lenkst ab.

Selbstverständlich kann ein Micropython Programm nicht die gleiche 
Performance erzielen. Aber es kann irre schnell sein wenn man auch nur 
halbwegs weiß was man tut. Und man tausende von Dingen perfekt damit 
umsetzen.

Wenn der OP allerdings erst mit einer einfachen Frage kommt und dann mit 
völlig irren Anforderungen (Timer mit 1µs Auflösung für Interrupts) 
trollt, dann kommt solch eine Diskussion dabei heraus.

Entweder hat er sich schon mal rudimentär mit der Funktionsweise der 
Sprache beschäftigt, dann käme nicht später mit einem Mikrosekunden 
Timer, oder er versucht nur Unruhe zu stiften.

Da war das Trollen wohl von vornherein der Zweck der Unternehmung.

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Entweder hat er sich schon mal rudimentär mit der Funktionsweise der
> Sprache beschäftigt, dann käme nicht später mit einem Mikrosekunden
> Timer, oder er versucht nur Unruhe zu stiften.

Ich denke, er hat Python noch nie auf Mikrocontrollern verwendet. 
Deswegen fragt er ja.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> Jetzt der Gedanke : ein ESP32 kann das ja auch alles, wenn ich das
> richtig sehe. Interrupt-Handling, Hardwaretimer, I2C-Bus, all das
> HW-Zeug.
> Aber anders als den Arduino (ATmega) kann ich da in (micro-) Python
> spielen.

Eine Hoch-Interpretersprache wie µpython und Interupt-Handling passen 
IMHO nicht wirklich zusammen.
Wieviel Echtzeit braucht den der modellbau ?

von Norbert (der_norbert)


Lesenswert?

Bradward B. schrieb:
> Eine Hoch-Interpretersprache wie µpython und Interupt-Handling passen
> IMHO nicht wirklich zusammen.

Gut dass es nur eine Meinung ist und nichts Fundiertes.

von Reiner D. (dollreiner)


Lesenswert?

Oh weh, was ist denn jetzt los ?
Ich hatte eine technische Frage gestellt ..

Also :

Stromerbrauch ? Irgendwas im zweistelligen mA-Bereich bei 5 V, oder ?
In 'nem Schifflein mit E-Antrieb und ein paar Ah Akku kein Problem.

Echtzeit im Modellbau ?
Beispiel Quadrocopter : die Achsregler arbeiten mit irgendwas um die 500 
Hz Zyklusfrequenz. Das sind zweistufige PID-Regler mit IMU-Sensoren, 
deren Signale gefiltert und fusioniert werden müssen. Dann mit ner PWM 
auf die Motoren.
Beispiel Schifflein : Mangels ausreichend vieler UARTs decodiere ich bei 
einem Projekt den RS232-Strom selber. Bei 9600 Baud 104 us Periode. 
Mitten im Bit getastet sind das 50 us Phase mit vielleicht 10 us 
erlaubtem Jitter.
Oder einfach die Servos : Simple PPM-Ansteuerung, aber wenn das jittet, 
fliest da dauernd Strom ins Servos (es "zittert"). Deshalb harte 
Echtzeit und kein Raspi oder sowas.

Nein, noch nie Python auf Controllern.
Viel auf PC und SPS (z.B. Beckhoff), aber nix was nicht an einem Kabel 
hängt.

-> Zurück zur eigentlichen technischen Frage. Kann ich auf dem ESP einen 
HW-Timer nicht direkt konfigurieren (Prescaler, Vergleichswert, 
Interrupt enable usw.) und dann per ISR vom Timer ausgelöst eine Aktion 
ausführen ?

von Reiner D. (dollreiner)


Lesenswert?

Eben gelesen :

Warning

The minimum timer period is one millisecond in MicroPython, whereas with 
Arduino code, it can easily be reduced to one microsecond. Timer 
performances are limited so that MicroPython can keep up with the pace..

Damit ist die Methode "Timer" aus "Machine" gemeint. Also fast sowas wie 
ein Abstraction Layer ;-)

von Monk (Gast)


Lesenswert?

Reiner D. schrieb:
> Stromerbrauch ? Irgendwas im zweistelligen mA-Bereich bei 5 V, oder ?

Oder

ESP32 nehmen im Mittel etwa 100mA auf, beim Senden 500mA. Und sie senden 
mehrmals pro Sekunde " ich bin noch da", weil WLAN das so will.

von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Oder einfach die Servos : Simple PPM-Ansteuerung, aber wenn das jittet,
> fliest da dauernd Strom ins Servos (es "zittert"). Deshalb harte
> Echtzeit und kein Raspi oder sowas.

Das machst du MANUELL? Ernsthaft?

Ratschlag: Vergiss Python oder sämtliche Abarten davon.
Nimm einen schönen Assembler und gut iss.
Kopfschüttelnd…

von Monk (Gast)


Lesenswert?

Reiner D. schrieb:
> Kann ich auf dem ESP einen HW-Timer nicht direkt konfigurieren
> (Prescaler, Vergleichswert, Interrupt enable usw.) und dann per ISR vom
> Timer ausgelöst eine Aktion ausführen ?

Das ist beim ESP32 nicht vorgesehen. Entsprechend mager ist die 
verfügbare Dokumentation. Die ESP32 werden ähnlich wie PC mit einem 
Multitasking Betriebssystem geliefert, auf dem Programme laufen, die 
Funktionen des Betriebssystems aufrufen. Die Schnittstelle zwischen 
Programm und Betriebssystem ist als sogenanntes IDF veröffentlicht. Das 
Betriebssysten ist geheim (closed Source). Der Python Interpreter ist 
ein Anwendungsprogramm, das auf dem Betriebssystem läuft. Damit kommst 
du also noch weiter von der direkten Registerprogrammierung weg.

Theoretisch kann man am Betriebssystem vorbei direkt auf Register 
zugreifen. Aber das ist nicht ratsam, da man nicht weiß, inwiefern 
Konflikte zum Betriebssystem entstehen. Du bewegst dich damit in eine 
wenig dokumentierte Grauzone, wo wenig Hilfe zu erwarten ist.

Bedenke, dass es außerdem nicht den ESP32 gibt, sondern viele 
unterschiedliche. Sogar mit völlig unterschiedlichen CPU Kernen mit 
unterschiedlichem Befehlssatz. Es hat auch nicht jeder ESP32 zwei CPU 
Kerne.

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Vergiss Python oder sämtliche Abarten davon.
> Nimm einen schönen Assembler und gut iss.

So schnell kann man sich 180 Grad wenden :-)

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> Norbert schrieb:
>> Vergiss Python oder sämtliche Abarten davon.
>> Nimm einen schönen Assembler und gut iss.
>
> So schnell kann man sich 180 Grad wenden :-)

Nun da ich weiß, dass er etwas völlig Beklopptes und Unrealistisches 
einfordert, ergibt es nur wenig Sinn diesen Weg fort zu schreiten.
So erspart man ihm und uns weitere Schmerzen.
Wenn man seine Servos manuell mit Attosekunden-Präzision ansteuern 
möchte…

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?


von Norbert (der_norbert)


Lesenswert?

Uwe D. schrieb:
> 
https://timhanewich.medium.com/taking-flight-with-the-raspberry-pi-pico-micropython-diy-quadcopter-drone-61ed4f7ee746
>
> Keine Ahnung ob sich das Teil gut fliegt, aber es fliegt.

Wundert mich nicht.
Erstens ist es ein für solche Aufgaben wirklich gut passender µC.
Zweitens weiß der Softwareersteller anscheinend was er tut und wie er 
sein Werkzeug handzuhaben hat.
Beide Voraussetzungen sind wichtig.

von Reiner D. (dollreiner)


Lesenswert?

@Monk :

Danke für deine sachliche Auskunft.
Ich wußte nicht, daß der ESP immer mit BS betrieben wird.
Ich dachte, der Python-Interpreter läuft direkt auf der Hardware.

Aber so ist das natürlich nix, da kann ich ja gleich einen Raspi und ein 
beliebiges RTOS einbauen, dann geht das wohl auch.

Also werd' ich wohl weiter auf dem Silizium vom AVR rumkratzen, und 
warten bis ein Python-Compiler geschrieben wird. Sag niemals NIE ! Für 
den Commodore64 gabs damals als "Turbo" einen Compiler fürs 
Interpreter-Basic ;-)

@Ein paar Andere :
Macht euch das Spaß, hier rumzupöbeln ?
Irgendwie hab ich das Gefühl, daß auch in diesem Forum das Niveau 
abstürzt...

von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Irgendwie hab ich das Gefühl, daß auch in diesem Forum das Niveau
> abstürzt

Oftmals beginnt das schon mit dem gezielt nebulös gehaltenen ersten 
Beitrag…

von Ada J. Quiroz (inschnier)


Lesenswert?

ich verstehe den Sinn von Micropython nicht. Wozu so etwas nutzen, wenn 
man nativ in C/C++ programmieren und debuggen kann? C/C++ für 
Mikrocontroller ist sehr schnell erlernt.

Debuggen mit Breakpoints kann man vermutlich gar nicht oder habe ich da 
etwas übersehen?

: Bearbeitet durch User
von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Wenn man seine Servos manuell mit Attosekunden-Präzision ansteuern
> möchte…

Was sollen immer diese maßlosen Übertreibungen?

von Uwe D. (monkye)


Lesenswert?

Ada J. Quiroz schrieb:
> ich verstehe den Sinn von Micropython nicht. Wozu so etwas nutzen, wenn
> man nativ in C/C++ programmieren und debuggen kann? C/C++ für
> Mikrocontroller ist sehr schnell erlernt.
>
> Debuggen mit Breakpoints kann man vermutlich gar nicht oder habe ich da
> etwas übersehen?

Wozu in C/C++ programmieren, wenn man den Assembler benutzen kann…?

Eine der vielen Möglichkeiten ist, weil es Zeit spart und es trotzdem 
die Anforderungen abdeckt. Und weil es dann auch noch ökonomisch ist. Es 
muss nicht immer die perfekte Lösung sein (wenn man das Ökonomieprinzip 
verstanden hat oder Pareto oder oder oder)

Es muss nicht immer ein gewerblicher Anwendungsfall sein.

von Monk (Gast)


Lesenswert?

Uwe D. schrieb:
> Keine Ahnung ob sich das Teil gut fliegt, aber es fliegt.

Man beachte den Kommentar "This was a very computationally challenging 
task, but through much trial-and-error, I was able to squeeze enough 
performance out of the RP2040 to allow for stable and agile flight."

und

"This was a very computationally challenging task, but through much 
trial-and-error, I was able to squeeze enough performance out of the 
RP2040 to allow for stable and agile flight."

von Ada J. Quiroz (inschnier)


Lesenswert?

Uwe D. schrieb:
> Wozu in C/C++ programmieren, wenn man den Assembler benutzen kann…?

Diese Frage klärt sich doch von alleine oder nicht?

Uwe D. schrieb:
> Eine der vielen Möglichkeiten ist, weil es Zeit spart und es trotzdem
> die Anforderungen abdeckt.

Wo genau spart es Zeit, wenn es nicht nativ unterstützt wird und keine 
Möglichkeit des Debuggens gibt? Also ich frage ernsthaft, denn ich kann 
keinen Vorteil von µPython erkennen.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Ada J. Quiroz schrieb:
> ich verstehe den Sinn von Micropython nicht.

Dann ist die Sprache nicht für dich. ;-)

Ada J. Quiroz schrieb:
> Wozu so etwas nutzen, wenn
> man nativ in C/C++ programmieren und debuggen kann?

Warum dort aufhören?
Warum nicht Assembler?

Aber, warum dort aufhören?
Warum nicht Maschinencode, wer braucht schon einen Assembler? Früher 
haben wir die passenden Mnemonics und Addressierungsarten herausgesucht 
und die Hex-codes direkt eingegeben.
War aber unbequem und zeitaufwendig.

Hmmm? Könnte es das vielleicht sein?
Eine gegebene Aufgabe einfachst möglich und dennoch perfekt zu lösen?

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> maßlosen Übertreibungen

Das ist nachweislich eine Falschaussage!

von Ada J. Quiroz (inschnier)


Lesenswert?

Norbert schrieb:
> Hmmm? Könnte es das vielleicht sein?
> Eine gegebene Aufgabe einfachst möglich und dennoch perfekt zu lösen?

Das kann ich auch mit C/C++.

Norbert schrieb:
> Warum dort aufhören?
> Warum nicht Assembler?

Weil Assembler aka Maschinencode keine Programmiersprache im 
eigentlichen Sinne ist.

µPython ist nur ein Workaround für Leute, die halt eben unbedingt Python 
nutzen wollen. Ist mir im beruflichen Kontext bereits aufgefallen, dass 
das von Personen eingesetzt wurde, die C/C++ für zu schwer hielten und 
nicht willens waren, das zu lernen.

Bitte nennt mir ein paar faktenbasierte Vorteile. Ich sehe keine, aber 
evtl. irre ich mich auch.

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Ada J. Quiroz schrieb:
> Bitte nennt mir ein paar faktenbasierte Vorteile. Ich sehe keine, aber
> evtl. irre ich mich auch.

Eine hinreichend komplexe Aufgabenstellung habe ich gerade vor mir (und 
in einem anderen Thread bereits erwähnt).

Gelöst in deutlich weniger als einem Zehntel der Zeit, welche ich mit 
C/C++ gebraucht hätte.

Und das kommt von jemandem, der C außerordentlich mag, lange Zeit 
genutzt hat, immer noch wenn erforderlich nutzt und auch keinen Hehl 
daraus macht.

Und der seit gut vierzig Jahren die verschiedensten Programmiersprachen 
genutzt hat, sich aber nun nun je nach Aufgabenstellung auf eine gute 
Handvoll beschränkt.

von Reiner D. (dollreiner)


Lesenswert?

Ist mir im beruflichen Kontext bereits aufgefallen, dass
> das von Personen eingesetzt wurde, die C/C++ für zu schwer hielten und
> nicht willens waren, das zu lernen.
>
> Bitte nennt mir ein paar faktenbasierte Vorteile. Ich sehe keine, aber
> evtl. irre ich mich auch.

Genau. Im beruflichen Kontext habe ich bei größeren Projekten die 
Erfahrung gemacht, daß Python von Newbies viel schneller verstanden wird 
als good-old C.
Das ist ein wesentlicher Vorteil, wenn man die Leute nicht beliebig 
schulen kann und die das vielleicht gar nicht wollen. Nicht umsonst hat 
Python in der "maschinenbaunahen" Automatisierungswelt so eine Karriere 
hingelegt !

(Ist natürlich völlig off-topic, es geht hier um reines Spielen, nur 
Spaß)

von Monk (Gast)


Lesenswert?

Ada J. Quiroz schrieb:
> Bitte nennt mir ein paar faktenbasierte Vorteile.

Python bringt eine Menge einfach verwendbarer Bibliotheksfunktionen mit. 
Damit kann man eine Menge Entwicklungszeit sparen. Man kommt mit weniger 
Zeilen Code ans Ziel.

Das kann man mit C-Bibliotheken freilich ebenso haben. Es ist nicht nur 
die Basis sämtlicher Mikrocontroller-Programmiersprachen, sondern auch 
von Windows und Linux.

Aber C stammt aus einer anderen Zeit, als man Anleitungen noch in Form 
von Büchern statt Youtube Clips veröffentlichte. Der Nachwuchs von heute 
will es Bunt und mit Videos dokumentiert haben. Lieber viel 
oberflächliche Masse die schnell zum Ziel führt, als sich in Details 
vertiefen. Die Bücher von Kernighan und Ritchie sind nicht mehr 
zeitgemäß. Nur Rentner lesen deren Werke freiwillig mit der gebührenden 
Wertschätzung.

Heute gilt "Masse statt Klasse" überall im Leben. Die neuen 
Programmiersprachen mit ihrem ganzen drumherum spiegeln das wieder. Wer 
gegen diesen Strom schwimmt, wird ausgelacht und abgestellt.

Ich will damit nicht sagen, das Python schlecht ist. Verglichen mit dem 
C64 Basic, das meine Jugendzeit prägte) ist es ein Segen. Es ist nur 
anders, und wird anders benutzt, als "damals". Es nützt nichts, darüber 
zu klagen. Lieber mit schwimmen, wenn man in der Branche tätig ist.

von Joachim S. (oyo)


Lesenswert?

Ada J. Quiroz schrieb:
> µPython ist nur ein Workaround für Leute, die halt eben unbedingt Python
> nutzen wollen. Ist mir im beruflichen Kontext bereits aufgefallen, dass
> das von Personen eingesetzt wurde, die C/C++ für zu schwer hielten und
> nicht willens waren, das zu lernen.

Das ist in der Tat der Hauptgrund, warum ich bei meinen letzten zwei 
ESP32-Projekten µPython benutzt habe: Meine Python-Kenntnisse sind 
ziemlich gut, meine C++-Kenntnisse hingegen ziemlich mies. Ich werde mit 
C++ einfach nicht warm, von allen Programmiersprachen, mit denen ich 
bislang zu tun hatte, fand ich C++ die mit Abstand komplizierte und 
beschissenste.

> Bitte nennt mir ein paar faktenbasierte Vorteile. Ich sehe keine, aber
> evtl. irre ich mich auch.

Ein Vorteil von Micropython ist z.B., dass man da eine REPL-Shell hat, 
was z.B. für Programmieranfänger ein wichtiger Vorteil ist. Du gibst 
einfach einen Befehl ein, drückst auf Enter, und schon siehst Du den 
Effekt.
Und ein anderer Vorteil ist, dass ein Python-Programm in der Regel 
einfach viiiel schneller programmiert ist als ein äquivalentes 
C++-Programm.

Gut, im beruflichen Umfeld würde ich wohl eher kein µPython einsetzen. 
Aber da ich Software für Mikrocontroller eh nur privat entwickle, werde 
ich C++ zukünftig wohl nur noch benutzen, wo µPython aus irgendeinem 
Grund nicht infrage kommt.

von Monk (Gast)


Lesenswert?

Joachim S. schrieb:
> von allen Programmiersprachen, mit denen ich
> bislang zu tun hatte, fand ich C++ die mit Abstand komplizierte und
> beschissenste.

Kennst du Java EE?

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

>> Eine Hoch-Interpretersprache wie µpython und Interupt-Handling passen
>> IMHO nicht wirklich zusammen.
>
> Gut dass es nur eine Meinung ist und nichts Fundiertes.

Das ist schon mehr als nur ne Meinung.
Für nen Interrupthandler brauchts die Möglichkeit, Code auf eine 
bestimmte Adresse zu legen (linker-skript, org-directive) und besondere 
CPU-Opcodes nutzen zu können (wie RETI).
Beides ist mit einem Standard-Interpreter-script nicht  oder nur schwer 
erreichbar. Und falls doch, dürfte die Abarbeitungszeit deutliche länger 
sein.

Das "interupt nesting" des ARM bspw. als weitere Schwierigkeit sei hier 
auch erwähnt.

von Ada J. Quiroz (inschnier)


Lesenswert?

Norbert schrieb:
> Eine hinreichend komplexe Aufgabenstellung habe ich gerade vor mir (und
> in einem anderen Thread bereits erwähnt).
>
> Gelöst in deutlich weniger als einem Zehntel der Zeit, welche ich mit
> C/C++ gebraucht hätte.
>
> Und das kommt von jemandem, der C außerordentlich mag, lange Zeit
> genutzt hat, immer noch wenn erforderlich nutzt und auch keinen Hehl
> daraus macht.
>
> Und der seit gut vierzig Jahren die verschiedensten Programmiersprachen
> genutzt hat, sich aber nun nun je nach Aufgabenstellung auf eine gute
> Handvoll beschränkt.

Das ist deine subjektive Sicht, keine Fakten.

Monk schrieb:
> Python bringt eine Menge einfach verwendbarer Bibliotheksfunktionen mit.
> Damit kann man eine Menge Entwicklungszeit sparen. Man kommt mit weniger
> Zeilen Code ans Ziel.

Bringt C/C++ auch. Wie viele dieser Python Biobliotheken sind denn bei 
µPythopn implementiert?

Monk schrieb:
> Der Nachwuchs von heute will es Bunt und mit Videos dokumentiert haben.

Das mag vielleicht bei den Hobbyisten so sein. Ich will eine fundierte 
Dokumentation.

Monk schrieb:
> Wer gegen diesen Strom schwimmt, wird ausgelacht und abgestellt.

Warum unterstützt dann quasi kein IDE der Hersteller für Mikrocontroller 
nativ python? Warum gibt es das nur als Bastelprojekt?

Joachim S. schrieb:
> Und ein anderer Vorteil ist, dass ein Python-Programm in der Regel
> einfach viiiel schneller programmiert ist als ein äquivalentes
> C++-Programm.

Aber doch nicht auf einem µC.

: Bearbeitet durch User
von Monk (Gast)


Lesenswert?

Ada J. Quiroz schrieb:
>> Der Nachwuchs von heute will es Bunt und mit Videos dokumentiert haben.
> Das mag vielleicht bei den Hobbyisten so sein.

Und in Berufsschulen - kein Scherz.

Ada J. Quiroz schrieb:
> Warum unterstützt dann quasi kein IDE der Hersteller für Mikrocontroller
> nativ python? Warum gibt es das nur als Bastelprojekt?

Das kommt schon noch. Jetzt wo Arduino damit angefangen hat wird es bald 
jeder haben. Denn es wird immer schwieriger C-Programmierer zu finden, 
aber immer einfacher, welche für Python zu finden. Ob jemand das gut 
findet, spielt dabei keine Rolle. Der Zug rollt bereits.

von Monk (Gast)


Lesenswert?

>> Und ein anderer Vorteil ist, dass ein Python-Programm in der Regel
>> einfach viiiel schneller programmiert ist als ein äquivalentes
>> C++-Programm.

Ada J. Quiroz schrieb:
> Aber doch nicht auf einem µC.

Hast du es mal probiert? Ich schon und kann daher gesichert mit einem 
"doch" antworten.

von Ada J. Quiroz (inschnier)


Lesenswert?

Monk schrieb:
> Hast du es mal probiert? Ich schon und kann daher gesichert mit einem
> "doch" antworten.

Ich musste schon einige Programme von µPython in C/C++ konvertieren 
(weil hier tatsächlich einer angestellt war, der versucht hat in µPython 
zu schreiben), weil die eben nicht richtig debuggt werden konnten und 
somit voller Fehler waren.

Das war nicht zu Warten und nicht Portierbar auf µC, für die es kein 
µPython gibt.

Monk schrieb:
> Jetzt wo Arduino damit angefangen hat

Arduino hat auch nicht viel im professionellen Umfeld zu suchen, bis auf 
Prototypenbasteleien.

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?

Ada J. Quiroz schrieb:
> Uwe D. schrieb:
>> Wozu in C/C++ programmieren, wenn man den Assembler benutzen kann…?
>
> Diese Frage klärt sich doch von alleine oder nicht?

Du fragst mich? Also offenbar nicht geklärt…

>
> Uwe D. schrieb:
>> Eine der vielen Möglichkeiten ist, weil es Zeit spart und es trotzdem
>> die Anforderungen abdeckt.
>
> Wo genau spart es Zeit, wenn es nicht nativ unterstützt wird und keine
> Möglichkeit des Debuggens gibt? Also ich frage ernsthaft, denn ich kann
> keinen Vorteil von µPython erkennen.

Was soll ich sagen, wenn Du keine Ideen hast? Wenn ich schnell ein paar 
Sensoren in meine Hausautomation einbauen bzw. testen will (Display, 
Buttons, Funk), dann habe den 1. Entwurf der etwas liefert sehr schnell 
fertig - insbesondere wenn ich dann noch (W)LAN anbinden will/muss.

Mach‘ was Du für gut hältst.

von Monk (Gast)


Lesenswert?

Ada J. Quiroz schrieb:
> Arduino hat auch nicht viel im professionellen Umfeld zu suchen, bis auf
> Prototypenbasteleien.

Es wird im Unterricht verwendet. Die Schüler von heute sind in 20 Jahren 
die Profis (in deren Autos wir zur Dialyse transportiert werden, oder so 
ähnlich).

von Joachim S. (oyo)


Lesenswert?

Monk schrieb:
> Joachim S. schrieb:
>> von allen Programmiersprachen, mit denen ich
>> bislang zu tun hatte, fand ich C++ die mit Abstand komplizierte und
>> beschissenste.
>
> Kennst du Java EE?

Mit Java EE habe ich zwar keine Erfahrung, aber mit Java SE schon, und 
die eigentliche Programmiersprache ist ja vermutlich in beiden Fällen 
identisch.
Im Vergleich mit C++ finde ich Java sehr angenehm.

Ada J. Quiroz schrieb:
>> Und ein anderer Vorteil ist, dass ein Python-Programm in der Regel
>> einfach viiiel schneller programmiert ist als ein äquivalentes
>> C++-Programm.
>
> Aber doch nicht auf einem µC.

Ich verstehe gerade nicht, was Sie damit meinen: Warum sollte es auf 
einem µC anders sein?

von Monk (Gast)


Lesenswert?

Joachim S. schrieb:
> Mit Java EE habe ich zwar keine Erfahrung, aber mit Java SE schon, und
> die eigentliche Programmiersprache ist ja vermutlich in beiden Fällen
> identisch.

Das schon, aber was die mit Java EE daraus gemacht haben ist ein 
komplexes Monster. Zum Beispiel SOAP Services mit WS-Security. Wenn du 
10 Jahre mit Java EE gearbeitet hast, schockt dich gar nichts mehr. 
Dagegen ist C++ und stl wie Urlaub machen.

von Norbert (der_norbert)


Angehängte Dateien:

Lesenswert?

Nur mal so für diejenigen, welche es möglicherweise interessiert.

Micropython 1.23 auf rp2040.

Generiert wird eine 100kHz PWM mit 10% duty (1µs) an Pin 0.
Pin 0 löst Interrupts mit der positiven Flanke aus.
In der ISR wird dann Pin 1 kurz auf High und wieder Low gesetzt.

Das Ganze (Pins 0…1) gescannt mit einer 10ns Auflösung.

Wie man erkennen kann, dauert es von der (IRQ-auslösenden) Flanke Pin 0 
bis zur ISR Änderung von Pin 1 geringfügig länger als 3µs.

Geht das mit C schneller? Eindeutig ja!

Braucht man diese Reaktionsgeschwindigkeit ständig?
Individuelle Abwägungssache.
Sollte halt nur zur Information dienen.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> Nur mal so für diejenigen, welche es möglicherweise interessiert.
Jup, mich interessiert's.

> Micropython 1.23 auf rp2040.
Taktfrequenz ist auf 125 MHz gestellt nehme ich an ?!

> bis zur ISR Änderung von Pin 1 geringfügig länger als 3µs.

Also etwas mehr als 375 Takte. In Assembler/C brauchts wahrscheinlich 
weniger als ein Zehntel.

: Bearbeitet durch User
von Monk (Gast)


Lesenswert?

Kann man denn davon ausgehen, dass der unbekannte ESP32 mit Micropython 
die gleiche Performance hat, wie der RP2040? Auch wenn WLAN 
eingeschaltet ist?

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> Kann man denn davon ausgehen, dass der unbekannte ESP32 mit Micropython
> die gleiche Performance hat, wie der RP2040? Auch wenn WLAN
> eingeschaltet ist?

Nö! Es wurde ja weiter oben schon gut erklärt, welch grauenhafter 
Gehgips dieses ESP Klötzchen ist. Möglicherweise für IOT ganz gut 
geeignet, bei etwas dass auch nur Ansatzweise in Richtung Echtzeit 
ginge, würde ich mein Geld wohl eher auf einen Scamp setzen.

von Norbert (der_norbert)


Lesenswert?

Bradward B. schrieb:
> In Assembler/C brauchts wahrscheinlich
> weniger als ein Zehntel.

Wenn's rein im RAM läuft (ohne FLASH waitstates und XIP Interaktion), 
wohl sogar noch weniger. Wie gesagt, wenn man dringend in diesen 
Sub-µs-Bereichen arbeiten muss, dann runter auf's reine Metall. Alles 
andere wäre Zeitverschwendung.

Man könnte die ISR zwar noch innerhalb von Micropython in 
Thumb-Assembler kodieren, aber ist … Quatsch …

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Nö! Es wurde ja weiter oben schon gut erklärt, welch grauenhafter
> Gehgips dieses ESP Klötzchen ist. Möglicherweise für IOT ganz gut
> geeignet, bei etwas dass auch nur Ansatzweise in Richtung Echtzeit
> ginge, würde ich mein Geld wohl eher auf einen Scamp setzen.

Das deckt sich mit meiner Erfahrung mit dem ESP8266. Danach hatte ich 
keine Lust mehr, mich mit dem "Nachfolger" auseinander zu setzen.

von 900ss (900ss)


Lesenswert?

Norbert schrieb:
> dass auch nur Ansatzweise in Richtung Echtzeit ginge

Kommt drauf an, wie hart die Echtzeit-Bedingungen sind. Es wird wohl 
eher schwer sein, die worst case Zeit herauszufinden.
Wenn er 0.5ms Latenzzeit hat, ist das ausreichend wenn nur 1ms gefordert 
sind. Die Zahlen sind nur Beispiele falls jemand jetzt Schnappatmung 
bekommt ;)

Das was du da gemessen hast in MicroPython ist schon für die meisten 
Fälle ausreichend.

: Bearbeitet durch User
von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> Kommt drauf an, wie hart die Echtzeit-Bedingungen sind. Es wird wohl
> eher schwer sein, die worst case Zeit herauszufinden.

Das darf eigentlich nicht sein, Echtzeit bedeudet eben das man eine 
garantierte maximale Antwortzeit hat bzw. nennen kann.

Beispielsweise Automobil, Bremsen.

Bei bare metal, also Programmierung ohne irgendwelche Zuliefer-Software 
dazwischen, zählt man eben die Takte im ISR und stellt mit der 
Architektur des Interrupt-Handlers sicher, das nicht irgendwelche 
Seiteneffekte diese Programmphase verlängern oder womöglich zu 
Endlosschleifen führen.

Oder das ein Event ohne Programmbearbeitung verloren geht. War mal ein 
typischer Bug, das in der UART-Kommunikation Daten "verloren" gehen oder 
verfälscht wurden, weil unter "ungünstigen" Verhältnissen (viel 
Prozessorlast) die Interuptbehandlung länger trödelte als erwartet. 
(Laufzeiteffekte)

: Bearbeitet durch User
von Monk (Gast)


Lesenswert?

Das Problem zufälligen Verzögerungen ist, dass sie zufällig auftreten 
:-)

Spaß beiseite: Wie will man nachweisen, dass ein Gesamtwerk immer 
einwandfrei funktionieren wird, wenn man wegen dem Zufall nicht einmal 
alle Kombinationen möglicher Ereignisse in der Abnahme reproduzieren 
kann?

Dieses Maß an Sicherheit ist sicher nicht überall nötig.

von Norbert (der_norbert)


Lesenswert?

900ss schrieb:
> Das was du da gemessen hast in MicroPython ist schon für die meisten
> Fälle ausreichend.

Stimme ich zu.
Bis zum heutigen Tage ist es mir noch nicht ein einziges Mal zum Problem 
geworden. IRQs nutze ich zB. um DMA-Ketten neu zu konfigurieren. Da 
kommt es noch nicht einmal auf eine Millisekunde an.

Zumal selbst der USB Stack im ungünstigen Fall einige wenige 
Mikrosekunden Latenz erzeugen kann. Könnte man natürlich in kritischen 
Sektionen problemlos alles abschalten, aber das wäre unsauber und bei 
zufälligen Ereignissen auch gar nicht machbar.

Also wird alles im Mikrosekunden-Bereich oder darunter an 
deterministische Hardware delegiert. Dieser Controller hat so etwas 
glücklicherweise und ich bin immer wieder fasziniert was man damit 
anstellen kann.
Andere Controller bekämen dann eine Art Frontend-Prozessor vorgeschaltet 
welche solche Aufgaben erledigen können. Habe ich früher mit Tinies und 
zwei Handvoll Assemblerzeilen gemacht.
Letzten Endes alles eine Frage der Anforderungen und des Designs.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> Spaß beiseite: Wie will man nachweisen, dass ein Gesamtwerk immer
> einwandfrei funktionieren wird, wenn man wegen dem Zufall nicht einmal
> alle Kombinationen möglicher Ereignisse in der Abnahme reproduzieren
> kann?

Zufällig ist da wohl die falsche Wortwahl, es ist wohl eher "statistisch 
verteilt" gemmeint. Bspw. ein Problem das nur auftritt, wenn der 29. 
Februar in ein Superschaltjahr fällt. Für sowas kann man eine 
(Unit-)Test case schreiben, wenn man seinen Code gezielt auf 
corner-Cases und Test-coverage analysiert.

Und vor dem Test, beim Systemdesign reduziert man in der Architektur die 
gesamthomplexität, indem man beispielsweise so wenig Code wie möglich am 
Laufen hat (KISS-Prinzip).

von Yalu X. (yalu) (Moderator)


Lesenswert?

MicroPython hat neben dem Bytecodecompiler, der – wie auch beim normalen
Python – immer zum Einsatz kommt, noch zwei weitere Compiler für
direkten Maschinencode, die auf Wunsch einzelne Python-Funktionen
kompilieren und sehr einfach in der Handhabung sind:

  https://docs.micropython.org/en/v1.9.3/pyboard/reference/speed_python.html#the-native-code-emitter

  https://docs.micropython.org/en/v1.9.3/pyboard/reference/speed_python.html#the-viper-code-emitter

Diese optimieren zwar nicht besonders gut, sind aber besser als gar
nichts.

Des Weiteren kann man auch C-Code mit Python verheiraten. Wenn es nur um
Interruptroutinen oder ein paar wenige zeitkritische Funktionen geht,
schreibt man diese ohne viel Aufwand (weil so kurz) in C und genießt für
die restlichen zigtausend Codezeilen die Vorteile von Python (kürzere
Entwicklungszeit, leichteres Handling komplexer Datenstrukturen, weniger
fehlerträchtig, übersichtlicher usw.).

von Norbert (der_norbert)


Lesenswert?

›@micropython.native‹ kann man nutzen, macht aber nur selten einen 
spürbaren Unterschied. Andererseits, meistens muss man die Funktion noch 
nicht einmal anfassen.

> …und sehr einfach in der Handhabung sind…

›@micropython.viper‹
ist für C Programmierer mit der innewohnenden Sichtweise auf Pointer und 
Arrays sicherlich einfach nutzbar. Für den normalen Python 
Programmierer: Der muss praktisch alles vergessen was er zu wissen 
glaubt. ;-)

Die 3µs sind übrigens mit viper realisiert.

Die dritte Möglichkeit sollte auch noch erwähnt werden:
›@micropython.asm_thumb‹
Das ist dann der echte Spaß-Bereich wenn einem der durchaus C-ähnliche 
viper code nicht reicht..

Zusätzlicher externer C-Code muss üblicherweise zusammen mit Micropython 
kompiliert und zu einer neuen Firmware gelinkt werden**. Dieser Aufwand 
nur für 'ne ISR, da würde es MMN schon einen verdammt heftigen Grund 
brauchen.

Ja, ich weiß, man kann experimentell mpy mit uctypes verheiraten.

Da habe ich passenden Assembler Code in einem Zehntel der Zeit fertig.

von 900ss (900ss)


Lesenswert?

Bradward B. schrieb:
> Das darf eigentlich nicht sein, Echtzeit bedeudet eben das man eine
> garantierte maximale Antwortzeit hat bzw. nennen kann.

Eben. Und die garantierte Antwortzeit herauszufinden ist meistens sehr 
schwierig und selten wirklich völlig sicher. Es gibt nicht umsonst 
extrem teure Tools die die WCET (worst case execution time) ermitteln. 
Aber auch das Ergebnis mit diesen Tools ist nicht 100% sichergestellt.
Und trotzdem funktioniert so vieles Sicherheitkritisches ;)

Und, ich wiederhole mich:

900ss schrieb:
> Wenn er 0.5ms Latenzzeit hat, ist das ausreichend wenn nur 1ms gefordert
> sind.

PS. Weshalb zitierst du ohne den Ursprung des Zitats zu zeigen? Es gibt 
bessere Gewohnheiten.

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Yalu X. schrieb:
> MicroPython hat neben dem Bytecodecompiler, der – wie auch beim normalen
> Python – immer zum Einsatz kommt, noch zwei weitere Compiler für
> direkten Maschinencode, die auf Wunsch einzelne Python-Funktionen
> kompilieren und sehr einfach in der Handhabung sind:

Als "old-school-Datenverarbeiter" (das ist glaube ich nicht das gleiche 
wie ein "IT'ler") habe ich da jetzt (sprachliche ?) Probleme.

Python ist doch (aktuell) eine Interpreter-Sprache, oder ?
(Daher auch Nachteile in der Laufzeit-Performance.)

Wenn ein Bytecode-Compiler eingesetzt wird (macht z.B. Windows auch bei 
Interpretersprachen, oder ?) wird ja vom BS praktisch eine 
"Zwischensprache" generiert, die dem Interpreter seine Arbeit 
erleichtert. Und das kann ein ESP32 mit seinem bisschen BS ?

von Monk (Gast)


Lesenswert?

Ich weiß gar nicht genau, wie Interrupts in Micropython auf einem ESP32 
programmiert werden.

Zumindest beim ESP8266 ist es so, das Interrupthandler im RAM stehen 
müssen, denn der Code aus dem Flash wird häppchenweise über eine 
serielle Schnittstelle ins RAM kopiert und steht deswegen nicht 
immer/ständig zur Verfügung. Vermutlich ist das beim ESP32 ebenso, oder?

Jedenfalls muss dieser Maschinencode im RAM dann den Python Quelltext 
des Interrupthandlers (seriell) laden, interpretieren und ausführen. 
Geht das überhaupt im Kontext einer Unterbrechung? Beim IDF sind 
Interrupthandler ja eh schon stark eingeschränkt, was die überhaupt 
aufrufen dürfen.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Norbert schrieb:
> Zusätzlicher externer C-Code muss üblicherweise zusammen mit Micropython
> kompiliert und zu einer neuen Firmware gelinkt werden**. Dieser Aufwand
> nur für 'ne ISR, da würde es MMN schon einen verdammt heftigen Grund
> brauchen.

Mache ich seit 2 Jahren im wsl2/linux. Die Einrichtung benötigte keine 
20 Minuten.
Grundgebend war der begrenzte RAM im esp8266. Heute compiliere ich alle 
py-Quellen ins Flash, zeitkritisches in C - bedeutet jedesmal alles 
native übersetzt auf Knopfdruck.

Ich kann betonen, ich liebe Python/uPy und schreibe meine build Tools 
für xc8/16/32, avr, rp2, esp32 in Python sowie erledige in W11 alles mit 
Python.
Python ist bei mir auch oft die bessere Wahl für bash.

Ich fange zwar gerade auch mit Rust und Go an, bin aber sicher, dass 
mich Python bis zum Ende begleitet.

Python macht mir richtig Spaß und getestet wird z.B. in PyCharm!

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Apollo M. schrieb:
> Mache ich seit 2 Jahren im wsl2/linux. Die Einrichtung benötigte keine
> 20 Minuten.
> Grundgebend war der begrenzte RAM im esp8266. Heute compiliere ich alle
> py-Quellen ins Flash, zeitkritisches in C - bedeutet jedesmal alles
> native übersetzt auf Knopfdruck.

Das mag auf den ESP Dingern nötig sein. Kann ich nicht beurteilen.
Wie sagt die englischsprachige Welt so blumig:
Wouldn't touch it with a barge pole

Klar, letzten Endes schmeißt man in der bash ein ›make‹ an und gut iss.

In den ganzen Jahren in denen ich mit µP arbeite, habe ich gerade mal 
knapp 20 modules in C geschrieben. Die meisten eher aus Spaß und zum 
Lernen, nötig waren nur die wenigsten beim rp2.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Monk schrieb:
> Ich weiß gar nicht genau, wie Interrupts in Micropython auf einem ESP32
> programmiert werden.

Es gibt kein HW Interrupt Interface in uPy. Die integrierten 
Modultreiber UART/Timer/... sind in C geschrieben und bedienen diese. 
Wenn eigene gewünscht sind kannst du diese leicht modifizieren. Die 
C-Toolchain ist die gleiche wie in der Arduinowelt.

von Monk (Gast)


Lesenswert?

Apollo M. schrieb:
> Es gibt kein HW Interrupt Interface in uPy. Die integrierten
> Modultreiber UART/Timer/... sind in C geschrieben

Ich hatte es geahnt. Danke für die Bestätigung.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Norbert schrieb:
> In den ganzen Jahren in denen ich mit µP arbeite, habe ich gerade mal
> knapp 20 modules in C geschrieben. Die meisten eher aus Spaß und zum
> Lernen, nötig waren nur die wenigsten beim rp2.

Geht mir genau so!
Am Anfang wollte ich Wlan und vom Preis sprach alles für esp8622, nach 
ersten Arduino Spielchen bin ich auf uPy aufmerksam geworden. Die Python 
Lernkurve war/ist schmerzvoll, stehe vielleicht sogar noch immer im 
unteren Drittel. Ich schaue mir oft gute Quellen an um zu lernen.
Meine ersten Programme waren C-Programme mit Python Syntax. Irgendwas 
zum laufen zu bringen war leicht, aber am anfang oft nicht 
pythonic/elegant.

Esp32 S2/S3/C3, rp2 sind billig und sehr brauchbar in uPy und/oder C.

Im Grundsatz ist das alles schon zu performant für meine Projekte und 
nur noch Eisenbahn spielen für mein Hirn.

von Norbert (der_norbert)


Lesenswert?

Apollo M. schrieb:
> Es gibt kein HW Interrupt Interface in uPy.

Das ist mir dann doch ein wenig zu generell und gilt nicht für alle µC.

rp2: Die Sprungtabelle liegt im RAM.
Man hat Zugriff auf NVIC und Register.
Es gibt asm_thumb.

Mehr braucht es nicht.

von Norbert (der_norbert)


Lesenswert?

Apollo M. schrieb:
> Meine ersten Programme waren C-Programme mit Python Syntax.

Man sagt ja: Ein guter Programmierer kann ›C-Code‹ in jeder 
Programmiersprache schreiben! ;-)

von Walter T. (nicolas)


Lesenswert?

Welchen Vorteil hat eigentlich MicroPython gegenüber der Alternative ?

Python auf dem PC hat den Vorteil gegenüber älteren Hochsprachen wie C, 
Pas cal, BASIC usw. hauptsächlich wegen der umfangreichen Libraries in 
Kombination mit dem Paketmanager, weniger aufgrund der 
Sprachmächtigkeit.

Aber anscheinend kann ich die Libraries größtenteils (?) nicht 
mitnehmen.

Was natürlich mit den "klassischen" Kompilaten auf Harward-Architektur 
nicht geht, ist selbstmodifizierender Code. Aber hier ist das wohl auch 
nicht der Anwendungsfall.

Also welchen Vorteil verspricht man sich?

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Es gibt asm_thumb.

Im Kontext vom ESP32 meinst du wohl eher asm_xtensa (gibt es asm_riscv 
für die neuen Modelle?)

Das ist dann aber Assembler, nicht Python.

> Man hat Zugriff auf NVIC und Register.

Wir hatten gerade geklärt, dass direkte Registerzugriffe bei ESP32 nicht 
vorgesehen sind.

von Walter T. (nicolas)


Lesenswert?

Walter T. schrieb:
> Also welchen Vorteil verspricht man sich?

(Ich nutze Python hauptsächlich zur String- und Bildbearbeitung - aber 
beides sind ja bei einem Embedded-System auch eher selten die primären 
Anwendungsfälle.)

von Norbert (der_norbert)


Lesenswert?

Monk schrieb:
> Im Kontext vom ESP32 meinst du wohl eher asm_xtensa (gibt es asm_riscv
> für die neuen Modelle?)
> Wir hatten gerade geklärt, dass direkte Registerzugriffe bei ESP32 nicht
> vorgesehen sind.

Es wäre schon freundlich, wenn du mich korrekt zitieren würdest.
Ich hatte explizit den rp2 als Gegenbeispiel für die generelle Aussage 
aufgeführt.

von Monk (Gast)


Lesenswert?

Norbert schrieb:
> Ich hatte explizit den rp2 als Gegenbeispiel für die generelle Aussage
> aufgeführt.

OK verstanden, das habe ich übersehen.

Allerdings nützt es dem TO nichts, wenn wir (nicht nur du) immer wieder 
zu diversen Raspberry Pi Modellen springen, um die 
Vorteile/Eigenschaften von µPython zu diskutieren. Denn er will einen 
ESP32 programmieren (eventuell mit µPython).

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Walter T. schrieb:
> Also welchen Vorteil verspricht man sich?

Bei mir war der Grund intensives (Meß-)Daten verwursteln und grafisch 
darstellen/GUI. Später kam die Eleganz dazu als ich es dann besser 
geblickt habe.
Die "leichte" beliebig komplexe Verarbeitung von Daten egal wie 
strukturiert ist eine Domain von Python. Wenn du heute als HW-naher 
Engineer nicht Python kannst, dann hast du ein Problem, weil 
Meßgeräteansteuerung, statistische Meßdatenauswertung, Darstellung,... 
oft in Python erledigt wird.

Heute lern ja quasi jeder im Kindesalter Python. Aber, wenn du die 
Python Syntax kennst kannst du noch lange nicht programmieren in Python.
Ich finde C dagegen richtig simple. Die Möglichkeiten mit Python 
erscheinen mir unbegrenzt und unüberschaubar.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Monk schrieb:
> Denn er will einen
> ESP32 programmieren (eventuell mit µPython).

Ich fasse den Esp32 nur noch mit uPy an, aber man sollte die 
unterschiedlichen Typen kennen und wissen warum S2,S3,C3 es sein soll.

Esp32 und uPy passt gut zusammen. Aber bescheiden ist die HW Doku des 
Esp32 und die von uPy zeigt auch schnell gray areas.

Einen Herzschrittmacher würde ich damit nicht unbedingt programmieren 
und life anwenden.

von Walter T. (nicolas)


Lesenswert?

Apollo M. schrieb:
> intensives (Meß-)Daten verwursteln und grafisch
> darstellen/GUI. [...] statistische Meßdatenauswertung, Darstellung, [...]

Verstehe ich nicht. Das sind doch typische PC-Aufgaben. Warum sollte man 
das auf dem Embedded-Prozessor machen?

(Okay - Datenvorverarbeitung auf dem Embedded-Gerät ist durchaus ein 
Ding. Aber da kommt ja wirklich auf Performanz an, weil fünf Prozent 
schnellere Datenverarbeitung of mit fünf Prozent höherer Auflösung oder 
Datenrate oder so gleichzusetzen sind.)

GUI - okay, das ergibt Sinn, wobei ich nicht beurteilen kann, wie 
geeignet Python-GUI-Konzepte für eine Embedded-Anwendung wirklich sind. 
(Gefühlt sind sowieso die Mehrzahl aller GUIs in elektronischen Geräten 
eine Katastrophe.)

: Bearbeitet durch User
von Christoph M. (mchris)


Lesenswert?

Walter schrieb
>Python auf dem PC hat den Vorteil gegenüber älteren Hochsprachen wie C,
>Pas cal, BASIC usw. hauptsächlich wegen der umfangreichen Libraries in
>Kombination mit dem Paketmanager, weniger aufgrund der
>Sprachmächtigkeit.

Die verwendeten Konzepte in Python sind schon ein paar Generationen 
moderner als Pascal oder Basic:

- Objektorientierung, Klassen
- Dictionaries
- iterable List
- keine Typ-Bindung

Damit kann sehr schnell sehr viel mehr machen als mit Basic, Pascal oder 
C.

von Walter T. (nicolas)


Lesenswert?

Es geht um MicroPython, nicht um Python auf dem PC.

Mit den Anwendungen auf dem PC bin ich vertraut.

Welchen Vorteil hat MicroPython gegenüber anderen Hochsprachen wie C, 
C++ und meinetwegen Bascom?

(Oder soll das eher eine Lücke wie LUA füllen?)

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Walter T. schrieb:
> Welchen Vorteil hat MicroPython gegenüber anderen Hochsprachen wie C,
> C++ und meinetwegen Bascom?
Bitte beantworte doch zuvor die folgenden Fragen.
(Gegebenenfalls noch um weitere Sprachen erweitern)
1
#!/usr/bin/python3
2
# -*- coding: UTF-8 -*-
3
# vim: fileencoding=utf-8: ts=4:  sw=4: expandtab:
4
5
sprachen = ['Assembler', 'C', 'C++', 'Python', 'Basic', 'Pascal']
6
for sprache_1 in sprachen:
7
    for sprache_2 in sprachen:
8
        print(f'Welchen Vorteil hat {sprache_1} gegenüber {sprache_2}?')

Gerne auch indem die dieses Fragment in den anderen Sprachen hier einmal 
vorstellst.

: Bearbeitet durch User
von Monk (Gast)


Lesenswert?

Walter T. schrieb:
> Welchen Vorteil hat MicroPython gegenüber anderen
> Hochsprachen wie C, C++ und meinetwegen Bascom?

Fragen dieser Art enden hier fast immer in religös-missionarischem Eifer 
ihrer Verfechter. Frage das lieber eine KI.

von Walter T. (nicolas)


Lesenswert?

Komischer Einwurf. Der TO will Micropython (vielleicht) Nutzen, also 
sollte es konkreten Nutzen geben.

Bislang wurden nur Nachteile ("Laufzeit") genannt.

Es wird mal langsam Zeit für die Vorteile.

von Norbert (der_norbert)


Lesenswert?

Walter T. schrieb:
> Komischer Einwurf.

Nicht im Geringsten. Es ermuntert dazu selbst einmal nachzudenken.

Walter T. schrieb:
> also
> sollte es konkreten Nutzen geben.

Gibt es. Sind ausreichend und an vielen Stellen dokumentiert. Muss also 
nicht gebetsmühlenartig wiedergekäut werden.

Dein Einwurf erinnert mich ein bisschen an:

Wozu photographieren? Es ist doch bereits alles photographiert.
Ja, aber nicht von jedem.

Aber ich gebe gerne noch einen Hinweis. Für einige wird es gar keine 
Vorteile geben, denn sie wollen keine Vorteile.
Diejenigen sollten sich besser gar nicht weiter damit beschäftigen. Die 
anderen schon, für die könnte es sich lohnen.

von Monk (Gast)


Lesenswert?

Walter T. schrieb:
> Komischer Einwurf. Der TO will Micropython (vielleicht) Nutzen, also
> sollte es konkreten Nutzen geben.
> Bislang wurden nur Nachteile ("Laufzeit") genannt.

Stimmt nicht, ich habe Vorteile genannt:

Monk schrieb:
> Python bringt eine Menge einfach verwendbarer Bibliotheksfunktionen mit.
> Damit kann man eine Menge Entwicklungszeit sparen. Man kommt mit weniger
> Zeilen Code ans Ziel.

Monk schrieb:
> es wird immer schwieriger C-Programmierer zu finden,
> aber immer einfacher, welche für Python zu finden.

ebenso der Joachim:

Joachim S. schrieb:
> Ein Vorteil von Micropython ist z.B., dass man da eine REPL-Shell hat,
> was z.B. für Programmieranfänger ein wichtiger Vorteil ist. Du gibst
> einfach einen Befehl ein, drückst auf Enter, und schon siehst Du den
> Effekt.
> Und ein anderer Vorteil ist, dass ein Python-Programm in der Regel
> einfach viiiel schneller programmiert ist als ein äquivalentes
> C++-Programm.

Uwe argumentierte so:

Uwe D. schrieb:
> Wenn ich schnell ein paar
> Sensoren in meine Hausautomation einbauen bzw. testen will (Display,
> Buttons, Funk), dann habe den 1. Entwurf der etwas liefert sehr schnell
> fertig - insbesondere wenn ich dann noch (W)LAN anbinden will/muss.

Yalu hatte auch etwas beizutragen:

Yalu X. schrieb:
> die Vorteile von Python (kürzere
> Entwicklungszeit, leichteres Handling komplexer Datenstrukturen, weniger
> fehlerträchtig, übersichtlicher usw.).

Apollo nannte einen weiteren Grund, den ich nachvollziehen kann:

Apollo M. schrieb:
> Die "leichte" beliebig komplexe Verarbeitung von Daten egal wie
> strukturiert ist eine Domain von Python. Wenn du heute als HW-naher
> Engineer nicht Python kannst, dann hast du ein Problem, weil
> Meßgeräteansteuerung, statistische Meßdatenauswertung, Darstellung,...
> oft in Python erledigt wird.
> Heute lernt ja quasi jeder im Kindesalter Python.

von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Reiner D. schrieb:
> Es geht im Prinzip um Modellbau...

Versuch macht klug.
Ich habe gerade übers Wochenende einen Fuatba SBUS-Decoder (100.000 Baud 
8E2, RX invers) in Micro Phyton für den RPi Pico geschrieben. Geht 
sicher auch für den ESP32.
Mein Fazit – ja Modellbau geeignet.

von Christoph M. (mchris)


Lesenswert?

>Mein Fazit – ja Modellbau geeignet.
Wobei bei mechanischen Regelungen die Abtastfrequenzen gar nicht so hoch 
sein müssen. Ich würde schätzen, für die Fluglagerregelung eines 
Modellfliegers 10ms bis 1ms reichen dürften.
Allerdings bin ich nicht zwingend ein Verfechter für Mikropython, wenn 
es um Signalverarbeitung und Regelungstechnik geht.

von Reiner D. (dollreiner)


Lesenswert?

> Ich würde schätzen, für die Fluglagerregelung eines
> Modellfliegers 10ms bis 1ms reichen dürften.

Gut geschätzt.

Mit 1 khz Regelkreisfrequenz fliegt sogar ein Quadrocopter 
außerordentlich stabil. Aber damit ist dann die Rechenleistung eines 
8bit-Controllers schon ziemlich überfordert, wenn man alles (Achsregler, 
Signalfilter, Sensoren, Navi mit GPS, Waypoint-Regelung, Höhenregler, 
usw.) auf dem einen Prozessor macht.
In nicht optimierten Projekten waren früher so 100...200 Hz das höchste 
der Gefühle. Bleibt auch oben ;-)

Beim Flächenflieger bei weitem nicht so anspruchsvoll.

Bei einem Schiff ist alles egal, da reicht auch 1 Hz ;-)

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> Mit 1 khz Regelkreisfrequenz fliegt sogar ein Quadrocopter ...

> In nicht optimierten Projekten waren früher so 100...200 Hz das höchste
> der Gefühle. Bleibt auch oben ;-)
>
> Beim Flächenflieger bei weitem nicht so anspruchsvoll.

Kommt wohl auf den Flieger resp. auf seine Auslegung hinsichtlich 
Eigen-Stabilität an, bspw. V-Stellung der Flügel oder Lage des 
Masse-Schwerpunktes. OK, Kunstflug stellt da andere Ansprüche als 
Streckenflug und Dogfight unterhalb der Sichherheitshöhe nochmal.
Aber OK, 1 Khz aka 125k Takte wäre schonmal ne Grenze, bei der man auch 
"suboptimal" Programmieren darf.

§§§§

OK, aber auch neben der Performance gibt es weitere Kriterien für das 
eine oder andere Programmier-Öko-System, da ist µpython nicht gleich 
µpython.

So bringt IMHO "Thonny" als EDK etliches an Komfort dank Einfachheit in 
der python-programmierung für den RasPi Pico mit, was anderen 
Python-EDK's fehlt. Auf dem PC reicht ein Text-Editor, im 
Embedded-Bereich hätte man dann aber auch Integriertes Download zum 
Target und debug-Schnittstelle (ARM-SWD).

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Bradward B. schrieb:
> So bringt IMHO "Thonny" als EDK etliches an Komfort dank Einfachheit

Wenn ich auf der Ziel-HW was laufen lasse und rumfummel, dann ist Thonny 
auch meine erste Wahl.

von Walter T. (nicolas)


Lesenswert?

Geht numpy? (Auf die Schnelle finde ich nur abgespeckte Versionen.)

von Uwe D. (monkye)


Lesenswert?

Walter T. schrieb:
> Geht numpy? (Auf die Schnelle finde ich nur abgespeckte Versionen.)

Wozu braucht man das auf einem MC? Nur Interessehalber… Für irgendwelche 
autonomen Anzeigen vielleicht?

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

>> Bitte nennt mir ein paar faktenbasierte Vorteile. Ich sehe keine, aber
>> evtl. irre ich mich auch.
>
> Ein Vorteil von Micropython ist z.B., dass man da eine REPL-Shell hat,

µPython ist quasi eine "ad-hoc shell", mit der man sofort einen 
einfachen zugriff auf die Hardware hat. So wie damals im 
Homecompter-BASIC Zeitalter mit PEEK und POKE: 
https://de.wikipedia.org/wiki/POKE_und_PEEK

Für Modellbauer ergibt sich die Möglichkeit ohne Neukompilierung auf 
alle Funktionen mit kleinen scripten zuzugreifen, beispielsweise könnte 
man an einem Schiffsmodell schnell das Ruder bewegen um besser 
dahinterschauen zu können oder die Funktion der Endlageschalters zu 
überprüfen.
Halt so ne Art Elektronik-Monitor ohne extra eine GUI dafür zu 
schreiben. OK, zusätzlich zum Python Interpreter braucht es dann noch 
eine serielle Verbindung (am besten über USB) und einen Rechner mit 
Terminal (wie bspw. putty oder eine schlanke IDE wie Thonny) aber das 
ist heutzutage verbreitet.

Da drei beispiele für adhoc-scripte zum Auslesen der elektronic:

https://www.elektronik-kompendium.de/sites/raspberry-pi/2612011.htm
https://www.elektronik-kompendium.de/sites/raspberry-pi/2612121.htm
https://www.elektronik-kompendium.de/sites/raspberry-pi/2703041.htm

Damit hat man die Möglichkeit, einen individuelle "pre-flight" Test vor 
start durchlaufen zu lassen oder nach dem lauf einen individuellen 
Wartungscheck und auslesen der logs durchzuführen.

: Bearbeitet durch User
von Walter T. (nicolas)


Lesenswert?

Uwe D. schrieb:
> Walter T. schrieb:
>> Geht numpy? (Auf die Schnelle finde ich nur abgespeckte Versionen.)
>
> Wozu braucht man das auf einem MC? Nur Interessehalber…

Mein Anwendungsfall wäre eine Modellbasierte Regleroptimierung. Das 
würde wirklich Entwicklungszeit sparen (im Vergleich zu einer 
analytischen Näherungslösung).

Wenn das 10 Sekunden zu rechnen bräuchte, wäre das netto immer noch ein 
Gewinn.

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

> Geht numpy? (Auf die Schnelle finde ich nur abgespeckte Versionen.)

* https://hackaday.com/2019/10/29/numpy-comes-to-micro-python/
* https://github.com/ComplexArts/micropython-numpy

* https://micropython-ulab.readthedocs.io/en/latest/ulab-intro.html


In wie weit dort aus individueller Betrachtung an der falschen Stelle 
der Speck fehlt kann man nicht per Ferndiagnose feststellen.

von Walter T. (nicolas)


Lesenswert?

Wieso "aus individueller Betrachtung"? numpy hat einen definierten 
Funktionsumfang, und jede dieser Varianten, die ich auch gefunden hatte, 
hat einen kleineren.

von Norbert (der_norbert)


Lesenswert?

Walter T. schrieb:
> Wieso "aus individueller Betrachtung"? numpy hat einen definierten
> Funktionsumfang, und jede dieser Varianten, die ich auch gefunden hatte,
> hat einen kleineren.

Auf meinem PC hat numpy eine Größe von ca. 20 MB (core+lib) und über 
30MB gesamt.
Wollen wir gemeinsam raten, wo sich da ein Problem zeigen könnte…?

: Bearbeitet durch User
von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Lesenswert?

Walter T. schrieb:
> Wieso "aus individueller Betrachtung"? numpy hat einen definierten
> Funktionsumfang, und jede dieser Varianten, die ich auch gefunden hatte,
> hat einen kleineren.

Es ist halt die Frage, ob in der jeweiligen Anwendung der vollen 
Funktions-Umfang nötig ist. Und Personen, die die Mathematik dahinter 
verstanden haben, lösen das Problem, wie man die spezielle "fehlende" 
Funktion durch die vorhandenen ersetzen resp. interpolieren kann.

Beispielweise wurden so vor 40 Jahren Interpolationsformeln fürs 
Radizieren gelehrt, damit man auch mit den billigen Taschenrechnern die 
nur die Grundrechenarten die Tsten drauf haben gelegentlich ne Wurzel 
ziehen kann.
Unt mit Borrechnern vergleichbarer Kapazität ist die NASA zum Mond und 
zurück geflogen.

von Walter T. (nicolas)


Lesenswert?

Norbert schrieb:
> Auf meinem PC hat numpy eine Größe von ca. 20 MB

Auf meinem PC ist meine clib auch deutlich größer als auf meinem STM32.

Aber okay, ich entnehme dem, dass ein bischen Numerik auf dem µC unter 
Micropython genauso wenig Spaß wie mit C/C++ macht, weil die 
interessanteren Libraries fehlen oder arg beschnitten sind.

von Norbert (der_norbert)


Lesenswert?

Walter T. schrieb:
> Auf meinem PC ist meine clib auch deutlich größer als auf meinem STM32.

Und die STM clib kann exakt das Gleiche wie die PC Version?
Möglicherweise ist die an manchen Stellen vielleicht abgespeckt…
Fragen über Fragen…

von Bradward B. (Firma: Starfleet) (ltjg_boimler)


Angehängte Dateien:

Lesenswert?

Anbei ne Übersicht über die Funktionsvielfalt vom micronumpy.

Größenangaben der compilierten lib für prebuilts für STM32 o.a. 
Platformen lassen sich auf die Schnelle nicht finden, grad mal für ulab 
lässt sich für den ESP32 eine Aussage "passt in eine 128k factory 
partition" aufspüren.

https://github.com/v923z/micropython-ulab

von Walter T. (nicolas)


Lesenswert?

Auf den ersten Blick fehlt im wesenlichen numpy.linalg.eig(), ansonsten 
sähe die Aussstattung gar nicht mal so übel aus.

numpy.kron() und numpy.trace() sind schnell nachgebaut, ansonsten 
scheint nichts wichtiges zu fehlen.

Aber: Sparse scheint nicht implementiert zu sein und "advanced indexing" 
fehlt auch. Damit ist für das Rechnen mit Zahlen deutlich unkomfortabler 
als man mit Python normal gewohnt ist.

von J. T. (chaoskind)


Lesenswert?

Norbert schrieb:
> Wenn man seine Servos manuell mit Attosekunden-Präzision ansteuern
> möchte…

Norbert schrieb:
> Monk schrieb:
>> maßlosen Übertreibungen
>
> Das ist nachweislich eine Falschaussage!

Wer aus gewünschten Mikrosekunden Attosekunden macht, übertreibt maßlos. 
Mikro->Nano Faktor 1000, Nano->Piko Faktor 1000, Piko->Femto Faktor 
1000, Femto->Atto Faktor 1000.

Also lediglich Faktor eine (deutsche) Billiarde daneben, oder 15 
Größenordnungen.
Da könnte wohl selbst ein Politiker nicht mehr behaupten, nicht daneben 
gelegen zu haben, ohne rot zu werden.

Halten wir also fest, 15 Größenordnungen daneben IST maßlos übertrieben, 
du hast eine solche Aussage getätigt, also ist deine Aussage der 
nachweislichen Falschaussage, eine nachweisliche Falschaussage

von Norbert (der_norbert)


Lesenswert?

J. T. schrieb:
> Halten wir also fest, 15 Größenordnungen daneben IST maßlos übertrieben,
> du hast eine solche Aussage getätigt, also ist deine Aussage der
> nachweislichen Falschaussage, eine nachweisliche Falschaussage

Tja liebes chaoskind, meine Aussage beinhaltet sehr wohl ein Maß 
(präziser formuliert ein Zeitmaß).
Sie kann also nicht ›Maßlos‹ sein.

Ihr meint vermutlich Überspitzt, welches ein durchaus gebräuchliches 
Stilmittel ist.

von J. T. (chaoskind)


Lesenswert?

Tja lieber Norbert, es gibt da so etwas, das nennt sich Umgangssprache. 
Und wenn man mit Hilfe dieser kommuniziert, dann bedeutet "maßlos 
übertrieben", wie du selbst ganz richtig feststellst, "überspitzt". 
Komisch dass du dass weißt, aber nicht anwenden kannst.
Meld dich gern, wenn ich dir mal wieder sprachliche Feinheiten erklären 
soll.

von Norbert (der_norbert)


Lesenswert?

J. T. schrieb:
> es gibt da so etwas, das nennt sich Umgangssprache.
> Und wenn man mit Hilfe dieser kommuniziert,

kommt zum Beispiel so etwas wie ›Stundenkilometer‹ dabei heraus.

Wenn Käthi und Pläti sich unterhalten, mag das vielleicht OK sein.

von J. T. (chaoskind)


Lesenswert?

Norbert schrieb:
> kommt zum Beispiel so etwas wie ›Stundenkilometer‹

so what? Jeder (halbwegs technisch versierte) Mensch weiß, dass das für 
zurückgelegte Strecke pro Zeiteinheit steht. Und es sagt sich schneller 
als Kilometer pro Stunde.

Norbert schrieb:
> Tja liebes chaoskind, meine Aussage beinhaltet sehr wohl ein Maß
> (präziser formuliert ein Zeitmaß).
> Sie kann also nicht ›Maßlos‹ sein.

Und um das nochmal ganz deutlich zu machen. Eine maßlose Übertreibung 
kann durchaus auch mit Maßeinheiten versehen sein. Es geht ja nicht 
darum, dass in deiner Aussage kein Maß vorkommt, sondern darum, dass 
sich für den Grad deiner Übertreibung kein Maß finden lässt.

Willst du jetzt weiter über sprachliche Feinheiten diskutieren, oder 
kannst du akzeptieren, dass deine Aussage ganz einfach Schwachsinn war?

von Norbert (der_norbert)


Lesenswert?

J. T. schrieb:
> Willst du jetzt weiter über sprachliche Feinheiten diskutieren

Mit dir?

Nein! Zwecklos!

Blubber ruhig weiter Quatsch, das schöne an deinen Ergüssen ist, die 
kann man ganz allein für sich stehen und für alle sichtbar lassen.

von J. T. (chaoskind)


Lesenswert?

Norbert schrieb:
> Blubber ruhig weiter Quatsch, das schöne an deinen Ergüssen ist, die
> kann man ganz allein für sich stehen und für alle sichtbar lassen.

Ich finde nicht, dass es Quatsch ist darauf hinzuweisen, dass man 
durchaus von maßlosem Übertreiben sprechen kann,  wenn jemand 
Mikrosekunden wünscht und ein anderer dann anfängt, von Attosekunden zu 
faseln und dann ein dritter nachhakt, ob diese Übertreibung nötig ist. 
Besagter dritter erzählt zwar auch gern mal Sachen, die ich so nicht 
unterschreiben würde, aber an dieser Stelle hat er ganz einfach recht.

Dinge die man nicht versteht, mögen einem oft wie Quatsch vorkommen und 
manche Menschen neigen halt zu Trotzreaktionen, wenn man sie auf ihr 
Fehlverhalten aufmerksam macht.

Und ja, ich seh es genauso, meine "Ergüsse" kann man ruhig für jeden 
sichtbar stehen lassen.


p.s.
schön dass du aktzeptierst dass deine Aussage Schwachsinn war unddu 
nicht weiter mit mir über sprachliche Feinheiten diskutieren möchtest.
Ich wünsch dir eine gute Nacht.

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Kurzer Bericht :

Es klappt prima mit dem ESP32 und Micropython !

Alles an Software für den Betrieb eines autonomen Schiffs ist fertig und 
funktioniert. GPS, PPM-Decoder mit Interrupt, PPM-Quelle für Servo mit 
PWM, Kompass, usw. haben miteinander knapp 2ms Laufzeit. Bei 10 Hz 
Kreisfrequenz mit NPRM-Scheduler (das langt für ein Schiff) sind das 
unter 2% Auslastung.

Thonny als Entwicklungstool reicht völlig aus, der ESP von expressif ist 
mit Bluetooth und WLAN völlig überdimensioniert (der lag halt gerade 
rum..).

Fehlt noch die H-Brücke für den Motor und ein 6V - Akku, dann gehts zum 
See ;-)

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Reiner D. schrieb:
> Fehlt noch die H-Brücke für den Motor und ein 6V - Akku, dann gehts zum
> See

Viel Spaß. Ziehe dich warm an.

von Reiner D. (dollreiner)


Lesenswert?

Jetzt hab ich doch noch eine Frage zu Python.

Die härteste Nuß war das Steuern der Servos.
Allgemein liest man hier, daß das mit dem ESP unter Python nicht geht, 
weil Zeitauflösung maximal im ms-Bereich erzielt werden kann.

Sucht man ein wenig länger, findet man mehrere Lösungen, die das aber 
doch ermöglichen. Die mir am einfachsten erscheinende ist der Mißbrauch 
des RMT-Moduls.Im Web findet sich dieser Code :
1
import esp32
2
from machine import Pin
3
4
r = esp32.RMT(0, pin=Pin(18), clock_div=8)
5
r   # RMT(channel=0, pin=18, source_freq=80000000, clock_div=8)
6
# The channel resolution is 100ns (1/(source_freq/clock_div)).
7
r.write_pulses((1, 20, 2, 40), 0) # Send 0 for 100ns, 1 for 2000ns, 0 for 200ns, 1 for 4000ns

Das klappt prima, aber ich verstehe die Zeile mit "r  #RMT(channel....." 
nicht. Da steht ohne den Kommentar einfach "r". Was ist das ??

In meiner Abwandlung schaut das dann so aus :
1
import esp32
2
from machine import Pin
3
4
#macht einen Puls, hier 2.5 ms (=2500us) an PIN 4
5
6
r = esp32.RMT(0, pin=Pin(4), clock_div=80)
7
#r 
8
r.write_pulses((2500,0),1)

Und : es geht auch ohne die mir unverständliche Zeile ?!  Was tut sie ?

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Offenbar von https://docs.micropython.org/en/latest/library/esp32.html 
kopiert.

Die Zeile git den Inhalt von r aus der Konsole aus.
Das hatte jemand zu Testzwecken eingefügt.

Probiere das:
1
python3
2
a=3
3
a

Erzeugt die Ausgabe "3", also den Inhalt von a.

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Au, ist dass peinlich ;-)

Ich hatte an so was ähnliches wie Konstruktoren oder einen 
superkryptischen Methodenaufruf der so gedacht.

Danke !

(das war genau die Quelle)

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Wieso schimpft denn keiner ?

Ich hatte herbe Kritik erwartet ob der schrägen Nutzung des RMT-Moduls !

(Aus der anderen Richtung gefragt : wieso gibts kein sauberes 
Timer-Modul, das in us parametrierbar ist ?)

von 900ss (900ss)


Lesenswert?

Schimpfen kommt gleich weil du plenkst. ;)

von Reiner D. (dollreiner)


Lesenswert?

Sorry, ich hatte mir doch schon Mühe gegeben und Groß/Klein-Schreibung 
benutzt, was ich sonst nie tue!

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Reiner D. schrieb:
> wieso gibts kein sauberes
> Timer-Modul, das in us parametrierbar ist ?

Frage Espressif. Woher sollen wir wissen, warum die Eierlegende 
Wollmilchsau keine Kakaobohnen kackt?

Das Erzeugen der Servo Signale ist per Software schwierig, weil

a) Dein Python Script interpretiert wird. ISR werden von der 
Programmiersprache nicht direkt unterstützt. Mit dem nötigen Overhead 
kommst du in ganz andere Zeit-Bereiche.

b) Weil der ESP ein Multitasking Betriebssystem Ausführt, dass nur in 
viel langsameren Intervallen Taskwechsel durchführt.

Unter Linux und Windows hast du das gleiche Problem. Ohne Hardware-Timer 
geht es nicht. Sei Froh, dass der ESP32 diesen RMT hat. Der ESP8266 hat 
keinen.

Kennst du den PCA9685? Der ist zur Ansteuerung von Servos prima 
geeignet, und er hat 12 Kanäle!

: Bearbeitet durch User
von Joe G. (feinmechaniker) Benutzerseite


Lesenswert?

Reiner D. schrieb:
> Die härteste Nuß war das Steuern der Servos.

Was spricht eigentlich gegen die PWM?
1
import machine
2
from machine import Pin, PWM
3
import utime, math
4
from time import sleep
5
6
7
# pwm
8
pwm = PWM(Pin(2), freq=50, duty=0)
9
10
11
def Servo(servo, angle):
12
    # angle / 180( * 2(0°-180°) + 0.5()/ 20ms * 1023
13
    pwm.duty(int(((angle)/180 *2 + 0.5) / 20 * 1023))    
14
15
16
def moveServo(position):
17
    Servo(pwm, position)
18
    utime.sleep(1)
19
    print("Servo  Angle : ",position)

von Reiner D. (dollreiner)


Lesenswert?

Mit PWM geht das prima, da gibts auch eine Parametrierung, die man in ns 
vorgeben kann. Aber halt bloß bei einem Servo. Mehrere Servos unabhängig 
klappt imho nicht. Mit RMT gehts sehr einfach, aktuell habe ich 2 Servos 
in Betrieb (möglich sind wohl 8). Die Impulse kommen (fast) gleichzeitig 
und sind völlig unabhängig. Der Zyklus dahinter (NPRM) ist 100 ms, damit 
haben die Rudermaschinen kein Problem.
1
import esp32
2
from machine import Pin
3
import config
4
5
#servos an pin 4, 18
6
r1 = esp32.RMT(0, pin=Pin(4), clock_div=80)
7
r2 = esp32.RMT(1, pin=Pin(18), clock_div=80)
8
9
def stellen():
10
    #in config.kanal[n] stehen die RC-Werte
11
    r1.write_pulses((config.kanal[0],0),1)
12
    r2.write_pulses((config.kanal[1],0),1)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Joe G. schrieb:
> Ich habe gerade übers Wochenende einen Fuatba SBUS-Decoder (100.000 Baud
> 8E2, RX invers) in Micro Phyton für den RPi Pico geschrieben. Geht
> sicher auch für den ESP32.
> Mein Fazit – ja Modellbau geeignet.

Dito hier für ein Tyco Rebound RC Car. SBUS Dekoder, 2 x ESC, Servo für 
die Kamera, Digitalsteuerung für Scheinwerfer. Alles im RPico in 
Micropython. Steuerung ist eine alte DJI Phantom auf 5,8GHz.

von Norbert (der_norbert)


Lesenswert?

Matthias S. schrieb:
> Alles im RPico in Micropython.

Psssst. So etwas darf man hier auf gar keinen Fall sagen.
Da könnte man auch gleich dreimal Rumpelstilzchen rufen. ;-)

von Joachim S. (oyo)


Lesenswert?

Reiner D. schrieb:
> Mit PWM geht das prima, da gibts auch eine Parametrierung, die man in ns
> vorgeben kann. Aber halt bloß bei einem Servo. Mehrere Servos unabhängig
> klappt imho nicht.

Das sollte schon gehen, der ESP32 hat ja mehrere unabhängige PWM-Kanäle.
Ich habe schon mal einen simplen 6-Kanal RC-"Empfänger" mit einem ESP32 
gebaut und die 6 Servo-Signale da auch alle per PWM erzeugen lassen.

von Reiner D. (dollreiner)


Lesenswert?

Ich hab auf deine Aussage hin weiter gesucht.
Klar hast du recht.

Wenn ich auf API-Ebene suche, finde ich die Beschreibung der 
Funktionsgruppen für die PWM-Erzeugung. Das sind, wenn ich nicht irre, 3 
Blöcke mit je 2 Kanälen. Auf API-Ebene (heißt das hier "idf"?) sind die 
dann auch unabhängig und hochauflösend parametrierbar (was in Pyton 
nicht unabhängig möglich ist, warum, verstehe ich nicht, wenn's die HW 
ja offenbar kann.)

Auch ein netter Spielplatz, da grab ich jetzt mal rum mit meinem 
Schäufelchen ;-)

Danke!

von Reiner D. (dollreiner)


Lesenswert?

Darf ich noch eine Anfängerfrage stellen?
Ich kapier die Parametrierung der Funktionen nicht so recht.

Hier ein Beispiel von mir:
1
def stellen():
2
    #in config.kanal[n] stehen die RC-Werte
3
    r1.write_pulses((config.kanal[0],0),1)
4
    r2.write_pulses((config.kanal[1],0),1)

und hier ein Beispiel von weiter oben (Joe G.):
1
def Servo(servo, angle):
2
    # angle / 180( * 2(0°-180°) + 0.5()/ 20ms * 1023
3
    pwm.duty(int(((angle)/180 *2 + 0.5) / 20 * 1023))

Meine Wissenslücke betrifft das "servo" aus: "def Servo(servo, angle):".
"angle" ist ein Parameter, der übergeben wird, klar, aber was ist 
"servo"?

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Anmerkungen:
Da Modellbauservos durchaus mit variablen Frequenzen angesteuert werden 
können (20Hz…50Hz), sollte man den dutycycle nicht davon abhängig 
machen. Zumal die PWM-Methoden ja eine duty_ns() vorsehen.

Auch wäre es sinnvoll den Bereich zu beschränken, es gibt Servos welche 
zu verblüffenden Reaktionen neigen wenn man den normalen Bereich 
(1000µs…1500µs…2000µs) verlässt.
1
#!/usr/bin/python3
2
# -*- coding: utf-8 -*-
3
4
SERVO_MIN = -110
5
SERVO_MAX = +110
6
7
def set_servo(percent):
8
    percent = max(SERVO_MIN, min(percent, SERVO_MAX))
9
    duty_ns = ((percent + 100) / 200 + 1) * 1e6
10
    print(f'{percent:4}  {duty_ns/1e3:+7.1f} µs')
11
    # set servo duty_ns here
12
13
for percent in range(-120, 120+1, 10):
14
    set_servo(percent)
1
-110   +950.0 µs
2
-110   +950.0 µs
3
-100  +1000.0 µs
4
 -90  +1050.0 µs
5
 -80  +1100.0 µs
6
 -70  +1150.0 µs
7
 -60  +1200.0 µs
8
 -50  +1250.0 µs
9
 -40  +1300.0 µs
10
 -30  +1350.0 µs
11
 -20  +1400.0 µs
12
 -10  +1450.0 µs
13
   0  +1500.0 µs
14
  10  +1550.0 µs
15
  20  +1600.0 µs
16
  30  +1650.0 µs
17
  40  +1700.0 µs
18
  50  +1750.0 µs
19
  60  +1800.0 µs
20
  70  +1850.0 µs
21
  80  +1900.0 µs
22
  90  +1950.0 µs
23
 100  +2000.0 µs
24
 110  +2050.0 µs
25
 110  +2050.0 µs

von Reiner D. (dollreiner)


Lesenswert?

Jetzt geht was! Der Beitrag von Norbert trifft genau in die gleiche 
Kerbe, an der ich gerade rumkratze.

Ich habe endlich eine ausführliche Doku gefunden:
https://docs.micropython.org/en/latest/micropython-docs.pdf

Und da steht auf Seite 483:

A maximum number of PWM channels (Pins) are available on the ESP32 - 16 
channels, but only 8 different PWM frequencies are available, the 
remaining 8 channels must have the same frequency. On the other hand, 16 
independent PWM duty cycles are possible at the same frequency.

..also mehr Kanäle als genug!

Und die Granularität (Seite 93):

class machine.PWM(dest, *, freq, duty_u16, duty_ns, invert)
Construct and return a new PWM object using the following parameters:
(...)
• duty_ns sets the pulse width in nanoseconds.

In ns, das ist fast schon zu feinkörnig ;-)


(Nebenbei hab ich noch was gefunden, was ich auch ausprobiere:
machine.time_pulse_us(pin, pulse_level, timeout_us=1000000, /)
Unklar ist mir, ob das mit HW-Timern realisiert ist, was die mehrfache 
Nutzung ja beschränken würde.)

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Alles prima, läuft einwandfrei.

Nebenbei gefragt:

Wenn ich im 50Hz-Zyklus PWM-Objekte erzeuge, ohne die wieder zu 
entfernen, macht das keine Probleme? Oder überschreibt der Konstruktor 
hier mit dem zweiten Objekt das erste:
1
#im Durchlauf n:
2
pwm0 = PWM(Pin(0), freq=50, duty_ns=100000) 
3
..
4
#im Durchlauf n+1:
5
pwm0 = PWM(Pin(0), freq=50, duty_ns=200000)

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Wenn ich im 50Hz-Zyklus PWM-Objekte erzeuge,

So was macht man nicht.
Die erzeugt man genau einmal zum Programmstart und nutzt sie dann 
einfach solange man sie braucht. Hardware, läuft ohne 
Prozessorinteraktion kontinuierlich durch. Nur den dutycycle 
gelegentlich ändern um die Servos zu positionieren.
1
#!/python
2
pwm0 = PWM(Pin(0), freq=50, duty_ns=1_500_000)

Dann, während des Programmlaufes:
1
#!/python
2
pwm0.duty_ns()

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Ohne Zweifel, selbstverständlich.
Danke für die Tipps trotz meiner unglaublich peinlichen Fehler..
Natürlich dreht man am Attribut, statt die ganze Kiste neu zu bauen.

Ist der Ruf mal ruiniert.. Ich hatte oben mal gefragt:

def Servo(servo, angle):
    # angle / 180( * 2(0°-180°) + 0.5()/ 20ms * 1023
    pwm.duty(int(((angle)/180 *2 + 0.5) / 20 * 1023))

Meine Wissenslücke betrifft das "servo" aus: "def Servo(servo, angle):".
"angle" ist ein Parameter, der übergeben wird, klar, aber was ist
"servo"?

von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Meine Wissenslücke betrifft das "servo" aus: "def Servo(servo, angle):".
> "angle" ist ein Parameter, der übergeben wird, klar, aber was ist
> "servo"?

Das ist an der Stelle einfach Unsinn.
Sollte sich servo auf ein Objekt beziehen, dann müsste die Zeile weiter 
unten wohl eher folgendermaßen lauten:

servo.duty(int(((angle)/180 *2 + 0.5) / 20 * 1023)

Aber auch das würde ich an deiner Stelle mal genauer durchrechnen. ;-)

von Reiner D. (dollreiner)


Lesenswert?

Das mit dem "servo" sind fremde Federn.
Vielleicht kann "Joe G. (feinmechaniker)" was dazu sagen?

Ich hab noch ein ähnliches Beispiel:
1
from machine import RTC
2
rtc = RTC() # init with default time and date
3
rtc = RTC(datetime=(2015, 8, 29, 9, 0, 0, 0, None)) # init with a specific time and date
4
print(rtc.now())
5
6
def alarm_handler (rtc_o):
7
    pass

Eine Variable "rtc_o", die übergeben werden könnte, ist weit und breit 
nicht zu sehen. Quelle: 
https://docs.micropython.org/en/latest/wipy/quickref.html#pwm-pulse-width-modulation

: Bearbeitet durch User
von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Eine Variable "rtc_o", die übergeben werden könnte, ist weit und breit
> nicht zu sehen.

Klar. Ist auch richtig so.
Die wird beim Interrupt übergeben und stellt die Instanz/das Objekt der 
RTC dar.

rtc_i = rtc.irq(trigger=RTC.ALARM0, handler=alarm_handler, 
wake=machine.SLEEP)

Bei einem Interrupt wird die alarm_handler Funktion mit dem 
entsprechenden Parameter aufgerufen, also mit der Instanz der RTC. Das 
Ding kannst du im Handler übrigens nennen wie du willst.

Reiner D. schrieb:
> Das mit dem "servo" sind fremde Federn.
> Vielleicht kann "Joe G. (feinmechaniker)" was dazu sagen?

Da wird er nicht viel anderes sagen können. Falsch ist falsch. Oder 
Schreibfehler ist Schreibfehler.

von Reiner D. (dollreiner)


Lesenswert?

Das ist jetzt für euch alles Kindergarten, Krabbelgruppe.
Wenn euch das zu blöd ist, antwortet einfach nicht..

Ich versuche, die logische Struktur hinter der Syntax zu verstehen. Das 
Problem ist, daß ich in einer Zeit "digital sozialisiert" wurde, als es 
noch keinen PC und keine OO gab. Fortran, Assembler, PDP11 usw.

Also :
1
from machine import RTC
2
rtc = RTC()

In Zeile 2 wird im Speicher ein Programmstück angesprungen 
("Konstruktor"(, das im Speicher eine Struktur macht, die aus Programmen 
("Methoden") und  Speicher ("Attribute") besteht. Das kann öfter 
geschehen, die Strukturen stören sich gegenseitig nicht.
1
print(rtc.datetime())

So kann ich z.b. auf so 'nen Speicherinhalz (Attribut) zugreifen.

Dazu jetzt Vererbung, private/public-Spiele und was sonst noch in diesem
Umfeld so existiert. Das kriege ich in C++ auch alles hin.

Aber:

"Bei einem Interrupt wird die alarm_handler Funktion mit dem
entsprechenden Parameter aufgerufen, also mit der Instanz der RTC."

Da setzt's jetzt aus. Der Alarm-Handler ist ein Programm. Ein Parameter 
ist (bisher) ein Wert, der als Eingabe für irgendeine Berechnung oder so 
dient.
Welchen Sinn hat es, ein Objekt (siehe ganz oben) zu "übergeben"? Da 
könnte ich doch in der Alarm-Handler-Routine auch einfach den 
Konstruktor aufrufen?

Man sieht deutlich, ich versteh' das nicht. Vielleicht kann jemand den 
Zusammenhang so stark vereinfacht beschreiben, daß ich eine Chance 
habe;-)

von Norbert (der_norbert)


Lesenswert?

Reiner D. schrieb:
> Da setzt's jetzt aus. Der Alarm-Handler ist ein Programm.

Der Alarm-Handler ist eine Funktion.


> Welchen Sinn hat es, ein Objekt (siehe ganz oben) zu "übergeben"?

Das wird klar, wenn du zB. zehn Alarm-Timer in der RTC hättest, welche 
alle auf einen einzigen Alarm-Handler verweisen können.
Dadurch dass das erzeugende Objekt übergeben wird, weiß der 
Alarm-Handler welches der zehn Alarme/Timer gerade aktiviert hat. 
Gleichzeitig kannst du mit dieser Objekt-Referenz auf genau diesen 
speziellen Alarm-Timer zugreifen um zB. nur dort Änderungen vorzunehmen.

> Da könnte ich doch in der Alarm-Handler-Routine auch einfach den
> Konstruktor aufrufen?

Du würdest damit innerhalb des Handlers (temporär) eine neue Instanz 
erzeugen und dich nicht auf die aktuelle Instanz beziehen. Kostet Zeit, 
braucht zusätzlichen Speicher und ist zudem insgesamt eher 
kontraproduktiv.

Das ist zwar für einen RP2040, aber vielleicht wird's ja etwas klarer.
1
#!/python
2
#!/micropython
3
# -*- coding: UTF-8 -*-
4
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
5
6
from machine import Pin, Timer
7
from time import sleep_ms
8
9
def timer_cb(objtimer):
10
    if objtimer == timer1:
11
        print('T1', end=' ')
12
        led.on()
13
14
    if objtimer == timer2:
15
        print('T2', end=' ')
16
        led.off()
17
18
# Nur einmal erzeugen
19
led = Pin(25)
20
timer1 = Timer()
21
timer2 = Timer()
22
for item in (led,timer1,timer2):
23
    print(item)
24
25
# Nun beliebig modifizieren
26
led.init(mode=Pin.OUT)
27
timer1.init(mode=Timer.PERIODIC, freq=5, callback=timer_cb)
28
timer2.init(mode=Timer.PERIODIC, freq=7, callback=timer_cb)
29
for item in (led,timer1,timer2):
30
    print(item)
31
32
sleep_ms(1000)
33
timer1.deinit()
34
timer2.deinit()
35
sleep_ms(200)
36
print()
1
Pin(GPIO25, mode=ALT, pull=PULL_DOWN, alt=31)
2
Timer(mode=ONE_SHOT, tick_hz=1000000, period=0)
3
Timer(mode=ONE_SHOT, tick_hz=1000000, period=0)
4
Pin(GPIO25, mode=OUT)
5
Timer(mode=PERIODIC, tick_hz=1000000, period=200000)
6
Timer(mode=PERIODIC, tick_hz=1000000, period=142857)
7
T2 T1 T2 T1 T2 T2 T1 T2 T1 T2 T1 T2

: Bearbeitet durch User
von Reiner D. (dollreiner)


Lesenswert?

Ein sehr schönes Beispiel, vielen Dank!

Mit:
1
def timer_cb(objtimer):
2
    if objtimer == timer1:
3
        print('T1', end=' ')
4
        led.on()

und dazu:
1
timer1.init(mode=Timer.PERIODIC, freq=5, callback=timer_cb)

ist mir klar, was du meinst. Viel gelernt!

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.