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

[NorthGuy]

Are the people claiming that C is a 'safe programming language' seriously going to argue that having all these safety features in cars, that are statistically proven to save lifes / prevent injuries, are nonsense as well?

What you need from the language is functionality, not safety. If your car doesn't run, you can wear a seat belt all day long and it won't do you any good.

The amount of problems you encounter during development will depend first and foremost on your design. If you design complicated contrived data structures, use over-complicated algorithms which involve lots lots of special processing and bloat, then the probability of making mistakes increases manifold. In contrast, if you come up with simple data structures and elegant algorithms, you will write less, you will make less bugs, and, more importantly your bugs will be easier to find and fix.

When it comes to choosing a language, you must chose a language which allows you to implement your beautiful elegant design. If you chose otherwise, you will have to abandon your design, make new design, write more code, make your code needlessly complex, prone to bugs. Moreover, the final product will not work as well as it would've if you could implement your original design.

When you write your code, you will make mistakes, like you may write "==" instead of "=" or vice versa, or you can type a wrong variable name, who knows. Some of them may make it through a compiler and cause strange behaviour. I don't see a big deal in correcting these or similar. This is really nothing compared to the fact that you can implement your design, because if you can't then this is a much bigger problem.

If I can do my design in either C or in Rust, then there's really no much difference. I certainly would choose C, but if I had more experience in Rust I could've chosen Rust. As long as I can implement the design. But if I can implement something in C, but cannot implement the same in Python, I wouldn't want to complicate my life just because someone on the Internet has an irrational belief that using Python would make your program safer, would I?

[tggzzz]

Too often the "I am good enough to use knives safely" chain of reasoning thought is merely an excuse for not learning how to use new tools to best advantage.

It's an excuse if you are comfortable enough with your current technology to not have to move onwards and step on new and unknown grounds.
I can see how this happens, but when something much better presents itself without many trade-offs, I would still make the jump.

The trick is to spot when a new language really does offer something new and beneficial. Too many languages are new without offering significant new benefits. There will always be penalties with jumping ship to a new language; the benefits must exceed the prenalties.

[pcprogrammer]

That is exactly where the problem is: only a few outliers make few mistakes. The rest are just normal humans. What I'm seeing from the workfloor is that common programmers do make mistakes. What do you want to do about that? Fire them and hire programmers that don't exist? Or choose a different programming language that makes those programmers more productive? Cost wise, the choice is pretty clear to me.

Only if the language is suited for the job, and not creating other problems instead. To quote our famous soccer player Johan Cruijf, "every advantage has its disadvantage". A good example of cost wise backfiring is outsourcing to cheap labor countries. Managers think they save lots of money that way, but in the end have to pay more to get a proper working product. Same can happen here.

How about educating your programmers to become better at the job, instead of having them learn another languages with its own set of problems. Put more focus on testing, instead of trying to avoid making the mistakes, have them learn from these mistakes.

In the end you can't fix stupid but catching (common) mistakes is very possible. And that is precisely the goal of those safety features. BTW: I was thinking about adding this text in my original posting but I choose not to. Maybe I should have to avoid people bringing up this nonsense argument. Next thing you know some will come up with stories how seatbelts makes things worse despite the statistics (that paint the big picture) telling otherwise.

You can call it a nonsense argument but it is still valid for a certain percentage of the population. If everybody on the planet was wise and responsible we would not need those safety features in the first place. But unfortunately that is not the case. Probably part of the reason why the seemingly safer programming languages are invented. To allow more people into programming. Is it a real improvement, I don't know. There is also a lot of shit being produced with all these languages. And don't forget that these languages have their own bugs too. Sure they will be ironed out over time, but can make live miserable for a while.

[pcprogrammer]

Acknowledge the fossils afraid of learning a new language (heavens!) and disregard their noise.

Who says we are afraid of learning new languages. I'm not, but will do so only when I feel the need for it and it solves problems I might have with some project that can't be solved with what I'm using normally.

And yes it is very wise to advice against listening to >30-40 years of experience. Nothing can be learned from that for sure. 

The thing is that I have not ran into the need of learning a new programming language for a long time until now. The new programming language I'm learning at the moment is a graphical one called robopro to make fischertechnik models work. Not very spectacular or capable to use for big complex projects but something new just the same.

My bet is that most of the what you call fossils are glad and willing to learn something new every day because that is in their nature.

[peter-h]

Had a quick scan of this thread.

I think there is too much polarisation. It's not black and white.

