Live data from Hacker News

Raspberry Pi Bare Metal Programming with Rust

blog.thiago.me

91–96 of 96 posts

Re: Raspberry Pi Bare Metal Programming with Rust

#91
post #67

Earlier quoted context omitted.

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…

I think you're giving it a bit more credit than necessary. Don't get me wrong, it's cool that they've got it running on a RPi, but it's almost word for word what you'd write in C (right down to needing to inline assembly to get a busy loop to work). The C implementation wouldn't need to bring in a bleeding edge nightly build, worry about name mangling etc..

The purpose of the article was to show how to get up and running with rust on a Raspberry Pi, not to show how that rust is easier to use than C for programming a Raspberry Pi.

Plenty of things I do are are word for word the same in C and python. (import math vs. #include , math.sin(x) vs. sin(x), etc.)

It is when you want to build something more complex than a blinking light that the differences between languages come out.

Re: Raspberry Pi Bare Metal Programming with Rust

#92
post #78

Earlier quoted context omitted.

You always need a cross-compiler, or a VM. There is no way around it.

I don't have a problem with needing a cross-compiler, but I don't want to write one. I don't have to write my own if I use Rust. Or D, or C. But I can't find such a thing for ATS for example. So just being a language which has semantics to support this is not sufficient to be declared a language "which can do this". I would also need to be able to download a toolchain which can do this.

Ok, but that is a matter of availability of implementations, not a language feature.

Re: Raspberry Pi Bare Metal Programming with Rust

#93

Earlier quoted context omitted.

A module system is always worth it because every program needs to use library functions. Even if you think you don't, LLVM will generate calls to library functions for ordinary code; for example, if you move structures around on the stack, LLVM might just decide to call memcpy(), even if you didn't ever import string.h. (Checking your code after the fact to verify there are no library calls doesn't get around this be…

Does bare metal Rust also use memcpy() or other library functions? If so, how are those linked into the final binary?

They are usually provided by libc, but if you do low level stuff they are provided by other means.

Re: Raspberry Pi Bare Metal Programming with Rust

#94
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.

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.

That's true, the reason I mentioned the RPi was because I happen to have one lying around. (Actually, I seem to remember there are a couple of AVR development boards lying around in the lab, so these might be worth a look.)

My project involves generating two analogue signals to drive a mirror (a sin wave on the x-axis and a staircase pattern on the y-axis), and a synchronized digital trigger signal for the camera. There are a number of configuration options that make this slightly more interesting than it looks at first (frequency, number of sin periods per staircase step, duty cycle and number of triggers per sin).

An implementation of this on a NI DAQ took the better part of a day and an implementation on a FPGA took roughly two weeks (mostly spent on familiarizing with the tools and communicating settings from the host.) I actually think an implementation on the RPi would be simpler than either, including wiring up simple DAQ.

Re: Raspberry Pi Bare Metal Programming with Rust

#95

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 far from outdated. The AtXmega series is very powerful. It includes modern features such as DMA transfers. AVR chips are much easier to work with than ARM for certain applications. They are also lower power and cheaper. The OPs application would be significantly easier to implement on an AVR. On the RPi you would have to write a Linux kernel driver and deal with real-time issues. In the AVR you would create a few interrupt handlers and be done.

Re: Raspberry Pi Bare Metal Programming with Rust

#96
post #94

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.

That's true, the reason I mentioned the RPi was because I happen to have one lying around. (Actually, I seem to remember there are a couple of AVR development boards lying around in the lab, so these might be worth a look.) My project involves generating two analogue signals to drive a mirror (a sin wave on the x-axis and a staircase pattern on the y-axis), and a synchronized digital trigger signal for the camera. Th…

I think you will run into real-time performance problems on the RPi.
Post reply on HN