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

[NorthGuy]

You are also missing the point. You really shouldn't need or want to be messing with dynamic memory allocation at all! Let well tested & proven libraries deal with that deep under the hood somewhere. When I need dynamically allocated structures in C, I will use C++ and STL templates that do this for me so the room for mistakes is next to non-existent. I've had my fair share of debugging time with valgrind to find other people's memory allocation mistakes. I don't want to add to that mess.

Recently I put solar panels on my roof. If you look at the 'professional' installers, 99% of them walk on sloped roofs without any safety measures. I, however, used a certified safety harness and attachements while working on the roof. Bottom line: just because something is possible or seems to be the standard way of doing something, it doesn't mean it is a wise thing to do. Safety first.

I think you confuse fear with safety. There's no reason to be afraid of mistakes. People learn from their mistakes. The more mistakes you make, the more opportunities to learn. Mistakes will not harm you. You'll find them and correct them. Moreover the more time you spend correcting your mistakes the easier it will become - you will see reasons why the mistakes appear, you will learn new ways to deal with them. Being indiscriminately afraid of mistakes is a really bad idea.

Working on the roof is different because if you fall down you will die.

[Siwastaja]

Working on the roof is different because if you fall down you will die.

Mistakes in embedded software can also cause someone to die - but this just emphasizes your point. If I had to hire someone to write firmware for a pacemaker or brake ECU, I would pick a team of extremely experienced professionals - those who have done gazillion of mistakes - not someone who says "hey, Python hides these memory allocations for you so it can't fail".

Yeah - the earlier you start doing all the mistakes, the better.

[uliano]

It is not about moving ghosts, but using well tested & proven libraries / existing code in a way that makes it hard to add mistakes. Python and Lua (for example, not saying you should limit yourself to Python or Lua) allow that.

