Raspberry Pi Forums

Hi there,
it has been a while since I've been searching for answers, support and hints on this forum and all of you always had been a great help!
Now I thought it might be time to give something back to the community which could be helpful for others as well.
I've recently started learning Rust as programming language and kinda 'fell in love' with it. One of the strength from my point of view is module system which allows you to very easy hook different features into your environment by just referring to them in a dependency. However, here goes the announcment:

RusPiRo
The overarching goal is to build a Rust RaspberryPi Robotic system for a small roboter I have in my mind. The aim is to provide while building the project simple as self contained as possible building blocks (crates in Rust terms) for re-usability that allows others to mix-and-match the features they want to re-use and start building their own when needed.
The current target architecture of the project is Raspberry Pi 3(B+) in 32Bit bare metal.

When searching ruspiro on https://crates.io/crates you will already find a bunch of them and more will be coming. Even though the source code repoitories are linked in on the crates.io pages they also could be found on github https://github.com/RusPiRo. Each crites.io release will usually have a corresponding release in github.
For a quick start there is also a reference baremetal kernel implementation that showcases the usage of different crates/features and also provides a good entry point for anyone's Rust bare metal RPi project: https://github.com/RusPiRo/ruspiro-kernel/releases. One might want to start with the pre-relase v0.0.0 of the kernel and check out the upcoming releases how things are done the more crates are provided and evolve over time .

As my current build pipeline is running on a Windows 10 PC and cross compiling from there to ARMv8 some of the steps described in the README of the ruspiro-kernel github might differ on MacOS or other hosting systems.

The core/heart of any RusPiRo based kernel is the ruspiro-boot crate. This is the one that provides all the assembly sartup code to get the Raspberry Pi up and running, sets all the stack pointer, initializes MMU with a simple 1:1 memory map and kicks off all 4 cores. Each core is kicked off one after another and calls entry points that need to be provided by the kernel implementer. This crate also comes with the necessary linker script to successfully build/link all the stuff into a functional kernel binary ready to be deployed to the Raspberry Pi.
Using this crate as part of your kernel allows to immediately start in the Rust environment without the need to invent the startup assembly every time.

All the stuff is tested on a real Raspberry Pi 3B+ (no Qemu or the like).
As the Raspberry Pi 4 was released recently I also thought about support for this one as soon as more documentation is available and I do own one for testing

Have fun and thanks for reading...
Happy bare metal coding....

Wow, that sounds great.Well done.

I just started on Rust in the last week or so. Normally I'm very dismissive of YAFL, yet another fine language, we have so many popping up all the time and they don't generally offer much new conceptually. Rust on the other hand certainly does.With it's obsession with memory safety and program correctness but the small size and speed of C/C++ it is ideal for robust, secure IoT devices.

I'll certainly fire up RusPiRo.

Hey there,

thanks for the response and that you would like to give it a try
Even if most developer might feel bare metal means as much assembly as possible I'm more the one that believes that bare metal shall be possible with high level languages that provide development efficiency, convenient code patterns and some sort of built-in safety on compile time with at less run-time performance penalty as possible. And Rust for me is a good match there

Hope you have fun and success using RusPiRo

See you in the Rustiverse....

Schnoogle

Heater's not the only one watching this

Schnoogle,

I think you are on the right track. Because:

Before the new kids on the block started calling it "bare metal" this kind of thing was known as "embedded system" programming. Generally small systems without an operating system, or a home made OS or a very minimal OS.

When I first started doing this in 1980 it was often done entirely in assembler. That has not been the case for decades now. Even the smallest PIC and AVR micro-controllers are programmed mostly in C/C++, see Arduino. Modern 32 mit MCU's with bigger RAM and program store even more so. Heck, I have "bare-metal" MCU's here that are programmed in Javascript and Python (Espruino, MicroPython)

Those who are serious about program correctness and safety, in avionics etc, would use Ada. A strongly typed language with strict memory safety guarantees.

As such I think Rust is an idea candidate for such embedded/bare-metal systems. It offers a lot of what Ada does for correctness and safety and some new interesting things besides.

A good match as you say.

Already I know there is one company building all it's on board satellite software in Rust.

