Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)

[SiliconWizard]

I dislike Tchaikovsky with a vengence. Put me off classical music for years.

To each their own.

I have found exactly one nutcracker that I like using; I've been using it for more than half a century. Even so, it isn't wonderful with brazil "nuts". Memo to self: find a tool that is better for that use case.

Maybe something involving XMOS?

[wek]

Let's shift the focus to some things that are useful and convenient,

1. 'Enum Types' (aka. algebraic data types, sum types, tagged unions) and the match operator:
2. 'Traits' (aka. interfaces, mixins)
3. First-class closures and good iterators/functional primitives
4. The 'question mark operator' / error handling

Thanks for the overview.

However I am not sure whether all these - and other advanced techniques/features - are that much applicable to microcontrollers programming.

I understand that with increasing chip density(*) the perception of mcus among developers is shifting towards "general-purpose computer with some annoying peripherals" (see HAL, multitasking, etc.); thus principles applying to general-purpose computers increasingly apply to mcus too.

However, I am coming from the "annoying peripherals" side, seeing C as a "better asm", feeling uneasy when the "oh there's surely enough memory" argument comes and being overwhelmed by the levels of abstraction in modern languages. I am afraid it would take me too much time to see clearly the connection between those constructs and the generated and run binary - and I need that understanding to be able to judge the impact of using any such construct to the actual workings of the mcu.

Also, I personally enjoy more reading a couple dozens of pages of manuals and poking the hardware using primitive methods, rather than observing how a few lines of highly abstract code translates into a complex yet perfectly functional product.

I have taken the view that I'd rather let my tools do the hard work of figuring out if what I'm doing makes sense.

I don't find the work of spelling out explicitly what I intend to do that hard.

JW

(*) R.I.P., Gordon Moore.

[tggzzz]

I dislike Tchaikovsky with a vengence. Put me off classical music for years.

To each their own.

Nah. I have good taste

I came across the received wisdom embodied in Peter Ustinov's anecdote that the answer to "name a Russian composer" is "Tchaikovsky" (Rachmaninov was an incorrect answer!)

Similarly I never thought Beethoven was "the best composer". I always preferred JS Bach, Scarlatti, and others.

I have found exactly one nutcracker that I like using; I've been using it for more than half a century. Even so, it isn't wonderful with brazil "nuts". Memo to self: find a tool that is better for that use case.

Maybe something involving XMOS?

Certainly not. The plastic is too soft.

[coppice]

I came across the received wisdom embodied in Peter Ustinov's anecdote that the answer to "name a Russian composer" is "Tchaikovsky" (Rachmaninov was an incorrect answer!)

The correct answer to "name a Russian composer" is Rimsky Korsakov. Have you heard how they play the flight of the bumble bee?

The Nutcracker really is a great work for introducing your children to the classics. Taking our daughter, and later our son, at about 4 years of age to see the Nutcracker performed with a live orchestra by a really good ballet founded their appreciation of great music and theatre.

[Marco]

Actually most people here have said that C was ridden with its own issues and that something "better" would be nice, but have argued that Rust may not be the answer.
If you don't like that idea, sorry to hear that.

Time is running out to be a contender. Billions of dollars are going to cement the winner of the memory safe system programming language race soon, Rust and ADA Spark seem the only contenders.

Unless the C++ standards committee pulls a rabbit out of a hat and stops writing more guidelines and and instead creates a machine verifiable safe C++ subset, while also replacing exceptions with something more sane (and thus the standard library).

[Siwastaja]

memory safe

Except this is just a buzzword. Everything relates to memory, every variable and data structure is in memory, and if you can do anything at all with data, you can also do mistakes. You can remove some types of errors like accessing array Y through overindexed array X, but this is just the tip of an iceberg; you can still accidentally access Y[5] when you wanted Y[4] and so on. The rest is just nontechnical brand work, like defining a term like "memory safe" in a way which allows you to call your product "memory safe".

