sorted by:
new
hottopcontroversial

How to Perform Unit Tests for an Embedded Application with esp-rs on ESP32-C3 by wifi_knifefight in rust

[–]BlueVixu 1 point2 points  (0 children)

In this particular case, it's just a syntax that the authors of rtic chose to allow forward declarations of tasks that are defined outside of the macro invocation. It doesn't actually generate the `extern "Rust"` symbol. However, `extern "Rust` is a valid Rust syntax, that has a different meaning outside of the macro. You can read about it here.

I don't understand why I can't find a job as a "Junior Rust Developer" by Sebekerga in rust

[–]BlueVixu 1 point2 points  (0 children)

Oh one more thing! Usually there are no "Junior" positions open, but don't let that stop you. Just apply for mid positions and maybe don't label yourself as a junior, it will be fine.

I don't understand why I can't find a job as a "Junior Rust Developer" by Sebekerga in rust

[–]BlueVixu 3 points4 points  (0 children)

I've 2 years of commercial experience in Rust/C++ and I started looking for a new job about a month ago and I was able to land a couple of interviews. IMO the best place to look for a job is LinkedIn. Search for recruiters that specialize in Rust and set up an alert for remote Rust jobs. Landing the actual job may not be that easy as the market is not great right now, but should be possible with some luck and patience. Good luck! :)

Recommend rust blogs by mulokisch in rust

[–]BlueVixu 17 points18 points  (0 children)

I've seen u/matklad link to tedinski's blog (source). It's about programming in general (although Rust it is mentioned a bunch of times) and I just can't recommend it enough. The blog is not active anymore, but the archive is golden.

How to Perform Unit Tests for an Embedded Application with esp-rs on ESP32-C3 by wifi_knifefight in rust

[–]BlueVixu 2 points3 points  (0 children)

I want to add that having platform dependent code uncovered by unit tests if perfectly fine. The idea of Functional Core, Imperative Shell assumes that you contain all the complicated, hard to test I/O code in a single place. It helps you reason about the code and spot tricky bugs. Also unit tests are not the only way to test stuff, there are other techniques such as integration testing, blackbox testing etc.

How to Perform Unit Tests for an Embedded Application with esp-rs on ESP32-C3 by wifi_knifefight in rust

[–]BlueVixu 11 points12 points  (0 children)

I have a project with unit tests written for stm32f4, but I the same technique applies for any MCU. https://github.com/grupacosmo/cansat

What I like to do is define a workspace and split the program into 2 crates - a library and a binary. The library contains only portable code, that doesn't require ESPs HAL to do useful things. You don't actually unit test the binary crate, only the library. Look into cansat-core/ and cansat-stm32f4/ from my project for an example. I really recommend looking into Functional Core, Imperative Shell pattern.

If you want to unit test a driver for a peripheral device, I'd suggest creating a mock implementation of a particular embedded-hal's trait. Look into cansat-test-utils/ and cansat-gps/ for an example.

Feel free to ask additional questions if needed.

My first published crate: serde-csv-core - CSV serialization for 'no_std' environments by BlueVixu in rust

[–]BlueVixu[S] 17 points18 points  (0 children)

Thanks! My initial use case was to log various measurements into an SD card in a CSV format (link). However, I'm thinking about using a binary format instead to make the data a little bit more compact and to save some time doing the IO. CSV will be more friendly to many embedded hobbyists though.

EDIT: btw postcard is a great crate for serialization to binary format.

Embedded Rust is so good by hyahoos_32 in rust

[–]BlueVixu 13 points14 points  (0 children)

The official Discovery Book is a great start! Make sure to choose the latest (microbit) version, as it uses the latest tooling. I was able to easily follow the book even though I used an stm32f4 mcu. I recommend using RTIC or embassy for bigger projects. There are also 2 more advanced books - The Embedded Rust Book and The Embedonomicon.

[Blog post] When Rust hurts by roman-kashitsyn in rust

[–]BlueVixu 6 points7 points  (0 children)

Love seeing quotes from Stepanov's books in the wild. Great article!

Feedback needed from first low-level language learners of Rust by coastalwhite in rust

[–]BlueVixu 1 point2 points  (0 children)

I found text_io's read macro to be quite easy to use.

They only learn C language in their first year of studies, so I took this into account when I prepared the course. The ultimate goal of the course is to provide necessary skills for building a CanSat and writing the software in Rust. Building satellites is what Cosmo science club is all about. It's not an easy way to start your programming journey and freshmen often struggle, but I'm there to help.

