SoylentNews is people
SoylentNews
from the things-expand-to-exceed-the-space-provided dept.
Hackaday has a story about a simple non-scientific calculator that packs an Alwinner A50 tablet SoC and the Android operating system:
As shipped they lack the Android launcher, so they aren't designed to run much more than the calculator app. Of course that won't stop somebody who knows their way around Google's mobile operating system for very long - at the end of the review, there's some shots of the gadget running Minecraft and playing streaming video.
But it does beg the question as to why such a product was put into production when the same task could have been performed using very cheap microcontroller. Further, having done so they make it a non-scientific machine, not even bestowing it with anything that could possibly justify the hardware.
Embedded has more generic related post about overengineering in embedded systems:
Embedded systems have traditionally been resource-constrained devices that have a specific purpose. They are not general computing devices but often some type of controller, sensor node, etc. As a result, embedded systems developers often are forced to balance bill-of-material (BOM) costs with software features and needs, resulting in a system that does a specific purpose efficiently and economically.
Over the last few years, I've noticed many systems being built that seem to ignore this balance. For example, I've seen intelligent thermostats that could be built using an Arm Cortex-M4 with a clock speed of fewer than 100 MHz and several hundred kilobytes of memory. Instead, these systems are designed using multicore Arm Cortex-M7 (or even Cortex-A!) parts running at 600 MHz+ with several megabytes of memory! This leads me to ask, are embedded systems developers today overengineering their systems?
I think there are more systems today that are designed with far more memory and processing power than is necessary to get the job done. To some degree, the push for IoT and edge devices has driven a new level of complexity into embedded systems that were once optimized for cost and performance. In addition, connectivity and the need to potentially add new features to a product for a decade or more into the future are leading developers to overestimate their needs and overengineer their systems.
While leaving extra headroom in a system for future expansion is always a great idea, I've seen the extras recently move into the excess. It's not uncommon for me to encounter a team without understanding their system's performance or software requirements. Yet, they've already selected the most cutting-edge microcontroller they can find. When asked about their part selection based on requirements, I've heard multiple times, "We don't know, so we picked the biggest part we could find just in case". Folks, that's not engineering; that's design by fear!
(Score: 5, Insightful) by shrewdsheep on Wednesday March 15 2023, @09:18AM (6 children)
"Overengineerd": In my book this seems to mean something different than described. I would call the system not designed at all. Indeed all the choices were made to avoid having to design something. I would call it system-assembly.
(Score: 5, Touché) by choose another one on Wednesday March 15 2023, @11:14AM
This.
The cost differentials are probably simply traded off against "not having to design anything" (not just cost of design but also time-to-market).
End of the day, if what you have, and know how to use, is infinite orbital-nukes, it's so much easier to just nuke everything from orbit.
"Eeek, a mouse"
"no problem, we'll just nuke it from orbit".
(Score: 5, Interesting) by garfiejas on Wednesday March 15 2023, @12:49PM (2 children)
Agreed; but I would also suggest that its likely to do with bootstrapping/coding; pretty trivial to design a calculator using Google tools, very cost effective to use an Android SOC and whatever touch panels you have. An actual ARM Cortex M7 with ARM CMSIS drivers on the other hand... even something as dev friendly like https://www.pjrc.com/store/teensy41.html [pjrc.com] - in C using a commercial or GCC toolchain ... requires a detailed knowledge of how the tin actually works and getting a real working GUI plugged into it is definitely non trivial...
(Score: 2) by jb on Thursday March 16 2023, @02:57AM (1 child)
Why on earth would you need even C to build something as simple as a ("non-scientific") calculator?
All you need is a couple of registers, a serial adder and a few strategically placed inverters and you have addition, subtraction, memory & clear taken care of. A small rom with a lookup table in it is probably still the most efficient way to add support for multiplication, division & square roots. Pretty sure a "non-scientific" calculator does not need more than that.
If design costs are your worry (small production runs), note that the average 2nd year EE student should be capable of designing something like that in the course of a 3 hour exam (and a top student will also manage to prove his design correct within that time limit). If your engineers can't, just fire them and hire a (much cheaper) graduate who can.
If unit costs are your worry (large production runs), note that tools exist to transform such a design into an ASIC layout that can be fabricated cheaply at scale.
As to "a real working GUI", there's nothing more "real" (nor, in most cases, more "working") than mechanical buttons (plus a series of 7seg displays for output of course). For a simple calculator-only device, adding a touch-screen will serve only to *diminish* usability and *diminish* service life ... but then again, I guess shipping barely usable devices that are built to break down seems to the *goal* of most electronics manufacturers today...
(Score: 3, Insightful) by Immerman on Thursday March 16 2023, @01:37PM
Sounds expensive.
Commercial design ultimately has one goal: maximizing the profit-versus-cost ratio.
These days you can get a mature and massively-too-powerful generic SoC off the shelf for well under a dollar. Good luck producing a custom calculator circuit with for anywhere close to that - the necessary ROM and RAM alone will likely be almost as expensive as they are increasingly specialty hardware (because why would you buy them separately when you can get lots more of both, already integrated with a powerful CPU, for a similar price?). Add in the adder and support circuitry and you're almost certainly more expensive than the SoC.
And that's before you consider the assembly costs, which increase linearly with the number of components - it costs just as much for a pick-and-place machine to place a single resistor as it does to place an entire SoC.
As for design...
Writing software is almost always vastly faster and easier than designing an equivalent circuit, is MUCH easier and faster to debug, and adds zero additional per-unit costs. And if you find a serious bug in the software late in production you can quickly re-flash all the existing inventory, while a bug in hardware probably means throwing it all away.
And on the hardware side, with a SoC the wiring is basically just connect power and I/O devices - very few components, very few connections connections, which means very little that can possibly be screwed up.
(Score: 5, Interesting) by SomeRandomGeek on Wednesday March 15 2023, @03:44PM
I strongly suspect that we simply do not understand the design trade offs that the engineers were making. Is the simpler part really cheaper? How much custom supporting hardware does each part need? How do the software development costs for the parts compare? Are both parts even available in today's market? Perhaps the calculator was overengineered or underengineered, but we are in no position to judge. For all we know, using an overpowered but mass produced android SoC is the absolute cheapest way to make a calculator in this economic environment. The calculator retailed for $10, and I doubt that the chip accounts for even a significant fraction of that cost.
(Score: 3, Interesting) by corey on Wednesday March 15 2023, @09:33PM
Yep. The younger guys at work live by the motto “just chuck a micro in it”, then they write a quick bit of software.
I’m old school so I try to go simple as possible but I ack that sometimes that increases the NRE.