Anbei ein SBUS-Dekoder [1] für eine FrSky Fernsteuerung. Der Dekoder läuft in Micropython auf einem RP2040 unter Verwendung der PIO. So bleiben die seriellen Schnittstellen für andere Aufgaben frei. Nutzer einer originalen Futaba Fernsteuerung müssen das SBUS-Signal invertieren, was jedoch im PIO Code relativ einfach umzusetzen ist. [1] https://github.com/Joe-Grabow/USV/tree/main/01%20Hardware/09%20RC%20Control/02%20Software
Danke für's posten. Meiner Meinung nach wäre ein einfaches Beispiel gut, damit man schnell sieht, wie das Modul eingebunden und verwendet wird.
Ich denke, ich werde alt - jetzt bin ich am Zug rum zu nölen á la "Warum machst du das nicht mit nem 8 oder 32 Bit µC, sondern mit einem Applikationsprozessor und einer rescourcenintensiven Sprache wie µPhyton?" - Yada Yada Doch, ein bisschen ernst meine ich die Frage. Hat das einen tatsächlichen konzeptionellen Grund, oder sind Pi´s / Mini-Pi´s und Phyton einfach deine angestammte Toolchain? Bei mir sind es mehr µC. Wahrscheinlich würde ich auch mit Kanonen auf Spatzen schießen und ne Bluepill unter Arduino verwenden. Einfach, weil ich die mit dem Framework von RogerClark Melbourne so verwenden kann, dass ich die Ease-Of-Use Vorteile vom Arduino habe und gleichzeitig fit genug mit dem STM32 bin, um für Custom-Kram die Register barematel zu konfigurieren.
Jasson J. schrieb: > Ich denke, ich werde alt Keinen Widerspruch (bei deinen Aussagen)! > "Warum machst du das nicht mit nem 8 oder 32 Bit µC, sondern mit einem Applikationsprozessor Nu rate mal was ein RP2040 ist. > einer Sprache wie µPhyton?" Keine Ahnung was ein Phyton sein soll, so etwas gibt es gar nicht. Allerdings nutzen viele MicroPython. > rescourcenintensiven Er nutzt Hardware, PIO Hardware, da wäre selbst Thumb Assembler nicht schneller.
Jasson J. schrieb: > "Warum machst du das nicht mit nem 8 oder 32 Bit µC, sondern mit einem > Applikationsprozessor und einer rescourcenintensiven Sprache wie > µPhyton?" Gerne möchte ich auf deine Fragen antworten. Der RP2040 enthält u.a. einen 32 Bit Prozessor. Das FUTABA-SBUS Signal ist recht exotisch und ich wollte zu Übungszwecken die PIO nutzen. Der RP2040 muß noch etwas mehr erledigen [1] als nur den SBUS zu dekodieren. [1] https://github.com/Joe-Grabow/USV/tree/main/01%20Hardware/07%20drive
Ah ok - I see Es kann auch gut sein, dass ich ESP Derivate nur deshalb (noch) nicht verstärkt einsetzte, weil ich in der Materie nicht warm bin. Schade eigentlich, weil gerade die Dinger mit WLan BT BLE einem schöne Dinge ermöglichen. Da hinke ich der Zeit hinterher. Ich schreib meine Überlegungen im Eröffnungspost gerne dazu - auch weil ich mich "gerne selbst reden höre" (ich finde Hobby hat auch was mit erlaubter Selbstbeweihräucherung zu tun :> ) und weil der Konzeptteil finde ich zum interessanten Teil gehört. Manchmal stelle ich den auch dem "Seht mal, was ich gebaut habe" Teil nach, weil die es interessiert das ohnehin lesen und die die das Konzept nicht juckt, einfach was süffisantes zu lesen haben und sich den TLDR Teil sparen können.
Jasson J. schrieb: > Es kann auch gut sein, dass ich ESP Derivate nur deshalb (noch) nicht > verstärkt einsetzte, weil ich in der Materie nicht warm bin. Siehst du, das ist mir nun völlig neu. Und vermutlich auch allen anderen – wirklich allen anderen – welche sich mit den Picos auseinander gesetzt haben. Die sind also tatsächlich vom ESP abgeleitet. Außer natürlich dass es eine völlig andere Prozessor-Architektur ist. Und eine völlig andere Hardware-Architektur ist. Und die ersten Picos (mehrere Jahre lang) ohne jedwede Funkanbindung hergestellt wurden. Die Welt hat doch immer noch Überraschungen bereit… > Ich schreib meine Überlegungen im Eröffnungspost gerne dazu - Ja, das mit dem ›Überlegen‹, so hat jeder sein Kreuz zu tragen…
Norbert schrieb: > Und die ersten Picos (mehrere Jahre lang) ohne jedwede Funkanbindung > hergestellt wurden. Knapp 1,5 Jahre, nicht mehrere. Allerdings hatte es dann nochmal ziemlich lange gedauert, bis auch Bluetooth nutzbar wurde. Das Schöne an den Pico-Dingern ist, dass halt alles recht offen ist. Auf Micropython-Ebene lassen sie sich allerdings fast gleich nutzen, bis auf eben die PIO, die hier ja auch zum Einsatz kommen. Ich finde das Projekt schon ziemlich interessant, komme nur leider gerade aus Zeitgründen nicht dazu, an meinen RC-Helikoptern zu basteln. SBUS kommt da auch zum Einsatz, wobei ich protokollmäßig sowieso dank EdgeTX auf einem Multiprotokollmodul-Sender eh ziemlich offen bin.
Jack V. schrieb: > Auf Micropython-Ebene lassen sie sich allerdings fast gleich nutzen, Liegt da (bei ESP) nicht noch ein RTOS dazwischen? Und wenn man den zweiten Kern benutzen möchte, dann läuft anstelle dessen alles auf dem ersten Kern im time-slicing? Vielleicht ist das ja mittlerweile gefixt, hab' mich lange nicht mehr darum gekümmert.
:
Bearbeitet durch User
Norbert schrieb: > Liegt da (bei ESP) nicht noch ein RTOS dazwischen? Das mag sein, oder auch nicht – soweit habe ich mich mit den ESPs nicht beschäftigt. Ist aber für die Nutzung von Micropython nicht von Belang. Natürlich gibt’s Unterschiede, deswegen das „fast“ – es ist aber in vielen (einfacheren) Fällen schlicht nicht von Bedeutung. Wie bei Arduino: In der Regel kannst du Arduino-Code für RP2040 auf für ESP32 bauen, und umgekehrt, solange du keine für den jeweiligen Controller spezifischen Sachen nutzt. Bei Micropython musst du’s bei generischen Sachen nicht mal neu kompilieren, allenfalls die Pins anpassen.
Jack V. schrieb: > Ist aber für die Nutzung von Micropython nicht von Belang. Also ich find's schon angenehm, wenn ich zwei von zwei Kernen nutzen kann. In einem gebe ich dir aber Recht, wenn man Micropython auf der Ebene des typischen Arduino Nutzer einsetzt — Google, Copy, Paste, Test, Swear, Ask — dann kann man das wirklich fast vergleichen. ;-) Dieses typische Verhalten konnte ich erst neulich (vor ein oder zwei Tagen) beobachten. Erst wurde mit Worthülsen geworfen, dann wurde die Erklärung nicht verstanden, dann kam das oben zitierte Eingeständnis.
Norbert schrieb: > Also ich find's schon angenehm, wenn ich zwei von zwei Kernen nutzen > kann. Beim RP2040 geht das problemlos, soweit ich weiß (ich konnte meine Rechenbedürfnisse bislang mit einem Kern erfüllen), und mit dem ESP hab ich mich, wie gesagt, auch noch nicht weit genug beschäftigt, um da was sagen zu können. Bin halt mit den RP2040 in die 32-Bit-Welt vorgestoßen, und da Mensch Gewohnheitstier ist […] Norbert schrieb: > In einem gebe ich dir aber Recht, wenn man Micropython auf der Ebene des > typischen Arduino Nutzer einsetzt — Google, Copy, Paste […] Dem Vernehmen nach soll es auch sowohl bei Arduino, als auch bei Micropython User geben, die wissen, wie man das Manual aufruft – und die es auch nutzen können. Ich finde dieses „Der nutzt Arduino|Micropython, der kann nur Copypasta, und doof isser auch!“ ein wenig problematisch.
Jack V. schrieb: > Beim RP2040 geht das problemlos, soweit ich weiß Das funktioniert hervorragend, um nicht zu sagen heraus baumelnd. So gut sogar, dass ich mir gelegentlich einen nutzbaren Dritt- oder Viertkern im RP2xxx wünsche. Bei mir verteilt sich der Einsatz von Python, C und Assembler mittlerweile paritätisch. Ich muss allerdings gestehen, dass ich mir einen Präprozessor für Micropython gebaut habe um die unterschiedliche Hardware/Addressen der RP2040 und RP2350 für Libraries zu abstrahieren. Jack V. schrieb: > Dem Vernehmen nach soll es auch sowohl bei Arduino, als auch bei > Micropython User geben, die wissen, wie man das Manual aufruft – und die > es auch nutzen können. Ich finde dieses „Der nutzt Arduino|Micropython, > der kann nur Copypasta, und doof isser auch!“ ein wenig problematisch. Grundsätzlich schon. Aber die Restmenge, die laute Restmenge. Da trennt sich eben die Weu vom Spreizen. PS. Man darf nicht vergessen, dass das Arduino Framework primär für die Menschen gedacht war, welche zum Beispiel auf der Dokumenta fettige Badewannen ausstellen. »Empowering anyone to innovate«
:
Bearbeitet durch User
Christoph M. schrieb: > Meiner Meinung nach wäre ein einfaches Beispiel gut, damit man schnell > sieht, wie das Modul eingebunden und verwendet wird. Bitteschön https://github.com/Joe-Grabow/USV/blob/main/01%20Hardware/09%20RC%20Control/02%20Software/00%20doc/UART_RX_Dokumentation.pdf
>Bitteschön
Besten Dank :-)
Vielleicht könnte es nützlich sein, sich an Vorgehen der Arduino-Welt zu
orientieren.
Im Arduino Bereich hat es sich als gute Praxis etabliert, die kurzen
Code-Beispiele in einem Ordner "examples" zu platzieren. Dann hat man
eine standardisierte Struktur und kann die Code-Beispiele als Templates
schnell als Startpunkt für das eigene Projekt kopieren.
Beitrag #7859013 wurde von einem Moderator gelöscht.
Beitrag #7859016 wurde von einem Moderator gelöscht.
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.