Hi, ich weiß, dass es zum Thema Rust bereits einen ellenlangen Thread gibt und ich möchte hier keinen neuen Glaubenskrieg heraufbeschwören. Deshalb möchte ich hier keine Vergleiche mit anderen Programmiersprachen sondern nur Erfahrungsberichte von Usern, die schon mit Rust Programme für AVR, ARM, Risc-V oder andere Mikrocontroller geschrieben haben. Ich hab schon vor einer Weile angefangen, mich in Rust einzuarbeiten, bin aber aus Zeitgründen noch nicht so weit wie ich gern wäre. Heute bin ich über diese Seite gestolpert, die mein Interesse wieder geweckt hat. https://rust-embedded.github.io/book/ Ich werde das Buch einmal durchlesen und werde versuchen, die Beispiele auf ein Teensy-LC zu portieren, so weit möglich. Ironischer weise arbeite ich nicht auf einem x86 sondern auch auf einem ARM. Ich habe mir ein Odroid N2 als Desktop Ersatz geleistet und dort Manjaro KDE installiert. Nebenbei installiert sich gerade Rust. Der Compiler läuft also auf einem ARM. Was es anscheinend nicht gibt ist arm-none-eabi-gdb, aber es gibt ein arm-none-eabi-bin. Das lässt sich nur leider nicht compilieren. Mal schauen, wie weit ich damit komme. Wer von euch hat sich erfolgreich mit Rust auf Mikrocontrollern befasst und mehr als nur ein Blinky Programm oder Hello World geschrieben? Gurß Markus
Moin, wir fangen in der Firma jetzt langsam an von C/C++ auf Rust umzustellen. Die Firmware wird komplett neugeschrieben in Rust. Wir nutzen hauptsaechlich ARM Cortex-M4 als Platform. Der generierte Code ist etwas groesser und langsamer, als das original in C/C++, aber das ist wohl hauptsaechlich dem Umstand geschuldet, das LLVM nicht so guten Code fuer Bare-Metal Targets erzeugt. In ersten Versuchen ist der Code ca. 10% groesser und ca. 3% langsamer, bei selber Optimierungsstufe (-Os). Fuer mich vertretbar, dafuer das die Sprache vor einem ganzen haufen Fehler schuetzt. Momentan werden einzelne Teile der Firmware rausgezogen, als Lib in Rust neugeschrieben, und dann in das C-Projekt gelinkt. So wird das Stueck fuer Stueck ersetzt. Gleichzeitig nutzen wir die Unit- und Integrationtests von Rust, um die Software auf dem PC zu testen. Bis jetzt sind meine Erfahrungen in allem sehr positiv. Mit Sealed Rust gibt es auch ein Projekt/eine Firma, die sich mit dem Einsatz von Rust in Bereichen wie Automotiv auseinandersetzt. https://ferrous-systems.com/blog/sealed-rust-the-pitch/ https://ferrous-systems.com/blog/sealed-rust-the-plan/ Gruesse
:
Bearbeitet durch User
Oha, gleich die komplette Firmware umstellen. Wäre bei uns undenkbar. Was einmal läuft wird nicht mehr angefasst. Was Versprecher ihr euch von der Umstellung? Mich überrascht dann doch etwas, dass die gleichen aprogramme dann doch merklich größer und auch noch langsamer sind
Markus B. schrieb: > Mich überrascht dann doch etwas, dass die gleichen aprogramme dann doch > merklich größer und auch noch langsamer sind Nicht wirklich, da anderer Compiler und andere Sprache. C/C++ wird mit GCC uebersetzt, Rust mit LLVM. Und es finden sich einige Vergleiche im Netz, die Zeigen, das LLVM eben nicht so guten Code fuer ARM erzeugt wie GCC, bei selbem C/C++ Code. Markus B. schrieb: > Was Versprecher ihr euch von der Umstellung? Ein deutliches Mehr an Sicherheit, Stabilitaet und Portierbarkeit.
Denke nicht, dass die Sprache so viel ausmacht. Dürfte eher am Compiler liegen. 10% größerer Code kann bei kleineren Controllern allerdings schon ein Problem sein.
Markus B. schrieb: > Ich hab schon vor einer Weile angefangen, mich in Rust einzuarbeiten, > bin aber aus Zeitgründen noch nicht so weit wie ich gern wäre. Das ging bzw. geht mir genauso. Eine Kurzrefferenz über die ich dieser Tage gestolpert bin ist https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/ Naja, 30 Minuten um Rust zu "lernen" halte ich zwar für völlig illusorisch aber als "Kurzrefferenz" finde ich es sehr gut, da quasi alle Bestandteile der Sprache kurz und knapp aber dennoch umfassend erläutert werden. Was den Einsatz von Rust im Embedded-Umfeld angeht, habe ich die Erfahrung gemacht, dass Cortex-M0(+) eher suboptimal ist (ARM-v6M hat z.B. keine CAS-Instruktion, d.h. kein "compare and swap". Hier würde ich also eher zu einem M4 raten. Da die ganzen std-Konstrukte wie vec! nicht auf einem no_std-System funktionieren empfehle ich hier an der Stelle mal den Crate "heapless": https://docs.rs/heapless/0.5.3/heapless/ Dort findet man String oder Vec mit fester Kapazität oder auch einen Ringbuffer (aka mpmc-queue bzw. spsc-queue). PS: Der heapless-crate stammt unter anderem vom selben Autor wie das "Rust Embedded"-Buch (d.h. von Jorge Aparicio). Seinen Blog finde ich ebenfalls sehr interessant: http://blog.japaric.io Viel Erfolg
:
Bearbeitet durch User
Learn Rust With Entirely Too Many Linked Lists https://rust-unofficial.github.io/too-many-lists/index.html#learn-rust-with-entirely-too-many-linked-lists
Kaj G. schrieb: > Learn Rust With Entirely Too Many Linked Lists > https://rust-unofficial.github.io/too-many-lists/index.html#learn-rust-with-entirely-too-many-linked-lists Das kannte ich sogar schon. Trotzdem danke. Scheint nicht viele zu geben, die Rust ernsthaft verwenden
Markus B. schrieb: > Scheint nicht viele zu geben, die Rust ernsthaft verwenden Programmiersprache: Microsoft erwägt Einsatz von Rust https://www.heise.de/developer/meldung/Programmiersprache-Microsoft-erwaegt-Einsatz-von-Rust-4475270.html https://en.wikipedia.org/wiki/Rust_(programming_language)#Projects https://www.rust-lang.org/production/users
Hier noch ein paar Links zum lesen: Writing an OS in Rust https://os.phil-opp.com/ Rust OSDev https://github.com/rust-osdev awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust Raspberry Pi Bare Metal Programming with Rust https://words.thiago.me/raspberry-pi-bare-metal-programming-with-rust/ intermezzOS https://intermezzos.github.io/ Operating System development tutorials in Rust on the Raspberry Pi https://github.com/rust-embedded/rust-raspi3-OS-tutorials
Ich bezog das mehr auf das Forum hier und die Verwendung mit Mikrocontroller. Microsoft erwägt im übrigen, eine eigene Programmiersprache ähnlich zu Rust zu entwickeln. Ob das so kommt sei Mal dahin gestellt
Kaj G. schrieb: > Der generierte Code ist etwas groesser und langsamer, als das original > in C/C++, aber das ist wohl hauptsaechlich dem Umstand geschuldet, das > LLVM nicht so guten Code fuer Bare-Metal Targets erzeugt. Hm, naja. So direkt würd ich das nicht unterschreiben. Hier meine Benchmarks GCC vs. Clang auf einem Cortex-M4 (~1 Jahr alt): https://gitlab.com/higaski/GccVsClang_uC Markus B. schrieb: > Ich bezog das mehr auf das Forum hier und die Verwendung mit > Mikrocontroller. > > Microsoft erwägt im übrigen, eine eigene Programmiersprache ähnlich zu > Rust zu entwickeln. Ob das so kommt sei Mal dahin gestellt Hier ein "Blabla" Talk dazu. Man will wohl eher die Borrow-Checker Idee weiter ausbaun. https://vimeo.com/376180843 Ich persönlich würde gerne Rust einsetzen aber meine Kollegen sind leider alle extrem konservativ. Wenn ich es denn mal einsetzen werde, dann wirds wohl eher im privaten Bereich sein...
> Ich bezog das mehr auf das Forum hier und die Verwendung mit > Mikrocontroller. Was erwartest du? Ich erwaege auch hin und wieder mal etwas anderes wie C zu verwenden und ich programmiere das allermeiste selbst. Trotzdem laesst man es dann doch solange der Leidensdruck nicht groesser ist. Die meisten hier kopieren von anderen oder verwenden die Libaries ihrer Prozessorhersteller. Da ist dann alles ausser C draussen. Und auch ich schaetze es wenn ich bei einem neuen Projekt vieles was ich mal selber geschrieben habe da einfach so reinkopieren kann. Sozusagen ein klassisches Henne-Ei Problem. Olaf
Wo ist nur der Spieltrieb geblieben? Und die Neugier? Ich werde mir ein Board mit STM32 besorgen und erstmal ganz normal mit C/c++ programmieren, aber parallel dazu werde ich mit Rust experimentieren
Markus B. schrieb: > Wo ist nur der Spieltrieb geblieben? Und die Neugier? Bei den Firmen im Insolvenzverzeichnis. Privat gebe ich Dir natürlich recht.
Ich koennte mir vorstellen das sich etwas aendert sobald mal kleine billige Mikrocontroller die Regel oder zumindest gaengig werden die mehr wie einen Kern haben. Dann haette man naemlich gerne eine Sprache die es erlaubt einzelne Funktionen mit voreingestellten Prioritaeten zu versehen und das als Teil der Sprache und nicht irgendwie druebergestuelpt. Olaf
Hab gerade nach einem dual core gesucht und den gefunden https://www.st.com/en/microcontrollers-microprocessors/stm32wb55cg.html Ist zumindest ein Anfang
Olaf schrieb: > Die meisten hier kopieren von anderen oder verwenden die Libaries ihrer > Prozessorhersteller. Da ist dann alles ausser C draussen. Und auch ich > schaetze es wenn ich bei einem neuen Projekt vieles was ich mal selber > geschrieben habe da einfach so reinkopieren kann. > Sozusagen ein klassisches Henne-Ei Problem. Naja, das Problem umschifft Rust halt, indem du C/C++ und Rust einfach zusammenlinken kannst. Du kannst also zu existierendem Code leicht was in Rust dazu bauen, oder, wie oben jemand geschrieben hat, eine bestehende Codebasis Stück für Stück umbauen. Aber generell ist natürlich das ganze Tooling natürlich oft sehr stark auf C/C++ ausgerichtet, bei manchen Herstellern kannst du ja schon froh sein, wenn die IDE out of the Box einen halbwegs aktuellen C++-Standard unterstützt...
Vor einigen Monaten habe ich mir mal die "Internet-of-Streams" Serie von James Munns angeschaut. Dabei wird ein komplettes Projekt step-by-step auf einem nRF52 implementiert (allerdings ohne BLE, da der erste BLE Stack (https://github.com/jonas-schievink/rubble) noch in einem alpha-beta stadium steckt): https://www.youtube.com/watch?v=S0VI70nY6Vo&list=PLX44HkctSkTewrL9frlUz0yeKLKecebT1 James Munns ist, wie auch Jorge Aparicio, teil der Embedded Working Group von Rust.
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.