3 ms·

It's easy to mix C/C++ with Lua or Rust. Lua requires you to write a C library or use LuaJIT's FFI library. There's a number of Rust crates that let you include

It's easy to mix C/C++ with Lua or Rust. Lua requires you to write a C library or use LuaJIT's FFI library. There's a number of Rust crates that let you include arbitrary C/C++ code, such as the cc crate [0]. This approach allows you to have the advantages of the higher-level language while still being able to utilize existing libraries. While not for an embedded project, I used this approach to write a Rust application that interfaces with the Helix Perforce C++ API. Also, regarding your point #3, I prefer the Rust version by far. Code is written once and read many times. Without needing to jump between places or rely on good IDE contextual information, the Rust version says: - SIGNALLED is intended to be modified. - ISR must conform to the rules of an interrupt handler -- be careful what you do in this method. - The write to SIGNALLED is unsafe and volatile. - The read of SIGNALLED is unsafe and volatile. You can be sure the while condition check won't be optimized away because you see the use of the "read_volatile" -- if you're tracking down a bug, no need to go look to see if SIGNALLED is marked volatile. Plus, in the comments of the Rust sample, the author recommends using a higher-level primitive, to avoid the direct calls to read/write_volatile. A good IDE would show type hints: "volatile bool" for C and "Atomic<bool>" for Rust, or something similar. [0] https://crates.io/crates/cc https://crates.io/crates/cc .

scoutt 7y ago
As a C firmware developer always trying to learn something new I looked into Rust for embedded, but cases like this hold me back to delve deeper. So, to set a value into a (volatile) boolean I have to call a function passing a pointer within an unsafe block? Why on earth it's clearer than or preferred over the C code? I know, you'll list several reasons, but please, it's not clearer and it's voodoo magic. In fact, it is the last thing I would (intuitively) think about doing, since it's known that you cannot operate from a pointer to a volatile variable because it may be UB in C++. >> the author recommends using a higher-level primitive Again, to read/write a boolean? Are we talking embedded here? From https://doc.rust-lang.org/core/ptr/fn.write_volatile.html https://doc.rust-lang.org/core/ptr/fn.write_volatile.html >> Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time. WHAT!? I cannot bring Rust to any serious development yet...
- burfog 7y ago
  I've done C firmware. I disagree about these problems. C did not have a rigorously and formally defined memory model until 2011. We did C for almost 40 years before we got that. Go read what Linus Torvalds has to say about "volatile", and then go rip it out of all your code. You should not be using that keyword, except possibly for a software-incremented global clock tick counter residing in normal RAM. You need to call a function that will properly perform any required memory fences. If you don't do this, the CPU or bridges may reorder the memory accesses. Rust might have problems, but the issues listed are not problems. My immediate concern is the availability of inline assembly. I would hope that this is possible and can be inlined into code that isn't marked unsafe.

scoutt 7y ago

As a C firmware developer always trying to learn something new I looked into Rust for embedded, but cases like this hold me back to delve deeper. So, to set a value into a (volatile) boolean I have to call a function passing a pointer within an unsafe block? Why on earth it's clearer than or preferred over the C code? I know, you'll list several reasons, but please, it's not clearer and it's voodoo magic. In fact, it is the last thing I would (intuitively) think about doing, since it's known that you cannot operate from a pointer to a volatile variable because it may be UB in C++. >> the author recommends using a higher-level primitive Again, to read/write a boolean? Are we talking embedded here? From https://doc.rust-lang.org/core/ptr/fn.write_volatile.html https://doc.rust-lang.org/core/ptr/fn.write_volatile.html >> Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what "volatile" means here is subject to change over time. WHAT!? I cannot bring Rust to any serious development yet...

burfog 7y ago
I've done C firmware. I disagree about these problems. C did not have a rigorously and formally defined memory model until 2011. We did C for almost 40 years before we got that. Go read what Linus Torvalds has to say about "volatile", and then go rip it out of all your code. You should not be using that keyword, except possibly for a software-incremented global clock tick counter residing in normal RAM. You need to call a function that will properly perform any required memory fences. If you don't do this, the CPU or bridges may reorder the memory accesses. Rust might have problems, but the issues listed are not problems. My immediate concern is the availability of inline assembly. I would hope that this is possible and can be inlined into code that isn't marked unsafe.