Announcement: there is an English version of this forum on 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.
:
Bearbeitet durch User
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.
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 :-)
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
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.
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.
@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?
:
Bearbeitet durch User
Norbert schrieb: > Wenn man seine Servos manuell mit Attosekunden-Präzision ansteuern > möchte… Was sollen immer diese maßlosen Übertreibungen?
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
ISR_delay.png
200 KB
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.
:
Bearbeitet durch User
Kann man denn davon ausgehen, dass der unbekannte ESP32 mit Micropython die gleiche Performance hat, wie der RP2040? Auch wenn WLAN eingeschaltet ist?
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.
:
Bearbeitet durch User
> 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
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-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.).
›@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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.)
:
Bearbeitet durch User
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?)
:
Bearbeitet durch User
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
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.
Geht numpy? (Auf die Schnelle finde ich nur abgespeckte Versionen.)
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.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
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.
> 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.
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…?
:
Bearbeitet durch User
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…
Angehängte Dateien:
-
micronumpy.PNG
34 KB
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.
:
Bearbeitet durch User
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 ;-)
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.
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 ?
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
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
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 ?)
Sorry, ich hatte mir doch schon Mühe gegeben und Groß/Klein-Schreibung benutzt, was ich sonst nie tue!
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
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) |
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) |
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!
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
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 |
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
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
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
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. ;-)
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
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.
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
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!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.