Programming ARM μC in Rust at four different levels of abstraction

http://pramode.in/2018/02/20/programming-a-microcontroller-in-rust-at-four-levels-of-abstraction/

by signa11 • 8 years ago

184 32 8 years ago

jfries• 8 years ago

Wow level 3 there was really elegant. In general I try to find use for a strong type system to force correct code, but here it's Rust's ownership model that ends up saving the day.

unwind2• 8 years ago

This is great and really helps emphasize why I should look into Rust some day (I program STM32s in C for a living).

It would have been awesome if this had shown the resulting assembly for the first few cases, too.

jabot3• 8 years ago

They do that in a prior post:

http://pramode.in/2018/01/31/ti-launchpad-with-rust-new-io/

unwind2• 8 years ago

Thanks, that's very nice and impressive. Zero-cost abstractions are very attractive.

classics2• 8 years ago

A GPIO pin starts out as an input; in that state, you can’t call the function set_high. It is a compile time error!

Which is throughly incorrect. Of course you can set the state of an output register that’s set to input, that state will just not appear on the pin.

jabot3• 8 years ago

The state of the pin is encoded in the type of the variable that is used to access the pin.

This kind of encoding prevents you from making the programming error of writing to an input pin - which is technically possible, just useless.

emilfihlman• 8 years ago

Not even remotely useless, it's often a feature.

bleke2• 8 years ago

As for input it can be always read to check real pin state, for example in open collector where 'high' value is determined by pull-up resistor, because microcontroller just make pin floating

KMag3• 8 years ago

Which is throughly incorrect. Of course you can set the state of an output register that’s set to input, that state will just not appear on the pin.

The context is Rust, where the statement is clearly correct. One can't call a function if the Rust compiler refuses to generate the binary. The author probably should have used a period between the first and second independent clauses and a semicolon between the second and third in order to show the close relations ship between being unable to call the function and it being a compile error.

foldr2• 8 years ago

The OP means that this is an incorrect model of the microcontroller.

mcguire• 8 years ago

... which is probably not what you wanted.

One would suspect that other functions in the HAL that control the feature you are looking for directly.

madez2• 8 years ago

Why is it necessary to mark the interrupt handler and the panic formatting function as extern C functions? Is the C way of doing that set in silicon?

m1el• 8 years ago

C and Rust (can) have different calling conventions. C is the de-facto standard calling convention. When you mark a function as `extern "C"`, it means that it can be called as if it is a C function.

madez2• 8 years ago

But what C code is running alongside the Rust code on the microcontroller that would make adhering to the C calling convention necessary? Is the hardware expecting the C calling convention?

leggomylibro• 8 years ago

I don't know much of anything about Rust, and I have a pretty limited knowledge of ARM, but I think that the 'Nested Vector Interrupt Controller' basically just pushes a stack frame and jumps to the memory location specified in a vector table that lives near the start of memory.

That sounds like how C functions are called; does Rust do something different?

dbaupp• 8 years ago

The fundamentals of pushing a stack frame and jumping is the same, but the details of how arguments are passed (e.g. is a value in registers, or on the stack) and return values returned differ between the calling conventions.

Programming ARM μC in Rust at four different levels of abstraction

Related Stories