> In embedded you should choose hardware that works.

I've never seen it approached with that kind of incompetence, in my professional life. Embedded is a system thing, not a hardware thing. You pick the system that will work. Ignoring the software side of things is ignoring the majority of the problem in embedded work. I would have agreed with you 20 years ago, but it's 2024, and why RPI is so often used for prototyping.

Sorry, wrote the original comment on my phone. The sentiment is close enough, but generally things are not quite that bad. I've seen hardware ask, but the person they asked didn't know how to check how much memory we actually needed. Hardware also failed to tell that person that half the memory they were asking about was dedicated to the GPU and thus not available for application code. I've also seen them choose hardware that seems to have great drivers and they can point to others in our industry who are shipping with that, only to latter hit a major bug that means we can't use it without that fixed - but we are too small a customer to be able to demand they fix bugs that only affect us.

RPI is often useful for prototyping because it is cheap enough, but if you are not a very large company nobody will talk to you. This is both you can't get support from Broadcom, and worse your supply management cannot get contract signed (for small companies this doesn't matter you take what you can get, but larger companies often demand better support than they can get from pi)