My IoT Product Journey
In my never-ending journey to expand my expertise in Maker IoT I've been reading The Art of Electronics when I can find time. I'm taking my time and really trying to internalize the concepts being presented. In the section on RC circuits I came across the following schematic.
Using a few very inexpensive discrete components and a voltage comparator IC (which, btw, can be created with discrete components) you can create a timed output signal from a simple input signal. Based on component selection the output pulse of the circuit can be "programmed" to go high for a very specific amount of time before turning off. Simple enough right? And perhaps not very interesting until you consider the applications. The input could be a coin sensor and the output turning on an air compressor like at a gas station. Maybe the input is motion detection from a PIR sensor and the output is turning on a flood light for a set time. What about having a float as the input and the output is running a sump pump for a number of seconds. So what's the point? Well, this simple circuit really got me thinking.
We Don't Always Need Code
To be honest, if I was given a requirement to trigger an output for a fixed time based on an input I would do it in firmware. The input would trigger some interrupt and then use a timer of some sort to control the output on/off time. But think about that for a second. What if my platform is a Raspberry Pi running a full operating system? There are SOOOO many thing that could go wrong that would prevent 1) my system from picking up the input trigger 2) triggering the output and most concerning 3) turning off the output after the time expires. Imagine turning on a sump pump for 30 seconds but during that 30 seconds some other application on your Pi causes a full scale kernel dump. Uh oh!
In the same application if I only use discrete components the only thing that could realistically go wrong is electrical failure of one or more of the components involved. This is far less likely than a rogue application causing a buffer overflow or even your own code being the culprit.
So We Shouldn't Write Code Anymore?
Ok, slow your roll, I'm not headed that far. Remember how Woz used to build entire computers including the video output with discrete components and chips. He literally built entire systems using physical components that ran no code. The schematic WAS the code. But boy did that take a lot of time and physical design space. Moving into the code domain fixes that problem. We can iterate very quickly just by typing new instructions and trying them out without having to solder up a new configuration. In short, coding saves us time and space; LOTS of time and space.
So What's Your Point Kevin?
Is it possible that the ease of coding things in firmware has resulted in it being a bug riddled crutch? Are there some parts of our designs that are great to prototype with code but should be designed out for production in discrete components to create a more deterministic, reliable result over time? I don't know the answer but this simple circuit really got me thinking about it.
