Design question: how to decide between software or circuit implementation?

[yuzhangy]

Hi,

I'm a beginner mechatronics engineer and I have a general design question:

In product design, if a feature can be achieved by either software or circuit, how to decide what features to implement in software and what features to implement in circuit?

For example: button debouncing, blinking indicator lights, 7-seg digits display etc. Certainly these can be implemented in the micro-controller, but they can also be implemented easily through some basic circuitry on the PCB. What's the criteria to decide which type of implementation is appropriate in the design of a mass-produced product. Is software implementation always cheaper?

Thanks!
YY

[DrGeoff]

It can often depend on the organisation doing the work and the system being developed.
Maintaining software can be expensive in an organisation, with loads of documentation, change control systems, maintenance of the development systems over the lifetime of a product etc etc.

If it is done in hardware then the ongoing costs are related to managing inventory to maintain the product over its lifetime, however the production cost can be higher.
Hardware solutions can be more difficult to change or add additional functionality once in place, so it would depend on how fixed the system specification is.

It's a balancing act and the product functionality is only a small part of the total evaluation.

[IanB]

Subjectively, I would say software is harder to get right, and therefore the lifetime cost in terms of faults, revisions, warranty claims and maintenance fixes is likely to be higher due to faulty software than due to faulty hardware.

I would say some reasons for this are that hardware design falls more readily into standard design patterns, application notes, and known best practices, and is more readily subject to design review, inspection and test verification.

Software, on the other hand, tends to be written or customized uniquely for each application, is often written by people who over-estimate their level of competence, and is harder to verify by inspection. Software is demonstrably easy to goof up and get wrong in subtle but critical ways.

As a pragmatic engineer I would therefore prefer hardware solutions, even though the perceived cost in terms of parts and manufacturing might seem to be higher.

[CircuitSlacker]

My day job is software, my hobby is hardware. Last year I finished a project for my employer that combined both disciplines. Over nearly a year, I built hardware which involved 20 push button switches, 40 LEDs, 2 microcontrollers, additional ICs and supporting hardware. This all connected to a database back-end to display and reset states input by about 20 machine operators.

To do some testing of another aspect of this system, I spent one day developing a web interface to do the exact same thing as the hardware that took me a year to build. I intended to use a mouse to click virtual buttons, which was not a possibility for production use of this system. About half way through the day I realized that if I used a touch screen, I could just press the virtual buttons on the touch screen and do the exact same thing that the hardware I was simulating would do.

When my fancy, expensive hardware fails, I will be be replacing it with a touch screen and the web interface.

In this particular instance, I could have saved a lot of time and money by implementing software instead of building hardware. I know this isn't exactly what the OP is asking about but I think it's relevant enough. What I've found is that by using a software approach, a lot of the work is already for you. The touch screen is a good example. I didn't need to do anything at all to make the virtual buttons touch compatible. They just worked because I was already using JavaScript, AJAX and a somewhat modern browser.

[CircuitSlacker]

Software, on the other hand, tends to be written or customized uniquely for each application, is often written by people who over-estimate their level of competence, and is harder to verify by inspection. Software is demonstrably easy to goof up and get wrong in subtle but critical ways.

IanB, you are not kidding! You can test until the cows come home and still some situation will occur that you never considered - and break your code.

[DrGeoff]

My day job is software, my hobby is hardware. Last year I finished a project for my employer that combined both disciplines. Over nearly a year, I built hardware which involved 20 push button switches, 40 LEDs, 2 microcontrollers, additional ICs and supporting hardware. This all connected to a database back-end to display and reset states input by about 20 machine operators.

To do some testing of another aspect of this system, I spent one day developing a web interface to do the exact same thing as the hardware that took me a year to build. I intended to use a mouse to click virtual buttons, which was not a possibility for production use of this system. About half way through the day I realized that if I used a touch screen, I could just press the virtual buttons on the touch screen and do the exact same thing that the hardware I was simulating would do.

