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 ?
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.
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.
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.
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.
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 ;-)
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.
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).
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.
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.
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…
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?
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?
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 ??
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?
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.
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.
> 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 ?
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.
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 ?
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 ;-)
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.
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…
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.
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…
@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...
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…
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?
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.
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."
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.
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?
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.
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.
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ß)
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.
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.
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?
>> 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.
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.
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.
>> 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.
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.
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.
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).
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?
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.
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.
> 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.
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.
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 …
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.
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.
> 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)
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.
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.
> 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).
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-emitterhttps://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.).
›@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.
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.
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 ?
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.
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!
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.
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.
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.
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.
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.
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! ;-)
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?
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.
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.)
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.
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).
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.
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.
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.)
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.
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?)
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)
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.
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.
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.
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.
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.
>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.
> 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 ;-)
> 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).
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.
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?
>> 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.htmhttps://www.elektronik-kompendium.de/sites/raspberry-pi/2612121.htmhttps://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.
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.
Wieso "aus individueller Betrachtung"? numpy hat einen definierten
Funktionsumfang, und jede dieser Varianten, die ich auch gefunden hatte,
hat einen kleineren.
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…?
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.
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.
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…
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
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.
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
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.
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.
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.
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?
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.
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.
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 ;-)
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 ?
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)
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 ?)
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!
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.
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.
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. ;-)
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.
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!
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.
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.)
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:
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.
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"?
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. ;-)
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.
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;-)
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.
Thread beobachten
Seitenaufteilung abschalten