Wiederauferstehung des RP6? -- Erste Erfahrungen und Aufruf zum Austausch!

[inka]

hallo in die runde!

habe bis jetzt nur mitgelesen, mein RP6 ruht seit jahren (2012?) unter einer "glasglocke", habe mich seitdem "nur" mit arduino und speziell mit ESP8266 und ESP32 beschäftigt. Finde es aber super, dass man hier versucht den RP6 wiederzubeleben....
Wieviel ähnlichkeit hat rust mit arduino c/c++ ?

so viel erstmal aus dem warmen und sonnigen süden, melde mich wieder wenn ich nicht nur mein smartphone zur verfügung hab

[Pr0gm4n]

Hallo Inka,

also generell hat Rust von der Syntax schon Ähnlichkeit mit C, aber durchaus auch seine Eigenheiten. Es gibt jedenfalls ebenfalls keine Objekte/Klassen, sondern man packt Daten eben in Structs und Enums. Dazu gibt es dann noch Traits und generische Parameter, die im Wesentlichen zur Abstraktion und Modularisierung dienen.

Meiner bisherigen Erfahrung nach spielt das bei der Interaktion mit einem Mikrocontroller allerdings eine eher nachrangige Rolle. Da geht es ja letztlich, wie Gerhard schon sagte, hauptsächlich ums "Bitschubsen". Ich nutze als Basis der Hardware-Abstraktion bei der Übersetzung der RP6Lib ein Github-Repo das für den Arduino designt war. Vermutlich kommt dadurch schnell das Gefühl auf, die Syntax wäre ähnlich zu Arduino C. Soll mir auch Recht sein, warum nicht. Letztlich möchte herausfinden wie man die RP6Lib so in Rust umsetzen kann, dass einem der Rust Compiler mit seinem starken Typensystem möglichst gut helfen kann, funktionierende Programme zu entwickeln.

Als Beispiel: In C wird meines Wissens nicht groß zwischen einem char, uint8_t oder einem Struct mit 8 single-bit unsigned unterschieden. Man macht im Zweifel einfach einen Cast, fertig. Wenn ich in Rust zwei Datentypen mit der gleichen Größe / Datenlayout anlege, dann muss man den Compiler schon explizit zwingen das einfach zu casten. Das gilt also auch, wenn man z.B. TXEN = 3 vom Typ "Index in Register UCSRB" hat, anders als eine "Bitmaske für Register UCSRB" (also TXEN = 1 << 3; oder TXEN = 0x8; ). Ausserdem könnte man direkt den Compiler vergleichen lassen, ob man die Bitmaske nun wirklich auf das richtige Register anwendet. Bevor man dort also (z.B. Copy&Paste-)Fehler fabriziert, würde man noch einige (durchaus sinnvolle!) Compiler-Rückmeldungen bekommen, die einem dann bewusst machen, dass man da gerade vermutlich was macht, was so gar nicht gedacht ist. Macht das Sinn?

Ob das am Ende wirklich jemandem nützt ausser mir, weil ich beim umschreiben der Library einiges lerne... das sehen wir dann!


LG Roland

- - - Aktualisiert - - -

Ein weiteres Beispiel sieht man vielleicht oben mit dem Makro:

set_pins!([Led3, Led2, Led1], value);

Ausgeschrieben generiert das (etwas bereinigt für Lesbarkeit) den Code:

let pin_mask = Led3::MASK | Led2::MASK | Led1::MASK;
Led3::DDR::set_mask_raw(pin_mask);
Led3::PORT::write(
    (Led3::PORT::read() & !pin_mask)
    | (((value >> 0) & 1) << Led1::OFFSET)
    | (((value >> 1) & 1) << Led2::OFFSET)
    | (((value >> 2) & 1) << Led3::OFFSET)
);

Also eine kleine Optimierung über eine Funktion, die jeden Pin einzeln setzt (z.B. Arduino-C meines Wissens), da sowohl DDR als auch PORT register nur einmal geschrieben werden. Der passende Code wird zur Compilezeit generiert, also ohne "schlecht wartbare" kopierte Aufrufe. Ich finde es ausserdem deutlich lesbarer als Funktion, als die originale Funktion in der RP6Lib, die die gleiche Optimierung macht. Zum Vergleich:

