[znpy]

I think that the issue here is the following:

    - you can charge money for things
    - anything that's not built with the "official compiler" is not "supported"

I've interviewed for a junior embedded software engineer when i was in university and when i started mentioning i had experience building cross-compilers i was immediately stopped by the guy interviewing me (he literally didn't even let me finish the sentence) and told me "Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE.

They used ARM chips, so not even anything strange...

The real issue would come if they did not provide the source code for the gcc build they sell you, though.

[Aurornis]

> Absolutely no. We don't want to maintain our own toolchain and we want everything to be coming from the BSP [Board support package] and integrated nicely with the vendor's IDE

This is critical if you want any support from the vendor.

If you come to them with a bug in their hardware but you’re not using their toolchain and BSP, it’s the end of the road. You have to recreate a minimal reproduction of the bug in their ecosystem before they’ll look at it.

When you’re working at company scale, paying $1000 for a compiler is a trivial expense.

[rcxdude]

IME you're usually on your own anyway. I've rarely found it worth slogging through their crappy BSP for the chance of maybe receiving some useful support.

(I am aware that there's a certain kind of mindset that likes to lean on support from vendors to do basically anything, and I think if you're in a position where you actually get good support, that might work, but in most of the instances where I've seen such a mentality it tends to produce expensive results that still don't actually work, and sometimes even when AFAICT the vendor's pretty switched on, they just don't actually have all the context)

[azonenberg]

I avoid vendor toolchains and BSPs just because of how buggy they are.

From my perspective, it's much better to reproduce a bug with a 20-line C or assembler file that compiles with upstream gcc, completely ruling all of their custom stuff out as the root cause.

Just tell me what the silicon does when I poke this register and I'll work around it.

[eqvinox]

> not using their toolchain and BSP, it’s the end of the road.

Mhm. I'd say, you're forced to reproduce it on their toolchain and BSP, which may or may not be the end of the road depending on how complex the problem and your use case are.

[mycatisblack]

Offloading the liability for a compiler sounds like common sense to me. How many heads did this company pay? 100, 1000?

Related, compiler bugs aren’t uncommon in the arm-none-eabi family. Especially the cortex m0 seems to have a few that recur every few years.

[azonenberg]

I have not used anything but arm-none-eabi-gcc for STM32s from day one. Never even installed CubeMX or any other ST software.