When my fancy, expensive hardware fails, I will be be replacing it with a touch screen and the web interface.

In this particular instance, I could have saved a lot of time and money by implementing software instead of building hardware. I know this isn't exactly what the OP is asking about but I think it's relevant enough. What I've found is that by using a software approach, a lot of the work is already for you. The touch screen is a good example. I didn't need to do anything at all to make the virtual buttons touch compatible. They just worked because I was already using JavaScript, AJAX and a somewhat modern browser.

I did design large panels full of illuminated buttons for control centres during the 1980's. They were still running 20 years later. Yes they had firmware (68K) and comms code, but nothing needed changing over that 20 years.
However, if it had been written with browser-based touchscreen functionality I doubt it would have survived the myriad of OS, browser and language upgrades and modifications over a 20-year lifecycle, and perhaps the screen itself would have died.

The point here is that you need to consider the entire product lifetime, especially in defence, aerospace and utility control situations, where changes occur very infrequently.
A system designed for 10 years will still be in operation 20 years later.

[CircuitSlacker]

The point here is that you need to consider the entire product lifetime...

Certainly this is a key consideration. In the case of my project, I'm already locked into following OS and database update requirements so adding another software element just becomes part of that continuous upgrade delta. When this isn't already part of the lifecycle, introducing the need to accommodate change in external software would be bad idea.

A system designed for 10 years will still be in operation 20 years later.

Those machine operators I mentioned - most of the machines they operate were purchased in the 1950's and have had so much tech added to them over the years that they look like Rube Goldberg contraptions.

[T3sl4co1l]

There's no substitute for responsibly designed systems, hardware or software.

Hardware may seem harder to get wrong, but I've seen it before.

To do hardware well, takes about as much concentration and understanding as to do software well.

The big difference with commercial software is, it's based on a framework of buggy libraries and languages, running inside intractable, opaque, and buggy operating systems; the hardware itself is so complex that, despite best efforts, it is buggy too.

It's quite possible to do software well, but it takes a lot of effort when the scope is more than trivial.  And it can't be done with existing (commercial) libraries.  (And, again, correctness still assumes the hardware behaves to spec.)

Tim

[CircuitSlacker]

The big difference with commercial software is, it's based on a framework of buggy libraries and languages, running inside intractable, opaque, and buggy operating systems...

I've often thought about this. Given the number of people who work on the various software in the software stack - applications using libraries running on top of kernels with drivers on top of firmware - I'm amazed that it works at all! Very few if any of these people ever have communicated with each other let alone collaborated with each other - and they are written at different times in different environments.

[danadak]

I found that project specs drove a significant part of the decision.
For example one can poll a pin in SW and count edges, hence make
a freq cntr, but its severely limited to low speeds/frequency. Here HW
makes a much better approach.

Another example, need for a filter, analog or digital. The latter has a big
advantage in that its clock determines, largely, accuracy of the filter, and
relative to analog is immune to temperature and drift by significant amount.
And filter response is controllable, adaptable, SW number crunching handles
that capability. Here SW rules, with the basic HW to manipulate.

Software rules for in-situ upgrade, no removing HW board to upgrade user interface,
capability, feature set. In many instances.

SW also has ability to create analog error correction loops, to "linearize" an
analog system signal path, performance. There are techniques to take low
accuracy high noise systems and convert them to higher performance systems.

SW has ability, in certain architectures like PSOC, to reconfigure the HW to serve
a different purpose. A good example was a Coke Machine manager done years ago.
During day it counted transactions, change, inventory, user interface....then at night
reconfigured itself as a management tool communicating all its status, data to a host
for central management. All this done in a $2 part with limited but reconfigurable HW
resources.

Generally speaking I tend to reach for a chip that has HW configuration so that
I can accommodate changes to spec, marketing input, and have basic HW cells I can
program into different functions as needed.

Regards, Dana.

[tggzzz]

The big difference with commercial software is, it's based on a framework of buggy libraries and languages, running inside intractable, opaque, and buggy operating systems...

