What do you think about different languages than usual C for embedded
systems?
I mean C++, Ada but also Python. Always more powerful embedded
processors are coming, so I expect new and modern languages will enter
in the embedded world.
Hardware are cheaper and more powerful than ever, but software stays
expensive. New and modern languages could reduce the software cost,
because they are simpler than C and much more similar to desktop/server
programming paradigm.
We embedded sw developers were lucky: electronics and technologies
change rapidly, but sw for embedded has changed slower than
desktop/mobile sw. Think of mobile app developers: maybe they already
changed IDEs, tools and languages ten times in a few years.
C language for embedded is today very similar than 10 years ago.
However I think this situation for embedded developers will change in
the very next years. And we will be forced to learn modern technologies,
such as new languages and tools.
Is it ok for me to study and learn new things... but it will be more
difficult to acquire new skills for real jobs.
What do you think?
Reply by David Brown●April 17, 20212021-04-17
On 17/04/2021 17:48, pozz wrote:
> What do you think about different languages than usual C for embedded
> systems?
>
> I mean C++, Ada but also Python. Always more powerful embedded
> processors are coming, so I expect new and modern languages will enter
> in the embedded world.
>
> Hardware are cheaper and more powerful than ever, but software stays
> expensive. New and modern languages could reduce the software cost,
> because they are simpler than C and much more similar to desktop/server
> programming paradigm.
>
> We embedded sw developers were lucky: electronics and technologies
> change rapidly, but sw for embedded has changed slower than
> desktop/mobile sw. Think of mobile app developers: maybe they already
> changed IDEs, tools and languages ten times in a few years.
> C language for embedded is today very similar than 10 years ago.
>
> However I think this situation for embedded developers will change in
> the very next years. And we will be forced to learn modern technologies,
> such as new languages and tools.
> Is it ok for me to study and learn new things... but it will be more
> difficult to acquire new skills for real jobs.
>
> What do you think?
You should probably add Rust to your list - I think its popularity will
increase.
Python is great when you have the resources. It's the language I use
most on PC's and servers, and it is very common on embedded Linux
systems (like Pi's, and industrial equivalents). Micropython is
sometimes found on smaller systems, such as ESP32 devices.
Ada involves a fair amount of change to how you work, compared to C
development. (Disclaimer - I have only done a very small amount of Ada
coding, and no serious projects. But I have considered it as an
option.) I really don't see it becoming much more common, and outside
of niche areas (defence, aerospace) it is very rare. Programming in Ada
often takes a lot more effort even for simple things, leading quickly to
code that is so wordy that it is unclear what is going on. And most of
the advantages of Ada (such as better typing) can be achieved in C++
with less effort, and at the same time C++ can give additional safety on
resources that is harder to get on Ada. (But Ada has some nice features
introspective that C++ programmers currently only dream about.)
C++ is not uncommon in embedded systems, and I expect to see more of it.
I use it as my main embedded language now. C++ gives more scope for
getting things wrong in weird ways, and more scope for accidentally
making your binary massively larger than you expect, but with care it
makes it a lot easier to write clear code and safe code, where common C
mistakes either can't happen or you get compile-time failures.
It used to be the case that C++ compilers were expensive and poor
quality, that the resulting code was very slow on common
microcontrollers, and that the language didn't have much extra to offer
small-systems embedded developers. That, I think, has changed in all
aspects. I use gcc 10 with C++17 on Cortex-M devices, and features like
templates, strong enumerations, std::array, and controlled automatic
conversions make it easier to write good code.
Reply by Tom Gardner●April 17, 20212021-04-17
On 17/04/21 17:45, David Brown wrote:
> And most of
> the advantages of Ada (such as better typing) can be achieved in C++
> with less effort, and at the same time C++ can give additional safety on
> resources that is harder to get on Ada.
Interesting. Could you give a quick outline of that?
Reply by Clifford Heath●April 17, 20212021-04-17
On 18/4/21 2:45 am, David Brown wrote:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> Hardware are cheaper and more powerful than ever, but software stays
>> expensive. New and modern languages could reduce the software cost,
>> because they are simpler than C and much more similar to desktop/server
>> programming paradigm.
>>
>> We embedded sw developers were lucky: electronics and technologies
>> change rapidly, but sw for embedded has changed slower than
>> desktop/mobile sw. Think of mobile app developers: maybe they already
>> changed IDEs, tools and languages ten times in a few years.
>> C language for embedded is today very similar than 10 years ago.
>>
>> However I think this situation for embedded developers will change in
>> the very next years. And we will be forced to learn modern technologies,
>> such as new languages and tools.
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
>
> You should probably add Rust to your list - I think its popularity will
> increase.
+1.
I've used C++ for over 30 years, but Rust is going to rule. It's not
really any harder, but vastly safer, especially for parallel coding.
CH
Reply by Dave Nadler●April 17, 20212021-04-17
On 4/17/2021 11:48 AM, pozz wrote:
> What do you think about different languages than usual C for embedded
> systems?
>
> I mean C++, Ada but also Python. Always more powerful embedded
> processors are coming, so I expect new and modern languages will enter
> in the embedded world.
Another +1 for C++. We started using C++ for embedded ~25 years ago, and
the tool quality (and language) is vastly better now. Main problem using
C++ is lack of available qualified staff - too many still only trained
in C. C++, even more than C, *requires* painful amount of knowledge of
how things work under the hood to use safely, not a good quality for any
tool in any realm. But for *qualified* developers, C++ certainly gives
faster development, produces better (ie faster/smaller) code, and
generally improves life (compared to C).
Reply by Don Y●April 17, 20212021-04-17
On 4/17/2021 6:07 PM, Dave Nadler wrote:
> Another +1 for C++. We started using C++ for embedded ~25 years ago, and the
> tool quality (and language) is vastly better now. Main problem using C++ is
> lack of available qualified staff - too many still only trained in C. C++, even
> more than C, *requires* painful amount of knowledge of how things work under
> the hood to use safely, not a good quality for any tool in any realm. But for
> *qualified* developers, C++ certainly gives faster development, produces better
> (ie faster/smaller) code, and generally improves life (compared to C).
This is exactly why I *don't* use C++ (or any "new fangled" languages)
for product development. I'm often the "Rev 1" author of a product.
Then, move on (to another product, another client, another application
domain).
I'm contractually obligated to fix bugs in my code (indefinitely and at no
charge) -- it's one of my selling points ("Yes, I'm *that* confident in the
code I've created for you!")
The last thing I need is some coder-wannabe tweeking my code with some
"harmless" change... then, defiantly claiming (to his management)
that the newly broken code is a consequence of my initial design
(he's just UNCOVERED a bug).
So, I get called back to *teach* the dweeb why what he's done
won't work. And, in the process, inevitably have to show him
how to do what he wants to do.
Yeah, I can bill the client -- which is countered with "but you said
you'd support your code, for free?" (yeah, but that wasn't MY code!).
Regardless, I'm not keen on spending my time as a tutor!
Or, swallow it as cost of doing business.
It's considerably easier to find multiple C coders (and hope one
of them will catch the guy's mistake) than a qualified C++, Erlang,
Python, etc. coder -- esp when you're dealing with small firms.
So, my strategy becomes: "Have you rebuilt MY sources using the
tools that *I* used? Does the product exhibit this bug? If not,
it's not my problem!"
[I can do this even with some other language. But, the dweeb will
inevitably claim -- to the owner/management -- that his changes are
benign. They, of course, won't want to think they hired an inept
employee, so...]
Reply by Niklas Holsti●April 18, 20212021-04-18
On 2021-04-17 19:45, David Brown wrote:
> On 17/04/2021 17:48, pozz wrote:
>> What do you think about different languages than usual C for embedded
>> systems?
>>
>> I mean C++, Ada but also Python. Always more powerful embedded
>> processors are coming, so I expect new and modern languages will enter
>> in the embedded world.
>>
>> ...
>> Is it ok for me to study and learn new things... but it will be more
>> difficult to acquire new skills for real jobs.
>>
>> What do you think?
>
> ...
> Ada involves a fair amount of change to how you work, compared to C
> development. (Disclaimer - I have only done a very small amount of Ada
> coding, and no serious projects. But I have considered it as an
> option.) I really don't see it becoming much more common, and outside
> of niche areas (defence, aerospace) it is very rare. Programming in Ada
> often takes a lot more effort even for simple things, leading quickly to
> code that is so wordy that it is unclear what is going on.
That depends, I guess, on what one considers "simple", and also, of
course, on how familiar one is with the languages.
Perhaps it is time to link once again to the experience of C versus Ada
in an introductory embedded-programming class using a model rail-road
example, where the students using Ada fared much better than those using C:
http://archive.adaic.com/projects/atwork/trains.html
I am (as you guessed) an Ada fan, and find it a pleasure to write, even
if it takes more keystrokes than the equivalent in C.
For embedded systems in particular, I find portability to be a great
advantage of Ada. With few exceptions, the embedded program can be
exercised on the development host, and if the target supports the
standard Ada tasking system (or a subset of it), this applies even to
multi-threaded programs (without the need to emulate some embedded
RTK/OS on the host).
> And most of the advantages of Ada (such as better typing) can be
> achieved in C++ with less effort,
According to the link above, the main Ada advantage was the ability to
define one's own problem-oriented scalar types, such as integers with
specific value ranges. AIUI, this is not easily done in C++.
> and at the same time C++ can give additional safety on
> resources that is harder to get on Ada. (But Ada has some nice features
> introspective that C++ programmers currently only dream about.)
Can you be more specific on those points, please?
> It used to be the case that C++ compilers were expensive and poor
> quality, that the resulting code was very slow on common
> microcontrollers, and that the language didn't have much extra to offer
> small-systems embedded developers. That, I think, has changed in all
> aspects. I use gcc 10 with C++17 on Cortex-M devices, and features like
> templates, strong enumerations, std::array, and controlled automatic
> conversions make it easier to write good code.
AdaCore provides the gcc-based GNAT Ada compiler for several embedded
targets, free to use for open-source projects: libre.adacore.com.
Commercial projects can use Ada on other targets by means of the
(different) AdaCore compiler that generates C code as an intermediate
representation.
Reply by Tom Gardner●April 18, 20212021-04-18
On 18/04/21 02:07, Dave Nadler wrote:
> Main problem using C++ is lack of available qualified staff - too many still
> only trained in C. C++, even more than C, *requires* painful amount of knowledge
> of how things work under the hood to use safely, not a good quality for any tool
> in any realm.
Yes indeed. Especially when coupled with inexperience leading
someone to believe they understand C or C++.
Your other (valid) caveats and points snipped for brevity.
Reply by David Brown●April 18, 20212021-04-18
On 17/04/2021 20:55, Tom Gardner wrote:
> On 17/04/21 17:45, David Brown wrote:
>> And most of
>> the advantages of Ada (such as better typing) can be achieved in C++
>> with less effort, and at the same time C++ can give additional safety on
>> resources that is harder to get on Ada.�
>
> Interesting. Could you give a quick outline of that?
>
Which part?
My understanding of Ada classes is that, like Pascal classes, you need
to explicitly construct and destruct objects. This gives far greater
scope for programmers to get things wrong than when they are handled
automatically by the language.
On the other hand, some of Ada's type mechanisms make it a lot easier to
make new types with similar properties while remaining distinct (such as
subranges of integer types). You can do that in C++, but someone needs
to make the effort to make the appropriate class templates. Thus these
are more often used in Ada coding than in C++ coding.
On the third hand (three hands are always useful for programming), the
wordy nature of type conversions in Ada mean programmers would be
tempted to take shortcuts and skip these extra types.
Reply by dalai lamah●April 18, 20212021-04-18
Un bel giorno pozz digit�:
> What do you think about different languages than usual C for embedded
> systems?
>
> I mean C++, Ada but also Python. Always more powerful embedded
> processors are coming, so I expect new and modern languages will enter
> in the embedded world.
I wouldn't include C++ in the list of "modern languages". One might as well
use C.
As for the "more modern" languages (Python, C#, Java etc) I've used most of
them and maybe it's the old man in me speaking, but I haven't felt any
inherent important advantages in using them. Their success is mostly due to
better support by popular development tools.
These days, smarter people praise functional programming languages
(Haskell, Clojure, etc...). They promise tangible advantages compared to
imperative languages, especially for maintainability and reliability. But I
think that even if they will gain popularity, years would pass before you
will see real applications in the embedded world.
Python is a "hybrid", it can be also used as a functional programming
language, and it will probably gain popularity in embedded systems.
--
Fletto i muscoli e sono nel vuoto.
Signal Processing Engineer Seeking a DSP Engineer to tackle complex technical challenges. Requires expertise in DSP algorithms, EW, anti-jam, and datalink vulnerability. Qualifications: Bachelor's degree, Secret Clearance, and proficiency in waveform modulation, LPD waveforms, signal detection, MATLAB, algorithm development, RF, data links, and EW systems. The position is on-site in Huntsville, AL and can support candidates at 3+ or 10+ years of experience.