void updateStatusLEDs(void)
{
	DDRB &= ~0x83;
	PORTB &= ~0x83;
	if(statusLEDs.LED4){ DDRB |= SL4; PORTB |= SL4; }
	if(statusLEDs.LED5){ DDRB |= SL5; PORTB |= SL5; }
	if(statusLEDs.LED6){ DDRB |= SL6; PORTB |= SL6; }
	DDRC &= ~0x70;
	PORTC &= ~0x70;
	DDRC |= ((statusLEDs.byte << 4) & 0x70);
	PORTC |= ((statusLEDs.byte << 4) & 0x70);
}

void setLEDs(uint8_t leds)
{
	statusLEDs.byte = leds;
	updateStatusLEDs();
}

Die Umsetzung dieses Makros hat seine Tücken, z.B., dass nur Pins in der gleichen Portgruppe damit angesteuert werden können. Dazu passiert noch etwas mehr als ich oben geschrieben habe. Ich habe einen Typencheck eingebaut, um sicherzustellen dass Led3:: DDR und Led3::PORT auch wirklich die richtigen Register für alle Pins beinhaltet, aber das wird dann durch Code-Eliminierung vom Compiler gar nicht in das fertige Binary übersetzt. Die ganzen Checks finden also zur Compilezeit (!) statt und wirken sich nicht negativ auf das Laufzeitverhalten aus. Ein möglicher Fehler für den Nutzer sähe z.B. so aus:

error[E0308]: mismatched types
   --> src/avr/device/pin.rs:145:24
    |
144 |         let mut _typecheck = <$base_pin as Pin>::DDR::default();
    |                              ---------------------------------- expected due to this value
145 |         $(_typecheck = <$pin as Pin>::DDR::default();)*
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `DDRB`, found struct `DDRC`
    |
   ::: src/rp6/robot_base/mod.rs:129:9
    |
129 |         set_pins!([Led6, Led5, Led4, Led3, Led2, Led1], value);
    |         ------------------------------------------------------ in this macro invocation
    |
    = note: this error originates in the macro `set_pins` (in Nightly builds, run with -Z macro-backtrace for more info)

Das ganze wäre in Realität dann farbig unterlegt und, wenn man die Fehlermeldungen vom Rust Compiler etwas kennt sieht man schnell, dass er einem direkt markiert dass der Fehler die nicht übereinstimmenden DDR Register sind.


LG Roland

[Dirk]

Ja, Leute,
da lese ich doch auch mal interessiert mit!
inka, fabq: euch kenne ich ja noch aus unserer grauen Vergangenheit hier im Forum ...
Toll, was du Roland da auf die Beine stellst. Hut ab!

[Pr0gm4n]

Na Dirk, ich erinnere mich durchaus an deine vielen hilfreichen Beiträge. Aber ich scheine wohl (noch?) nicht genug vernünftiges beigetragen zu haben, um in Erinnerung zu bleiben. Nun ja, bitte keine vorschnellen Lorbeeren – ich versuche dran zu bleiben aber es ist noch ein weiter Weg.

PS: Bei einem "Dirk" aus NRW muss ich nun fragen... du bist nicht zufällig begeistertes Mitglied eines Modellfliegerclubs in der Eifel? Dann kenne ich dich nämlich inzwischen persönlich...

Grüsse aus Zürich,
Roland

[Dirk]

Hi Roland,
sorry, die Aufzählung von RP6-Aktivisten war nicht diskriminierend gemeint: du bist js auch schon ein "Oldie" hier, aber in meiner morschen Erinnerung von immerhin schon fast 19 Jahren früher eher allgemein so mit AVR und GCC unterwegs, und nicht speziell RP6, ... ???
Nein, zum Modellfliegerclub in der Eifel gehöre ich nicht, obwohl auch sehr reizvoll! Immerhin habe ich mal Schiffsmodellbau (z.B. den Hamburger Bugsier 3) gemacht.
Thema Rust: ist das eigentlich eine noch "erfolgreiche" Programmiersprache? Ich habe gelesen, dass sie in Form von Stiftungen finanziell am Leben gehalten wird. In welchen ausserakademischen Bereichen wird die denn angewendet?

