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

Hallo zusammen!

[off-topic]
Es ist nun knapp 12 Jahre her, dass ich hier im Roboternetz zuletzt aktiv war, und mangels besserer Ideen um Kontakt aufzunehmen – nun dieser Thread. Ganz schön lange Zeit! Ich hatte immer mit Wehmut daran gedacht, dass ich dieses Elektronik-Basteln nicht weiter verfolgt hab. Inzwischen hab ich mein Abi, sowie einen Bachelor & Master in Informatik gemacht, bin gerade gar sogar an der Promotion. Man könnte also meinen, inzwischen sollte ich genug technisches Verständnis mitbringen, um Projekte auch tatsächlich umsetzen zu können. An dieser Stelle nochmals vielen vielen Dank an all diejenigen, die mein jugendliches, neugieriges und unwissendes Ich hier vor so langer Zeit geduldig ertragen und mir stets mit Rat zur Seite gestanden haben! Zurück zum Thema...
[/off-topic]

Ich habe also am Wochenende mal in meiner alten Bastel-Kiste gestöbert und bin doch gleich beim Robby hängen geblieben. Da war mir schnell klar, der Robby soll wieder Leben eingehaucht bekommen! Also dann, wie ging das nochmal?

Erste Schritte waren (eigentlich) ganz machbar:

• Die neuste Software von der Webseite gezogen und die avr-gcc Toolchain für Linux aus den Distro-Packages installiert.
• Kompilieren der Examples funktioniert, sofern man die Makefiles leicht anpasst: 'RP6lib' sollte wohl 'RP6Lib' heißen und der neuere Kompiler möchte gern das '-fcommon' Flag gesetzt haben damit er die Dateien linken will.
• Der Robotloader erkennt unter Linux (Fedora 37) sofort den USB-Comport und läuft mit openjdk 17.0.5 bislang problemlos. Die LEDs blinken!

Wohin also nun? Erste Ideen gibt es schon:

• Ich habe inzwischen einen Co-Bastler gefunden, der auch Interesse hat den Robby zu reaktivieren. Leider hat er noch keine Kenntnisse beim Programmieren, dafür kann er Löten und versteht was von Mechanik und normalen elektronischen Schaltungen. Falls jemand für ihn noch einen zweiten Robby (egal ob erste oder zweite Version) rumstehen hätte den er uns gegen ein paar Bier anbieten möchte, dürft ihr Euch natürlich gerne melden.
• Ich arbeite derzeit beruflich mit rust, und da gibt es ja auch ein vielversprechend aussehendes Hardware-Abstraktionslayer das unseren Atmega32 unterstützt. Mal sehen ob ich das hinkriege, wäre mein erstes Embedded-Projekt mit rust. Eventuell jemand Lust sich für eine Portierung der RP6Lib zusammenzutun?
• Fürs erste würden wir wohl gerne eine Schaufel o.Ä. an den Robby basteln, die dann per Servo abkippen und ein wenig "autonom" herumfahren. Ich denke dann fallen uns eh 1000 neue weitere Dinge ein.

Was machen Eure Robbies denn so inzwischen?


LG Roland

Heut Abend ging es also hoch motiviert ans Werk – mit Erfolg. Nach etwas Kampf mit den verschiedenen mäßig dokumentierten Ressourcen zu Rust Programmierung für AVR Targets läuft es nun also. Alles bisher einfach noch so "zusammengehackt", aber das kann man sicher noch aufräumen. Die Verwendung von Raw-Pointern erfordert in Rust das "unsafe" Keyword und hebelt die Spracheigenen Checks daher an manchen Stellen aus. Das wird sich für den Hardware-Zugriff wohl nicht umgehen lassen, jedoch großteils in Libraries verschieben lassen. Der Code den man als Entwickler dann schlussendlich schreibt, kann sich meiner Meinung nach schon sehen lassen:

Code:

---

#![no_std]
#![no_main]

use rp6::*;

/// entry point for the embedded rust program
#[no_mangle]
pub extern "C" fn main() {
    RobotBase::init();
    UART::write_str("Hello world!\n");

    let init_leds: u8 = 0b001001;
    let mut running_light: u8 = init_leds;
    loop {
        // set LEDs according to the binary number `running_light`
        RobotBase::set_leds(running_light);

        // sleep for one second
        delay_ms(250);

        // shift to the left for the 'running' effect
        running_light <<= 1;

        // reset to the initial LED pattern after the last LED was lit
        if running_light > 0b111111 {
            running_light = init_leds;
        }
    }
}

