Stories
Slash Boxes
Comments

SoylentNews is people

posted by hubie on Wednesday March 15 2023, @06:37AM   Printer-friendly
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!


Original Submission

 
This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by jb on Thursday March 16 2023, @02:57AM (1 child)

    by jb (338) on Thursday March 16 2023, @02:57AM (#1296388)

    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...

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Insightful) by Immerman on Thursday March 16 2023, @01:37PM

    by Immerman (3985) on Thursday March 16 2023, @01:37PM (#1296470)

    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.