I think we need something better than the term baremetal.
Embedded seems a bit old considering what can be done now on Pi's.

There is a couple of interesting newer langauges that might be interesting to use. D, Rust, Go.
Pony I have compiled on Pi's and this week V got an editor that might port.

For Smart IIoT devices stronger languages are better, just from a development time frame.
It is the cost of the Zero that is the game changer, so much precessing power for a small price.
Once we get RISC-V SoC's in everything who has time to debug all that C code.
Linux is overkill but a good prototyping method, it's just not designed for IIoT.

Embedded Prolog?
Embeded High Level Languages, EHLLs?

Have a look at Gobot for a clue on the Go Lang for bots.
https://gobot.io/documentation/platforms/
This market is so new there is room for everyone and every langauge?
ROS sucks.

Gavinmc42,

I think we need something better than the term baremetal.
Embedded seems a bit old considering what can be done now on Pi's.

I think "bare-metal" and "embedded system" are describing two different, orthogonal, features of a system.

"Embedded system" generally refers to a computing device, inc. software, that is not generally seen as a computer. Being a computer is not it's primary purpose. For example the anti-lock brakes controller on your car or the thermostat in your house. They are computers embedded into some other device doing whatever function they do. Still a perfectly valid term.

Meanwhile "bare-metal" describes how the application software on such a device works. Does it have an OS? Or is it just a single program with all the hardware interfacing it needs built in. Did you have to write all that or did you put an OS or other run time between your code and the metal? Also a perfectly valid term.

So we could have a "bare metal" computer, for example all those early 8 bit machines and their BASIC, like the C64.

Or we could have embedded systems that are not bare metal, they may well use some small OS or even Linux.

Of all the new languages popping up all the time Rust is the first one to offer something both conceptually new and practical for decades, with it's emphasis on memory safety whilst at the same time building fast self contained binaries that need no run time underneath them like C.

Is this on Pi's yet?
https://www.redox-os.org/

Write RusPiRo on Redox on Pi's?

Hi there,

well to be honest I do not really care of the term The thing is just there is so many interpretations of both of them...
So "NOS" (No OS) or "WORT" (With Out RunTime) might be the closest from my point of view with less room of stretching into either direction .

Redox looks great, however the initial intention of RusPiRo is to provide building blocks, easy to consume to build a custom runtime/application may an OS on top of this. My current goal is to set a Raspberry Pi (currently 3 maybe 4 in the future) as the core/brain of a small robot and see how far I get with this approach and may be with the help or inspiration of the community it will lead to something more - who knows. May be if Redox is not yet on Pi it might use RusPiRo building blocks while porting

However, RusPiRo might just bring a quite young but promising high-level language into the "building my own software without OS but special purpose on Raspberry"-Community ... and let's see into which direction it may grow

NOSWORT, German for not working?

One of the things that make OS's an operating SYSTEM is some sort of scripting language.
Linux without shell script is just a kernel that does nothing apart from the low level stuff.
Things like Ultibo are compiled applications that don't change.

I went looking at scripting languages and found this.
http://runtimeterror.com/tech/lil/
Like Forth it can grow, but Forth is unreadable by mortals.

ROS, the Robot Operation System is huge, too big for me to grasp it all.
A language that is an Operating system that can grow and expand.
A bit like Oberon but for bots.

Rust is a good stat because things like Leaf are Rusty.
https://github.com/autumnai/leaf

Robots without AI are toys

https://bheisler.github.io/post/state-of-gpgpu-in-rust/
OpenCL is supposed to work on a Pi4.

I do a lot of GPU coding on Zero's using USB boot mode.
https://github.com/raspberrypi/usbboot
A Pi 4 has 4 USB ports, so 4 Pi Zero co-processors?
Realtime GPIO, OpenCV cameras etc and all upgrade-able.

Plus there are now lost cost FPGA's that can use opensource FPGA tools that run on Pi's.

It is a very interesting time for Robotics.
Looks like I need to install Rustc on Buster, was going to wait for USB boot and a 4B4.

Gavinmc42 wrote: ↑

Fri Aug 09, 2019 10:51 am

NOSWORT, German for not working?

nice try This has no meaning in German, but WORT is German for "word"

And fantastic to see an ML library in Rust that seem to be ready to be used in "no-os" environments as well....can't wait to reach the state of RusPiRo that it will make use of it ...

Schnoogle,

It's an excellent idea.

I have not had a chance to look into your repos yet but I was thinking....

I suspect that at least initially you will be building a Rust program, putting it on an SD card or USB stick and booting the Pi into it. Which might get a bit tedious after a while.

A next step might be to have that Rust "kernel" listen on the UART for an application program to download and run. Seems it's quite easy to load code bytes into an array and call some function within them in Rust. Just means playing with "unsafe" a bit.

But that is OK because the binary you are about to launch from the kernel will be a Rust binary, which is safe and you have tested on your PC first. Thus minimizing risk of failure.

To make a really safe IoT system, with updates over serial (or whatever) it would be really cool for the kernel to download not native ARM binaries but WASM binaries, which it could then execute in a safe WASM sand box with a WASM interpreter like nanowasm.

This could grow into an excellent, robust, safe, secure, Iot system.

Instead of "bare metal" or "embedded system" programming we should refer to it the Rust way:

no_std programming.

Heater wrote: ↑

Fri Aug 09, 2019 12:32 pm

I suspect that at least initially you will be building a Rust program, putting it on an SD card or USB stick and booting the Pi into it. Which might get a bit tedious after a while.

Hey, actually I’m running a small boot loader on my Pi that I’ve written way back in c to easily and convenient deploy new versions of the Rust kernel via Uart. So all testing of the code happens on real hardware

In addition I’ve also thought about a mechanism to allow “patching” or “feature adding” on the fly once the RusPiRo kernel has evolved enough and I appreciate your thoughts and inputs in this direction

For the time being it will be a single application/kernel build each time... may be I publish the boot loader as well, but it is rather dump and very simple... but good enough for a quite fast development and test cycle on the Pi itself...

Br,
Schnoogle

Heater wrote: ↑

Fri Aug 09, 2019 2:49 pm

Instead of "bare metal" or "embedded system" programming we should refer to it the Rust way:

no_std programming.

Also a really good catch will update the thread title

Oh what?

A boot loader in C is cool and all. But give that this is a Rusty project surely the first thing to do is recreate the boot loader in Rust?

The purpose of a thread title is to tell people what it is about.
I would guess that the majority of readers now have no idea what this thread is about "Announce: RusPiRo - [no_std] - the Rust way " is just typical of the rust developers penchants for "not invented here" and using new words for old concepts.

PeterO

PeterO,

I would guess that the majority of readers now have no idea what this thread is about "Announce: RusPiRo - [no_std] - the Rust way " is just typical of the rust developers penchants for "not invented here" and using new words for old concepts.

Oh for goodness sake. What a gross generalization. As if all the hundreds of Rust developers can be thrown into some arbitrary category you have invented for yourself. With nothing better to do than dream up weird ways to change things for no useful purpose other than to confuse you.

So they use "no_std" in their source code rather than "-nostdlib" on the GCC command line. Well guess what? It's not C. It's not C++. It's a totally different language. One should no more expect things in Rust to be the same in C in anymore than in Javascript, Java, C#, etc that have a superficial similarity of syntax.

Personally, I'm very happy to see the "not invented here" thing. Rust has a far richer semantics than C whilst avoiding the complexity of C++ and avoiding the undefined behaviors of both.

However, I think I agree, the thread title has become a bit confusing. "Announcing RusPiRo, a kernel in Rust" might be better.

Heater wrote: ↑

Fri Aug 09, 2019 6:09 pm

Oh what?

A boot loader in C is cool and all. But give that this is a Rusty project surely the first thing to do is recreate the boot loader in Rust?

well, sure you are right, but I did not re-write the bootloader first as I did know fur sure this one is working However, you are totally right in saying this, but in priority I thought it might be a bit behind the other rusty stuff

...ok...back the more "sophisticated" thread title
..thought it as a bit of fun to read it as [no_std] - gave it a bit of a "nerdy" touch ... however.... changed it again... that's the thing - nothing is written into stone and never fear refactoring

Nothing wrong with a little nerdy in joke.

All the opinions of die hard C/C++ programmers are NULL and void*

