3 ms·

All the Rust Embedded code I've seen is off the rails deep into "C++ template meta programming" and the absolute antithesis of what to do. Even the code here,

All the Rust Embedded code I've seen is off the rails deep into "C++ template meta programming" and the absolute antithesis of what to do. Even the code here, given the absolute impossibility to detect errors with something like a GPIO chip, has too many Results. It's an incredible code smell for "terrible abstractions".

Jweb_Guru 5y ago
The Results here aren't from the GPIO operations, so that's not really relevant.
MrBuddyCasino 5y ago
Thanks! So its no just me. This feels like reading one of those Haskell-Blogs: certainly impressive, where author explains the dimensions along which this solution is superior, but its just incomprehensible brainfuck and doesn't pass any standards of beauty. I've written some Rust; I know it is workable, and "if it compiles it works" is mostly true. But its so ugly.
- stormbrew 5y ago
  This is very nearly a mechanical line by line conversion of the C to rust. What on earth is so much uglier about it that it renders it "incomprehensible brainfuck"? Is this satire and I'm missing the joke
  - db48x 5y ago
    I assume that they are talking about the abstractions that people sometimes build when working with hardware at a low level. In Rust you can literally build the hardware restrictions into your types, so that for example all registers (or pins in this case) have both read and write methods except the ones that the hardware does not allow you to write to; those only have read methods. Or think about access control: it’s not ok for two programs (or two kernel threads) to interleave accesses to the same GPIO pin, for example. You decide that you want to have some kind of handle or struct that lets you read and write to the pin, but that cannot be duplicated or dropped. This way you can create that object once during initialization, and then pass it to whoever needs it. If you want to call something that needs access to the pin, you then have to pass it the object and you can only regain access to the pin if it passes the object back as a return value. The compiler just won’t let you interleave accesses, because the code won’t even compile if you try to do something not allowed. But all of those neat features add complexity, and often some people just prefer to write comments instead. Usually I recommend starting with very straight–forward code and only adding abstractions in later refactoring steps. Another option is to write the usage code first; this can help you design abstractions without going full architecture astronaut.
bsder 5y ago
I would be interested in what you think of something like BBQueue: https://github.com/jamesmunns/bbqueue https://github.com/jamesmunns/bbqueue
the__alchemist 5y ago
Exactly! I think the point of OP's example is how to write clean driver code. Much of the Rust embedded code available open source is a mess of abstractions, with no specific use case in mind. Ie, no way to weight if the abstractions' utility is worth their complications. This includes code by the Rust Embedded Working Group.

Jweb_Guru 5y ago

The Results here aren't from the GPIO operations, so that's not really relevant.

MrBuddyCasino 5y ago

Thanks! So its no just me. This feels like reading one of those Haskell-Blogs: certainly impressive, where author explains the dimensions along which this solution is superior, but its just incomprehensible brainfuck and doesn't pass any standards of beauty. I've written some Rust; I know it is workable, and "if it compiles it works" is mostly true. But its so ugly.

stormbrew 5y ago
This is very nearly a mechanical line by line conversion of the C to rust. What on earth is so much uglier about it that it renders it "incomprehensible brainfuck"? Is this satire and I'm missing the joke
- db48x 5y ago
  I assume that they are talking about the abstractions that people sometimes build when working with hardware at a low level. In Rust you can literally build the hardware restrictions into your types, so that for example all registers (or pins in this case) have both read and write methods except the ones that the hardware does not allow you to write to; those only have read methods. Or think about access control: it’s not ok for two programs (or two kernel threads) to interleave accesses to the same GPIO pin, for example. You decide that you want to have some kind of handle or struct that lets you read and write to the pin, but that cannot be duplicated or dropped. This way you can create that object once during initialization, and then pass it to whoever needs it. If you want to call something that needs access to the pin, you then have to pass it the object and you can only regain access to the pin if it passes the object back as a return value. The compiler just won’t let you interleave accesses, because the code won’t even compile if you try to do something not allowed. But all of those neat features add complexity, and often some people just prefer to write comments instead. Usually I recommend starting with very straight–forward code and only adding abstractions in later refactoring steps. Another option is to write the usage code first; this can help you design abstractions without going full architecture astronaut.

bsder 5y ago

I would be interested in what you think of something like BBQueue: https://github.com/jamesmunns/bbqueue https://github.com/jamesmunns/bbqueue

the__alchemist 5y ago

Exactly! I think the point of OP's example is how to write clean driver code. Much of the Rust embedded code available open source is a mess of abstractions, with no specific use case in mind. Ie, no way to weight if the abstractions' utility is worth their complications. This includes code by the Rust Embedded Working Group.