ProHoster > Blog > Nachrichten aus dem Internet > Veröffentlichung von Rust 1.96. Bewertung der Eignung von Rust zur Erstellung von Firmware für Mikrocontroller.

Veröffentlichung von Rust 1.96. Bewertung der Eignung von Rust zur Erstellung von Firmware für Mikrocontroller.

Die Version 1.96 der Programmiersprache Rust wurde veröffentlicht, die ursprünglich von Mozilla entwickelt wurde, aber mittlerweile unter der Schirmherrschaft der unabhängigen Non-Profit-Organisation Rust Foundation weiterentwickelt wird. Die Sprache konzentriert sich auf sicheren Umgang mit Speicher und bietet Mittel zur Erreichung hohen Parallelismus bei der Ausführung von Aufgaben, ohne einen Garbage Collector oder eine Runtime (Runtime beschränkt sich auf die grundlegende Initialisierung und Wartung der Standardbibliothek) zu verwenden.

Die Methoden zur Arbeit mit Speicher in Rust zielen darauf ab, Fehler beim Umgang mit Zeigern zu vermeiden und Probleme zu verhindern, die durch die Low-Level-Arbeit mit Speicher entstehen, wie den Zugriff auf freigegebenen Speicher, Dereferenzierung nuller Zeiger, Pufferüberläufe usw. Zur Verbreitung von Bibliotheken, zur Sicherstellung der Kompilierung und zum Management von Abhängigkeiten wird der Paketmanager Cargo weiterentwickelt. Für die Bereitstellung von Bibliotheken wird das Repository crates.io unterstützt.

Sichere Speicherverwaltung wird in Rust während der Kompilierung durch Überprüfung von Referenzen, Nachverfolgung des Eigentums an Objekten, Berücksichtigung der Lebensdauer von Objekten (Sichtbarkeitsbereiche) und Bewertung der Korrektheit des Zugriffs auf den Speicher während der Ausführung des Codes gewährleistet. Rust bietet ebenfalls Mittel zum Schutz vor Überläufen bei Ganzzahlen, fordert die zwingende Initialisierung von Variablenwerten vor deren Verwendung und behandelt Fehler in der Standardbibliothek besser. Außerdem wird das Konzept der Unveränderlichkeit (immutable) von Referenzen und Variablen standardmäßig angewendet, und es bietet eine starke statische Typisierung zur Minimierung logischer Fehler.