---

Für mehr Details hab ich das Projekt schon mal auf Github gepackt. Ich werde sicherlich in den nächsten Tagen noch eine Beschreibung basteln, was man für den Build alles für Dependencies hat. Falls es jemand nicht erwarten kann, schaut mal nach "rustup override set nightly" (verwenden alle Rust AVR Projekte) und verwendet das Makefile im Repository. Was sind denn so generell die Meinungen vom ersten Eindruck? Könnte sich jemand vorstellen, dass Rust auch hier im (Hobby-)Embedded-Bereich eine Rolle spielen könnte? Mir gefällt, dass es eine wirklich moderne und mächtige Sprache ist, und ich freue mich insbesondere darauf ihre Pattern-Matching Features nutzen zu können. Das sorgt in der Regel für echt übersichtlichen Code, bei dem vor allem garantiert wird dass man keinen Fall vergessen hat. Mal sehen, wie gut sich das auf den Embedded-Bereich überträgt.

Nächste Schritte:
Man sieht vlt. im Github Repo schon in welche Richtung ich gerade tendiere. Das Modul "avr" ist aus dem ruduino Crate zusammenkopiert, da ich den leider nicht als Dependency zum laufen bekommen habe. Die Idee wäre jedenfalls, deren Traits für Register und Pins wiederzuverwenden, dann bräuchte ich selbst in der Library kaum mehr "unsafe" Code schreiben. Zusätzlich wollte ich mir gerne noch diese HAL anschauen. Mal sehen, ob er den Atmega32 richtig abbilden kann, dann käme das auch in Betracht.

So, es ist schon spät. Gute Nacht,
Roland

Hallo Roland
ich habe auch noch einen RP6. Allerdings wartet hier das Fahrgestell auf die Elektronik. Hatte damals -sicher vor mehr als 10 Jahren- mit nem RP5 angefangen, aber nur Fahrwerk, ohne die dazugehörige Elektronik - und diese Elektronik selbergebaut (Lochrasterplatine mit nem Microchip PIC). Dann das Interesse verloren und das Fahrgestell verkauft. Als ich dann in Rente ging (bin schon 60+) kam das Interesse wieder und hab mir nen RP6 gekauft. Möchte da aber wieder meine selbstgebaute Elektronik einbauen. Bin aber im Moment mit anderen Elektronik-Projekten beschäftigt. Aber irgendwann fang ich wieder mit dem RP6 an...

Gruß und weiter viel Spass
Gerhard (Raum München)

Hallo Gerhard,

Das klingt doch super! Ich hoffe auch, dass mein Interesse für die Bastelei noch viele Jahre bestehen bleibt und ich mir mit zunehmender Unsportlichkeit vielleicht ja auch immer mehr Zeit dafür nehmen kann... ;-)
Lass uns wissen wenn du dich wieder dran setzt, ich fand das immer ganz toll hier täglich Updates zu den verschiedenen Projekten der Leute zu lesen und aktiv mitzudiskutieren.

Grüße nach Unterschleissheim (hab auch mal in Garching gewohnt & studiert),
Roland

Also ich hab mich nun dafür entschieden, eine eher simple Hardware Abstraktion auf Basis des Crates 'avrd' selbst zu bauen. Die anderen sind zwar vielleicht genereller, aber haben so komplizierte Build Chains dass ich die Einfachheit des RP6 vermisse. Ich möchte das gerne "schrittweise begreifbar" haben, also erst mal verwenden und wenn man dann doch mal in die Funktionen schaut, sollen die auch nicht gerade über 10 Ecken laufen.

Prinzipiell, gibt es für das grundlegendste einfach die Funktionen:

Code:

---

port::c4::set_output();
port::c4::set_high();
port::c4::set_low();

---

Gibt's erste Meinungen hierzu? Ich glaube eine ähnliche Abstraktion mal beim Arduino-C gesehen zu haben... oder?

Ein Beispiel wie man mit dieser API dann die 'set_leds()' umsetzen könnte gibt's hier:
https://github.com/Pr0gm4n/rust-rp6l...1a5134edc189fe

