Author Topic: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)  (Read 31111 times)

0 Members and 1 Guest are viewing this topic.

Offline TopQuarkTopic starter

  • Frequent Contributor
  • **
  • Posts: 303
  • Country: hk
Hi, the company I currently work for exclusively uses Rust for our product's embedded development, and I have been learning Rust and specifically embedded Rust lately. I thought I'd kickstart a thread discussing using embedded Rust, including learnings, successes and failures. I am still no expert in Rust, but I have gone through the "fighting the compiler" stage and am starting to see how Rust can be valuable in production. In fact, for a long time, I have been a Rust holdout and swore by C, but now I am starting to be a Rust convert.

My company (M-Labs HK) happens to open source everything we develop, so I thought I'd share a few examples of usage of Rust in "real world" shipping, money making products.

https://git.m-labs.hk/M-Labs/thermostat - Baremetal Rust on STM32F4, dual channel TEC controller capable of better than 1 milliKelvin control stability. Not quite stable release yet, but we have shipped systems to early beta participating customers.

https://git.m-labs.hk/M-Labs/kirdy - Baremetal Rust on STM32F4, precision laser driver with TEC controller and photodiode monitor. Under (my) development, very early stage, hardware not finalised.

https://github.com/m-labs/artiq - Baremetal Rust on softcore, Migen for FPGA fabric and softcore. Quantum physics control system. Very mature and production ready.

https://git.m-labs.hk/M-Labs/artiq-zynq - Baremetal Rust on Zynq 7000, Migen for FPGA fabric. Quantum physics control system. Reasonably mature and production ready.

This is by no means advertisement, but rather to demonstrate that "new-fangled" tools like Rust and Migen CAN be used in "real" products. I'd love to see more discussions and examples of Rust being used in products and projects! Show us your Rusty projects and discuss anything embedded Rust related!
 
The following users thanked this post: paf, JPortici, WillTurner, elagergren

Online voltsandjolts

  • Supporter
  • ****
  • Posts: 2282
  • Country: gb
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #1 on: November 07, 2022, 01:16:48 pm »
Interested to get your thoughts on this.

Can you list the top five advantages of Rust over C, in an embedded environment like baremetal Cortex-M, as you see it?
 

Offline TopQuarkTopic starter

  • Frequent Contributor
  • **
  • Posts: 303
  • Country: hk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #2 on: November 07, 2022, 02:39:44 pm »
Just off my head, somethings I like about embedded rust

1. Memory (and by extension memory mapped peripheral) safety. In baremetal C on systems without memory protection unit, there's nothing preventing you from dropping a HAL_GPIO_WritePin(port, pin) anywhere in your code, or changing a peripheral setting register anywhere in the code. There's no warning from the compiler nor any checks against this. This means if you have multiple processes (esp. when developed by multiple developers), you can't trust that the state of the memory (and memory mapped peripheral) is in the state you left it in, someone / some process could have changed it under the rug.

In Rust, unless you specifically wrap your code in an unsafe block, the compiler simply does not allow you to do that. Every bit of memory (and by extension memory mapped peripheral) has an owner, and only the owner of that bit of memory has write access to that bit of memory. Take for example a gpio pin, in Rust, the init code would take ownership of all the peripherals, break up the peripherals into individual objects (some SPI busses, some GPIO pins, some I2C busses etc), and pass the ownership these objects to various processes that now owns that bit of peripheral and has write access to it. The implication is your process can always trust that it has exclusive ownership of its memory objects, and can have confidence no other processes has altered its state. This is all done in COMPILE TIME, so there's no runtime overhead for having memory safety, even without a MPU.

This alone is very significant imo.

2. Modern tooling. In Rust there's Cargo, a build system + package manager that makes code building and reusing much nicer than C. If I want to add a library to my code, I just have to specify the name and version of the library I wish to use, and Cargo will integrate the library into my code properly and take care of all the dependencies and dependencies of dependencies. This is way better than C. Cross compiling is also a breeze, as Rustc uses LLVM, cross compiling means I just have to specify the architecture of the target and stuff just works. I don't need to maintain a version of GCC for linux, another version for windows, then arm-none-eabi-gcc for my cortex M stuff.

