Embedded world is weird. Changing hardware design is difficult and costly by itself and manufacture process is limited by real world constraints, therefore the largest "part of why you would pick chip A over chip B" is availability, both long-term and short-term: will I be able to source the chip in 5 years? how easy it would be to change delivery schedule if my manufacture schedule changes?. Oh, and ARM looks like a solution until you have to battery operate it.

Cost of the software in embedded systems is quite often low compared to hardware costs. I ballpark lower limit for part cost at $10. I ballpark software development cost at $100k/y or $50/h. Let's say it is reasonable to get software done in a man-year. At 1M units of projected sales, software cost is at 1% of hardware cost (not project cost). At such ballpark estimate software engineers' opinion is only treated as a humble request.

Of course this varies from project to project. Increasing portion of embedded systems are mostly software. Portion of projects have hard-realtime requirements. Here software engineers are benevolent dictators. But that is by no means a general case.

> If you don't have a C++ compiler, and you end up having to re-invent C++ in C, then maybe you should have picked the chip with decent tools.

So the software engineers are the only ones on the project who get a say as to what chips get used?

No (and that isn't what he said), but surely they should get a say, right?

pslam basically did in his next paragraph:

> If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them.

ARM is not entirely suitable for any application just because you have complex (for some definition of complex) software.

No, but the software impact of choosing a particular piece of hardware should absolutely be part of the system design process. If it is not, then you are part of a project with bad leadership, or very, very old-fashioned architects.

It's not just ARM - there's plenty of other CPU architectures with modern Clang, GCC, or other toolchains with C++ support. Given that this is a large code base (justifying this amount of work), this cannot be a "tiny" microcontroller, as in 8 bit, and needing to run on microamps. I cannot believe that there were not C++-capable microcontrollers available which would have done the job, without breaking the bank.

Doing it at lowest cost is the point. Because even if you don't lower your cost, your competitors will.

Those low end cortex M's tend to have C++2003.

I am kinda-sorta happy to have C++ at all.

I think.

I work mainly on embedded systems and i would much rather work with a different CPU but stuck with the hardware we have.

The compiler I use does have an embedded c++ option but it's limited and has some issues working with the RTOS that's supplied with the compiler. Also with a total of 6K of ram available it's usually easier just to stick to writing plain C.