|
Anzeige
|
Micropython rp2040Liebes Forum, meine Frage bezieht sich auf Micropython und den rp2040-µC. Läuft auf dem µC ein Micropython-Interpreter und das Micropython-Programm wird auf den rp2040 geladen oder wird mit der IDE (Thonny z.B.), in der dann der Interpreter vorhanden ist, ein Binärfile erstellt, das geladen und vom rp2040 abgearbeitet wird? Viele Grüße, Alexander Der Interpreter läuft auf dem RP2040, dazu muss er natürlich erstmal in den Speicher geschrieben werden. Die Python-Files selbst liegen dann normal als Textfiles in einer Art virtuellem Dateisystem, wo man sie via Thonny oder auch via etwa mpremote/mpr lesen und schreiben kann. Einstiegspunkt für Micropython ist dann main.py, von der aus können aber andere im Speicher liegende Files normal eingebunden werden. Danke, darum ging es in der Frage. Letztlich will ich nur wissen, ob Programmieren mit Micropython wie fahren mit angezogener Handbremse ist und man bei zeitkritischen Programmen besser C verwenden sollte. Viele Grüße, Alexander
Ja, sollte man. ... und wenn man dann mit C programmiert, spricht irgendetwas gegen die Arduino-IDE? Viele Grüße, Alexander
Davon ausgehend, dass du immer noch zeitkritische Aufgaben meinst: ja – mit Arduino sind präzise Sachen nur schwer bis gar nicht möglich. Für Fälle, in denen das Arduino-Framework reicht, könntest du genausogut auch Micropython nehmen – hängt dann von deinem persönlichen Geschmack ab. Es gibt übrigens auch die Möglichkeit, PIO-Code aus Micropython heraus zu nutzen, sodass man da durchaus auch taktgenau arbeiten kann, wenn einem so ist. Ob die Möglichkeit aus dem Arduino-Kram heraus ebenso einfach nutzbar ist, weiß ich nicht.
Kommt ganz auf deine Definition von Zeitkritisch an. Die beiden Kerne laufen mit 125MHz, können lt. Datenblatt 133MHz und lassen sich problemlos auf 200% hoch takten. Viele Aufgaben können über die Hardware, Interrupts, DMA erledigt werden. Selbst Thumb-Assembler für die kleinen ›wirklich‹ zeitkritischen Routinen ist mit Bordmitteln möglich. Meistens braucht man das aber gar nicht, den ADC zB., mit 500.000 samples pro Sekunde, kann man ohne Probleme mit Python Code fehlerfrei lesen. Es geht konkret um LED-Bargraph-Aussteuerungsanzeigen. Audio und die ballistischen Gleichrichter laufen auf einem Teensy 4.1 mit 8 Kanälen. Die Momentanwerte werden alle paar ms via UART auf einen µC übertragen, der dann die Pegelwerte berechnet (Logarithmus, float) und diese dann auf die LED-Anzeige mappt (TLC5926 Schieberegister LED-Treiber). Da der Raspberry pico preisgünstig und vor allem verfügbar ist, habe ich ihn in den Blick genommen. Ich möchte nur abschätzen, ob ein Pico reicht oder ob ich mehrere nehmen muß. Und da ist es schon interessant, daß zwei Kerne an Bord sind und welche Programmiersprache benutzt wird. Ganz habe ich es mit den Einschränkungen der Arduino-IDE nicht verstanden. Kompliziert sind die Programme nicht, einige Wertebereichs-Abfragen, float-Arithmetik und UART-Empfang von jeweils 8 Bytes pro zwei Kanäle. Viele Grüße, Alexander
Also entweder ich kann C++ und Arduino, dann brauche ich kein Python oder ich benutze Python weil mir C++ zu schwer ist. Wenn ich in C++ Arduino benutzen, dann hauptsächlich wegen der Unmengen an Libs. Bei zeitkritische Sachen schränkt mich Arduino nicht ein. Man kann die PinWackelFunktionen o.ä. von Arduino nutzen, muss es aber nicht. Bei den Highlevel-Libs wie USB Ethernet u.s.w hat Arduino keine zeitlichen Nachteile. Den Interrupts ist es auch egal ob da irgendwo was von Arduino im Flash liegt oder nicht.
Das gibts keinen Arduino Einschränkungen. So was triviales schafft der RP2040 auch unter Arduino im Hintergrund zum Bitcoin schürfen... Ja das ist ein echtes Problem! ;-) Da wird der Pico sich wohl zu 99% langweilen und in der Sonne räckeln. Vorsichtig und konservativ geschätzt sollten viele 10.000 FLOPS drin sein. Die UARTs haben einstellbare Puffer oder FIFOs (und alle paar ms ist sowieso eine Ewigkeit)
Man kann die PIOs auch gut in reinem C programmieren. Was ich als "zeitkritisch" bei Arduino sehe, ist die ewig lange Zeit zum Überbersetzen und Laden des neuen Programmes. Hinzu kommt, daß jegliches sinnvolles Debugging fehlt. Frage an Norbert: "Bei Python doch auch, oder?" Wenn RP2040, dann besser mit einem SWD-Programmierer/Debugger, der aber derzeit schwer beschaffbar und teuer ist. Das wäre egal, wenn Du eine Serie mit 100 Stück planst. Für ein Einzelstück und wenn es nicht zwingend ein RP2040 sein muß, würde ich einen kleinen STM32 auf einem Nucleo-Board empfehlen. STM32G431 zum Beispiel kostet netto bei Mouser 12 Euro und hat schon einen ST-Link auf dem Board. Ich kann beides bzw. ich habe in den letzten Jahren C++/Arduino-IDE genutzt. In der Arduino-IDE habe ich von Earle F. Philhower (der III.) die rp2040-Lib eingebunden. Allerdings weiß ich nicht, wie verläßlich diese Lib ist. Micropython ist nicht uninteressant, da sich manches kompakter als mit C++ ausdrücken läßt und so auch das Ausprobieren vereinfacht wird. Für meine Anwendung habe ich schon vor einiger Zeit für vier Kanäle den Teensy-LC benutzt, der aber wohl nicht mehr verfügbar ist. Das C++-Programm werde ich aber wohl ohne weiteres auf den rp2040 portieren können und muß nicht einmal die Arduino-IDE verlassen. Es wird allerdings auf die beiden Kerne anzupassen sein. Zum Glück habe ich ja eine natürliche "Kanalzerlegung". Als neugieriger Mensch wollte ich auch einmal mit Micropython herumspielen"... Viele Grüße, Alexander
Dann tue das doch! Was hält dich ab?
Gast
#7411346
Genau, das wollte ich auch dazu sagen. Ein wenig Aufwand steht schon dahinter. Es können pro Balken 40, 80 oder 120 LEDs verwendet werden. Pegelanzeige mit Balken und Peak-Hold mit Einzel-Led sind vorhanden. Die Pegelbereiche können verändert werden und es können auch Spreizanzeigen verwendet werden, bei denen beispielsweise niedrige Pegelwerte eine gröbere Auflöung als hohe Pegelwert haben...
Ist das so? Reicht da nicht ein Raspbery Pi Pico oder eine Raspberry Pi Debug Probe mit der Open Source Firmware Picoprobe?
Beitrag #7411364 wurde von einem Moderator gelöscht.
Nein, ist nicht so, und ja: ein Pico mit Picoprobe tut den Job ganz ausgezeichnet.
Solange der Code aus dem Flash läuft, nutzt das nur relativ wenig. Je umfangreicher der Code, desto weniger. Aber da der RP2040 eine ganze Menge RAM hat, kann man oft alles, was besonders schnell sein muss, dorthin laden und von dort ausführen. Damit erspart man sich die dauernden "Schluckaufs", die durch das (Um-)Füllen des Cache aus dem seriellen Flash entstehen.
Ja. Aber dran denken: ISRs sind auch Code. Die gehören auf jeden Fall in den RAM. Kein Mensch kann hohe Interruptlatenzen gebrauchen.
Nunja, das kommt ja wohl stark darauf an, was man mit dem Teil tut...
Das kann ich 100%ig bestätigen. Nur ein kleines Problem gibt es: die Pins eines Pico sind weder kurzschluss- noch überspannungsfest. Und ein kleiner Fehler beim Anstöpseln oder Zuschalten der Spannungen passiert in Versuchsaufbauten in der Entwicklung doch recht schnell mal. Zum Glück ist es recht einfach, auf ein anderes Pinpaar umzuziehen, so das nicht gleich das Picoprobe durch so ein Malheur komplett unbrauchbar wird. Aber auf lange Sicht ist es wohl doch ziemlich sinnvoll, das "Standard-Picoprobe" durch entsprechende Schutzschaltungen zu ergänzen, wie sie bei "richtigen" Programmern aus gutem Grund auch absolut üblich sind. Micopython käme für mich niemals in Frage, aber läuft da echt ein Interpreter auf dem µC? Bin ich der Einzige, der das total behämmert findet? C++ ist nun wirklich nicht schwer.
Ja.
Nein. Bei MicroPython liegt der Bytecode im RAM und der komplette Interpreter mitsamt aller Module im FLASH. Hier die Geschwindigkeiten bei jeweils 100_000 log() Berechnungen:
In der Reihenfolge ›normaler‹ Code, ›native‹ Code, ›viper‹ Code. Die FLASH waitstates wirken sich bis zu 266MHz nicht aus. Wenn ich richtig gerechnet habe, wären das also (in der schnellsten Version) 6,55µs pro math.log() pro Kern. Danke für die ausführliche Information. Wenn ich Audiosignalverarbeitung mit ft=48kHz im Blick habe, passen drei Log-Berechnungen in einen Zeitrahmen. Das ist, verglichen mit Festkomma-DSPs, recht bescheiden, denn da benötige ich ca. 25 Clock-Zyklen für einen Logarithmus, was bei 250MHz Prozessortakt ca. 200 Berechnungen im Audiotakt entspricht. Viele Grüße, Alexander
Echt ein guter Satire Post. :)
Ja, für so etwas sollte man einen besseren/passenderen µC nehmen. Der RP2040 hat keinen Divisions-Befehl sondern nur eine etwas spezielle Implementation für Division eingebaut. Die braucht für 32Bit-Wort ÷ 32Bit-Wort genau 8 Zyklen. Man kann während der Wartezeit zwar noch etwas anderes machen, aber das sprengt dann doch Python, C, C++. Mit dem Assembler ginge es problemlos (wenn der Algorithmus es hergibt) Mal auf den Punkt gebracht:
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