I've often thought about this. Given the number of people who work on the various software in the software stack - applications using libraries running on top of kernels with drivers on top of firmware - I'm amazed that it works at all! Very few if any of these people ever have communicated with each other let alone collaborated with each other - and they are written at different times in different environments.

Tim's point is simultaneously very valid, overstates the case, and understates the case

There are too many examples of subtly buggy hardware; e.g. many years afgo I was first bitten by a relatively simple IC that was up to revision G. That should have been A Big Clue.

It is not just that individual libraries contain bugs, but that people actively design whole ecosystems in ignorance of what lies at a lower level. One simple example of this is comms, where from low level to high level you can see various layers implementing async (PHY), then sync (some MACs), then async (IP), then sync (TCP), then async (some CORBA and "web" protocols), then sync (some "web" protocols), where "web" should be taken to include many application level protocols.

Now, what conclusions would you draw from the following anecdote from the mid-80s? A team was bringing up a Smalltalk environment and everything was workng (GUI, compilers, debuggers, file system etc) - except that the contents of window panes scrolled in the wrong direction. The problem was eventually traced to a faulty implementation of subtraction of negative numbers within the VM interpreter (and it was an interpreter).

[paulca]

Subjectively, I would say software is harder to get right, and therefore the lifetime cost in terms of faults, revisions, warranty claims and maintenance fixes is likely to be higher due to faulty software than due to faulty hardware.

I would say some reasons for this are that hardware design falls more readily into standard design patterns, application notes, and known best practices, and is more readily subject to design review, inspection and test verification.

Software, on the other hand, tends to be written or customized uniquely for each application, is often written by people who over-estimate their level of competence, and is harder to verify by inspection. Software is demonstrably easy to goof up and get wrong in subtle but critical ways.

As a pragmatic engineer I would therefore prefer hardware solutions, even though the perceived cost in terms of parts and manufacturing might seem to be higher.

I find that a fairly insulating and inaccurate assessment from someone who has probably never done any professional software development.

Software tends to follow established design patterns, architectures and procedures.  Software is developed under various methodologies some stricter than others.   Software can be design reviewed, version controlled, tested and verified by multiple teams and the end customer.  Software can go through multiple release stages, often called alpha, beta, gamma or "Dev", "SIT", "UAT", "Production", "Fail Over", Release candidates, release versions, legacy versions.  Today a lot of this is entirely automated.  You can't produce a line of bad code without something in the build chain whining at you about it or out right rejecting it. 

Often people use what is called a "Gated SDLC", so nothing can move from one stage to the next without a gate review, checklist and all parties signing off on it.

Like electronics it depends on what you are building as to how much you spend (time/money) on process, documentation, test and verification.  If you are making a hobby project, it's usually, "Looks like it works, it works."  If it's a critical safety system for an airliner then every single line of code will have potentially pages of documentation, justification, test matrix entries, unit tests, integration tests, system tests, static, dynamic code analysis results, performance test results etc.

If you find a bug in a production product you can often patch it, in many cases without even an RTB.  Embedded software being a little more difficult to patch in the wild, but non-embedded it's standard practice and happens on your mobile phone daily without you even caring. 

If you find a bug in your electronics it's a RTB and a rework or bin the 1000s of boards you have in stock and re-manufacture.

Also, if you design and implement your software once, you can ship it a hundred million times at virtually zero extra cost.  There is virtually zero cost per instance.

[paulca]

It is not just that individual libraries contain bugs, but that people actively design whole ecosystems in ignorance of what lies at a lower level. One simple example of this is comms, where from low level to high level you can see various layers implementing async (PHY), then sync (some MACs), then async (IP), then sync (TCP), then async (some CORBA and "web" protocols), then sync (some "web" protocols), where "web" should be taken to include many application level protocols.

But that's by design, not by accident or ignorance.  Abstraction layers.  Software collaboration/integration.