I go back to ~1978 when Coral and later Ada were used in the military business. The problem with that business is that the contractor gets a contract to develop say a new torpedo, and 300 programmers are recruited for the contract. When this is done, say 2 years later, they all get laid off (fired). Then it repeats. So you need a language which can be used to write code which isn't total crap, in that scenario, and that is really difficult.

Same in a big company where you might have 20 coders working on one product. Out of those 20, maybe 5 will be good. But if you want the finished thing to work, you probably can't use C.

Then throw in the lack of code comments which is a fashion among coders (except those writing asm) and lack of documentation (unless absolutely enforced) done to make laying off as unpleasant as possible for the company.

Then throw in the need to pick up the product 5-10 years later. By that time the original coders have moved on. Especially if they were contractors; I'd say 90% are gone after 5 years (usually got a full time job, for less money but much better security).

For server-side stuff I always specify PHP. Other stuff, and most of the trendy frameworks, will be old hat at 5-10 years. Look at Ruby. Java produces a vast amount of just-working code, low performance, impossible to maintain.

C will be around for ever. But you need to get somebody good, and you need to make them test and document stuff.

Some other language just means your choice of coders will be really narrow. It takes years to become productive in a new language. And it looks terrible on a CV

I am not saying C is good; I am being practical.

[SiliconWizard]

As a side and related note, any developer not capable of writing robust C is probably not fit for teaching anyone how to develop and what kind of language they should use.

I hate to engage in these threads, because it's just pollution, but this little slight is just sad. Do you derive joy from making any reader feel inferior -- and worse, feel like they aren't qualified to teach anyone anything in programming, which is honestly worse, because teaching is a bidirectional learning process -- on the condition of them not matching your unstated, vague specification of "robust C" ? You're better than this, man.

Every time I've heard someone gatekeep like this

       
For someone who "hates" to engage in "these threads", you sure seem quite ill-minded and are twisting the whole thing around pretty bad.

We are being lectured how linux kernel is crap, our working methods are crap, C is crap, by some self-proclaimed "experts" who think Python is a silver bullet. I'm surprised The Excellency of ChatGPT hasn't been mentioned yet.

We are doing nothing else but simply say the truth out loud. It is your choice to get offended by it. I'm 99.999% sure SiliconWizard never meant any offence.

Yep. If I had a YT channel and I had said that in a video, I'm pretty sure I would have received death threats.

[coppice]

Then throw in the lack of code comments which is a fashion among coders (except those writing asm) and lack of documentation (unless absolutely enforced) done to make laying off as unpleasant as possible for the company.

Oh, that old chestnut. I've spent long periods taking projects that went astray, and getting them back in good order. The first thing to do with most code is strip out all the comments. They rarely illuminate anything. They are usually sufficiently out of date they just confuse you, and they bulk up the code making it harder to scan through. Next step is to reformat everything to a consistent layout to improve readability. Next comes identifying what symbols like asdoigildub actual mean, and globally editing them to something more meaningful. That's not an easy task is the average program which reused the same name for a whole bunch of things in different parts of the code. Good practice is to make the code readable, not the comments. The compiler will check the code is up to date. It won't check that the comments haven't been meaningful for the past 2 years. Comments should be for things like "this bit might seem completely stupid, but it deals with this obscure issue it took ages for us to flush out".

[peter-h]

Sure, but if people write crap code, they will write crap code in any language.

[Siwastaja]

Are the people claiming that C is a 'safe programming language'

But no one ever claimed that. This is a totally ridiculous strawman argument. You are picking fight for no apparent reason. All that was questioned was that safer languages (than C) are silver bullets that significantly reduce number of dangerous bugs. This is not true. Most bugs are not caused by lack of automated memory range checking, zero terminated strings and other classic similar C issues (which we all agree are dangerous); but logical thinking errors in higher level design, implementation of algorithms, failure to sanitize inputs and doing the wrong thing as a result, and so on.

There is also an impression that languages which do not allow overindexing a table or casting a type to other, do not require nearly as much input validation. This is also wrong. Projects that depend on automatic escalation of exceptions to a top level handler (or worse, no handling at all), because developers were lazy and/or thought "the language takes care of it", are notoriously fragile. On a PC, they just crash with a massive wall of text. On embedded, you don't even get that; the thing just dies.

Failing less dramatically is still failing, and especially in embedded, the difference is surprisingly small.

[peter-h]

I agree.

Look at Pascal. All the rage when I was at univ. IAR and others had a go at getting it into embedded. What did it do? Reduce productivity