3. I don't usually allocate heap when programming cortex M, but when I do, it is so much safer in Rust. The compiler makes sure there's no memory leaks, no double freeing, no dangling pointers etc. all at compile time with minimal runtime overhead. This also means no garbage collector is needed.

4. Very strong, static, type system. Say you have a library function that implements sleep/delay. In Rust, properly written libraries will take a parameter of type time, instead of say a u32. In C, the programmer has to be cognizant of the physical meaning and unit of the number you pass to the sleep function. e.g. In stm32cube, HAL_Delay(x) takes a u32 and sleeps for x milliseconds. The programmer takes responsibility of making sure the number specified means milliseconds, not seconds, not microseconds, not ticks, not processor cycles. In Rust, the sleep function would take a generic parameter of time, and time can be a variable of type ms, or type us, or type second, or type ticks, and the sleep function would sleep according to the numeric value and type of the variable. So in Rust, your sleep function would look something like sleep(10_u32.millis()), or sleep(10000_u32.micros()), explicitly stating both the value and type, i.e.unit of the value. The compiler takes care of the part that translates the generic time type to the native type the sleep functions uses to count elapsed time, so no overhead again.

5. General attitude and mindset. In Rust, the programmer is not to be trusted, and the compiler does what it can to force you not to write certain types of bugs (e.g. memory leaks, out of bound array indexing), unless you explicitly wrap your code with unsafe. In C, the programmer is assumed to know its sh*t and trusted to do whatever he/she wishes to do. This different attitude takes some getting used to, and rubs some people the wrong way. Many of us would like to think we are super smart and never writes bugs, but coding in Rust means you have to admit that you do write stupid and buggy code sometimes, and for certain types of coding errors, the compiler is capable of knowing better than you on what's buggy and what's not. This is particularly valuable in two situations imo,
- You work solo with no one to review your code
- You oversee a group of programmers with different levels of aptitude.
In these situations, your code review process is much simpler and the resulting code is much less error prone, because
- Illegal memory (and by extension memory mapped peripheral) access is prohibited by the compiler (point 1, 3)
e.g. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
- Strong type system reduces the chances of passing the wrong type of data to the wrong function (point 4)
e.g. https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
- You can focus your review effort to the handful of lines of code marked unsafe, instead of scrutinising every single line of code.


This is longer than I thought it would be, but I think it is good food for thought. I welcome counter arguments, but please don't turn this into a holy war between different languages.
« Last Edit: November 07, 2022, 03:01:25 pm by TopQuark »
 
The following users thanked this post: hans, paf, ajb, voltsandjolts, ralphrmartin, newbrain, JPortici, spostma, WillTurner, dtodorov, tellurium

Offline AVI-crak

  • Regular Contributor
  • *
  • Posts: 124
  • Country: ru
    • Rtos
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #3 on: November 07, 2022, 02:52:09 pm »
If you separate the bare metal, peripheral control, program level, and user level into different project files, with minimal connections, then 99.99% of the problems of the entire project will be solved.
But the vast majority writes in the Arduino style, and this is not treated in any way. Even changing the programming language will not help.
 

Offline TopQuarkTopic starter

  • Frequent Contributor
  • **
  • Posts: 303
  • Country: hk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #4 on: November 07, 2022, 03:06:34 pm »
If you separate the bare metal, peripheral control, program level, and user level into different project files, with minimal connections, then 99.99% of the problems of the entire project will be solved.
But the vast majority writes in the Arduino style, and this is not treated in any way. Even changing the programming language will not help.

Sure, maybe you really know better than most people, and maybe 99.99% or you code is actually bug free, maybe. And maybe you are right that most people in the industry write crappy code. But what about your "arduino programming" colleagues? Wouldn't you want some kind of tooling (can be rust, can be something else) to force them to write better code?
 