If you post a letter, do you have the slightest idea how the postal system works?  Does the postman who collects the letter from the postbox know how the sorting office works?  No.

Isolation of concern.  Each component uses the services the other provides via it's interface.  It becomes a cloud of "Don't need to know", as long as it works.  It allows you to isolate and focus your requirements.  This is quite unlike a lot of electronics circuits.  In that case if your IC fails it can cause a chain reaction of failures ending in your house mains breaker popping.  In software the PSU driver would have thrown a "Invalid operation. Disconnecting." long before it got that far.

Granted it adds HUGE amounts of effectively unrequired code to abstract, integrate and translate between all those components and layers.

[T3sl4co1l]

Isolation of concern.  Each component uses the services the other provides via it's interface.  It becomes a cloud of "Don't need to know", as long as it works.  It allows you to isolate and focus your requirements.  This is quite unlike a lot of electronics circuits.  In that case if your IC fails it can cause a chain reaction of failures ending in your house mains breaker popping.  In software the PSU driver would have thrown a "Invalid operation. Disconnecting." long before it got that far.

Well.  A poorly made one. At the very least you have a fuse, the electrical equivalent of the NMI (which traditionally disabled the processor as a hard crash; a BSoD and automatic reset is probably the modern equivalent).  A better made system can fail softly, in stages.  For example, compare a classic TL494 based voltage mode control SMPS to a modern current mode design: if an output device fails shorted (say, rectifiers or capacitors or load), the former will ramp up to full throttle, while the latter will simmer at its maximum current limit (and probably do some auto-restart behavior, too).  One can recover, or at least be repairable; the other is a melted piece of junk.  (This level of protection is perhaps comparable to a Win98 "it may be possible to recover" dialog. Which you always knew meant the application in question had corrupted memory beyond its allocation, and the system wasn't going to be stable for very long...)

At any point in a well-designed circuit, the designer makes every node have a well-defined operating voltage and current range, and a maximum possible voltage and current on/through that node under a fault condition.  And if the magnitude of that fault has to be large (because of other constraints like low resistance), then extra steps should be taken to ensure that fault occurs less frequently.

One can take this hand-waving approach and formalize it: this is known as FMEA (Failure Mode Effects Analysis).  There are also ways to calculate failure rate.

Tim

[IanB]

I find that a fairly insulating and inaccurate assessment from someone who has probably never done any professional software development.

Did I touch a nerve?

Software tends to follow established design patterns, architectures and procedures.  Software is developed under various methodologies some stricter than others.   Software can be design reviewed, version controlled, tested and verified by multiple teams and the end customer.  Software can go through multiple release stages, often called alpha, beta, gamma or "Dev", "SIT", "UAT", "Production", "Fail Over", Release candidates, release versions, legacy versions.  Today a lot of this is entirely automated.  You can't produce a line of bad code without something in the build chain whining at you about it or out right rejecting it. 

Often people use what is called a "Gated SDLC", so nothing can move from one stage to the next without a gate review, checklist and all parties signing off on it.

And yet software still ships with bugs. Microsoft continues to push new security patches every month for supposedly mature and stable products. Apple hits the headlines for major goofs in their software. Everywhere you look in the industry you can see evidence of bad code.

I work in the software business. It has been my world for the last 35 years or so. I see how hard it is to get software right, in spite of all the processes you describe. If you think my assessment is inaccurate then good for you. I'm afraid we will have to agree to differ.

[TheUnnamedNewbie]

I would like to throw in another reason why one might choose one over the other: Power.

Depending on what you do, an circuit sollution (this does not have to be an analog circuit!) can be much, much lower power than a software sollution of the same problem. This is a result of what is at the same time on of the strengths of software - abstraction and flexibility. That abstraction and flexibility requires support infrastructure on a hardware level that might not be needed in a pure hardware sollution. This can be important in some fields, such as sensor nodes.

Another location where power shows up is when dealing with RF. There exist ADCs which can allow you to downconvert the entire spectrum up to a few GHz and do all your WiFi, BLE, or whatever in digital. Even if that was possible to do on a reasonable budget comparable to an analog solution with a downcoverter, it would take far more power to switch that ADC at the samplerate needed to do so. There is a reason why those ADCs need big heatsinks, but your phone's analog front end does not.

As for the failiure behaviour - I am not going to claim one is safter as the other. On the one hand, there is a phrase that goes something along the lines of "Testing code van prove that there are bugs, but will never prove that there aren't." However, I think in terms of hard ware, whenever you need code to detect hardware problems, you need hardware to tell the code there are hardware problems - hence the hardware already had to know there were problems. The key is that it is (or at least so I believe) much, much easier to implement predictable, fail-safe situations in software based on these hardware cues.

However, in some cases fixing hardware can be much, much easier than software when the designers aren't there to do the fixing. Ask anyone doing repairs and I think they will confirm, the most terrifying thing when doing repair work is when the microcontroller with on-board flash for the code is broken. You can get the hardware replacement, but getting the software could be a whole lot more troublesome. Along the same lines, in some cases it is easier to replace hardware with different types of hardware - If a power transistor breaks chances are there is a whole list of parts that could work as replacement. If the PIC18BSOMELONGCODE breaks, I need that exact part as replacement. (ofcourse, there is also hardware where this applies like FPGAs, ASICs, Dataconverters, etc.).

With the low cost of modern microcontrollers, it can be very easy to just do things in software, and that might also be the right choice in that case. Something to never forget: "the best is the enemy of the good". There is no need to make it "optimal". If it works, then it works. All extra effort you do to make it better will be for naught.

As others have said, software can be more flexible than hardware, though this becomes a more hazy line to draw when you start talking about FPGAs and FPAAs.

[tggzzz]

It is not just that individual libraries contain bugs, but that people actively design whole ecosystems in ignorance of what lies at a lower level. One simple example of this is comms, where from low level to high level you can see various layers implementing async (PHY), then sync (some MACs), then async (IP), then sync (TCP), then async (some CORBA and "web" protocols), then sync (some "web" protocols), where "web" should be taken to include many application level protocols.

But that's by design, not by accident or ignorance.  Abstraction layers.  Software collaboration/integration.

If you post a letter, do you have the slightest idea how the postal system works?  Does the postman who collects the letter from the postbox know how the sorting office works?  No.

Isolation of concern.  Each component uses the services the other provides via it's interface.  It becomes a cloud of "Don't need to know", as long as it works.  It allows you to isolate and focus your requirements.  This is quite unlike a lot of electronics circuits.  In that case if your IC fails it can cause a chain reaction of failures ending in your house mains breaker popping.  In software the PSU driver would have thrown a "Invalid operation. Disconnecting." long before it got that far.

Granted it adds HUGE amounts of effectively unrequired code to abstract, integrate and translate between all those components and layers.

It is by design, not by accident, and is often completely indistinguishable from ignorance.

Consider, as one example, SOAP. Initially it was not described as RPC-over-HTTP, but if you looked at it that is exactly what it was. The failings of RPC in a distributed and changing environment were well-known at that time, and were completely ignored by the designer. Many people jumped on the bandwagon, and it took five or so years for young inexperienced people to realise they were having "unexpected" problems - and move to REST architectures. Those of us that had been around the block a few times ignored it and implemented informal REST architectures from the beginning.

If you want to have a look at other examples, look no further than "enterprise message busses", and think about the extra guarantees they don't offer over technologies lower in the stack. Their major advantage is that they enable salesmen to bamboozle the ignorant into thinking that their product allows developers to completely ignore fundamental properties "because the framework takes care of it". Like hell they do! Or rather, if they do have solutions to the dining philosophers' problem, the byzantine generals' problem, or the split brain problem, then they have made fundamental advances.

I hypothesise that many of the "service inexplicably gone down" and "I can't see that on the computer" occurrences that bedevil mere customers, could be traced back to such fundamentals.

(As for understanding email, I remember "bang addressing" where the sender had to specify each and every machine on the path between the sender and the recipient. Conversations such as "Have you tried ucbvax? That's well connected" were a daily occurrence )

[TheUnnamedNewbie]

And yet software still ships with bugs. Microsoft continues to push new security patches every month for supposedly mature and stable products. Apple hits the headlines for major goofs in their software. Everywhere you look in the industry you can see evidence of bad code.

In the context of the op's quesiton it's important to keep in mind the complexity of a system. Sure, many bits of software contain a absolute mess of code and bugs, but those are also massivly complex systems - which would often be impossible to even do on hardware.

And on the same note - there are also many idiotic choices and mistakes made in hardware. I think for hardware there are simply more standards and frameworks in place to weed them out ahead of time - You need to adhere to standards regarding many things when designing hardware before it may go to market, but this is not the case for software, so the industry has just not yet been able to make those riggorous concepts a thing. As T3sl4co1l said, hardware designers often are raised with the mindset of thinking what happens when things go wrong. Software is catchign up, but still a good bit behind on that "think about the ways it can go wrong" riggorously.

[paulca]

And yet software still ships with bugs. Microsoft continues to push new security patches every month for supposedly mature and stable products. Apple hits the headlines for major goofs in their software. Everywhere you look in the industry you can see evidence of bad code.

I work in the software business. It has been my world for the last 35 years or so. I see how hard it is to get software right, in spite of all the processes you describe. If you think my assessment is inaccurate then good for you. I'm afraid we will have to agree to differ.

I think a lot of issues comes down to bad requirements, or unseen requirements, unseen circumstances or combinations of circumstances.

Yes there is bad code.  But there are bad electronics too.  To be fair software is orders of magnitude more complex than the hardware that runs it.

I just thought you were being a little unbalanced in seeming to suggest all software was written by cowboy script kiddies hacking stuff together without due care and attention.

[paulca]

Consider, as one example, SOAP. ...
If you want to have a look at other examples, look no further than "enterprise message busses",

SOAP is annoying because it's a "simple" protocol which simplifies in one place and adds complexity in another, the net is virtually zero.  REST on the other hand, especially as it's tolerant to being only partially implemented actually makes things simpler quicker and more productive, especially in the small scale.  WDSLs, stubs, public/private, remote/local and all that non-sense was just renamed and moved around in SOAP.

Enterprise buses are usually similar, in that they try and simplify things but in the end just make them as complicated as the lower level alternatives just in different ways, and at the same time locking you into design decisions they impose upon you.

By the way, I didn't say the developer should be blind the other layers.  Anything but.  If you have a problem with SOAP it pays to have the skills to understand the lower and higher levels to determine if it's a problem with SOAP or a problem with your HTTP or application code.

The software should be blind to functionality beyond the interfaces it consumes.  Hot wiring/jury rigging/spaghetti coding reference through layers leads to tight coupling, rigidity, fragility and a mess later.

The Internet TCP/IP stack is an interest example of layering done very well.  They had a policy back then that I wish people would get back to today.  "A protocol is not complete when you have added everything you can add.  A protocol is complete when you have removed everything you can remove and it still works."

[tszaboo]

Here is my 2c. If there is a reasonable cost ASIC to do it, I use that. It works, it is proven, it is more tested.
If you are talking about making discrete resistor-transistor logic, then no. I see too many design, where I can just circle a two dozen component, and replace it with an AND gate and a capacitor. But they go through the effort of building it. Same with using a 555 timer to blink an LED, if there is a micro on the board. I dont think that is very smart, and I wouldnt do that. Or the button debouncing. Maxim makes a button debouncer. Would I use it? It is 6 dollar in single quantity.

You need to ask this questions:
Is it going to make the design simpler?
Is it going to make it more reliable?
Is it cheaper? Remember, software costs money, you just dont see it in your BOM.

If none of those answers if yes, then probably you should use the original plan.

[tggzzz]

Consider, as one example, SOAP. ...
If you want to have a look at other examples, look no further than "enterprise message busses",

SOAP is annoying because it's a "simple" protocol which simplifies in one place and adds complexity in another, the net is virtually zero.  REST on the other hand, especially as it's tolerant to being only partially implemented actually makes things simpler quicker and more productive, especially in the small scale.  WDSLs, stubs, public/private, remote/local and all that non-sense was just renamed and moved around in SOAP.

Enterprise buses are usually similar, in that they try and simplify things but in the end just make them as complicated as the lower level alternatives just in different ways, and at the same time locking you into design decisions they impose upon you.

We seem to be in agreement.

By the way, I didn't say the developer should be blind the other layers.  Anything but.  If you have a problem with SOAP it pays to have the skills to understand the lower and higher levels to determine if it's a problem with SOAP or a problem with your HTTP or application code.

The architect/designer of such things damn well ought to understand what's available, and reuse it where beneficial. The world, and particularly the software world, is full of poorly reinvented wheels that are elliptical or eccentric and are being touted as better than sliced bread.

The software should be blind to functionality beyond the interfaces it consumes.  Hot wiring/jury rigging/spaghetti coding reference through layers leads to tight coupling, rigidity, fragility and a mess later.

Of course. But the devil is in the details.

When creating another general purpose layer to "simplify things for the developer", there is a dilemma: does you interface expose the lowest common denominator or the least common multiple of the underlying layers?

(Next to consider: domain specific languages, as opposed to domain-specific libraries)

The Internet TCP/IP stack is an interest example of layering done very well. 

Very definitely, and I speak as one that was familiar with the protocol stack wars of the late 80s. The right stack won!

They had a policy back then that I wish people would get back to today.  "A protocol is not complete when you have added everything you can add.  A protocol is complete when you have removed everything you can remove and it still works."

There's an earlier, more general, and more elegantly expressed version of that, which I have been known to use as a .sig because it applies in spades to most software...
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.", Antoine de Saint-Exupery, Airman's Odyssey.

[paulca]

We seem to be in agreement.

Friend of mine made this a few years back.  Tres amusing.
https://www.foaas.com/

[Damianos]

Hi,

I'm a beginner mechatronics engineer and I have a general design question:

In product design, if a feature can be achieved by either software or circuit, how to decide what features to implement in software and what features to implement in circuit?

For example: button debouncing, blinking indicator lights, 7-seg digits display etc. Certainly these can be implemented in the micro-controller, but they can also be implemented easily through some basic circuitry on the PCB. What's the criteria to decide which type of implementation is appropriate in the design of a mass-produced product. Is software implementation always cheaper?

Thanks!
YY

Welcome to the forum!

I will try to answer using the examples you give:
- buttons: are these near the micro-controller? If yes, you can use either one or the other. If they are at a distant  point, then they need some filtering and some protection, so the de-bounce is already there.
- blinking indicators: if they are near the controller, it seems easier the software way. But if there is a chance of interfere with critical signals, I think it is better to do it in hardware...
- displays: almost same as above, plus consider the processing power needed to not affect time critical functions.
OK, this maybe is not an answer but some points of thinking.

[David Hess]

It is not only the software you write and maintain which can cause problems.  We had to give up using anything PC related for low level functions when system management mode was introduced because it screwed up anything which relied real time operation.  This extends to reusable code and libraries which propagate reusable bugs and exploits.  Unfortunately not using them just means writing your own bugs and exploits.

I cannot stand the user interfaces on modern systems.  They are slow because of managed languages and incredibly deep software stacks and these limit their ability to replace hardware and dedicated lower level systems.

I have seen some cases where replacing hardware with software was a false economy because the hardware was still needed for reliability in an adverse environment.  For instance discrete debouncing also intercepts ESD from a front panel and this applies to indicators as well since they can conduct ESD.