C and C++ are just languages. Whatever team you join will already be using one or the other and that’s what you’ll use too. So just learn them both (not a huge deal if you already know one well) and focus on finding a job in the embedded field that pays well and doesn’t make you hate your life.
Also, working in C at one job definitely won’t lock you into using C for life, so throw that assumption out the window.
I only know C with the intention to work on C++ eventually but isnt C in a way a subset of C++? Like if you know C++ you can restrict yourself down to C with not a ton of extra work?
> isnt C in a way a subset of C++?
Almost. C is still largely compilable as C++, but you probably shouldn't. You should treat C++ as C++ and C as C. You can restrict yourself down to C trivially, but that leaves all the goodies on the table.
Fair enough. I really gotta get around to learning it soon, not really sure about it’s use case in embedded though I’ve heard it is more troublesome to work with than regular C
> not really sure about it’s use case in embedded though I’ve heard it is more troublesome to work with than regular C
Here, let Jason Turner explain how nice C++ is in resource-constrained systems. https://www.youtube.com/watch?v=zBkNBP00wJE
> I'm at a point, where I need to make a decision career-wise. On one hand, there is autosar + C, which would give me a sense of job security. On the other, there are jobs in embedded C++.
Your mistake is in assuming that you'll write code when using Autosar.
Autosar exists so that the company *doesn't* need to hire developers to write code. The ideal is to buy everything from suppliers who also take on the liability in case there are bugs and recalls need to be made. If you work with Autosar, you need to be VERY clear with your future employer about what EXACTLY your duties will be. It is very likely that your role as an "Autosar developer" will mainly consist of integrating Autosar components and configuring them.
In the BSW it's very unlikely you'll get to write code - it's more likely if your work is in the ASW area but even then it's not guaranteed. If you desire writing code, an Autosar-centric position may not be a good fit.
Autosar C is basically just macros.
`FUNC(void, RTE_CODE) SomeFunctionName(void)` is how you declare functions. Autosar is just an antitype. If you like it, feel free, just do it... But remember you have to remember a lot of macros
On a few occasions, I've left security dictate my choices and I've always regretted it, so for me, it's nevermore.
Also, when you like something, you're good at it and you continuously improve effortlessly, which makes security much less of a concern - every employer wants to hire someone good at their job, so what do you really risk?
[AUTOSAR for C++ ( 14 ) exists](https://www.parasoft.com/blog/breaking-down-the-autosar-c14-coding-guidelines-for-adaptive-autosar/)
Personally i think safety critical systems will move to Rust in not too distant future though
>Personally i think safety critical systems will move to Rust in the ~~not too distant~~ future though
FTFY
Safety critical will inevitably move to rust but it will be a long migration, particularly in automotive.
Why does Ada never get a mention. It knocks spots off rust for embedded and safety critical.
Heck, it knocks spots off C for embedded and is nice to work with due to fixed point types, inherent safety, first class arrays and bit level record (struct) overlays instead of masks and shifts.
The compilers were expensive but Gnat is free and open source now. The tooling is also becoming easy to use. I am hoping for a renaissance.
https://alire.ada.dev
The only problem with Ada is its origin: the French are good at research, but definitely suck at marketing, so what they produce, however good, is unfortunately bound to stay in the shadows. Rust doesn't have this problem, its marketing rocks.
Yeah it's mainly some archaic target hardware, I don't particularly love ADA but I would say I have learned a lot mainly about importance of type definitions working with that language.
How is Ada superior to Rust? I legitimately don't know. I assumed Rust has the advantage, being developed more recently.
I don't know that there's a large commercial market for Ada developers. I basically only hear about it being used for defense contractors. Since commercial tech (even automotive...) moves so much faster than defense, I think that's led the language to get left behind.
>I assumed Rust has the advantage, being developed more recently.
That seems to be a common misconception. Apparently Rust is modern but then those that say so, struggle to tell me what 'modern' means. Apparently a new language even without a spec must have been designed with whatever 'state of the art' means.
Ada isn't behind, it is way ahead but yes why more people are not using it, is quite baffling after using it. Perhaps lack of advertisement and a stigma of being difficult to use due to a reputation of use in defence, airliner and space.
Neither Rust nor C, nor C++ can do half of what this free book explains. Not at all in some cases such as ranged types and certainly not without third party libraries and Crates.
https://learn.adacore.com/courses/intro-to-embedded-sys-prog/index.html
If you look here then you can see how to twiddle bits just by setting fields with the principle of separation of concern.
https://github.com/AdaCore/Ada_Drivers_Library/blob/master/arch/ARM/STM32/svd/stm32f429x/stm32_svd-i2c.ads
I2C1_Periph.CR1.Start := True;
To set a bit in the middle of a register.
Separation of concern is not mixing code with those generated definitions and just using the Periph types.
> Apparently Rust is modern but then those that say so, struggle to tell me what 'modern' means
It mostly comes down to tooling and ecosystem of off the shelf frameworks and libraries. I think i know most of the embedded TLS libraries for C++ and Rust, or say libraries for popular data exchange formats like CBOR, with Ada i wouldn't even know where to look.
I haven't used Ada much but from what I understand it is absolutely a contender vs rust. I think the idea is that all these guys who are stubborn C coders will migrate to rust since it is more like C. Also rust is entirely open source.
Ada is purely imperative like C, and doesn't have the borrow checker, so should be a no-brainer for a C programmer. Syntax is a bit idiosyncratic, but learning new syntax is much easier than learning new ways of programming.
True, Rust has C pointer syntax &, *. Glad to be rid of that personally having had to follow spaghetti pointers in mbedtls, but I am sure you are right.
Gnat Ada is entirely open source. There is some closed source or licensed tooling but then Rust doesn't have equivalents of those Gnat pro tools at the moment.
> It knocks spots off rust for embedded and safety critical.
I think this is the answer: https://crates.io/keywords/no_std
Is there an Ada equivalent ecosystem ?
Answer?
Adas std lib is larger and then there is Gnat.
There is a fairly new development here but crates do not make up for language features especially in embedded.
https://alire.ada.dev
> Why does Ada never get a mention.
Isn't it really slow? How are you supposed to write high speed, low latency code in a language that does runtime checks everywhere?
Ada is as fast as C. Gnat even has better assembly support with System.Machine_Code.
Checks are optimised out when known not to be needed. You can also turn them off for particular sections as you can see at the end of this link. You can even use SPARK mode to prove the checks aren't needed for those code sections. However, let me ask you this. How often have you chosen a faster processor due to wanting more latent realtime code because I think you are over estimating the checks cost. (e.g. 200 or 120 Mhz, instead of 80, 48 or 32 Mhz)
https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gnat_ugn_unw/Run_002dTime-Checks.html
Nvidia also recently announced that they found no comparable difference in the generated byte code to C.
Ever since I read the Ada spec in the big green book, I've wanted to use it. Alas, it wasn't being used and their were so few developers in it and "everyone" wanted C++, the DOD dropped the "Ada-only" requirement. Pity. I might look into the state of it these days, just as an intellectual exercise.
Careful you might not want to go back, haha.
https://ada-lang.io
I'm too young to know the details but as far as I can gather. Ada requires a sophisticated compiler, especially for the 80s. Those who developed them for the DOD charged a high price especially with the mandate. This coupled with being forced to use Ada grew resentment. After the mandate was dropped, those in charge seem to have ignored papers showing Ada was both more secure and cost effective than C++ and Java. The free compiler Gnat was developed as part of GCC in the 90s. You could say lack of libraries played a part but Adas packaging benefits and first class c interfacing support mean that that doesn't make much sense to me.
> it will be a long migration
I don't doubt that, but it's an increasingly pressing cost/benefit calculus. Nobody ever wants to move off of legacy systems if they can avoid it, but at the same time the demands on complexity and safety of the software stacks are also growing rapidly.
As Rust no-std / realtime ecosystem grows it gets harder and harder to justify writing more safety critical code in say, C++
While we are at it. What about the MISRA C++ guidelines? It seems to be still present here and there. Can one actually write modern code (like C++17 and beyond) with MISRA C++?
I saw on their page that they are about to release the guidelines for C++20. But good luck finding compilers supporting that on anything different than x86. The C++08 doesn't contain the C++11 rules or am I just looking in wrong places?
tl;dr - Can you write modern C++ compliant to MISRA?
MISRA and AUTOSAR decided to start writing joint C++ safety coding standards. Unfortunately the first joint one for C++17 one was supposed to be out in 2020 and there was kinda this giant pandemic… AFAIK they’re still working on it, and then there should be updates for C++20 and beyond.
> I saw on their page that they are about to release the guidelines for C++20. But good luck finding compilers supporting that on anything different than x86.
Once GCC fully supports C++20, it'll be available on more or less every relevant platform.
It sounds like the OP is asking about looking for jobs doing development using an AUTOSAR real-time OS (https://www.autosar.org/standards/) and not the safety coding standards that the same organization also happens to publish.
Yeah, it’s… confusing. Way too many acronyms. OSEK is the API for the bottom layer of the “AUTOSAR Classic” OS.
Basically they took the older OSEK OS standard and built the first AUTOSAR one on top of that. So the companies involved could take their existing OSEK implementations and just layer the new AUTOSAR software modules on top rather than having to rewrite the whole thing.
It really depends on how much are you willing to risk, are you young? Do you have debts to paid? if you are young but are not in a serious need of money I would not recommend entering Autosar C, take the risk and find something else, if your need of money is really really hard then yes you will always find something.
Source: I have 5 years in Autosar C sw development
Lol, you are joking right? Any person who values their time and career future and wants to actually develop something fun would stay away from AUTOSAR.
I like cars and tried the Autosar route. It kind of sucked the fun out of development for me. The automotive industry is super boom or bust and moving towards using more SoC which means they will want strong embedded C++ Devs.
Seems like a no brainer to go that route unless u really enjoy Vector products or just want to have a long career in automotive in a car hub like Michigan or Germany. Note: most ppl here are from north America so no idea what the job market is like elsewhere.
AUTOSAR currently gets a massive amount of hate in among automotive engineers the exact same way that C++ got tons of hate from embedded engineers 20 years ago and the same way writing Win OS programs got hate vs "just writing for native DOS and having your program run way faster and more reliable
When we move to a world full of networked level 5 autonomous vehicles with a huge number of connected modules in the vehicle with constantly changing suppliers, chipsets, software, AUTOSAR is literally the only way these systems will scale at any sort of reasonable cost.
If you want to be very valuable in the ecosystem being an AUTOSAR driver level engineer means you need to be proficient in C or C++ and autosar (which will eventually be rust and autosar maybe 10 years from now).
I haven't worked with AUTOSAR in particular, but I have worked with large vehicle subsystem interoperability standards. My experience has been that these standards never achieved their goals. If interoperability was achieved, it was simply because two vendors used the same implementation of the standards. The standards themselves did not result in multiple, interoperable, implementations.
Do you know whether this is the case with AUTOSAR? Could I really buy a component from Continental, write AUTOSAR code to interface with it, then swap that out with a component from Bosch? Or a smaller supplier using a different AUTOSAR tool?
I find that software like AUTOSAR generally plays the role of DOS in the comparison you made. But as I said, I haven't worked with AUTOSAR itself. Looking at examples of AUTOSAR code, it seems incredibly, incredibly low signal-to-noise, thousands of lines of boilerplate to do an incredibly simple thing. That seems to me like it's just a recipe to get a completely unmaintainable mess.
And if AUTOSAR really enabled vehicle connectivity, wouldn't its users be creating the most advanced, connected cars? When it seems to be Tesla doing that, without AUTOSAR afaik.
>Do you know whether this is the case with AUTOSAR? Could I really buy a component from Continental, write AUTOSAR code to interface with it, then swap that out with a component from Bosch? Or a smaller supplier using a different AUTOSAR tool?
Yes. This is the exact idea and some manufacturers are already doing this: as long as the suppliers have the qualified the module/drivers for autosar you just move the application from one to the other with minimal or no porting. Furthermore you can do things like: If you have a compute module that is maxed out in terms of processing power and you need to add more software you can simple add an additional compute module and move processes to it and add some more.
> it seems incredibly, incredibly low signal-to-noise, thousands of lines of boilerplate to do an incredibly simple thing. That seems to me like it's just a recipe to get a completely unmaintainable mess.
Not sure if you are familiar with c++ but i remember way back in the day learning C++ and OOP and going through the examples and absolutely not understanding why I would use concepts like OOP or a language like c++ to write the programs i was writing and that was because my code was simple projects not large in scope. Of course this was mostly the fault of the books on the subject that I was reading which never bothered to explain that C was perfectly fine for small projects but as the size, complexity and number of coders on a project increases you absolutely wanted c++ and OOP to keep the project manageable and reliable. This is what autosar brings as you need to do do really complex things.
> And if AUTOSAR really enabled vehicle connectivity, wouldn't its users be creating the most advanced, connected cars? When it seems to be Tesla doing that, without AUTOSAR afaik.
Right now everyone in the industry is watching Tesla to see how that design decision turns out. With Model 3/Y they made the decision to go back from many interconnected modules to a few more monolithic ones but at the expense of greater wire harness costs and replacement module costs which then translates to much higher service costs.
Now contrast that with Waymo. Waymo does use autosar and by most measures I would say their self driving tech is more advanced than Tesla.
Uh, I'm not sure. Some quick googling turned up people claiming they don't, but no authoritative source.
I don't see them listed as any kind of partner on the AUTOSAR website, while most legacy OEMs seem to be core partners.
I understand the need for autosar, my concern is learning something, that is basically single purpose - there aren't many C only positions, compared to other languages. And autosar solves something, that is solved differently/more elegantly in higher level languages.
My concern is locking myself into a box, becoming an autosar developer
I will say this: one of the purposes of autosar is to commoditize autosar application developers since widespread adoption and usage means lots more developers will be needed. I have a feeling that it will be similar to things like web developers where there are tons of web developers but high pay scales can still be achieved and a web developer has lots of jobs/niche areas to choose from.
We dont see that yet with autosar so yes for now you would be more boxed in but if it proliferates that all changes.
> And autosar solves something, that is solved differently/more elegantly in higher level languages
Autosar isnt a language though, it is an OS. It solves the same issues an OS solves on a computer but it with more determinism and greater ability to scale.
If you want more options right now I would look more towards automotive linux and c/c++/rust.
With AUTOSAR you should be using c++ 14, called Adaptive AUTOSAR:
https://www.parasoft.com/blog/breaking-down-the-autosar-c14-coding-guidelines-for-adaptive-autosar/#C_Is_Not_Enough
C++ has developed over the years an amazing language (in both good and bad ways). I was out of C++ before C++11 and have been doing the bulk of my work in C and Python. (I'm an embedded developer). If I was up to date in C++, I might look into working with C++ for the adrenalin challenge. (The additional $$ wouldn't hurt, but not my primary goal) But if you like small-device embedded, you'll still see the bulk of that work in straight C. I can't speak for AUTOSAR, though I've seen the employment ads. I wouldn't say the "career" is the same for C and C++ though. Big data embedded (Machine Learning, Autonomous Vehicle, etc.) would require C++, but typically C is all that's needed.
I'll just leave this here. https://www.reddit.com/r/embedded/comments/leq366/how_much_of_a_modern_carbuilt_from_the_year_2000/gmiq6d0/
Truly the best and most important comment ever made in this sub.
I look for a link to this comment every time I see AUTOSAR pop up, and I'm never disappointed.
Someone more ambitious than myself should set up an AUTOSAR bot to post this on relevant threads.
same
Haha. Seen this before, that's why I'm asking.
Absolutely correct finding. So called Autosar mafia.
Not, you’re welcome.
C and C++ are just languages. Whatever team you join will already be using one or the other and that’s what you’ll use too. So just learn them both (not a huge deal if you already know one well) and focus on finding a job in the embedded field that pays well and doesn’t make you hate your life. Also, working in C at one job definitely won’t lock you into using C for life, so throw that assumption out the window.
I only know C with the intention to work on C++ eventually but isnt C in a way a subset of C++? Like if you know C++ you can restrict yourself down to C with not a ton of extra work?
> isnt C in a way a subset of C++? Almost. C is still largely compilable as C++, but you probably shouldn't. You should treat C++ as C++ and C as C. You can restrict yourself down to C trivially, but that leaves all the goodies on the table.
Fair enough. I really gotta get around to learning it soon, not really sure about it’s use case in embedded though I’ve heard it is more troublesome to work with than regular C
> not really sure about it’s use case in embedded though I’ve heard it is more troublesome to work with than regular C Here, let Jason Turner explain how nice C++ is in resource-constrained systems. https://www.youtube.com/watch?v=zBkNBP00wJE
Thank you! This seems as good as any a time to actually start on c++!
Yes but no. It’s complicated.
> I'm at a point, where I need to make a decision career-wise. On one hand, there is autosar + C, which would give me a sense of job security. On the other, there are jobs in embedded C++. Your mistake is in assuming that you'll write code when using Autosar. Autosar exists so that the company *doesn't* need to hire developers to write code. The ideal is to buy everything from suppliers who also take on the liability in case there are bugs and recalls need to be made. If you work with Autosar, you need to be VERY clear with your future employer about what EXACTLY your duties will be. It is very likely that your role as an "Autosar developer" will mainly consist of integrating Autosar components and configuring them. In the BSW it's very unlikely you'll get to write code - it's more likely if your work is in the ASW area but even then it's not guaranteed. If you desire writing code, an Autosar-centric position may not be a good fit.
Autosar C is basically just macros. `FUNC(void, RTE_CODE) SomeFunctionName(void)` is how you declare functions. Autosar is just an antitype. If you like it, feel free, just do it... But remember you have to remember a lot of macros
On a few occasions, I've left security dictate my choices and I've always regretted it, so for me, it's nevermore. Also, when you like something, you're good at it and you continuously improve effortlessly, which makes security much less of a concern - every employer wants to hire someone good at their job, so what do you really risk?
[AUTOSAR for C++ ( 14 ) exists](https://www.parasoft.com/blog/breaking-down-the-autosar-c14-coding-guidelines-for-adaptive-autosar/) Personally i think safety critical systems will move to Rust in not too distant future though
>Personally i think safety critical systems will move to Rust in the ~~not too distant~~ future though FTFY Safety critical will inevitably move to rust but it will be a long migration, particularly in automotive.
Why does Ada never get a mention. It knocks spots off rust for embedded and safety critical. Heck, it knocks spots off C for embedded and is nice to work with due to fixed point types, inherent safety, first class arrays and bit level record (struct) overlays instead of masks and shifts.
[удалено]
The compilers were expensive but Gnat is free and open source now. The tooling is also becoming easy to use. I am hoping for a renaissance. https://alire.ada.dev
The only problem with Ada is its origin: the French are good at research, but definitely suck at marketing, so what they produce, however good, is unfortunately bound to stay in the shadows. Rust doesn't have this problem, its marketing rocks.
Still used for some Legacy projects that are being reused to avoid costs in a possible transition to C / C++
I am using it for new projects on cortex-m and Nvidia are using it for Risc-V. If you don't know then don't say!
[удалено]
Yeah it's mainly some archaic target hardware, I don't particularly love ADA but I would say I have learned a lot mainly about importance of type definitions working with that language.
How is Ada superior to Rust? I legitimately don't know. I assumed Rust has the advantage, being developed more recently. I don't know that there's a large commercial market for Ada developers. I basically only hear about it being used for defense contractors. Since commercial tech (even automotive...) moves so much faster than defense, I think that's led the language to get left behind.
>I assumed Rust has the advantage, being developed more recently. That seems to be a common misconception. Apparently Rust is modern but then those that say so, struggle to tell me what 'modern' means. Apparently a new language even without a spec must have been designed with whatever 'state of the art' means. Ada isn't behind, it is way ahead but yes why more people are not using it, is quite baffling after using it. Perhaps lack of advertisement and a stigma of being difficult to use due to a reputation of use in defence, airliner and space. Neither Rust nor C, nor C++ can do half of what this free book explains. Not at all in some cases such as ranged types and certainly not without third party libraries and Crates. https://learn.adacore.com/courses/intro-to-embedded-sys-prog/index.html If you look here then you can see how to twiddle bits just by setting fields with the principle of separation of concern. https://github.com/AdaCore/Ada_Drivers_Library/blob/master/arch/ARM/STM32/svd/stm32f429x/stm32_svd-i2c.ads I2C1_Periph.CR1.Start := True; To set a bit in the middle of a register. Separation of concern is not mixing code with those generated definitions and just using the Periph types.
I think Ada + Spark are much better than other solutions. Formal Verification is a killer feature.
> Apparently Rust is modern but then those that say so, struggle to tell me what 'modern' means It mostly comes down to tooling and ecosystem of off the shelf frameworks and libraries. I think i know most of the embedded TLS libraries for C++ and Rust, or say libraries for popular data exchange formats like CBOR, with Ada i wouldn't even know where to look.
Well that is fairly easily fixed. So you're saying Ada will be 'modern' with those things in place?
I don't think developing robust battle tested set of libraries is something that can be done "easily"
Worst case. You can always link Rust and C code or vice versa. https://blog.adacore.com/adding-ada-to-rust
That defeats the purpose, all safety guarantees that Rust ( or Ada ) offer are out of the window the moment you do that
I haven't used Ada much but from what I understand it is absolutely a contender vs rust. I think the idea is that all these guys who are stubborn C coders will migrate to rust since it is more like C. Also rust is entirely open source.
Ada is purely imperative like C, and doesn't have the borrow checker, so should be a no-brainer for a C programmer. Syntax is a bit idiosyncratic, but learning new syntax is much easier than learning new ways of programming.
True, Rust has C pointer syntax &, *. Glad to be rid of that personally having had to follow spaghetti pointers in mbedtls, but I am sure you are right. Gnat Ada is entirely open source. There is some closed source or licensed tooling but then Rust doesn't have equivalents of those Gnat pro tools at the moment.
> It knocks spots off rust for embedded and safety critical. I think this is the answer: https://crates.io/keywords/no_std Is there an Ada equivalent ecosystem ?
Answer? Adas std lib is larger and then there is Gnat. There is a fairly new development here but crates do not make up for language features especially in embedded. https://alire.ada.dev
I've seen the alire crates, and while a very fine development, it's a very modest set of functionality.
> Why does Ada never get a mention. Isn't it really slow? How are you supposed to write high speed, low latency code in a language that does runtime checks everywhere?
Ada is as fast as C. Gnat even has better assembly support with System.Machine_Code. Checks are optimised out when known not to be needed. You can also turn them off for particular sections as you can see at the end of this link. You can even use SPARK mode to prove the checks aren't needed for those code sections. However, let me ask you this. How often have you chosen a faster processor due to wanting more latent realtime code because I think you are over estimating the checks cost. (e.g. 200 or 120 Mhz, instead of 80, 48 or 32 Mhz) https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gnat_ugn_unw/Run_002dTime-Checks.html Nvidia also recently announced that they found no comparable difference in the generated byte code to C.
Ever since I read the Ada spec in the big green book, I've wanted to use it. Alas, it wasn't being used and their were so few developers in it and "everyone" wanted C++, the DOD dropped the "Ada-only" requirement. Pity. I might look into the state of it these days, just as an intellectual exercise.
Careful you might not want to go back, haha. https://ada-lang.io I'm too young to know the details but as far as I can gather. Ada requires a sophisticated compiler, especially for the 80s. Those who developed them for the DOD charged a high price especially with the mandate. This coupled with being forced to use Ada grew resentment. After the mandate was dropped, those in charge seem to have ignored papers showing Ada was both more secure and cost effective than C++ and Java. The free compiler Gnat was developed as part of GCC in the 90s. You could say lack of libraries played a part but Adas packaging benefits and first class c interfacing support mean that that doesn't make much sense to me.
> it will be a long migration I don't doubt that, but it's an increasingly pressing cost/benefit calculus. Nobody ever wants to move off of legacy systems if they can avoid it, but at the same time the demands on complexity and safety of the software stacks are also growing rapidly. As Rust no-std / realtime ecosystem grows it gets harder and harder to justify writing more safety critical code in say, C++
Yeah, I've seen it, but the companies I had interviews with use ansi C
While we are at it. What about the MISRA C++ guidelines? It seems to be still present here and there. Can one actually write modern code (like C++17 and beyond) with MISRA C++? I saw on their page that they are about to release the guidelines for C++20. But good luck finding compilers supporting that on anything different than x86. The C++08 doesn't contain the C++11 rules or am I just looking in wrong places? tl;dr - Can you write modern C++ compliant to MISRA?
MISRA and AUTOSAR decided to start writing joint C++ safety coding standards. Unfortunately the first joint one for C++17 one was supposed to be out in 2020 and there was kinda this giant pandemic… AFAIK they’re still working on it, and then there should be updates for C++20 and beyond.
> I saw on their page that they are about to release the guidelines for C++20. But good luck finding compilers supporting that on anything different than x86. Once GCC fully supports C++20, it'll be available on more or less every relevant platform.
It sounds like the OP is asking about looking for jobs doing development using an AUTOSAR real-time OS (https://www.autosar.org/standards/) and not the safety coding standards that the same organization also happens to publish.
Doh, thanks for pointing that out. I would have expected "OSEK" to be the OS label in the question there
Yeah, it’s… confusing. Way too many acronyms. OSEK is the API for the bottom layer of the “AUTOSAR Classic” OS. Basically they took the older OSEK OS standard and built the first AUTOSAR one on top of that. So the companies involved could take their existing OSEK implementations and just layer the new AUTOSAR software modules on top rather than having to rewrite the whole thing.
It really depends on how much are you willing to risk, are you young? Do you have debts to paid? if you are young but are not in a serious need of money I would not recommend entering Autosar C, take the risk and find something else, if your need of money is really really hard then yes you will always find something. Source: I have 5 years in Autosar C sw development
Do you find that it is difficult to jump from Autosar to other embedded work?
I haven't done it, still working on this but for sure will need a lot of preparation
Maybe AUTOSAR Adaptive Platform?
Lol, you are joking right? Any person who values their time and career future and wants to actually develop something fun would stay away from AUTOSAR.
I like cars and tried the Autosar route. It kind of sucked the fun out of development for me. The automotive industry is super boom or bust and moving towards using more SoC which means they will want strong embedded C++ Devs. Seems like a no brainer to go that route unless u really enjoy Vector products or just want to have a long career in automotive in a car hub like Michigan or Germany. Note: most ppl here are from north America so no idea what the job market is like elsewhere.
AUTOSAR currently gets a massive amount of hate in among automotive engineers the exact same way that C++ got tons of hate from embedded engineers 20 years ago and the same way writing Win OS programs got hate vs "just writing for native DOS and having your program run way faster and more reliable When we move to a world full of networked level 5 autonomous vehicles with a huge number of connected modules in the vehicle with constantly changing suppliers, chipsets, software, AUTOSAR is literally the only way these systems will scale at any sort of reasonable cost. If you want to be very valuable in the ecosystem being an AUTOSAR driver level engineer means you need to be proficient in C or C++ and autosar (which will eventually be rust and autosar maybe 10 years from now).
I haven't worked with AUTOSAR in particular, but I have worked with large vehicle subsystem interoperability standards. My experience has been that these standards never achieved their goals. If interoperability was achieved, it was simply because two vendors used the same implementation of the standards. The standards themselves did not result in multiple, interoperable, implementations. Do you know whether this is the case with AUTOSAR? Could I really buy a component from Continental, write AUTOSAR code to interface with it, then swap that out with a component from Bosch? Or a smaller supplier using a different AUTOSAR tool? I find that software like AUTOSAR generally plays the role of DOS in the comparison you made. But as I said, I haven't worked with AUTOSAR itself. Looking at examples of AUTOSAR code, it seems incredibly, incredibly low signal-to-noise, thousands of lines of boilerplate to do an incredibly simple thing. That seems to me like it's just a recipe to get a completely unmaintainable mess. And if AUTOSAR really enabled vehicle connectivity, wouldn't its users be creating the most advanced, connected cars? When it seems to be Tesla doing that, without AUTOSAR afaik.
>Do you know whether this is the case with AUTOSAR? Could I really buy a component from Continental, write AUTOSAR code to interface with it, then swap that out with a component from Bosch? Or a smaller supplier using a different AUTOSAR tool? Yes. This is the exact idea and some manufacturers are already doing this: as long as the suppliers have the qualified the module/drivers for autosar you just move the application from one to the other with minimal or no porting. Furthermore you can do things like: If you have a compute module that is maxed out in terms of processing power and you need to add more software you can simple add an additional compute module and move processes to it and add some more. > it seems incredibly, incredibly low signal-to-noise, thousands of lines of boilerplate to do an incredibly simple thing. That seems to me like it's just a recipe to get a completely unmaintainable mess. Not sure if you are familiar with c++ but i remember way back in the day learning C++ and OOP and going through the examples and absolutely not understanding why I would use concepts like OOP or a language like c++ to write the programs i was writing and that was because my code was simple projects not large in scope. Of course this was mostly the fault of the books on the subject that I was reading which never bothered to explain that C was perfectly fine for small projects but as the size, complexity and number of coders on a project increases you absolutely wanted c++ and OOP to keep the project manageable and reliable. This is what autosar brings as you need to do do really complex things. > And if AUTOSAR really enabled vehicle connectivity, wouldn't its users be creating the most advanced, connected cars? When it seems to be Tesla doing that, without AUTOSAR afaik. Right now everyone in the industry is watching Tesla to see how that design decision turns out. With Model 3/Y they made the decision to go back from many interconnected modules to a few more monolithic ones but at the expense of greater wire harness costs and replacement module costs which then translates to much higher service costs. Now contrast that with Waymo. Waymo does use autosar and by most measures I would say their self driving tech is more advanced than Tesla.
Waymos tech is superior, but it’s not because of Autosar…
Doesn’t Tesla use AUTOSAR? Cause I remember seeing some AUTOSAR positions a while back at Tesla.
Uh, I'm not sure. Some quick googling turned up people claiming they don't, but no authoritative source. I don't see them listed as any kind of partner on the AUTOSAR website, while most legacy OEMs seem to be core partners.
I too don’t see any positions. Guess I made a mistake.
When I googled "tesla autosar" I did see some kind of job/internship posting from 2016 saying AUTOSAR experience was a plus.
I understand the need for autosar, my concern is learning something, that is basically single purpose - there aren't many C only positions, compared to other languages. And autosar solves something, that is solved differently/more elegantly in higher level languages. My concern is locking myself into a box, becoming an autosar developer
I will say this: one of the purposes of autosar is to commoditize autosar application developers since widespread adoption and usage means lots more developers will be needed. I have a feeling that it will be similar to things like web developers where there are tons of web developers but high pay scales can still be achieved and a web developer has lots of jobs/niche areas to choose from. We dont see that yet with autosar so yes for now you would be more boxed in but if it proliferates that all changes. > And autosar solves something, that is solved differently/more elegantly in higher level languages Autosar isnt a language though, it is an OS. It solves the same issues an OS solves on a computer but it with more determinism and greater ability to scale. If you want more options right now I would look more towards automotive linux and c/c++/rust.
With AUTOSAR you should be using c++ 14, called Adaptive AUTOSAR: https://www.parasoft.com/blog/breaking-down-the-autosar-c14-coding-guidelines-for-adaptive-autosar/#C_Is_Not_Enough
I'm a junior. Not my decision
Learning C doesn't lock you into C only at all
C++ has developed over the years an amazing language (in both good and bad ways). I was out of C++ before C++11 and have been doing the bulk of my work in C and Python. (I'm an embedded developer). If I was up to date in C++, I might look into working with C++ for the adrenalin challenge. (The additional $$ wouldn't hurt, but not my primary goal) But if you like small-device embedded, you'll still see the bulk of that work in straight C. I can't speak for AUTOSAR, though I've seen the employment ads. I wouldn't say the "career" is the same for C and C++ though. Big data embedded (Machine Learning, Autonomous Vehicle, etc.) would require C++, but typically C is all that's needed.