Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Raspberry Pi Bare Metal Programming with Rust

blog.thiago.me

Post reply on HN
Print view View original

61–70 of 96 posts

Re: Raspberry Pi Bare Metal Programming with Rust

#61

Post by 0xcde4c3db »

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.

My experience doing this sort of stuff in C is that this class of complexities is still present, but hidden outside the source in the crt0 and build scripts. Putting it in the actual program text seems like an improvement.

Re: Raspberry Pi Bare Metal Programming with Rust

#62

Post by rdtsc »

Aeolos wrote: post #8

I have the perfect project for this! Generate a signal using the GPIO ports to drive a mirror and camera in a synchronized fashion. Does anyone know if the RPi GPIOs can be driven at around 80KHz? I've seen reports that this is possible, but that the USB or video driver tends to lock the CPU for long times, messing with timings - but hopefully running on bare metal would take care of that.

Here is an example of a project driving a realtime camera with Beaglebone black.

http://www.erlang-factory.com/static/upload/media/1394631509...

There is a video for the presentation as well.

https://www.youtube.com/watch?v=OBGqVmzuDQg&list=UUKrD_GYN3i...

The trick is Bealgebone black has 2 co-processors PRUs and they can be used for realtime work:

http://beagleboard.org/pru

http://elinux.org/Ti_AM33XX_PRUSSv2

It is a programmable 200-MHz, 32-bit processor with single-cycle I/O so it can be used to toggling GPIO pins.

Re: Raspberry Pi Bare Metal Programming with Rust

#63

Post by mrob »

IshKebab wrote: post #32
jcoffland wrote: post #26

Earlier quoted context omitted.

You could do this with much less than an RPi. I would recommend using an AVR or better yet a 555 timer if all you need is an 80KHz signal. Let me know if you want help with this I'm looking for projects like this or something much more complicated.

I wouldn't recommend an AVR. That is outdated technology. Even Atmel mostly makes ARM microcontrollers now (and they are much nicer than their AVR ones).

AVRs are simple and reliable. You can read the whole datasheet and understand everything with much less effort than modern ARM MCUs. They've been around long enough that I have a lot of confidence in them. They're electrically more robust than most modern chips so they're hard to accidentally damage. There's a lot of community support available because of the popularity of Arduinos. Many tasks don't need anything more powerful. I think it would be foolish to discard AVRs as obsolete just because they're old.

Re: Raspberry Pi Bare Metal Programming with Rust

#64

Post by Manishearth »

magicmu wrote: post #33
Manishearth wrote: post #21

Earlier quoted context omitted.

Could you list which packages you tried to use which were blocked on a nightly? In many cases a package can be moved off nightly with trivial changes, I can try to do it.

