comments:
More parts = more complexity = greater probability of failure. Why? If I need n things to work and each have probability p_n of failing, then the probability of the system working is: success(n) = product(i=1..n, 1 - p_n) But, 0 < p_n <= 1, so 0 < 1 - p_n <= 1, so lim(n -> infinite, success(n)) = 0. This is the Keep It Simple Stupid (KISS) design principal. An electric kettle with a timer and a target temperature functionality? Who needs target temperature? A kettle is for boiling water. Do you need your water to be precisely 35 deg C? Are you working with temperature critical enzymes or trying to sparge grain? Or are you trying to make a cup of tea? Let's go down that design path. Throw an microcontroller on there, be generous and put a PIC or an ATMEGA. You need to heat the water with a big ass resistive element, so you need to switch 120 VAC at a few amps. So you need a relay. But the microcontroller doesn't have enough output current to drive the relay coil, so you need a transistor that can handle the voltage / current to turn on the relay. Then you need a temperature sensor of some sort and an ADC to digitize the value so the microcontroller can sense the temperature as an input to its control loop. Which sensor? Can it accurately and reliably sense 4 deg C to 100 deg C? A thermocouple would work ... but it generates microvolt range voltages and you have to worry about junction temperatures and currents and you need some signal conditioning so the microcontroller can read it. And then you need an interface. Push buttons and LEDs or be fancy and put a screen on it. Will that work if it over heats from the boiling water? And you'll need (depending on your microcontroller) a power supply that can provide 1.8V/3.3V/5V/12V (for the relay coils). Why? The bill of material (BOM) on is so expensive! And that's before you have to pay somebody to write, validate and debug the code. And how do you guarantee that the unit shuts off and doesn't keep heating until it boils off the water and dry heats the heating element and causes a fire? The first electric kettle with shutoff was invented in 1955 by the British company Russell Hobbs! They didn't have microcontrollers back then - they barely even had transistors!!! This kettle costs USD $17: https://www.walmart.com/ip/Mainstays-1-7L-Electric-Kettle-Color-White-New-Condition-Model-MS8400778514-3/5158672824 There is no way that has microcontrollers at that price point. But it's the solution that we've had that has consistently worked for 70 years! How did they do it? A piece of bimetallic metal (the two surfaces of a sheet expand/contract at different rates, then you bend it into a coil). Then you put a mercury switch on top of it. As the water heats up, the bimetallic strip expands, changing the orientation of the mercury switch which opens the circuit and it stops heating. There's literally like 4-5 parts! If you want it programmable to different temperatures, you rotate the bimetallic strip. It's the same principle that this thermostat works on: https://www.homedepot.com/p/Honeywell-Home-Round-Non-Programmable-Thermostat-with-1H-Single-Stage-Heating-Manual-Control-Low-Voltage-White-CT87K/100476730 It doesn't need updates, because it only relies on physics! Controlled by software. You USB cable? It has software that that completely transparent negotiates with the devices its plugged in to function properly. Overheat protection in chargers. Almost everything in a car that you don't want to control in a car. Almost everything in a plane. Basic USB cables are straight through or crossed over. USB Power Delivery (PD) requires a Marker Chip in some higher wattage configurations. Lower wattages just use sensing resistors. Here is an example of such a marker chip: https://www.mouser.com/datasheet/2/308/FUSB380C-D-1625964.pdf It is "programmable", in that you can change the configuration that it supports. It does not have firmware, per se. Aside from that, the host (in USB) usually queries descriptors from the device and cable and implements sets a configuration. Devices that connect to a computer of necessity have microcontrollers with firmware. Some of that hardware that supports USB PD is written in an FPGA (in VHDL or Verilog), where the timing is closed and the design is simulated and validated and then sometimes made into an ASIC, by serious electrical engineers, not by some code monkey slinging half baked code. Because, if it fails, you devices (letting the smoke out) or burn somebody's house down. Almost everything in a car that you don't want to control in a car. Fuel injection (FI) is one of the major gains of this, you don't get modern fuel efficiency in an IC engine without an ECU controlling it. They did have mechanical FI in the 1950s but it sucked and wasn't very reliable. But the ECU isn't updated willy nilly. You also don't get modern electric vehicles without a software controlled VFD. In both of these cases, these are necessary, not fluff. But then again, those are rigorous designs under going multiple rounds of review and simulation/testing. Not a big fan of forced non-essential OTA updates ... because they change the state of the device unexpectedly. Almost everything in a plane. Aerospace software is tightly controlled and regulated, because the general public doesn't enjoy random shit falling out of the air and killing them. Even those airplanes with digital (instead of mechanical) instrument clusters have insane levels of validation. Every update is heavily validated, documented and probably registered with some kind of regulatory agency, like the FAA. Tons of stuff outside the cynical, shitty bullshit that corporate sociopaths and capitalist assholes push are currently being controlled by software and they are objectively better for it. I'm not saying everything should have software in it but lots of things already do. There is a bit more nuance, because firmware can mean 1) full ROM image containing an embedded OS and applications running on an application ARM or 2) a small program loop running on bare metal on a small microcontroller, like an ATMEGA, PIC, ARM Cortex M, STM32, etc. In the later case (e.g. #2 and especially if you don't have a cache or pipelined/branching architecture, you can almost count timing deterministically - so timing can sort of be closed). You're not going to have some unexpected OTA update or device-breaks-when-the-company-doesn't-want-to-support-it-anymore situation. They aren't connected, don't have a security attack surface and don't require constant updates. Yes, technically, they run some sort of code, but most people nowadays mean firmware in the sense of option #1. Just because you are cynical doesn't mean you are right. When the only tool you have is software, every solution gets bludgeoned into being a software problem. That's not very elegant.