Online JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #5 on: November 07, 2022, 03:22:30 pm »
My problem with rust is that i don't have an official compiler for it (let me know when C++ or Rust or whatever will be available for PIC24/dsPIC). And with official i mean something i can do production with, not some abandoned experiment on github that was started on a rainy saturday and then left there to rot (but enough for the random nagger to point the greasy finger and say "see it can be done? xxx is evil because they make you pay for it")

Point 4, about type safety and polymorphism is already handled by C++ for which you have a production ready compiler. I could argue that newer C compilers or static analysis tool may nag you if you don't cast to the appropriate alias of the u32 type, but i won't.
Point 2, i don't really care for now
Point 3, i could argue that i tend not to use the heap either if i have another option and most of those bugs can be handled by runtime checks so it leads down to good practices, ect, ect, ect, but i won't.
I am intrigued by 1 and 5 and wonder how big is the real performance penality
 

Offline TopQuarkTopic starter

  • Frequent Contributor
  • **
  • Posts: 303
  • Country: hk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #6 on: November 07, 2022, 03:40:24 pm »
My problem with rust is that i don't have an official compiler for it (let me know when C++ or Rust or whatever will be available for PIC24/dsPIC). And with official i mean something i can do production with, not some abandoned experiment on github that was started on a rainy saturday and then left there to rot (but enough for the random nagger to point the greasy finger and say "see it can be done? xxx is evil because they make you pay for it")

Point 4, about type safety and polymorphism is already handled by C++ for which you have a production ready compiler. I could argue that newer C compilers or static analysis tool may nag you if you don't cast to the appropriate alias of the u32 type, but i won't.
Point 2, i don't really care for now
Point 3, i could argue that i tend not to use the heap either if i have another option and most of those bugs can be handled by runtime checks so it leads down to good practices, ect, ect, ect, but i won't.
I am intrigued by 1 and 5 and wonder how big is the real performance penality

Re compilers and everything else. Yes, Rust is still in early days, and vendors still provide tooling mainly in C, rarely in C++, and almost never in Rust (besides espressif). My company actually spends quite some working hours (i.e. money) developing Rust drivers for different parts. If you want strong vendor support, Rust is not there yet.