Nun verwende ich also für Register und Pins als Basis mal die Traits 'Pin' und 'Register' vom 'ruduino' Projekt (vermutlich daher die Nähe zur Arduino Abstraktion...), auch wenn ich hier und dort noch etwas daran verändern möchte:
- Es würde eigentlich Sinn machen, wenn der Rust Compiler genutzt wird um zu überprüfen, dass man nur Pins auf high/low setzt, die in dem Moment auch als Output konfiguriert sind. Sollte eigentlich machbar sein.
- Ich werde wohl auch über eine Art 'Pingroup' nachdenken, die in der gleichen Port-Gruppe sind (also z.B. PB7, PB1 und PB0 für die LEDs 4-6). Mit dieser Pin-Abstraktion müsste man die sonst alle nacheinander setzen, muss ja eigentlich nicht sein. Und ich würde hoffen dass man dann solchen Code schreiben könnte:

Code:

---

use crate::ports::*;

pub fn set_leds(value: u8) {
    // set LEDs 1-3 connected on PORTC
    let pin_group = PinGroup([c6, c5, c4]);
    pin_group.set_outputs();
    pin_group.set(value);

    // set LEDs 4-6 connected on PORTB
    let pin_group = PinGroup([b0, b1, b7]);
    pin_group.set_outputs();
    pin_group.set(value >> 3);
}

---

Dabei müsste die 'set(...)' Funktion halt automatisch anhand der Anzahl vorhandener Pins maskieren, bzw. einfach die unteren x Bits verwenden.


Liebe Grüße,
Roland

Hallo
bei deinem Code-Beispiel fühl ich mich erst mal als Oldi, da ich ausser Assembler nur in C programmiere (n kann :-) ) Also das ist Rust?
Roboter Programmieren ist für mich auch nur sowas wie Bitschubserei, deine Funktionen sehen aber toll aus, mal sehen, ob ich sowas auch in c zustande bringe...

Gruß
gerhard

Hallo Gerhard,

also jetzt wo du es sagst – der 'rustonian way' das zu implementieren wäre eigentlich eine API in dieser Art:

Code:

---

use crate::ports::*;

pub fn set_leds(value: u8) {
    // set LEDs 1-3 connected on PORTC
    PinGroup([c6, c5, c4])
        .ensure_outputs()
        .set(value);

    // set LEDs 4-6 connected on PORTB
    PinGroup([b0, b1, b7])
        .ensure_outputs()
        .set(value >> 3);
}

---

Oder gar das 'ensure_output()' in der '.set(...)' Funktion handhaben... aber da bin ich mir dann nicht sicher ob das nicht "unnötig Zyklen verschwendet"? Was meint Ihr dazu? Sollte so eine API lieber priorisieren dass der Pin auf jeden Fall als Output gesetzt ist und dazu das DDR Register jedes mal überschreiben? (So hat das jedenfalls die RP6Lib implementiert bei den LEDs.)

Und wenn man dann schon dabei ist, könnte man die LEDs die an verschiedenen PORTs angehängt sind ja auch gleich noch als 'MixedPinGroup' Typ implementieren..., dann bekäme man direkt eine Funktion '.set(...)' die dann die 6 verschiedenen Bits richtig ansteuert. Also (ein etwas vollständigeres Beispiel):

Code:

---

use crate::ports::*;

pub struct RobotBase {
    LEDS: MixedPinGroup;
}

impl RobotBase {
    const LEDS = MixedPinGroup([b0, b1, b7, c6, c5, c4]);
}

---

Und in der main dann:

Code:

---

use rp6::*;

pub extern "C" fn main() {
    RobotBase::init();

    loop {
        RobotBase::LEDS.set(0b111111);
        delay_ms(1000);
        RobotBase::LEDS.set(0b000000);
        delay_ms(1000);
    }
}

---

Möglichkeiten über Möglichkeiten... was meint Ihr? ;-)

Grüße,
Roland

Hallo zusammen!

Nach einigem Rumprobieren und Ausloten was denn nun möglich ist, und was nicht, habe ich nun also ein solches Makro hinbekommen:

Code:

---

    /// Set the LEDs on the `RobotBase` to the least significant 6 bits of the provided value
    pub fn set_leds(value: u8) {
        // set LEDs SL1-SL3
        set_pins!([c6, c5, c4], value);
        // set LEDs SL4-SL6
        set_pins!([b0, b1, b7], value >> 3);
    }

---

https://github.com/Pr0gm4n/rust-rp6l...t_base.rs#L132

Das mit den LEDs über mehrere Register hinweg hab ich mir dann nochmal überlegt und befunden, dass mir dazu gar nicht so viele Anwendungsfälle einfallen. Naja, das schöne an der Lösung mit dem Makro ist jedenfalls, dass das alles bereits zur Compile-Zeit übersetzt und entsprechend vom Compiler optimiert werden kann. Ich denke damit bin ich jetzt einfach mal zufrieden.

Den Rest vom heutigen Nachmittag wollte ich gern damit verbringen, mehr von der RP6 Library zu portieren um so weitere Features "freizuschalten".

Grüße aus dem verregneten Zürich,
Roland

Hallo zusammen,

mal wieder ein kleines Update von mir! Ich lerne bei dem Projekt doch auch einiges über die low-level Features von Rust – ganz anders als in der Arbeit wo es eher um parallele Datenstrukturen und Skalierbarkeit geht. Wirklich spannend, aber ich möchte mir auch die Zeit nehmen die Dinge richtig zu implementieren!

Ich habe nun schon mal die UART Schnittstelle angebunden, zumindest schreibend. Ein paar Dinge habe ich dabei zum Beispiel gelernt:
- Es wäre ja zu schade das Rust-Typensystem nicht vernünftig zu nutzen. Ich musste etwas rumprobieren, aber nun gibt es eine vernünftige API die etwa so benutzt werden kann:

Code:

---


Serial::write("Hier kann man einfach irgendetwas übergeben.");
Serial::write('E');
Serial::write('i');
Serial::write('n');
Serial::write('e');
Serial::write("Zahl: ");
Serial::write(1337);
Serial::write(" oder was auch immer das den Trait `SerialWritable` implementiert.");
Serial::new_line();

// Alternativ gibt es auch ein Macro für Convenience. Bei Zeiten möchte ich mir auch
// mal proc_macros ansehen und damit ein schöneres `format!` Macro bauen.
println!("Counter: ", counter, " (DEC) | ", counter => hex, "(HEX)");

---

- Rust's eingebaute Formatter sind wahre Monster (zumindest für den Embedded-Einsatz): https://jamesmunns.com/blog/fmt-unreasonably-expensive/
- Ich habe also auf `ufmt` umgestellt – das kann leider nur Formatierung als Dezimal- und Hexadezimal Werte, da bin ich also mit einem Pull Request dran das hoffentlich mittelfristig zu ändern: https://github.com/japaric/ufmt/pull/54

Demnächst steht dann an, sich damit auseinanderzusetzen wie ich die Hardware-Interrupts in Rust verarbeiten kann, um auch vernünftige Receive-Funktionen bauen zu können. Mal sehen wann ich wieder Zeit finde :-)


LG Roland

- - - Aktualisiert - - -

Ach ja, ich denke ich hatte noch gar nichts über die Fortschritte bei der sonstigen Library geredet. Es gibt jedenfalls nun eine Hardware-Abstraktion für alle Pins, basierend auf dem `avrd` crate (auch wenn der Bitmasken leider seltsam definiert...: https://github.com/avr-rust/avrd/issues/22)
https://github.com/Pr0gm4n/rust-rp6l...t_base/port.rs

Und damit sieht die Implementierung von Basis-Funktionen meiner Meinung nach schon sehr lesbar aus:
https://github.com/Pr0gm4n/rust-rp6l...ase/mod.rs#L86

Was meint Ihr dazu? Ein paar Namen habe ich nach wie vor einfach aus der RP6Lib übernommen, da ich mich noch nicht mit den zugehörigen Pins beschäftigt habe.


LG und Gute Nacht,
Roland

Wow, gleich zwei Leute, die hier über den RP6 quatschen, da muss ich doch gleich mal mitschnuppern!
Schön, dass noch mehr Menschen den RP6 nicht weglegen, sondern wiederauferstehen lassen wollen. Danke euch! Ich würde noch ein zweites Thema aufmachen, RP6 und ESP32, da ich leider rust nicht kann, aber ich beteilige mich hier gern nach meinen Möglichkeiten.

Schöne Grüße in die (kleine) Runde!
- fabqu