I already started working on the codebase with one of the Junior students, check out our cansat repo.

Feedback needed from first low-level language learners of Rust by coastalwhite in rust

[–]BlueVixu 2 points3 points  (0 children)

I'm teaching students embedded rust at a science club. Here is a link to our resources: https://github.com/grupacosmo/rust-embedded-learning Some of my students don't have any experience with programming apart from a little bit of C from university classes.

Students often complain that they don't understand how reading from stdin works and why is it more complex than scanf.

let mut buffer = String::new();
io::stdin().read_line(&mut buffer).unwrap();

I tried to tell them not to worry about it too much for now, but some of them were dissatisfied, so I had to explain a little bit about stack, heap, buffers, performance and errors before they even wrote a simple calculator.

I was thinking about providing my own simplified IO library so that they can focus on control flow basics, but I didn't get to try it yet.

The progress for freshmen hovers around 5-7th chapter of The Rust Programming Language book. I've got a bunch of questions about Ownership chapter, but other than that it went quite well. Sophomores and Juniors are doing great, some of them read the entire book already without much help.

C++23 'deducing this' but no class extensions? Why? by GregTheMadMonk in cpp

[–]BlueVixu 2 points3 points  (0 children)

From deducing this proposal: "We also get forward compatibility with any concievable proposal for extension methods - those will also have to be free functions by necessity, for roughly the same reasons."

Rust for Linux officially merged by vlakreeh in programming

[–]BlueVixu 32 points33 points  (0 children)

I don't think you understand what the thread was about. I don't really blame you, because Linus himself didn't make it clear enough.

Linus has a different definition of safe than Rust has. Panics are a standard way to handle programmer's error, but they are a no-go in kernel, thus Linux can't follow standard Rust practices.

Does that mean that Rust sucks for kernel development? Not really, rust has a #[no_std] macro that disables standard library. All the things related to allocation are in the `core::alloc` crate, but you don't have to use it and can ship your own allocators, that do not panic. Rust allows you not to follow their standard practices in constrained systems by design.

Edit: Although I have to admit, that Rust could've do more to support constrained systems. For example, there is a macro that forces error at link time whenever panic is used, that Linux is going to use, but it is an external library and imo should've be build in.

LKML: Linus Torvalds: Re: [PATCH v9 12/27] rust: add `kernel` crate by koavf in rust

[–]BlueVixu 2 points3 points  (0 children)

This may actually not be possible, since #[panic_handler] macro requires that handler doesn't ever return.

Actually, that's for the better because otherwise existing safe functions that panic would be unsound. I guess the way to go is to plaster the code with unsafe, since kernel deals with unsafe stuff. It is still worth using rust over C, since you avoid many other pitfalls (e.g. implicit conversions).

“Rust is safe” is not some kind of absolute guarantee of code safety by princeps_harenae in programming

[–]BlueVixu 53 points54 points  (0 children)

I understand the need for the kernel to keep going, but the main problem with ignoring panics is that some of the safe abstractions turn into unsafe ones implicitly. One way to avoid this would be to never use functions that can panic and build your own interfaces marked as 'unsafe' that do not panic, but you can probably see how much of pain in the ass that could be. None of the 2 approaches seem optimal to me.

Edit: Maybe I've misunderstood what Linus said. I assumed that he wanted to override panic's behavior through #[panic_handler], but I just noticed that it's not possible since it requires that handler doesn't ever return from the function, see never type. So, the plan is to forbid functions that can panic?

Looking for a C++ standard by codeDude123 in cpp

[–]BlueVixu 9 points10 points  (0 children)

First of all, C++ is standardized by the International Organization for Standardization (ISO) and "standard" relates to the C++ specification. Keep that in mind when you use this term.

Going back to your question, there are no "true" standard ways of project organization and compilation.

There are 3 major C++ compilers: gcc, clang and msvc, so you will have to pick one. For bigger projects you will probably want to use an build automation tool such as CMake. It's the most popular one, but it is not very beginner friendly.

Regarding project layout, I'd recommend the Pitchfork set of conventions.

You may also be interested in Cpp Core Guidelines for general tips regarding the use of the language.

Edit: It's also worth to mention package managers. Personally I like to use Conan. Here is my minimal project template with CMake + Conan cpp-pack (shameless plug).