[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.