I used it quite a lot, back then and since.

[tggzzz]

Are the people claiming that C is a 'safe programming language'

But no one ever claimed that. This is a totally ridiculous strawman argument. You are picking fight for no apparent reason. All that was questioned was that safer languages (than C) are silver bullets that significantly reduce number of dangerous bugs. This is not true. Most bugs are not caused by lack of automated memory range checking, zero terminated strings and other classic similar C issues (which we all agree are dangerous); but logical thinking errors in higher level design, implementation of algorithms, failure to sanitize inputs and doing the wrong thing as a result, and so on.

Not "caused by...", but certainly "enabled by...", especially in conjunction with commercial pressures and human frailties.

There is also an impression that languages which do not allow overindexing a table or casting a type to other, do not require nearly as much input validation. This is also wrong. Projects that depend on automatic escalation of exceptions to a top level handler (or worse, no handling at all), because developers were lazy and/or thought "the language takes care of it", are notoriously fragile. On a PC, they just crash with a massive wall of text. On embedded, you don't even get that; the thing just dies.

Agreed. Input validation is always a requirement, to contain errors and to assign [legal,technical] liability.

I hate the modern trend towards having "unchecked exceptions" silently passed up the stack.

A major benefit of "checked exceptions" is that the different ways in which a subsystem can fail are forced in your face and cannot be ignored. Either you deal with them or force somebody else to deal with them. There's nothing preventing silently swallowing exceptions, but that is an explicit visible decision, and the version control system will show who committed the sin. (Yes, I have seen a project where NullPointerExceptions were routinely swallowed )

[Siwastaja]

The "power" of exception system in general is, it supposedly saves developer time: one does not need to check everywhere because they propagate. But this power is also the danger of the system.

