Forum: Compiler & IDEs Erfahrungen mit Rust für Mikrocontroller


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus B. (markus_b571)


Bewertung
3 lesenswert
nicht lesenswert
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

von Kaj G. (Firma: RUB) (bloody)


Bewertung
4 lesenswert
nicht lesenswert
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
von Markus B. (markus_b571)


Bewertung
0 lesenswert
nicht lesenswert
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

von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus B. (markus_b571)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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
von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht lesenswert

von Markus B. (markus_b571)


Bewertung
0 lesenswert
nicht lesenswert
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

von Kaj G. (Firma: RUB) (bloody)


Bewertung
0 lesenswert
nicht lesenswert

von Kaj G. (Firma: RUB) (bloody)


Bewertung
1 lesenswert
nicht lesenswert
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

von Markus B. (markus_b571)


Bewertung
0 lesenswert
nicht lesenswert
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

von Vincent H. (vinci)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Markus B. (markus_b571)


Bewertung
0 lesenswert
nicht lesenswert
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

von lalala (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus B. schrieb:
> Wo ist nur der Spieltrieb geblieben? Und die Neugier?

Bei den Firmen im Insolvenzverzeichnis. Privat gebe ich Dir natürlich 
recht.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Markus B. (markus_b571)


Bewertung
0 lesenswert
nicht lesenswert
Hab gerade nach einem dual core gesucht und den gefunden

https://www.st.com/en/microcontrollers-microprocessors/stm32wb55cg.html

Ist zumindest ein Anfang

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Thom Lab (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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):

Youtube-Video "Hello Blinky World!"

James Munns ist, wie auch Jorge Aparicio, teil der Embedded Working 
Group von Rust.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.