I tried digging around but couldn't find the package names -- I could've sworn ansi-term ( https://crates.io/crates/ansi_term/ ) and hyper ( https://crates.io/crates/hyper/ ) were two of them, but it looks like they both use stable. Thanks though!

Depends on when you last tried I guess.

So what happened was that many of these packages existed pre-1.0 when there was no stability system. Nobody knew which features would be stabilized (if you go further back, the fact that things would be stabilized in such a way wasn't clear either).

So we all just used whatever feature we liked. Many of these unstable APIs or features had stable counterparts, but the choice to use an API/feature was made pre-stability, so nobody had any way of knowing. Which meant that a lot of unnecessary unstable API usage persisted after 1.0. Some crates made a transition. some were slower (I think hyper was pretty quick to stabilize). Servo, for example, didn't have any issue with using nightlies for various reasons so we kept using unstable APIs (I later audited and removed low-hanging extraneous unstable API usage. Most of our out-of-tree crates are stable too).

There have been efforts both by maintainers and by individual community members to bring crates to stable, and I think at the moment most useful non-plugin crates work fine on stable. Let me know (@Manishearth on twitter) if you find a crate that you need that doesn't work on stable!

Re: Raspberry Pi Bare Metal Programming with Rust

#65

Post by Manishearth »

izacus wrote: post #37
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.

Of course that same ability lets you clobber anything else in your address space and leads to those lovely debugging sessions playing "track down what corrupted my datastructure".

Whilst having to debug this is still undesirable, I recommend trying `rr` (http://rr-project.org/) to track this if you're ever in such a situation. It's as simple as setting a watchpoint and reverse-continue-ing!

I don't do much C/++ these days, but when I do (and it's a large codebase which is hard to debug), `rr` is invaluable. It works with Rust too.

Re: Raspberry Pi Bare Metal Programming with Rust

#66

Post by Manishearth »

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…

I don't think the post is bragging about this. It's well known amongst the Rust community that this stuff is pretty easy to do)

I read it as a primer for writing simple Rust programs that can run baremetal on the Pi (I've cross compiled for a Pi-with-OS before but never tried this) and access GPIO.

If you're talking about the HN upvotes, HN just tends to upvote posts mentioning Rust a lot :)

Have you looked at https://zinc.rs/?

Re: Raspberry Pi Bare Metal Programming with Rust

#67

Post by e12e »

0xcde4c3db wrote: post #61
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.

My experience doing this sort of stuff in C is that this class of complexities is still present, but hidden outside the source in the crt0 and build scripts. Putting it in the actual program text seems like an improvement.

Exactly. I saw the gp comment and feared there was lots of boilerplate, arcane incantations -- and the only slightly smelly thing in the (IMNHO) beautiful and short example is the use of an empty asm block to "fight" the compiler on optimizing out the busy loop.

I can't imagine the full C example for this is any prettier or easier to follow?

[ed: As for "no name mangling" - having such an easy way to turn it off when needed, and yet avoid collisions when you do need it seems pretty good to me. Perhaps just having something that's "extern" be umangled by default would be better -- but it's not like one needs to bend over backwards to get a "mostly safe" bare metal program here.]

Re: Raspberry Pi Bare Metal Programming with Rust

#68

Post by e12e »

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#

And C++, surely? (Although, I would probably choose C (or even assembler) over C++ for something this simple (loop, blink a light). And between all those, I think Rust is really interesting.

It could probably be argued that Rust doesn't add much on top of D (as a "better" C++) -- but between the mind-share and the focus on "safe" (and boxing in unsafe) memory access, I think Rust is really interesting. Not sure how run-time free D is coming along - believe there were some issues with the standard lib?

Ada was troubled by a confusing split between FSF LGPL Gnat trailing Ada Core GPL/commercial compiler with a release -- leaving people a little confused if there was a good Free Ada compiler that could be used for commercial (or just non-GPL) development. (Yes, it was a real issue, just as one needs an LGPL libc for c development etc).

But as I understand it the GNAT compiler has matured to the point that one can now use modern Ada without having to worry about that. Unfortunately Ada probably lost a lot of potential developers due to the confusion/issue.

Re: Raspberry Pi Bare Metal Programming with Rust

#69

Post by fpgaminer »

bsder wrote: post #45
tdicola wrote: post #27

Earlier quoted context omitted.

Yeah 80khz should be no problem. Even in Linux if you access the Pi's GPIO registers directly you can toggle pins in a tight loop at around 1-2mhz. As others mentioned though you might look at a small microcontroller though since the Pi is kind of overkill for generating a simple signal.

> Even in Linux if you access the Pi's GPIO registers directly you can toggle pins in a tight loop at around 1-2mhz. Careful, this is strongly dependent upon the hardware, not Linux. I seem to recall that people doing SWD programming can barely get the GPIO's to move faster than a couple of KHz. I can tell you that, at least on the BeagleBone Black, you have to do some Linux driver voodoo to get better than a couple…

On the other hand, the BBB has two dedicated on-chip MCU's for driving the GPIO's.

Re: Raspberry Pi Bare Metal Programming with Rust

#70

Post by bsder »

fpgaminer wrote: post #69
bsder wrote: post #45

Earlier quoted context omitted.

> Even in Linux if you access the Pi's GPIO registers directly you can toggle pins in a tight loop at around 1-2mhz. Careful, this is strongly dependent upon the hardware, not Linux. I seem to recall that people doing SWD programming can barely get the GPIO's to move faster than a couple of KHz. I can tell you that, at least on the BeagleBone Black, you have to do some Linux driver voodoo to get better than a couple…

On the other hand, the BBB has two dedicated on-chip MCU's for driving the GPIO's.

True, but those are really annoying to program and are mostly meant for hard real-time rather than maximum speed.

The speed on the BBB for GPIO's is okay (I can get to about 12.5MHz with some care). It's more annoying that you actually have to be in supervisor mode to change the I/O direction of a GPIO pin.

Post reply on HN