Re point 1,3,5. Rust handles all the memory safety guarantees in compile time, not run time. There's no Java like runtime in rust and there's no garbage collector at all. The penalty is next to nothing. Someone recently rewrote the Linux NVME driver in Rust, and it benchmarks practically just as fast as the native Linux one written in C (https://www.phoronix.com/news/LPC-2022-Rust-Linux). The memory safety and everything else causes the compile time to increase a bit, but not the execution time.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26757
  • Country: nl
    • NCT Developments
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #7 on: November 07, 2022, 04:09:48 pm »
@TopQuark: First of all thanks for sharing this.

My strong opinion is that C is not really suitable for writing complex software but so far it seems to be the best suitable for the job. What I'm tired of when writing C is adding all kinds of bounds checks just to make the software robust. I have been looking at Ada in the past but that doesn't seem to be gaining any traction at all. So I'm very interested to see where Rust is going. I have been looking at Lua and Micropython scripting as well which can be useful for implementing high level functionality but the low level still needs to be written in C.

Now my question is: how is the debugging organised? Can you write software in Rust on a PC and single step through it? And how about doing debugging on a microcontroller?
« Last Edit: November 07, 2022, 04:26:44 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21609
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #8 on: November 07, 2022, 04:16:07 pm »
Kind of tempted to look into this.  But I mostly have AVRs handy; and, last I looked, there was actually an LLVM output for that, but veeery beta, so probably not too great to use.  I mean, I wouldn't mind contributing improvements to such a project, honestly, but I suspect it's also going to fight me as much as learning the language in the first place, so that'd be a bit much.  Especially if I expect to make real projects (read: $$$) at the same time.  Perhaps I'll take a look soon [I last looked a few years ago], or in a few years again.

Or maybe in a few years, a less...cryptic? dialect, or whole language, will come along?...  Then more years of waiting for platform support...oh, right... :-DD

Mind, not to say C isn't fucking cryptic, it just happens to be the crypt I've already learned. :P

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline AVI-crak

  • Regular Contributor
  • *
  • Posts: 124
  • Country: ru
    • Rtos
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #9 on: November 07, 2022, 04:53:27 pm »
Wouldn't you want some kind of tooling (can be rust, can be something else) to force them to write better code?

My code also has errors, like everyone else. Personal record - code work for five years, with a very difficult to detect error. The culprit was one missing letter in the macro. As a result, a very rare event performed a double-precision calculation, which created additional delay in the control of the manipulator mechanics. The steel gripper was lowered onto a plastic container with glass products - with an offset of several millimeters. A rare but extremely high-profile event!!!
This is the price of inattention. This code has been reviewed and tested by many people, with no result. The error was found by accident when it was necessary to write a new one.

Additional tools?
Everything that could be invented has long been implemented in different variations.
Everything that needs to be invented - breaks the old.
For 50 years, overflow and saturation operators have not been added to the C language (there are functions). 10 years ago, GCC added tracking of array boundaries - the error is visible only during assembly !!!. Three years ago, a single IDE started using shadow compilation to track errors while writing code. The rate of progress is certainly impressive, but even a simple text editor develops many times faster.

What is not, is not planned, and is not created from tools - intelligent assistants.
For example, the source code view mode in the IDE is in overlay mode. This is when the source code is supplemented with types of variables or constants. For example:
Code: [Select]
/// 1)example
void setPixel_line_ram (int16_t x1,int16_t y1, int16_t x2, int16_t y2, uint8_t RGB);

/// 2)usage example in code
setPixel_line_ram (lin.a, lin.b, 10, 25, g8.green);

/// 3)overlay mode in code view
setPixel_line_ram (<i16 x1> lin.a, <i16 y1> lin.b, <i16 y2> 10,
                    <i16 y2> 25, <u8 RGB> g8.green);

The first line is written somewhere very far away. In real code, I can find out about it - if I hold the mouse cursor for more than 5 seconds.
When using a function, there are always hints, well, or almost always. While the fields are being filled in, the tooltip changes dynamically, and this is noma.
With a quick view (2): the purpose of the function fields must either be known by heart, or variables consonant with the function field should be used - which is not always possible in the implementation.
What you want to see in the view mode (3) - overlay with a separate color. Protecting overlays from copying in the IDE by the user - to protect against errors. A separate beautiful button for enabling this mode.

Am I wanting too much?
 

Offline TopQuarkTopic starter

  • Frequent Contributor
  • **
  • Posts: 303
  • Country: hk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #10 on: November 07, 2022, 05:21:16 pm »
Now my question is: how is the debugging organised? Can you write software in Rust on a PC and single step through it? And how about doing debugging on a microcontroller?

Debugging is just as good as C. You use GDB with whatever debug probe you have, and the experience is just as good as C, at least with VS Code. Single stepping, call stack view, register view, memory view etc. everything is there. Even Segger RTT prints work flawlessly. See the attached screenshot.

Am I wanting too much?

I don't fully understand what it is you want, but what you describe (Good IDE/code editor hinting support) is available in Rust too. The hinting system integrates very well with the compiler, and is able to infer the complex types of the variables and show it, making it really easy to know what is what. See the attached screenshot.

Kind of tempted to look into this.  But I mostly have AVRs handy; and, last I looked, there was actually an LLVM output for that, but veeery beta, so probably not too great to use.  I mean, I wouldn't mind contributing improvements to such a project, honestly, but I suspect it's also going to fight me as much as learning the language in the first place, so that'd be a bit much.  Especially if I expect to make real projects (read: $$$) at the same time.  Perhaps I'll take a look soon [I last looked a few years ago], or in a few years again.

Or maybe in a few years, a less...cryptic? dialect, or whole language, will come along?...  Then more years of waiting for platform support...oh, right... :-DD

Mind, not to say C isn't fucking cryptic, it just happens to be the crypt I've already learned. :P

Tim

I read you. I still very much love C. The language is dead simple with very few keywords, but you can do pretty much everything with it (not that you should do everything with it). I think it will take many years for Rust to be close to C in terms of vendor support.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #11 on: November 08, 2022, 03:27:20 am »
Quote
adding all kinds of bounds checks just to make the software robust [is annoying, in C]
So ... let me ask a question about "bounds checking."

When one talks about adding bounds checking to a C program, you usually end up with depressing code like:
Code: [Select]
int foo(a, b) {  bounds_check(a);  bounds_check(b);  int result = bar(a, b, 123);  bounds_check(result);  return result;}int bar(a, b, c) {  bounds_check(a);  bounds_check(b);  bounds_check(c);
  int result = baz(a, c, 567);  bounds_check(result);  return result;}

ie redundant bounds checking at every level of a call tree.  Even if you don't actually USE a parameter, but just pass it on.  Because, after all, you don't know if the function that called you, or the function that you're calling, will do its own bounds checking.

Do languages that inherently support bounds checking managed to optimize it so that a variable is only checked when it is about to be used?  (and preferably, only if it hasn't been checked already since the last time it was changed?)
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #12 on: November 08, 2022, 04:08:26 am »
Quote
adding all kinds of bounds checks just to make the software robust [is annoying, in C]
So ... let me ask a question about "bounds checking."

When one talks about adding bounds checking to a C program, you usually end up with depressing code like:
Code: [Select]
int foo(a, b) {  bounds_check(a);  bounds_check(b);  int result = bar(a, b, 123);  bounds_check(result);  return result;}int bar(a, b, c) {  bounds_check(a);  bounds_check(b);  bounds_check(c);
  int result = baz(a, c, 567);  bounds_check(result);  return result;}

ie redundant bounds checking at every level of a call tree.  Even if you don't actually USE a parameter, but just pass it on.  Because, after all, you don't know if the function that called you, or the function that you're calling, will do its own bounds checking.

Do languages that inherently support bounds checking managed to optimize it so that a variable is only checked when it is about to be used?  (and preferably, only if it hasn't been checked already since the last time it was changed?)

A reasonable C compiler will optimize redundant tests if all functions are in the same compilation unit. If not, of course, it can't. Although GCC's LTO might be able to do this as well, but I haven't used LTO much.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26757
  • Country: nl
    • NCT Developments
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #13 on: November 08, 2022, 05:09:46 pm »
Quote
adding all kinds of bounds checks just to make the software robust [is annoying, in C]
So ... let me ask a question about "bounds checking."

When one talks about adding bounds checking to a C program, you usually end up with depressing code like:
Code: [Select]
int foo(a, b) {  bounds_check(a);  bounds_check(b);  int result = bar(a, b, 123);  bounds_check(result);  return result;}int bar(a, b, c) {  bounds_check(a);  bounds_check(b);  bounds_check(c);
  int result = baz(a, c, 567);  bounds_check(result);  return result;}

ie redundant bounds checking at every level of a call tree.  Even if you don't actually USE a parameter, but just pass it on.  Because, after all, you don't know if the function that called you, or the function that you're calling, will do its own bounds checking.
Something along that line. Typically with throwing a meaningful error somewhere in a log or debug output. Depressing but it has helped to diagnose and fix sporadic errors that would otherwise have been hard to catch. I'd be interested as well in how that works with Rust. In many cases compile time bounds checking isn't enough.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: neil555

Offline JuniorJack

  • Contributor
  • Posts: 16
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #14 on: November 14, 2022, 04:54:02 pm »
Hey TopQuark,

Thanks for posting this detailed info about Rust.

My personal reason to stick with C is that is very easy(unless i go crazy on optimizations) to just read out the Flash memory, drag the .bin file to IDA Pro
and decompile. It takes just seconds to locate functions i am interested in and usually it is pretty easy to see variables and execution paths.

How readable would be a code generated in Rust from its binary form ? I have very bad experience with C++ in this regard. Thanks!
 

Offline uliano

  • Regular Contributor
  • *
  • Posts: 172
  • Country: it
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #15 on: March 10, 2023, 10:15:31 am »

Debugging is just as good as C. You use GDB with whatever debug probe you have, and the experience is just as good as C, at least with VS Code. Single stepping, call stack view, register view, memory view etc. everything is there. Even Segger RTT prints work flawlessly. See the attached screenshot.

Can you provide link/pointers to configure vscode+gdb+rust (also RTT, it would be really great!) I'm not finding much...
Is it possible to view also peripheral register (by reading .SVD) or only cortex ones?
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #16 on: March 10, 2023, 05:05:12 pm »
My be this is off topic, but I have these two rather philosophical points:

1. Nowadays, programmers are obsessed with languages. But I believe the language doesn't matter, as long as it allows you to write what you have designed without typing too much.

Imagine, a microbiologists writes a thesis about his microbes and then he decides that he needs to learn French and write the thesis in French. This is because French is safer. For example:

Code: [Select]
Je pense // I think
Tu penses // You think

Therefore the spellchecker will be able to find errors if you mess things up. If you write "Je penses" then clearly you need to change something to make it correct. This makes writing in French safer and therefore it's a good idea to switch to French. Never mind the thesis is about microbes and what does matter is what he has to say about microbes, not the language he says it in.

When a programmer dwells on languages instead of concentrating in the design it's equally silly.

2. Everybody tries to achieve safety. They're convinced that the opposite of safety is recklessness. Like programming in assembler is reckless, while programming in Java is safe.

In reality, the opposite of safety is freedom. The more safety you try to get, the more freedom you have to give up. Who on Earth lives in the conditions of greatest safety? Patients of mental institutions. They cannot hurt themselves even if they try very hard. How is this achieved? Very simple. Their freedom is taken away.

Same in programming. Instead of giving up your freedom for imaginary safety, use your freedom to create a simpler design which has less operations, less special cases, less bloat. And then your design will be smaller, simpler, easier to work with, and surprisingly it also will be safer.
 
The following users thanked this post: neil555, snarkysparky, GromBeestje, spostma, SiliconWizard, woofy, pcprogrammer

Offline paf

  • Regular Contributor
  • *
  • Posts: 91
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #17 on: March 10, 2023, 06:55:42 pm »
Me, I have the intention of learning Rust one of these days.

Rant:
You have bad examples and bad metaphors. Your french english example is bad. French has more redundancy, so is more reliable in the presence of errors/cuts. If in english you hear "think" it may be "I think" or "you think" or "think".  If you hear "pense" in french is "je pense" and "penses" is "tu penses". 

Different programming languages have different abstractions and data structures, that may offer different ways of thinking.

In C (or assembly) I can cast anything to anything. In other languages I cannot unless I really want. The impression that I have from Rust ia that I will spend lots of time "fighting the compiler", but I think that is better to send more time "fighting the compiler" than to "fight bugs" after the compile phase. 

Learning a different language is always good because it gives you a "different way" of thinking. You only have learned a different language when you start to "think" in that language.   
       


 
The following users thanked this post: karpouzi9

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #18 on: March 10, 2023, 07:15:20 pm »
I agree with NorthGuy here. I wouldn't quite go as far as saying that the programming language doesn't matter at all, but it's certainly not what matters most.

Given the very steep learning curve of Rust, my opinion is that this time would be much better invested in learning how to improve your designs and how to make the most of the tools you already know.

You might say that the two are not orthogonal, but our time is precious and limited.

When one keeps looking for "better" tools rather than working on one's skills, this is pretty much akin to procrastination. Just my 2 cents.

 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3630
  • Country: nl
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #19 on: March 10, 2023, 07:47:19 pm »
I agree with NorthGuy too. As a hobbyist there is no need to learn a lot of languages unless that is your hobby. Don't expect your projects to magically become better by switching to some more secure or higher level language.

Programming is a skill and some will never learn it no matter what language they use. Sounds harsh but it is what it is.

@uliano, in some other thread you mentioned the desire to go bare metal, and for that assembly is almost the barest of them all, but it is not necessary to go that low. With plain C you can achieve everything you want, as long as you really understand programming. And to learn programming my advise is to revisit the basics. Seek out the logic behind it. Forget about libraries, and really go bare metal.

Offline artag

  • Super Contributor
  • ***
  • Posts: 1061
  • Country: gb
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #20 on: March 10, 2023, 08:16:55 pm »
I started to look at Rust, because although I'm against the concept of removing sharp edges to make things safe, I do appreciate that some things could be improved - though it will be worthless if I have to declare all the hard bits 'unsafe' to get them to compile.

However what really puts me off - and this is probably why there's no official compiler - is that the language isn't properly defined yet. I see python, which is also changing constantly, and although I'm sure it's great for personal scripts it's just a portability disaster. I don't want to see another of those.

Let someone think it right through and define it self-consistently. At the moment, it's an experiment.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19281
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #21 on: March 10, 2023, 08:58:37 pm »
I agree with NorthGuy here. I wouldn't quite go as far as saying that the programming language doesn't matter at all, but it's certainly not what matters most.

Given the very steep learning curve of Rust, my opinion is that this time would be much better invested in learning how to improve your designs and how to make the most of the tools you already know.

You might say that the two are not orthogonal, but our time is precious and limited.

When one keeps looking for "better" tools rather than working on one's skills, this is pretty much akin to procrastination. Just my 2 cents.


Yes, repeat no.

Language isn't the most important thing. But, and it is a big but, a language which enables you to accurately and succinctly express your solution is a big thing. The corollary is to choose a language that suits your problem and your solution.

Thus there is little difference between Java and C#, or Delphi and Pascal, or C and assembler ( :) ) If you grok one it takes very little time to grok the alternative.

But there is a big difference between C, Smalltalk, xC, VHDL, Go, Rust, R, SQL, Prolog, LISP, Fortran, COBOL. When considering a career, it is vital to be able to distinguish "boring similar" languages from those that are worth grokking.

Hence, understand your problem's constraints and then choose the language.

If you are programming in a highly parallel environment then Rust or Go or xC have big advantages over C. Which is more or less applicable depends on the detailed nature of the parallelism.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: paf

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #22 on: March 10, 2023, 10:10:07 pm »
My be this is off topic, but I have these two rather philosophical points:

1. Nowadays, programmers are obsessed with languages. But I believe the language doesn't matter, as long as it allows you to write what you have designed without typing too much.
My personal opinion is that the whole development of new languages that are more safe etc. are the result of businesses that need so many programmers that they hire someone with some degree which is not root core programming.

I rather have a record proven old language than a new language that might have issues.
If there is a better new proven language than I am fine.
But low and behold, new language features always introduce new issues.
An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19281
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #23 on: March 10, 2023, 10:29:47 pm »
An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

Start by considering the performance of, say, a cache implemented in C. Then consider the performance effects of all the hardware caches and superscalar operations in a modern processor.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14309
  • Country: fr
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #24 on: March 11, 2023, 01:00:06 am »
You may be intrigued/interested to know that GCC 13 is going to include Modula-2 as an official front-end.
Could be interesting for embedded development as well.
Although again you should not focus too much on the language, at least for programming microcontrollers. Still interesting times.

They are also working on a Rust front-end, although obviously it will take quite a while before becoming mature.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf