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

[gunzelg]

Hallo
bei mir gibts nur das RP6-Fahrwerk, die Elektronik ist selbst gebaut, basiert auf einem PIC (dsPIC30F4013), programmiert wird in klassischem C, so neumodisches Zeug wie Rost, sorry Rust, kenn ich nur vom Hörensagen..

Gruß
Gerhard

[fabqu]

Oje, dann kommst du ja gar nicht in den Genuss dieser schönen Hardware/Elektronik des RP6 samt seinen guten C-Bibliotheken! Schade
Ich kaufe gerade auch noch einige RP6 auf Ebay etc, ich würde die gerne mit dem ESP32 fit machen für Programmierkurse für Kinder/Jugendliche. Also: es gibt noch welche

[gunzelg]

Ja, als Elektroniker war das eigentlich auch mein Ziel, Hardware und Software alles selber zu bauen, auch für den Preis, dass ich da nur ne Lochrasterplatine habe und auch nicht soviel Features, wie da auf der Platine so drauf sind. Da ich aber öfter mal was mit PIC's mache, ist das nicht so dramatisch, auf unterster Ebene zu programmieren, also auch ohne Bibliotheken auskommen zu müssen. Oft haben die ja auch Einschränkungen in dem Sinne, dass die jetzt nicht genau das machen, was ich will. Aber dass du Kurse für Kids machst, finde ich toll. Des ESP32 kenn ich auch nicht. 32-Bit-Prozessor gegen meinen 16-Bitter, wobei ich meist eh nur die 8-Bitter von Microchip verwende. Das bisschen Bit-Schupserei braucht noch keinen 16-Bitter. Für den RP6 werd ich vielleicht ne neue Hardware bauen, und da dann nen anderen 16-Bitter von Microchip verwenden, nen PIC24. Aber auch nur aus Neugierde, und weniger weil es für den Roboter notwendig wäre...

Gruß
Gerhard

[Pr0gm4n]

Hey super, hier kommt ja richtig Bewegung in die Sache!
Die Idee den RP6 für Programmierkurse zu nutzen finde ich super! Ich fand eben C zu... schwierig? Klar, die RP6Lib nimmt einem schon einiges ab, aber wenn man dann doch mal schauen geht was die Library-Funktionen dahinter so machen bzw. wie die implementiert sind... dann findet man dort schon eher "kryptische" Funktionen. Aber klar, wenn man jemanden zur Seite hat der sich damit auskennt, kann man dann schon gut etwas basteln! Das ist auch eine Motivation für mich um das in Rust zu übertragen. Und eben einiges über Rust zu lernen.

LG Roland

[gunzelg]

Als 60+ Elektroniker frag ich mich jetzt, welche Bedeutung Rust hat? Bei meinem letzten Job vor der Rente waren in meinem Betrieb drei Programmiersprachen gefragt: C/C++, LabView und Phyton. Rust ist wohl was neueres, und wofür wird das verwendet? Im PC-Bereich oder auch/nur für uC?

Gruß
Gerhard

[Pr0gm4n]

Hallo Gerhard,

also prinzipiell ist Rust eine sehr moderne Sprache mit vielen High-Level Konstrukten und einem sehr fähigen Paketmanager (cargo) wie man sie aus Python/Java/Javascript kennt, aber gleichzeitig ist Rust hinsichtlich der Performanz vergleichbar mit C/C++. Da es eine kompilierte Sprache ist, braucht es für jegliche Plattformen einfach entsprechende Compiler. Der für AVRs ist als Standard bereits mitinstalliert.

Designt wurde Rust von Mozilla als moderne Sprache für System-Programmierung. Rust basiert auf 2-3 Grundprinzipien:
- einem starken Typsystem, und davon dass sie einen zwingt jegliche Fehler die auftreten könnten bereits im Code handzuhaben. Ein Programm läuft dafür oft direkt ohne jemals groß Probleme zu machen.
- dem Ownership-Prinzip. Zu jeder Variable (Memory-Adresse) darf es nur eine exklusive Referenz geben. Man kann von vielen Programmteilen (oder Threads) von einer Zelle lesen, solange der Compiler garantieren kann dass während dieser Zeit kein Schreibvorgang stattfindet. Was erst mal kompliziert klingt, ist am Schluss beim Programmieren eigentlich recht logisch. Dadurch gibt es keine Memory-Leaks, aber der Compiler ist auch relativ strikt und es kann durchaus dauern bis man Code mal zum kompilieren bringt.
- Dokumentation ist integrierter Bestandteil des Paket- und Buildtools (cargo). Man hat also direkt hübsche (und einheitliche!) Doku für alle Pakete die man in seinem Projekt benutzt. Siehe auch: https://doc.rust-lang.org/std/macro.println.html als Beispiel.

Naja also zusammengefasst kann man sagen, die Zielgruppe ist jeglicher Code bei dem es auf Performance ankommt, aber auch dass der Code stabil läuft. Auf einem AVR wird man aber wohl kaum die Vielfalt an Features ausnutzen können. Ich denke aber dass die modernen Programmierkonzepte es erlauben, den Code übersichtlicher und langfristig wartbarer zu gestalten.


Als Beispiel für den Einsatzzweck von Rust könnte man das wohl prominenteste open-source Projekt anführen: den Linux-Kernel. Gerade vor ein paar Monaten wurde bekanntgegeben, dass in Zukunft mehr und mehr vom Linux Kernel in Rust implementiert werden soll. Macht aus meiner Sicht auch Sinn.


Hilft das soweit? Hier noch ein Link mit ein paar Beispielen zu ein paar Features von Rust.
https://learnxinyminutes.com/docs/rust/


LG Roland

[gunzelg]

Dank für die Einführung !

[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!