Texas Instruments has awesome documentation. Every single MSP430 microcontroller comes with: - a family guide describing all features of microcontroller family, usually >500 pages long - concrete microcontroller guide describing specifics of a single microcontroller, usually >50 pages long - errata guide describing all(?) known silicon bugs with their workarounds Also, Clang has a backend for MSP430 by default: `clan…
Sure, but that's irrelevant. The MSP430 is not (in) an Eth PHY.
As the Author demonstrated, the network IC world is very unaproachable.
Token ring was old in 1996 when my masters thesis focused on error handling behavior and simulation thereof. I wonder if there are certain elements in certain "industrial complexes" that need to maintain or interface with legacy TR systems and that's why it's still hanging around in "dark silicon".
The chemical factory I did an internship at in 2001 was sticking with Token Ring at the time.
Personally I hated the NXP's docs for the ARM M4 core. Bunch of dry tables listing each register in details, lacking the juicy diagrams and descriptions on how the bits integrate to work as a subsystem. I constantly needed to cross-reference 3+ documents (most of which describe the whole family and not the specific IC). Their HALs and code samples were obviously written by students/interns. I liked working with Micro…
Yeah, NXP in my experience had an issue with having too much documentation. In the sense that you get drowned in a 3000 pages PDF that lists every detail but becomes hard to parse unless you want to base everything around that specific platform for years. Though that sounds like an awesome "issue" to have in some circumstances.
When you add up all the various PDFs documenting the NXP MCXN947 it comes to around ~7,000 pages.
The thing I loathe the most about embedded work is dealing with silicon vendors and their boneheaded refusal to publish the fucking documentation and tooling.
Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.
Because creating good documentation suitable for external consumers costs money, and even if you have decent documentation, people buying small quantities of parts can end up costing companies money just to interact with one of their application engineers. If you're not set up for it (very few companies are), it literally is negative value to answer support questions for small time customers.
Why though? This is clearly a problem I just don't understand what the vendors are getting out of it.
Because creating good documentation suitable for external consumers costs money, and even if you have decent documentation, people buying small quantities of parts can end up costing companies money just to interact with one of their application engineers. If you're not set up for it (very few companies are), it literally is negative value to answer support questions for small time customers.
I'm not sure how your answer relates to the question about why they won't release documentation they already have. Are you saying that releasing documentation is going to increase the number of support questions?
If you want to sell or limit support, why not do that without the documentation complications?
The usual terminology is hard, firm and soft realtime. In hard realtime, missing a deadline is a total failure and to be avoided at all cost, i.e. your reactor melts down, you car runs over someone, stuff like that. Firm realtime means that a missed deadline will not be a total catastrophic failure but it will make the result useless. E.g. when your printer control system mistimes the "fire ink now" in the printer, a…
It should be noted these distinctions don't correlate with timing; you can have a hard realtime system that needs some network packets at 50ms±10ms intervals, and a soft realtime system that needs packets at 500µs±5µs. Some audio setups are run quite "close to the metal", both because it needs less buffering, but also the lower human threshold for noticing latency seems to be around 10ms. And having audio not get out…
Correct. If you imagine having a dam overflow, the release valves are a hard realtime system. If the dam overflows for more than a few minutes, damage will occur, so the release valves need to be opened within, say, overflow plus 5mins. A generous deadline for any computer, but still a deadline that needs to be kept at all cost.
Because creating good documentation suitable for external consumers costs money, and even if you have decent documentation, people buying small quantities of parts can end up costing companies money just to interact with one of their application engineers. If you're not set up for it (very few companies are), it literally is negative value to answer support questions for small time customers.
I'm not sure how your answer relates to the question about why they won't release documentation they already have. Are you saying that releasing documentation is going to increase the number of support questions? If you want to sell or limit support, why not do that without the documentation complications?
> Are you saying that releasing documentation is going to increase the number of support questions?
Yes, absolutely. Notoriously, smaller customers are more needy in fact. The bigger the customer, the more competent their engineers tend to be (or, the more time they have to spend figuring out how to use your stuff). Smaller customers try to offload support onto vendors, which pushes burden onto internal vendor teams (who don't want to provide the support...).
I'm not sure how your answer relates to the question about why they won't release documentation they already have. Are you saying that releasing documentation is going to increase the number of support questions? If you want to sell or limit support, why not do that without the documentation complications?
> Are you saying that releasing documentation is going to increase the number of support questions? Yes, absolutely. Notoriously, smaller customers are more needy in fact. The bigger the customer, the more competent their engineers tend to be (or, the more time they have to spend figuring out how to use your stuff). Smaller customers try to offload support onto vendors, which pushes burden onto internal vendor teams…
Smaller customers are more needy, sure, but there's a couple steps missing here. Is better public documentation going to bring in a lot more small customers, more than it solves problems? Is an NDA by itself keeping away lots of small customers?