For something that doesn't even have a standard, I don't know. <New language X> fanboys always place their bets on safety critical industries such as aviation because it "sounds cool" and they themselves think it's convincing, but safety critical industries specifically require a long legacy to the level or being boring and just barely functional due to actual greybeardism way above people like NorthGuy who is, I'm sure, totally open to any solution he finds useful.

[tggzzz]

Unless the C++ standards committee pulls a rabbit out of a hat and stops writing more guidelines and and instead creates a machine verifiable safe C++ subset, while also replacing exceptions with something more sane (and thus the standard library).

Fat chance!

In the early-mid 90s the committee

• flatly denied that the STL was a Turing complete programming language - until Erwin Unruh forcibly rubbed their noses in it by causing the compiler to generate the prime numbers during compilation
• spent years discussing whether or not to require/forbid "casting away constness"; there are good reasons for either decision

and even this millennium it was necessary for Hans Boehm to produce his famous paper https://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf "Threads Cannot be Implemented as a Library"

That convinced me that C++ was a castle built on sand, and nothing has caused me to change my mind since.

[coppice]

Time is running out to be a contender. Billions of dollars are going to cement the winner of the memory safe system programming language race soon, Rust and ADA Spark seem the only contenders.

Time ran out for anything in the ADA sphere a long time ago. If you build a new language on one that was only ever used when the customer said it must be used, you are probably only trying to appeal to the same niche's updated thinking.

[Marco]

Except this is just a buzzword.

Nah, it's just imprecisely defined. The minimum definition is just that the program isn't allowed to access un/deallocated memory.

For something that doesn't even have a standard, I don't know.

US government Billions can get things moving quickly. NSA and congress talking about memory safety is the reason Bjarne has been talking up C++'s ability to be memory safe (convincing absolutely no one, they lack the will to do what is truly necessary).

[Marco]

Time ran out for anything in the ADA sphere a long time ago. If you build a new language on one that was only ever used when the customer said it must be used, you are probably only trying to appeal to the same niche's updated thinking.

Because US government allowed alternatives ... money talks.

[SiliconWizard]

Actually most people here have said that C was ridden with its own issues and that something "better" would be nice, but have argued that Rust may not be the answer.
If you don't like that idea, sorry to hear that.

Time is running out to be a contender. Billions of dollars are going to cement the winner of the memory safe system programming language race soon, Rust and ADA Spark seem the only contenders.

Not only "memory safe" is largely a buzzword, possibly focusing on the wrong problem, as some of us have said, but that aside, your statement above has the benefit of making clear what it's all about: marketing and money. It's a political and commercial affair, not an engineering or scientific one. And the buzzwords have all their place.

[ve7xen]