[Pr0gm4n]

Hab sie auch nicht als diskriminierend aufgenommen. Schade dass du keine Modellfliegerei in der Eifel betreibst, aber dann kenne ich halt jetzt 2 Dirks in NRW.

Rust wird meines Wissens kommerziell bei Dropbox, Microsoft, Cloudflare, Facebook, ... produktiv eingesetzt. Ursprünglich getrieben und entwickelt von der Mozilla Foundation, also sogesehen von einer "Stiftung" wie du sagst. Empfinde ich hier aber eher von Vorteil, als wenn das jetzt eine einzige Firma prägend in der Hand hätte. Wie oben beschrieben, das prominenteste Open-Source Projekt ist meines Wissens der Linux Kernel, der nun nach und nach mehr Rust bekommen soll. Da Rust noch sehr jung ist, sehe ich die Sprache aber eher noch auf dem aufsteigenden Ast. Ein Beispiel von Features die ich so toll finde habe ich erst heute morgen wieder entdeckt: Eine Funktion kann als Rückgabetyp "endet nie" haben, dargestellt mit einem Ausrufezeichen "!".

Immerhin hab ich Neuigkeiten: ich hab die ersten Interrupts zum Laufen bekommen!

Der Code beim Anwender sieht dann etwa so aus:

#[interrupt]
fn INT0() {
    // do some stuff on hardware interrupt INT0
}

Natürlich muss man den Interrupt trotzdem erst mal aktivieren. Und ich muss noch ein bisschen rausbekommen wie man dann ordentlich zurückspringt und so... aber das kommt schon noch zusammen


LG Roland

[Pr0gm4n]

So Ihr Lieben, da bin ich wieder!

Inzwischen hab ich mich mit allen möglichen Arten von atomischen Operationen, Mutexen, und anderen Ideen, wie man möglichst statisch (= zur Compilezeit) absichern kann dass nichts schief geht, herumgeschlagen. Ich denke ich bin soweit ganz happy, aber was meint Ihr denn so?

Hier mal ein kleines Beispiel, das nun einen Ringbuffer für USART_RXC implementiert:

use rp6::{interrupt::mutex::Mutex, *};

// Shared data: While constants can be accessed safely (since they are never modified, it is
// recommended to wrap your mutable data in an `rp6::interrupt::Mutex`. Note that a `Mutex` can
// only be used inside a `CriticalSection`, e.g., by calling `interrupt::without_interrupts`.
const USART_BUFFER_SIZE: usize = 32;
static USART_BUFFER: Mutex<[u8; USART_BUFFER_SIZE]> = Mutex::new([' ' as u8; USART_BUFFER_SIZE]);
static USART_WRITE_PTR: Mutex<usize> = Mutex::new(0);

#[interrupt]
fn USART_RXC() {
    interrupt::without_interrupts(|cs| {
        let buffer = USART_BUFFER.lock(cs);
        let write_ptr = USART_WRITE_PTR.lock(cs);

        // save newly received byte to the ringbuffer
        buffer.update(|mut b| {
            b[write_ptr.get()] = Serial::read_raw();
            b
        });

        // increment USART write pointer and wrap around if necessary
        write_ptr.update(|x| if x + 1 < USART_BUFFER_SIZE { x + 1 } else { 0 });
    });
}

Eventuell besser zu lesen mit Code-Highlighting auf Github!

In Anlehnung an das RP6Example gibt das Programm (weiter unten in der main) dann einfach regelmässig einen hochzählenden Counter aus, sowie den aktuellen Inhalt des Ringbuffers.

Na, wie sieht das für Euch (noch-)nicht-Rustaceans aus?


LG und gute Nacht,
Roland