SoylentNews

guest reader writes:

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