For me the problem with Rust has been mostly the documentation and specifically the auto generated API documentation. Nothing wrong with generating documentation from source code, but even the standard library seems to have a lot of methods that have just one line, actually only a shortened sentence, as a description. You are apparently supposed to recognize what this is about just from the name of the function and the function signature. This part is really subpar :-( The thing is for a learner you don't know how things fit together, plus parsing the signatures can be very hard. Double so if you are not used to read signatures with a lot of type variance, which might be concepts you do not really understand that well.

That is a big fail. Automatically generated documentation is outright useless because the coherency between the parts gets lost. How the parts fit together and how they are to be used is the most important information a user for a library needs. Someone should add ChatGPT to Doxygen as a code analysis tool and produce documentation. It will be an improvement for sure... But maybe (hopefully) there is a book about it.

This is absolutely my biggest sticking point with it too. The Rust Book is a pretty good introduction to a lot of the language concepts, but it has no context. When I'm learning a new language I tend to spend most of my time in the library/API documentation sections poking around the bits I think will be useful to the problem I'm solving. Usually these docs will include context-aware usage examples which are idiomatic, and help with understanding how to compose useful things out of the language concepts. To me this is what is lacking most. Once you understand that so much behaviour is driven by Traits, you learn to follow the trail of Trait implementations to find some documentation on how they're meant to be used, but again, these docs & examples lack the context of the struct implementing them, which doesn't help much with idiomatic usage of a given library. Not to even get into how difficult it is to make sense of what the type generics are being used to do. Huge room for improvement here, especially (obviously) with embedded that is much newer in the ecosystem.

That's not what most of the posts I've read or written here are about. If that's what you read, read again. IMHO.

The thread at large, no, but the chain of posts I was referring to was a lot of 'I want to do <thing I can do in C> in Rust and it sounds like I can't'. In general, any comparison or 'subjective' evaluation may not explicitly be with respect to C, but it's a pretty darn safe assumption in this space. Whether or not that's the case in the thread, the point was to bring some things folks might/probably not know about if they haven't looked at Rust past the surface, which I haven't seen a lot of discussion about.

Unfortunately, we are failing to see any real-world metric that would prove it yields undoubtedly "safer" products while keeping productivity at a reasonable level, so it's often a lot of talk and some whining as soon as some people dare question its benefits.

If I'm mischaracterizing the conversation, I think this is doing the same. My main point is not even about safety, despite that people seem to think this is all Rust has to offer. Whether or not this leads to fundamentally safer products in the end is not really an answerable question. There's a) far more to it than thread/memory safety and b) other ways to prove/test/guarantee the system is working properly (though these are generally a lot more expensive than a few seconds of compile time). But when I'm wearing my developer hat, I certainly appreciate having two fewer things that can be fraught with hidden pitfalls to think about, and which I will certainly get wrong eventually, no matter how good I think I understand what I'm doing. Outside of embedded, which is still a very open question for me, I have found it's just a pleasant and capable tool to use. It offers all the performance of other low-level languages, but far more modern niceties, most of which are 'free' at runtime, which for me makes it nearly as usable as something like Python.

Does that transfer to embedded without creating undue friction? Still trying to figure that out, but I don't think there is a way to know without getting your hands dirty and actually learning the language, because it is fundamentally so different. From what I've done so far, I think it is not ready yet, the HAL APIs aren't stable enough/have some warts, too much type ugliness shows through to the application, and as mentioned the documentation - but these are not language issues and it seems things are improving rapidly. If you just want to bang on the registers via PAC and manage concurrency yourself, I think it's quite usable, but the learning curve is quite steep.

[tggzzz]

Actually most people here have said that C was ridden with its own issues and that something "better" would be nice, but have argued that Rust may not be the answer.
If you don't like that idea, sorry to hear that.

Time is running out to be a contender. Billions of dollars are going to cement the winner of the memory safe system programming language race soon, Rust and ADA Spark seem the only contenders.

Not only "memory safe" is largely a buzzword, possibly focusing on the wrong problem, as some of us have said, but that aside, your statement above has the benefit of making clear what it's all about: marketing and money. It's a political and commercial affair, not an engineering or scientific one. And the buzzwords have all their place.

"Memory safety" is not largely a buzzword.
"Memory safety" is not the whole solution, by any means.
"Memory safety" is an important and useful mechanism of reducing common and widespread defects.

Defects introduced by suboptimum tools waste valuable engineering attention, time (and money).

Much more profitable to focus engineering attention where it belongs: on understanding the task at hand and creating a solution to the problems inherent in the task. Not problems in the tools.

[NorthGuy]

Memory errors are symptoms of other problems - they can be caused by many things - typos, miscalculations, misunderstandings, design failures, etc. etc. In each particular case, the cause must be found and fixed. Curing symptoms, even if possible, will not cure problems.

For example, people cough, which is a bad thing and may be a symptom of various diseases. If everyone would be required to wear a special collar which makes coughing physically impossible, this would hardly cure anyone.

[Siwastaja]

For example, people cough, which is a bad thing and may be a symptom of various diseases. If everyone would be required to wear a special collar which makes coughing physically impossible, this would hardly cure anyone.

On the other hand, if coughing becomes impossible, that will reduce the spread of the disease to others. Disease still needs to be cured, but consequences are less serious. That's the whole point of mechanisms such as preventing access to other unrelated memory through overindexing an array, and some of them are relatively easy to implement, so called low hanging fruits.

[tggzzz]