Then, if you limit yourself to base Python (I never used micro- but I suppose it's a subset, possibly not proven as much as cpython), you are sailing calm waters and, I agree, if you are goin' on the heap you don't need Python but even modern C++ or, surprise, Rust, among others, can do the same.

Other libraries not part of Python core itself have varying degrees of provedness so, yes there could be some ghost.

However, generally speaking the heap is not my first choice for memory management on MCUs.

[uliano]

I'm sure this won't be controversial, but I'm a happy user of embedded-rs for all sorts of microcontrollers, including in production

So maybe you can help in my original question (before the thread got derailed and went guerrilla)

I'm mostly there, given I don't understand the mechanics/jargon that governs rust dependency management, I was able to set up a stupid blinker and debug it in vscode with cortex-debug with st-link. Then I got lost trying to move that to Jlink to use  RTT. An hell made of duplicated crates (with different second version digit), linker errors and stuff that mostly I don't understand has appeared.

Yes, i know, I'm just doing the wrong way around but I have been surprised by the limited number of silly functional examples out there and the difficulty/impossibility to combine them grabbin' one piece here and another there (yeah, bad practice, but before entering the rust world it mostly served me well).

Bottomline

I'm lookin' for a working example of VSCode + cortex-debug + JLink + RTT.

After that, I swear, I'll go back and start a systematic study.

[tggzzz]

You are also missing the point. You really shouldn't need or want to be messing with dynamic memory allocation at all! Let well tested & proven libraries deal with that deep under the hood somewhere. When I need dynamically allocated structures in C, I will use C++ and STL templates that do this for me so the room for mistakes is next to non-existent. I've had my fair share of debugging time with valgrind to find other people's memory allocation mistakes. I don't want to add to that mess.

Recently I put solar panels on my roof. If you look at the 'professional' installers, 99% of them walk on sloped roofs without any safety measures. I, however, used a certified safety harness and attachements while working on the roof. Bottom line: just because something is possible or seems to be the standard way of doing something, it doesn't mean it is a wise thing to do. Safety first.

I think you confuse fear with safety. There's no reason to be afraid of mistakes. People learn from their mistakes. The more mistakes you make, the more opportunities to learn. Mistakes will not harm you. You'll find them and correct them. Moreover the more time you spend correcting your mistakes the easier it will become - you will see reasons why the mistakes appear, you will learn new ways to deal with them. Being indiscriminately afraid of mistakes is a really bad idea.

Working on the roof is different because if you fall down you will die.

Complacent nonsense.

There are many ways a mistake can harm you. The obvious way is a mistake could cause you to lose your job or career. (Yes, there are other ways for that to happen, but they are irrelevant to your point)

As an extreme example, one product I implemented could kill people - even if it worked as designed.

[nctnico]

Working on the roof is different because if you fall down you will die.

Mistakes in embedded software can also cause someone to die - but this just emphasizes your point. If I had to hire someone to write firmware for a pacemaker or brake ECU, I would pick a team of extremely experienced professionals - those who have done gazillion of mistakes - not someone who says "hey, Python hides these memory allocations for you so it can't fail".

Those professionals will use Lua, Python, Ada, Rust (?), etc. Anything that has a managed environment that doesn't allow to shoot yourself in the foot like you can with C.

[nctnico]

You are also missing the point. You really shouldn't need or want to be messing with dynamic memory allocation at all! Let well tested & proven libraries deal with that deep under the hood somewhere. When I need dynamically allocated structures in C, I will use C++ and STL templates that do this for me so the room for mistakes is next to non-existent. I've had my fair share of debugging time with valgrind to find other people's memory allocation mistakes. I don't want to add to that mess.

Recently I put solar panels on my roof. If you look at the 'professional' installers, 99% of them walk on sloped roofs without any safety measures. I, however, used a certified safety harness and attachements while working on the roof. Bottom line: just because something is possible or seems to be the standard way of doing something, it doesn't mean it is a wise thing to do. Safety first.

I think you confuse fear with safety. There's no reason to be afraid of mistakes. People learn from their mistakes. The more mistakes you make, the more opportunities to learn. Mistakes will not harm you. You'll find them and correct them. Moreover the more time you spend correcting your mistakes the easier it will become - you will see reasons why the mistakes appear, you will learn new ways to deal with them. Being indiscriminately afraid of mistakes is a really bad idea.

I've made enough mistakes and I'm simply tired of using tools that need extra bandaids/work because they allow mistakes. Maybe you are not at that point yet or are just not aware of your own 'mortality'. As some point you learn to point & push sharp objects away from you.

[Siwastaja]

I've made enough mistakes and I'm simply tired of using tools that need extra bandaids/work because they allow mistakes. Maybe you are not at that point yet or are just not aware of your own 'mortality'.

Higher level languages on microcontrollers tend to allow larger-scale mistakes, such as failure to assign resources (such as RAM), because it is difficult or even impossible to do so. The consequence of these mistakes is the same as the small C mistakes: complete failure of the product. The difference is, a memory leak in C implementation can be found and fixed. A python implementation using a library with too high memory requirements requires a complete rewrite on a project. I have seen numerous of such cases. Product is designed, high-level software team thinks they can do it, project is engineered - until finally it is found out no one has idea how to do embedded. Then people like me are called in and write the firmware in a lower-level language.

On a PC, this is not as much an issue because software engineering can choose to ignore availability of resources because they are so plentiful.

[nctnico]

I've made enough mistakes and I'm simply tired of using tools that need extra bandaids/work because they allow mistakes. Maybe you are not at that point yet or are just not aware of your own 'mortality'.

Higher level languages on microcontrollers tend to allow larger-scale mistakes, such as failure to assign resources (such as RAM), because it is difficult or even impossible to do so. The consequence of these mistakes is the same as the small C mistakes: complete failure of the product.

No. Having enough resources is part of the design process. But even when resources run out due to some unforeseen circumstance, you can make the software fail & recover in a much more predictable way because there is a layer to deal with that situation. Both embedded Lua and Micropython allow to set heap sizes which are dedicated areas of RAM. So the underlying software will not be affected by a memory shortage and still be fully operational (and able to do an orderly shutdown / recovery).

[Siwastaja]

So the underlying software will not be affected by a memory shortage and still be fully operational (and able to do an orderly shutdown / recovery).

And that "underlying software" is some handler which dumps "out of memory" error message to... nowhere. Or maybe, in best case, some debug interface.

If the part running out of memory was not important, it could have been removed to begin with.

But that's fine, we clearly just mean completely different things with "embedded".

[uliano]

I've made enough mistakes and I'm simply tired of using tools that need extra bandaids/work because they allow mistakes. Maybe you are not at that point yet or are just not aware of your own 'mortality'. As some point you learn to point & push sharp objects away from you.

mistakes were and are being made in python and lua despite the security in memory mangment...

[nctnico]

So the underlying software will not be affected by a memory shortage and still be fully operational (and able to do an orderly shutdown / recovery).

And that "underlying software" is some handler which dumps "out of memory" error message to... nowhere. Or maybe, in best case, some debug interface.

Dumping the error somewhere is one, but recovery is the other. In what way the device should recover is part of the design requirements but there is nothing that stands in the way of clearing the heap and restarting the program. And there really is no need to have a different definition of embedded. The bottom line is that C is far from ideal in order to make robust software because it allows mistakes that are beyond functional errors in software.

For example: you have a dataset you want to process. In C you can make several mistakes: use the wrong range (buffer overflow), use the wrong type and have an error in the formula. In Python or Lua you can only have an error in the formula.

Moving towards managed languages is a natural evolution of embedded programming. But we'll have the C versus assembly argument allover again.

[uliano]

In Python or Lua you can only have an error in the formula.

Python doesn't check types...

[Siwastaja]

For example: you have a dataset you want to process. In C you can make several mistakes: use the wrong range (buffer overflow), use the wrong type and have an error in the formula. In Python or Lua you can only have an error in the formula.

C: Can't have wrong type (as easily), as language is manually and semi-strongly typed. Compiler erroring out on incompatible types is forced by standard.
Python: Type errors cause silently wrong results or more implicit conversions which affect memory footprint.

Wrong range:
C: Crash
Python: Crash
(with different definition of "crash", but same result for end user, as explained above)

Formula:
C: Need to be extra careful with integer promotions, casts, and other such rules that seem weird especially to mathematicians
Python: Arguably easier and matches better with expectations coming from Matlab/etc.

But nctnico is just nctnicoing, as usual. This is my last off-topic comment in this thread.

[uliano]

Moving towards managed languages is a natural evolution of embedded programming. But we'll have the C versus assembly argument allover again.

you mean in the IoT kind of stuff?

[nctnico]

Moving towards managed languages is a natural evolution of embedded programming. But we'll have the C versus assembly argument allover again.

you mean in the IoT kind of stuff?

No, in general. Microcontrollers with large memories keep getting cheaper so a small memory footprint becomes less important. In general the functionality also increases in size; it just doesn't make sense to wanting to program everything in C 'just because'. The controller to be used in the project I'm currently working on has about 1MB or RAM and several MB of flash while it costs somewhere around US $4 in small quantities. Someone else will be implementing the logic for this product; it is very helpfull & economic if that person doesn't need to be a C expert.

Also the modern day junior software engineers are more geared towards the 'higher level' languages anyway. How much time do you want to spend on training them & fixing their errors while they learn how to program C? And how worthwhile (=economic sensible) is that given the alternatives?

[nctnico]

In Python or Lua you can only have an error in the formula.

Python doesn't check types...

It does but the type for a variable is determined by what you assign to it initially. You'll need to convert between types if you want to assign variables with different types. If there is a mismatch, you'll get a runtime error.

[uliano]

 The controller to be used in the project I'm currently working on has about 1MB or RAM and several MB of flash while it costs somewhere around US $4 in small quantities.

and also runs ta a few dozen GHz? as the constraints were (and are): flash, ram AND time and Python is not fast... Unless you write a low level library in... guess what? C or similar...

[uliano]

Python doesn't check types...

It does but the type for a variable is determined by what you assign to it initially. You'll need to convert between types if you want to assign variables with different types. If there is a mismatch, you'll get a runtime error.

I strongly advise you to revise your Python...

[tggzzz]

When people start comparing types in languages, I like to annoy them by pointing out that Smalltalk (and Python) is strongly typed whereas C is untyped.

When they start huffing and puffing, I refine that to:

• in C, variables are typed but data untyped. That's why you can cast a Person into Concrete
• in Smalltalk, variables are untyped but the data is strongly typed. There's no way you can coerce the program into treating a Person as a Dog

Java has the best of both worlds: both variables and data are strongly typed.

The advantage of strongly typed data is obvious. Having strongly typed variables is the starting point for that wonder of decent IDEs: cntl-space for autocompletion

[nctnico]

Python doesn't check types...

It does but the type for a variable is determined by what you assign to it initially. You'll need to convert between types if you want to assign variables with different types. If there is a mismatch, you'll get a runtime error.

I strongly advise you to revise your Python...

I've been using Python (version 3) quite a bit lately and adding a variable which has a number to one that has a string doesn't work.

 The controller to be used in the project I'm currently working on has about 1MB or RAM and several MB of flash while it costs somewhere around US $4 in small quantities.

and also runs ta a few dozen GHz? as the constraints were (and are): flash, ram AND time and Python is not fast... Unless you write a low level library in... guess what? C or similar...

No. Somewhere around 130MHz. IIRC the controller maxes out at 250MHz. Typically I don't worry about execution speed until it is a problem. Optimising for speed takes an exponential amount of time (=money) so the least you have to optimise, the lower the NRE costs. Worrying about speed upfront is like wanting to buy a vehicle without knowing what you need to transport. A definition for a solution can only come from a definition of a problem.

[NorthGuy]

The controller to be used in the project I'm currently working on has about 1MB or RAM and several MB of flash while it costs somewhere around US $4 in small quantities.

We live in different worlds. I just went to DigiKey and selected all the MCUs with at least 1MB RAM and 4MB flash, and the cheapest for quantity of 1000 came at US $13 ($15 if you count only those that they have 1000 in stock).

[coppice]

• in C, variables are typed but data untyped. That's why you can cast a Person into Concrete

Have you been developing any bridging software? Your comment seems foundational for that market.

[uliano]

Python OBJECTS are typed, variables are just names referring to them and DON'T carry ANY type along, they just adapt to what they are referring to, moment by moment.

Python (recent versions) has type annotations AKA type hints

IDE need to know function/method prototypes to make their wonders and Python doesn't enforce that.

Various approach have been taken either by libraries or IDE to document their content: generating stubs, reading all code...

[tggzzz]

• in C, variables are typed but data untyped. That's why you can cast a Person into Concrete

Have you been developing any bridging software? Your comment seems foundational for that market.

Nah. While I might think some of the people I've worked with/for are a mob, I've never worked with the mob. There are some people that I've encountered that made me wish I was a crow, though, so I could use "mob" as a verb.