Heater wrote: ↑

Fri Aug 09, 2019 6:55 pm

PeterO,
Oh for goodness sake. What a gross generalization. As if all the hundreds of Rust developers can be thrown into some arbitrary category you have invented for yourself. With nothing better to do than dream up weird ways to change things for no useful purpose other than to confuse you.

It's a common human trait, it's called tribalism. It seems to be intended to make sure that only the cognoscenti can join in and sets a high barrier to entry into the tribe. It's nothing unique to computing.

However, I think I agree, the thread title has become a bit confusing. "Announcing RusPiRo, a kernel in Rust" might be better.

PeterO

Whatever.

All this idle talk of "not invented here" and "tribalism" contributes nothing to Schnoogle's project. It says nothing of the technical merits of Rust or it's practicality and usefulness for whatever purpose.

Rather it's just mudslinging at the now thousands of people who have contributed to the Rust project and it's eco system.

Your mud will not stick.

I am language agnostic these days, I will learn a new language if it works for what I want to do.
It is mostly about punctuation anyway.

Rust is in the top few on my list I made some time ago.
Plus it compiles fast, I like fast compilers.
It is language worth using and the more baremetal "kernels" we have for Pi, the less I need C
More interesting to me than fibonacci is how many of those languages can be used to make kernels.

This obsession with C/C++ smacks of religious fervour and yes goes back to tribalism.
"Burn the Haskell witch"? In place of Haskell insert your least favourite
For too long the world has been dominate by GNU/Linux, bring on the Reformation.

PS- have used C for bots for decades, it sucks nearly as bad as Python.
A change is as good as a holiday and I need a holiday from C.

Gavinmc42,

I am language agnostic these days, I will learn a new language if it works for what I want to do.

In my dotage I take a different view. Having had to learn more different languages than I can remember for various projects over the decades I decided a few years back that enough was enough. Endlessly learning a new syntax just to be able to do the same old, same old over again is a pointless waste of time. No more YAFL! Rather a language has to convince me it offers something new before I want to spend any time on it. In recent years that has meant I did get into Javascript for web stuff and because it offers many sophisticated language features compared to C or C++, then Verilog for getting on with my FPGA experiments, and now Rust because of it's sophisticated type checking and memory semantics whilst being usable in small systems like C/C++ is.

It is mostly about punctuation anyway.

That is my point. It should not be about the punctuation. That was certainly the case when I worked in C, PL/M, Coral, Ada even C++. All pretty much conceptually the same, just requiring a different syntax to get the job done.

It should be more than "punctuation" a language and it's compiler/interpreter are computer programs like any other. They should compute stuff. They have to do work for you. It's about what work do they do. What work do they save you having to do.

Examples:

You could program by poking binary or hex bytes into memory some how. That soon gets very tedious and error prone, figuring out what bits you need for all those instructions, calculating jump offsets etc, etc. Soon you find your yourself creating an assembly language and an assembler to do all that tedious work for you and get the calculations right.

So now you can program in assembler. Soon you find that endlessly constructing those sequences of instructions for loops or subroutine calls and parameter passing etc is very tedious and error prone. So you create a high level language like Fortran, Algol, C to do all the boring work for you, and get it right of course.

So now you can program in something C like. Soon you find that it's very tedious that your programs crash at random, have weird responses to odd input and are full of security vulnerabilities. Worse still it takes ages to debug this kind of thing. Wouldn't it be great if we could dream up a language that does all that error checking for you?

So you create a language that does that, perhaps Java, C#, Python, etc. Great. Now you can program and let the language detect and deal with all your silly mistakes.

But wait... In doing that you have introduced an interpreter and a garbage collector. Now your programs run 10 or a 100 times slower and have no timing determinism. Disaster!

Enter Rust... finally somebody has put together a language that compiles to small fast code like C but does all that extra work for you in checking for your silly mistakes. It's incredible that it has taken so many decades to get to this.

So, I claim it's not about the punctuation, it's about what the language does for you.

(Aside: Of course there was the amazingly strict Ada along the way. For whatever reason the world ignored it.)

(Other aside: C is of course brilliant. It does what it was designed to do very well. It was ground breaking at the time.)