Hauptneuheiten:

  • Das Modul range wurde hinzugefügt, das neue Typen implementiert, die als Ersatz für die veralteten Typen Range, RangeInclusive, RangeToInclusive und RangeFrom entwickelt wurden und es ermöglichen, Bereiche in Copy-Strukturen zu speichern. Der Typ Range definiert Bereiche, die durch einen minimalen und maximalen zulässigen Wert begrenzt sind (aber nicht diesen einschließen), der Typ RangeFrom definiert Zahlen, die mit einem angegebenen Wert beginnen, und der Typ RangeInclusive umfasst die Werte des angegebenen Bereichs, einschließlich beider Grenzen. In zukünftigen Versionen werden Typen wie RangeFull und RangeTo hinzukommen, die alte Implementierung wird in core::range::legacy::* übertragen und die Syntax „N..M“ wird auf die neue Typenvariante umgestellt.

    Die neuen Typen zeichnen sich dadurch aus, dass sie anstelle des Traits Iterator den Trait IntoIterator implementieren, d. h. sie definieren, wie der Typ in einen Iterator umgewandelt wird, anstelle einen eingebauten Iterator zu verwenden. Dieser Ansatz ermöglicht die Verwendung der Kopieroperation (Trait Copy, der angibt, dass Werte des Typs durch einfaches Kopieren dupliziert werden können), die zuvor aufgrund der Inkompatibilität mit Typen mit eingebauten Iteratoren nicht verfügbar war.
    Zum Beispiel ermöglichen es die neuen Typen, die Grenzen eines Slice in einer Struktur zu speichern, die vollständig kopiert wird, ohne die Anfangs- und Endwerte separat zu speichern:

    use core::range::Range;

    #[derive(Clone, Copy)]
    pub struct Span(Range);

    impl Span {
    pub fn of(self, s: &str) -> &str {
    &s[self.0]
    }
    }

  • Es wurden die Makros „assert_matches!“ und „debug_assert_matches!“ hinzugefügt, die überprüfen, ob der Wert dem angegebenen Muster entspricht, und die Ausführung im Falle einer Abweichung abbrechen. Im Gegensatz zu den Ausdrücken „assert!(matches!(..))“ und „debug_assert!(matches!(..))“ geben die neuen Makros Debug-Informationen über die Werte aus, die den Fehler verursacht haben. Um Überschneidungen mit Drittanbieter-Makros zu vermeiden, die unter ähnlichen Namen geliefert werden, erfordern die neuen Makros einen expliziten Import der Bibliothek „core::assert_matches“.

    use core::assert_matches;

    fn get_random_number() -> u32 {
    4
    }

    fn main() {
    assert_matches!(get_random_number(), 1..=6);
    }

  • Beim Erstellen für die Zielplattform WebAssembly wurde die Übergabe der Option „—allow-undefined“ an den Linker eingestellt, die das Binden bei Vorhandensein undefinierter Symbole erlaubte, die in den Import aus dem Modul „env“ umgewandelt wurden. Beim Erstellen für WebAssembly müssen nun alle mit dem Linken verbundenen Symbole standardmäßig definiert sein. Um das frühere Verhalten wiederherzustellen, kann die Umgebungsvariable „RUSTFLAGS=-Clink-arg=—allow-undefined“ oder der Ausdruck ‘#[link(wasm_import_module = „env“)]’ im Code verwendet werden.
  • Eine neue Charge von APIs wurde in den stabilen Bereich überführt, darunter wurden Methoden und Implementierungen von Traits stabilisiert:
    • assert_matches!
    • debug_assert_matches!
    • From für AssertUnwindSafe
    • From für LazyCell
    • From für LazyLock
    • core::range::RangeToInclusive
    • core::range::RangeToInclusiveIter
    • core::range::RangeFrom
    • core::range::RangeFromIter
    • core::range::Range
    • core::range::RangeIter
  • Im Paketmanager Cargo wurde die Schwachstelle CVE-2026-5223 behoben, die zur Überschreibung des Quellcodes eines anderen crate-Pakets im lokalen Paket-Cache aus demselben Repository über Manipulationen mit symbolischen Links innerhalb des crate-Pakets verwendet werden kann. Diese Schwachstelle tritt nur bei der Arbeit mit Drittanbieter-Paket-Repositories auf und betrifft nicht die Benutzer des repositories crates.io, da das Hochladen von Paketen mit symbolischen Links auf crates.io verboten ist.

Zusätzlich kann die Veröffentlichung der Ergebnisse einer Analyse der Eignung der Programmiersprache Rust für die Entwicklung von Firmware für Mikrocontroller und eingebettete Systeme mit begrenzten Ressourcen erwähnt werden (PDF).
Die Untersuchung wurde von STMicroelectronics in Zusammenarbeit mit mehreren europäischen Universitäten durchgeführt. Zwei isolierten Entwicklerteams wurde die Aufgabe gestellt, dieselbe Firmware für die Mikrocontroller STM32U585AI mit einem Arm Cortex-M33-Kern zu implementieren. Das erste Team entwickelte die Firmware in C, das zweite in Rust.

Die Tests der durchgeführten Arbeiten zeigten keine signifikanten Vorteile bei der Verwendung der Programmiersprache C im Vergleich zu Rust bei der Entwicklung von Firmware für Mikrocontroller hinsichtlich Speicherverbrauch und Leistung. Darüber hinaus ermöglichte der Einsatz der auf Rust geschriebenen System-Runtime aus dem Open-Source-Projekt Ariel OS, einen niedrigeren Speicherverbrauch im Rust-Projekt zu erzielen als in der C-Implementierung, die auf dem traditionellen Stack für die Entwicklung von Firmware auf Basis der Bibliothek newlib basiert.

Die Größe des resultierenden Firmware-Binarys betrug 84100 Byte im Rust-Projekt und 76744 Byte im C-Projekt (10 % weniger), jedoch war der Speicherverbrauch in der Firmware auf Rust deutlich niedriger — 24640 Byte im Vergleich zu 42608 Byte. Was die Leistung betrifft, so übertraf die Implementierung in Rust bei den Tests der ersten Prototypen, die in 6 Wochen entwickelt wurden, die Implementierung in C um das Doppelte, aber beide Implementierungen blieben deutlich hinter der berechneten maximalen Leistung zurück. Nach 4 Wochen, die für die Optimierung aufgewendet wurden, erzielten beide Implementierungen ungefähr dasselbe Ergebnis, das nahe am berechneten Maximum lag.



Quelle: opennet.ru
60GB SSD 8Gb DDR4