Memory errors are symptoms of other problems - they can be caused by many things - typos, miscalculations, misunderstandings, design failures, etc. etc. In each particular case, the cause must be found and fixed. Curing symptoms, even if possible, will not cure problems.

You "forgot" to add that they can be caused by choosing a poor tool for the job.

Avoidance is better than cure.

For example, people cough, which is a bad thing and may be a symptom of various diseases. If everyone would be required to wear a special collar which makes coughing physically impossible, this would hardly cure anyone.

That's a revealing analogy. More analogies like that will help all readers of this thread.

[coppice]

Memory errors are symptoms of other problems - they can be caused by many things - typos, miscalculations, misunderstandings, design failures, etc. etc. In each particular case, the cause must be found and fixed. Curing symptoms, even if possible, will not cure problems.

You "forgot" to add that they can be caused by choosing a poor tool for the job.

Just because they aren't very good programmers, you shouldn't call them a tool. I assume that's what you meant. By far the biggest factor in the success of any software development is the quality of the people, not the quality of what they use. The average slob can make a disaster out of anything.

[tggzzz]

Memory errors are symptoms of other problems - they can be caused by many things - typos, miscalculations, misunderstandings, design failures, etc. etc. In each particular case, the cause must be found and fixed. Curing symptoms, even if possible, will not cure problems.

You "forgot" to add that they can be caused by choosing a poor tool for the job.

Just because they aren't very good programmers, you shouldn't call them a tool. I assume that's what you meant. By far the biggest factor in the success of any software development is the quality of the people, not the quality of what they use. The average slob can make a disaster out of anything.

Neat misinterpretation I wonder how well the joke is understood by those for whom English is a second language (and that includes left-pondians).

[uliano]

(and that includes left-pondians).

As a non native english reader I fell into a huge rabbit hole.

[baldurn]

So I was thinking of the poor documentation and why don't they just use ChatGPT to improve the documentation? Then I thought why don't _I_ use ChatGPT to get better documentation? And so I tried this prompt:

"I need documentation with examples for embedded rust HAL and PAC for use with RP2040"

And what do you know? It started giving me much better documentation on exactly that :-)

Funny enough it made an example for the timer using unsafe:

Timers

The RP2040 features timers that can be used for timekeeping, delays, and generating periodic events.

Example: Timer Interrupt

Code: [Select]

#![no_std]
#![no_main]

use cortex_m_rt::{entry, exception};
use hal::clocks::{init_clocks_and_plls, Clock};
use hal::gpio::{GpioExt, Input, Output, PullDown, PullNone};
use hal::sio::Sio;
use hal::timer::Timer;
use pac::{interrupt, Peripherals, TIMER};
use cortex_m::peripheral::NVIC;

static mut LED_TOGGLE: bool = false;

#[entry]
fn main() -> ! {
    let pac_peripherals = Peripherals::take().unwrap();
    let sio = Sio::new(pac_peripherals.SIO);

    let pins = hal::gpio::Pins::new(pac_peripherals.IO_BANK0, pac_peripherals.PADS_BANK0, sio.gpio_bank0, &sio);
    let mut led = pins.gpio25.into_push_pull_output();

    let mut timer = Timer::new(pac_peripherals.TIMER);
    timer.init_interrupt(1_000_000.hz());

    // Enable the TIMER_IRQ_0 interrupt
    unsafe {
        let mut nvic = NVIC::new();
        nvic.enable(interrupt::TIMER_IRQ_0);
    }

    loop {
        if unsafe { LED_TOGGLE } {
            led.set_high().unwrap();
        } else {
            led.set_low().unwrap();
        }

        cortex_m::asm::wfi();
    }
}

#[interrupt]
fn TIMER_IRQ_0() {
    let mut peripherals = unsafe { Peripherals::steal() };
    peripherals.TIMER.ints.modify(|_, w| w.timerr().set_bit());
    unsafe { LED_TOGGLE = !LED_TOGGLE; }
}

In this example, we configure a timer to generate an interrupt every second. The TIMER_IRQ_0 interrupt handler toggles the LED state and clears the interrupt flag.