C does not come with such power built-in (let's forget setjmp/longjmp stuff), forcing the developers to do good old if(check) return ERR; stuff. Most of us complain about this being a lot of work; but later accept that as a necessary fact of life.

The flawed argument we see is: "because C is low level, C has power, and with power, comes danger and responsibilities". The next argument is, "high level languages are very powerful and save time". For some illogical reason, people think that kind of power is free from danger and responsibilities. It isn't. Exception system is a perfect example. It's an advanced goto on steroids. And it's 1000 times more dangerous than goto, exactly because it saves one from repetitive work. That repetitive work was important.

[tggzzz]

The "power" of exception system in general is, it supposedly saves developer time: one does not need to check everywhere because they propagate. But this power is also the danger of the system.

I disagree.

The power of an exception system is that the user of a module is forcibly confronted with the ways in which it can fail. They then have to explicitly deal with the failure or explicitly punt the responsibility somewhere else.

Unchecked exceptions subvert that benefit, just as "unsafe" keywords subvert the benefits of managed environments.

The interesting boundary is things like division by zero. If a module invokes tan(x), then there is the possibility of a division by zero inside the tan() function. In my opinion a /0 exception should be caught near the tan(x) operation, and mutated into another exception that is specific to the module's function and operation[1]. That new exception can then be passed upwards if appropriate.

Of course, if it doesn't matter whether the software works reliably and predictably, then any discussion of exceptions is moot ;}

[1] even an "oh shit wake up the lawyer" exception is acceptable

[nctnico]

Are the people claiming that C is a 'safe programming language'

But no one ever claimed that. This is a totally ridiculous strawman argument. You are picking fight for no apparent reason.

I'm not picking a fight at all. It is you who is getting utterly defensive over a very narrow range of issues and losing track of the big picture.

All that was questioned was that safer languages (than C) are silver bullets that significantly reduce number of dangerous bugs. This is not true. Most bugs are not caused by lack of automated memory range checking, zero terminated strings and other classic similar C issues (which we all agree are dangerous); but logical thinking errors in higher level design, implementation of algorithms, failure to sanitize inputs and doing the wrong thing as a result, and so on.

Such bugs are easy to find, easy to test for and easy to fix; the program does not behave as it should given a certain input / condition. If software gets released in such a state, management is to blame for not allowing enough development & testing time.

However, in my experience the pitfalls of C are the cause of the bugs that are the hardest to find (and thus take a lot of time). Avoiding those pitfalls is rather tedious as well. On top of that I see less experienced programmers step into those pitfalls quite often leading to code that is not as robust as it should be. So to me it makes a lot of sense to look at different programming languages that lead to better (=more robust) code with less effort. That takes care of at least one source of bugs; I'm making a clear distinction between 'language induced bugs' and 'programming error' here. I'm not saying such a language exists or a particular language is best but I'm certainly interested in alternatives for C for use on microcontrollers. In all my previous postings in this thread I listed Python and Lua as examples of possibilities. Not to be silver bullets; I have used the word 'example' a couple of times.

After programming in C and working with other people on C software for several decades, I simply noticed several drawbacks of using C which are technical, human resource and human nature related. Some of these drawbacks can be addressed effectively by using a different language (either as part of the mix or as a replacement). Personally I can't ignore that outside of embedded programming world, the C programming language is used very little so other languages must have at least some merit.

[tggzzz]

Are the people claiming that C is a 'safe programming language'

But no one ever claimed that. This is a totally ridiculous strawman argument. You are picking fight for no apparent reason.

I'm not picking a fight at all. It is you who is getting utterly defensive over a very narrow range of issues and losing track of the big picture.

All that was questioned was that safer languages (than C) are silver bullets that significantly reduce number of dangerous bugs. This is not true. Most bugs are not caused by lack of automated memory range checking, zero terminated strings and other classic similar C issues (which we all agree are dangerous); but logical thinking errors in higher level design, implementation of algorithms, failure to sanitize inputs and doing the wrong thing as a result, and so on.

Such bugs are easy to find, easy to test for and easy to fix; the program does not behave as it should given a certain input / condition. If software gets released in such a state, management is to blame for not allowing enough development & testing time.

Perhaps - the code you or your organisation write. But most projects include code from other people organisations.

Your comments below indicate you realise that, but it is worth emphasising

However, in my experience the pitfalls of C are the cause of the bugs that are the hardest to find (and thus take a lot of time). Avoiding those pitfalls is rather tedious as well. On top of that I see less experienced programmers step into those pitfalls quite often leading to code that is not as robust as it should be. So to me it makes a lot of sense to look at different programming languages that lead to better (=more robust) code with less effort. That takes care of at least one source of bugs. I'm not saying such a language exists or a particular language is best but I'm certainly interested in alternatives for C for use on microcontrollers. In all my previous postings in this thread I listed Python and Lua as examples of possibilities. Not to be silver bullets; I have used the word 'example' a couple of times.

After programming in C and working with other people on C software for several decades, I simply noticed several drawbacks of using C which are technical, human resource and human nature related. Some of these drawbacks can be addressed effectively by using a different language (either as part of the mix or as a replacement). Personally I can't ignore that outside of embedded programming world, the C programming language is used very little so other languages must have at least some merit.

Just so.

My "report card" summary of C: "Adequate, but could do better. Improvement required".

[peter-h]

The context here is "embedded" and there you usually have a huge problem when compared to other uses: no user interface capable of reporting errors.

So all the stuff which Language X might have to prevent say buffer overflow is of no use, because the product will just crash, or maybe reboot, perhaps with a watchdog reset.

AFAICT the only benefit some other language might have is better static analysis. Like avoiding this kind of time wasting mess
https://www.eevblog.com/forum/microcontrollers/a-question-on-gcc-ld-linker-script-syntax/msg4764548/#msg4764548
And yes that mess was caused by idiotic programming, using weak functions which enable a project to build but not work. Idiotic programming is language independent

[nctnico]

The context here is "embedded" and there you usually have a huge problem when compared to other uses: no user interface capable of reporting errors.

The same goes for tons of software running on servers and background processes running on desktop PCs; there is no error reporting UI either.

So all the stuff which Language X might have to prevent say buffer overflow is of no use, because the product will just crash, or maybe reboot, perhaps with a watchdog reset.

No. If you use a language that can iterate through an array without the programmer needing to know the actual array bounds, you already prevent 99% of the mistakes made when using array sizes in C. From what I have seen is that having an array with 10 elements numbered from 0 to 9 is very counter intuitive to many. Even seasoned C programmers slip up every now and then. Or take the extra 0 at the end of a string in C. Not many answer that question correctly during a job interview. All the more reason to use a language that doesn't need attention to such details.

[uliano]

Fun fact: most post in this thread are about C.

[peter-h]

The same goes for tons of software running on servers and background processes running on desktop PCs; there is no error reporting UI either.

Well, depends. Take Windows 3.1. You'd be doing well if you got more than a few hours out of it before a GPF error. And M$ got "telemetry" from these; in the old days via bug reports and in later versions via actual telemetry. So the bugs could be fixed. In embedded you rarely get the option to do telemetry.

[nctnico]

The same goes for tons of software running on servers and background processes running on desktop PCs; there is no error reporting UI either.

Well, depends. Take Windows 3.1. You'd be doing well if you got more than a few hours out of it before a GPF error. And M$ got "telemetry" from these; in the old days via bug reports and in later versions via actual telemetry. So the bugs could be fixed. In embedded you rarely get the option to do telemetry.

All the more reason to minimise the chance on making mistakes. However, it also helps a lot to make an embedded device as debuggable as possible. Typically I have a status LED, a command line interface and serial debug output that provides status changes and data. This has been proven to be super helpful to diagnose problems from systems that are in-situ and solve bugs without needing to go to the customer's location.

[NorthGuy]

Fun fact: most post in this thread are about C.

They try to make it into a "C vs Rust" discussion. People will take sides. The funny thing is that by taking a side, regardless of what side you're taking, you silently agree that software engineering is about languages. It is not. The practical difference between "bad" and "good" designs is such that it simply dwarfs the difference between languages.

It would be easy to demonstrate if you actually gave the same project to 1000 different software designers using different languages and compared the results. But there's no such studies. And there never will be

But you can do it in micro-scale by yourself. Get a small project. Implement it in Rust. Implement it in C for comparison. Post the results.

[peter-h]

I would still say that if I was contracting out something which needs to work and be "workable on" by others well into the future, I would not allow the use of some "wonderful new language" because I know full well that it will bite me in the bum

Outside of embedded, and particularly server-side, we see a new "paradigm" every month, with fashionable new "frameworks" all the time. That's why most people over about 40 are sick of that work. But we've seen all kinds of these initiatives even in embedded. I recall somebody pushing Forth some years ago. You just know that when that guy retires, disappears, or dies, your product will be dead as far as any maintenance goes.

C is reasonably future-proof. You still have to get a coder who is careful, but that's true for any language. Well, except Java, where the application of unlimited money, say $100 per line, will eventually deliver something which isn't complete crap

[nctnico]

There is another facet to this discussion. One recurring question I have gotten from various customers is that they want to be able to make changes to the software themselves in an easy way. I noticed that as soon as I pointed them to a fully fledged IDE with libraries they have to install and deal with programming hardware, they become awfully quiet and let go of the idea. So I went looking for an alternative. For a couple of embedded Linux projects I have implemented the logic for an application using Lua. The Lua script is a seperate file that can be uploaded onto the device using a USB stick. Before deployment, the code can be tested using a testbench that can run on a PC. For most this is way more accessible compared messing around in C directly.

Where it comes microcontroller based projects I had to dissapoint my customers so far. And truth to be told, I have created several projects that implement complicated logic; this would have been easier to implement in Lua for me as well. So I have set a goal for myself to have an off-the-shelve Lua implementation that I can use on (OS-less) microcontroller projects. Still, when I mention Lua the reception is luke warm. I always get the question: can't you use Python instead of Lua? I know I'm back at Lua and Python right now but this is because I know Lua better than Python while my customers are asking for Python.

[peter-h]

Python is certainly very much in vogue right now.

It's not easy to work out how long this will last. Also while those writing code, in most companies, are relatively young, the decisionmakers (the successful ones) tend to be a lot older. Also those writing code are generally happy to do anything that puts bread on the table at home (regardless of their company's success), those who own the companies need to think much more long-term.

And embedded is just a very different world to everything else (not least due to the extreme difficulties of fixing bugs in the field, and the commercial risk of delivering 10k boxes which turn out to have a bug - stuff which is regarded as both normal and commercially acceptable in other sectors) yet I think many (not you) conflate embedded with the more trendy stuff like server-side tools.

There is a similarity between C for embedded, and PHP for server-side. Both are slagged off by many as crap, insecure, blah blah, but both represent by far the most long term maintainable approaches.

[nctnico]

Offtopic: I strongly doubt PHP will remain for (web) server side programming. I have been involved in various projects at several clients that collect data on a server and all use Python. The Python libraries that help implement web / data services pack a serious punch. It takes surprisingly little programming effort (*) to make -for example- a database driven online inventory system using Python. The strong point of Python is that it is a programming language that universally useable so knowledge can be re-used more effectively. Or to be more precise: the ecosystem around Python is way more universal compared to PHP. But this is based on my own observations that may not be representative for the entire world.


* Early this millenium I have done quite a bit of PHP programming myself for web applications so I do know the basics and what is involved.