4 ms·
It really depends on the complexity. Sure, 555 timers and even microcontrollers have datasheets. CPUs that run Linux, Wifi chips supporting recent standards,
by jrockway 3y ago
It really depends on the complexity. Sure, 555 timers and even microcontrollers have datasheets. CPUs that run Linux, Wifi chips supporting recent standards, etc.? Rare. This is why Linux in the 90s was a big pain; you get some random Ethernet chip and there is no documentation on how to talk to it, so you're just dead in the water. (I think Android was the turning point. From then on, stuff had to support Linux, because Mobile was the future and Apple wasn't going to buy your chip. But of course, "works on Linux" means that it works in the hardware vendor's 3-year-old version of Linux. And "works" is always up in the air when hardware vendors start writing code.)
When I worked on embedded devices, we would report bugs and the vendor would send us new datasheets with updated known issues; updated to include the issue we reported. Or we'd do something like "the datasheet says it can handle a 100MHz clock but it's very unreliable" and they'd send back a datasheet saying it only supports 50MHz. That's the reason that datasheets are closed, every customer gets their own datasheet.
The more you get into higher margin stuff, be it hardware or software, the more you'll run into datasheets or branches just for you. It is weird and inefficient. But cheaper than testing it yourself.
- reaperman 3y ago> But cheaper than testing it yourself. It always felt like, IMO, that we end up testing it ourselves anyways. Obviously we don't go through the whole spec, but like you, we implement what we need and find the relevant bugs/errata ourselves. It's very painful to run across these and I don't recall an MCU that doesn't have at least one that we run into and have to workaround because development is already deep enough that we're economically locked it and it wouldn't be worth the rework to switch to a different MCU. Sometimes the bugs are in the silicon, sometimes they're in the middleware, but both are very painful to root-cause.
- themaninthedark 3y agoI think that they were saying it was cheaper for the manufacturer to not test it and use their customers as bug testers and troubleshooters.
- mfuzzey 3y agoIt seems to depend on the market. For example CPUs that run Linux open reference manuals are still the norm in the industrial range (chips like the NXP i.MX series, the TI SAMA ones or the fairly new STM32MP1) whereas in the mobile market (Qualcomm, Exynos etc) you can't get any information without a NDA and they'll only sign one with you if you're going to be buying millions. The first category also tend to have good mainline support, the second stuck on ancient vendor kernels.
- userbinator 3y agoCPUs that run Linux, Wifi chips supporting recent standards, etc.? Rare. Intel was relatively open with its documentation (including reference schematics -- I think you can still find the 440BX ones on their site somewhere) until around the end of the P4 era, so that covers "CPUs that run Linux". As for the wireless stuff, I suspect a lot of that has to do with regulatory issues.
- genmud 3y agoI mean, sure, for certain x86 things... like 20 years ago, but IIRC their host controllers were not though, and that isn't but a fraction of all CPUs. Think about how many billions of devices there are where you can't get simple a pinout diagram for the main CPU. I would argue only a tiny, TINY, percentage of any Linux devices actually have CPUs/SOCs/SOMs with sufficient documentation to look at from a hardware design standpoint.
- rjsw 3y agoStrongARM and followon ARM CPUs from Intel had good documentation too.
- charcircuit 3y ago>Android was the turning point >vendor's 3-year-old version of Linux Android uses the latest LTS Linux kernel.
- adrian_b 3y agoComplex CPUs and peripherals up to around 1995, e.g. up to Pentium, had mostly open documentation, not much different than for a 555. Only after that the public documentation has become progressively more and more restricted. Some restrictions are quite recent, e.g. only since the first Zen AMD has stopped publishing the BIOS and Kernel Developer's Guides and Intel has stopped publishing even summary datasheets for the mobile CPUs only a few product generations ago (summary datasheets are still published for desktop CPUs).