Raspberry Pi Bare Metal Programming with Rust • Hacker News Board

Re: Raspberry Pi Bare Metal Programming with Rust

#51

Post by roywiggins » Sun, Jan 17, 2016, 12:21 AM UTC

Aeolos wrote: post #17

asandweech wrote: post #10

Earlier quoted context omitted.

This might be of interest: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-...

Excellent, thanks! So GPIO performance won't be a problem, but they note that OS multitasking can cause issues: "What is not evident from the snapshots, however, is that due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc" Running on bare metal should take car…

You could probably use an Arduino for this, they connect to a computer using serial-over-USB.

You can do GPIO bit-twiddling pretty fast: http://skpang.co.uk/blog/archives/323

Re: Raspberry Pi Bare Metal Programming with Rust

#52

Post by akhilcacharya » Sun, Jan 17, 2016, 12:25 AM UTC

jeremyjh wrote: post #49

pjmlp wrote: post #43

Earlier quoted context omitted.

Still alive: Ada, SPARK, ATS, FreePascal, D Controversial: Go (if someone ports the runtime to bare metal), embedded JVMs, embedded, Swift (depending how Apple drives it), .NET Native (if C# gets missing features from System C#) Faded away: Algol, PL/I, CPL, Mesa, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Forth, Sing#, System C#

I think he was asking which languages could actually be used to do this today, without writing a new cross-compiler first.

That's exactly right. I didn't know that D would be an appropriate language for things like this - I'll have to check it out.

Re: Raspberry Pi Bare Metal Programming with Rust

#53

Post by rdc12 » Sun, Jan 17, 2016, 12:54 AM UTC

notabot wrote: post #38

As a C programmer who fiddles with low level stuff I wonder why people get exciting about such trivial thing. Don't get me wrong. Rust is an interesting language. The thing described in this post is well within its capability, i.e. IMO there isn't really anything that worths bragging about. Such trivial thing neither demonstrates the real potential of Rust, nor answers important questions from real world engineering…

Has hello world ever been exciting, it is only really a building point. You can't do anything intersting until you know the basics, of building and flashing the board.

The question is what does Rust have to offer as your embedded program grows.

Re: Raspberry Pi Bare Metal Programming with Rust

#54

Post by Narishma » Sun, Jan 17, 2016, 1:26 AM UTC

ajb wrote: post #30

Aeolos wrote: post #19

Earlier quoted context omitted.

O.o this $5 puppy could essentially replace the 1.5K National Instruments DAQ I'm using right now. Even better, I won't have to deal with their horrendous API documentation anymore. Of course that would require a Linux kernel, so not bare metal anymore, but there might be a way to make this work! Now I just need to get my hands on one, it's out of stock everywhere within a radius of 300km...

They haven't committed to making more, or if they do, to the $5 price point.

They are making more, but they sell them faster than they can make them.

Re: Raspberry Pi Bare Metal Programming with Rust

#55

Post by pdpi » Sun, Jan 17, 2016, 2:06 AM UTC

jacquesm wrote: post #11

akerro wrote: post #9

Is Rust the future? As a C++ (hobby), Java (full time) developer, should I invest my time in Rust?

Rust, Go, Java, Scala, Clojure, Javascript... (leaving out quite a few other choices for brevity). They say choice is a good thing but too much choice is actually really annoying and fragments the community across a very large number of ecosystems.

I see the point you're trying to make, yet:

- Nobody in their right mind would choose Rust or Javascript for a project where the other is more appropriate.

Though (AFAIK) Scala and Clojure both interop quite well with Java, and Scala/Clojure interop isn't terrible either, plus there's definitely a culture of reusing in Clojure/Scala all the stuff that the Java ecosystem already had. So this cluster isn't causing much fragmentation at all.

You have something of an argument that Go and the JVM languages clash for mindshare, but at that point the argument around really annoying fragmentation has kind of lost steam.

Re: Raspberry Pi Bare Metal Programming with Rust

#56

Post by dom96 » Sun, Jan 17, 2016, 2:16 AM UTC

pjmlp wrote: post #43

akhilcacharya wrote: post #39

Outside of C, are there any other languages or platforms that can do this? I'd like something modern, but I haven't liked what I've seen with Rust personally.

Still alive: Ada, SPARK, ATS, FreePascal, D Controversial: Go (if someone ports the runtime to bare metal), embedded JVMs, embedded, Swift (depending how Apple drives it), .NET Native (if C# gets missing features from System C#) Faded away: Algol, PL/I, CPL, Mesa, Modula-2, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Forth, Sing#, System C#

Don't forget to add Nim to that list! One of Nim's defining features (compilation to C) makes it work rather well for this sort of thing.

Re: Raspberry Pi Bare Metal Programming with Rust

#57

Post by pcwalton » Sun, Jan 17, 2016, 2:59 AM UTC

jcoffland wrote: post #28

As a long time C programmer this is not very convincing. A C program to do the same requires far less voodoo. All you need to do is take the address of the GPIO register then toggle the bit. No name mangling. No error handlers to override. Don't get me wrong I know rust does have some compelling features. It does seem odd to me that so many of what would be compiler options in C are hard coded.

Point by point:

> All you need to do is take the address of the GPIO register then toggle the bit.

Yes, and that is unsafe. Rust makes you put that in an unsafe block, to encourage you to build safe interfaces. This is a good thing.

> No name mangling.

The alternative to name mangling is not having a module system, with all the fun name conflict issues that come with it. Rust made the right decision here.

> No error handlers to override.

C has no concept of a panic handler because what would be panics in C are undefined behavior. Undefined behavior is bad for safety and understandability of the code. Having to declare an error handler is a small price to pay.

> It does seem odd to me that so many of what would be compiler options in C are hard coded.

Because Rust is safe by default. That's one of its most important features. Being more like C in the ways you mention would mean compromising that principle.

Re: Raspberry Pi Bare Metal Programming with Rust

#58

Post by kod » Sun, Jan 17, 2016, 2:59 AM UTC

If you want to play around with the code in this post that requires nightly, multirust makes it much more pleasant to use nightly and / or stable rust.

https://github.com/brson/multirust

Re: Raspberry Pi Bare Metal Programming with Rust

#59

Post by Animats » Sun, Jan 17, 2016, 3:01 AM UTC

jcoffland wrote: post #28

As a long time C programmer this is not very convincing. A C program to do the same requires far less voodoo. All you need to do is take the address of the GPIO register then toggle the bit. No name mangling. No error handlers to override. Don't get me wrong I know rust does have some compelling features. It does seem odd to me that so many of what would be compiler options in C are hard coded.

That's because there's no language syntax for device address space. Modula had DEVICE as a keyword, and you could define structures as being in device space.

That's a useful language feature for low-level programming. It tells the compiler that the address space is special - it can change without help from the program. Other features of device space can include that the write width can matter (some registers have to be written as a single byte, world, or double word) and some registers are read-only or write-only. The compiler needs to know this stuff. Especially because Rust makes some strong assumptions about memory.

Rust probably needs to know about both device registers and memory shared with peripherals to operate at this level. For the blinky light program it doesn't matter; for the network stack it matters a lot.

Re: Raspberry Pi Bare Metal Programming with Rust

#60

Post by bluejekyll » Sun, Jan 17, 2016, 4:21 AM UTC

vive-la-liberte wrote: post #24

Cshelton wrote: post #12

Earlier quoted context omitted.

Out of all the new languages of the last 5 years or so (D, Rust, Crystal, Go?, etc.) I think Rust shows the most promise. It is attracting both c/c++ people and people coming from dynamic languages (Python, ruby, js). So I'd recommend trying Rust out for sure, not much to lose, maybe spending a day...

The first release of D was in 2001. That's 15, not 5, years ago.

Though, what I find odd is that for me (and yes that is an extremely small sample) I barely heard of D until people started wondering why rust was being picked over D.