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: 4, Interesting) by Anonymous Coward on Wednesday March 15 2023, @08:17AM (3 children)

    by Anonymous Coward on Wednesday March 15 2023, @08:17AM (#1296220)

    Working in the space industry, where in many cases we don't have the luxury of putting any cheap and super-high performance SoC, we end up having to explain to "embedded software" engineers complaining about the resource constraints that it's their fault if they cannot implement basic spacecraft control algorithms in the same low resources that others could 5 years ago.

    Starting Score:    0  points
    Moderation   +4  
       Interesting=4, Total=4
    Extra 'Interesting' Modifier   0  

    Total Score:   4  
  • (Score: 5, Insightful) by TheReaperD on Wednesday March 15 2023, @09:18AM (1 child)

    by TheReaperD (5556) on Wednesday March 15 2023, @09:18AM (#1296228)

    Intel and Microsoft has so long pushed the narrative of throwing more CPU and RAM at a problem is more economical than come up with quality software and the fact that components have become dirt cheap (comparatively) has just made the problem even worse. For the most part, it's not an issue, except it leaves even more security holes for attackers to exploit.

    The space program is where this comes to a screeching halt. Satellites, or worse, manned space vehicles, can't have components easily repaired or replaced, if at all. This means that chips and components have to be guaranteed to perform in the environment for the specified mission duration, which may span decades without maintenance. This means you can't use the newest an highest performance components hot off the silicon presses. At best, you can use five year old components that have just cleared stress testing. In reality, that's a highly optimistic scenario. Many units are a decade or more old because the design has to have been proven to work.

    The problem, as you stated, is you get these new software engineers that have been trained to slop together a commercial application with high-level languages and framework upon framework and now they're having to work with components that are a decade or more out of date and having to run high end calculations on them, which requires low-level languages and working directly with the hardware with little to no abstraction layers. Modern programmers simply aren't trained to do this anymore. It might actually be more efficient for NASA and other space organizations to hire kids right out of high-school and train them how to program from scratch. It'd save having to try and get them to unlearn all the bad habits programmers that are taught in college these days. It'd also have the advantage of repopulating the embedded and low-level driver programmers again, which is quickly turning into a lost art. (Looking at driver install packages in the hundreds of MB!)

    We can't keep counting on boomers to keep putting off retirement. We need to start training the next generations before all the boomers die off, which is already starting to happen. We wait another 5-10 years and it'll be too late. It takes years to train skills like this to any level of proficiency and years more for mastery!

    --
    Ad eundum quo nemo ante iit
    • (Score: 3, Interesting) by DannyB on Wednesday March 15 2023, @05:27PM

      by DannyB (5839) Subscriber Badge on Wednesday March 15 2023, @05:27PM (#1296277) Journal

      epopulating the embedded and low-level driver programmers again, which is quickly turning into a lost art.

      I am reminded of the pilot episode of ST:TOS, or the two part episode The Menagerie, where the inhabitants living underground had forgotten how to repair the machines built by their ancestors.

      (Looking at driver install packages in the hundreds of MB!)

      The driver part is a tiny fraction of that. The rest is all advertising, spyware, bloatware, things you don't need and didn't ask for. Shovelware. Craptacular special offers if you sign up online. Etc.

      --
      The lower I set my standards the more accomplishments I have.
  • (Score: 2, Touché) by Anonymous Coward on Wednesday March 15 2023, @10:55AM

    by Anonymous Coward on Wednesday March 15 2023, @10:55AM (#1296231)

    You mean you can't just `pip install pyControl' ?? That's what they say to do on StackOverflow!