@joshbressers @mweiss @WhyNotZoidberg Wow, Nebraska seems to be full of random persons. :)

Good version! 👍

@joshbressers @mweiss @WhyNotZoidberg
I'm currently working at $DAYJOB where we're integrating a newer ARM core into a system-on-chip.

The software team is having trouble connecting an external debugger to this core because they don't know how the core's debug interface is supposed to work and what the micro-architectural preconditions for stopping code execution on the core are. The setup requirements are documented by ARM, at least, but that team doesn't have all the expertise it needs to set up the standard development toolchains on this new platform.

Even in big companies, crucial digital and computing infrastructure knowledge and implementation experience are all funneled and concentrated to a very few subject matter experts. There are often issues which only one or two people know how to debug in a productive way. (When there are thousands of signals and hardware registers which might contribute to an issue, having to figure it all out from scratch is very hard.)

The number one reason why people don't spend more time learning how to debug other issues or understanding the fundamental architecture and operation is that there's a LOT of testing to do and a LOT of possible issues to investigate and check when debugging, and the schedule of the hardware project ticks on by regardless. There's a certain reckless disregard for creating ultra-low-bus-factor technology at that low level of hardware technology because we still need all the possible micro-optimizations at the hardware level to get the power efficiency and performance that are the standard.

Microelectronics design is also tediously cursed in this manner, though without the same hobby project burden.