Sujet : Re: hefty data sheet
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.designDate : 16. Mar 2025, 01:12:50
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vr5523$iqbj$1@dont-email.me>
References : 1 2
User-Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
On 3/15/2025 11:56 AM, bitrex wrote:
I need a printed copy to put on someone's desk when they says "8 bit is obsolete, just use an ARM"
While I've traditionally liked having paper copies of reference
documents, it's just no longer possible. OTOH, most documents, now
(esp ARM) contain a lot of duplication. It's as if they were
machine generated and the machine didn't have conciseness as a
goal.
[I was looking at a page yesterday that was just a giant table
describing the format of a particular register. Every bit's
description included a sentence: "For more detail, see the
description of the Whatchamacallit in the BlahBlahBlah section"
Is there a reason this can't be stated *once* as applying to
every bit?]
In an earlier post (s
news://news.eternal-september.org:563/vhsc2o$1m1kj$1@dont-email.me),
I mentioned that the "datasheet" for the CPU I'm using is 16,000 pages
(15,863). And, that just describes the *hardware* on the assumption that
you already know how to use the features laid out, there.
There are also manuals for the two different types of CPUs contained within,
the FPU, the MMU, etc.
Plus, app notes to assist in system design and board layout.
Most users have to rely on a third party to provide a "subassembly"
(hardware and software) that they can use -- so they don't have to grok
all of this detail. To them, they become black boxes with very little
understanding of what's inside or how to fix it when/if the need
arises.
There's nothing wrong with using an 8b (or 16b, 4b, 1b) MCU -- *if*
appropriate for the task at hand. But, once you add a network stack
to a device, you discover that the CPU is likely overtaxed (I wrote
my first stack on a Z180 and it would struggle to keep up with a
*10*Mb network)
OTOH, the development environment afforded by more capable MCUs is,
IMHO, well worth the increase in product cost; it makes it easier to
design with security and reliability in from the ground up (instead
of layering those things on, as an afterthought). Abstraction
has a performance cost.
History teaches us that better will always get cheaper so why
start on a year (or more) long development effort with an MCU
that is appropriate to *today* (instead of tomorrow or next year)?