Introduction: Methodology for Converting an Idea for a Gadget Into an Electronic Circuit

By day I am an Application Engineer who help Application Specific Integrated Circuit (ASIC) designers to use my company's Electronic Design Automation Software to successfully design their chips. In my spare time I dabble in Cryptos, stocks, listen to music, read and make things. I have always being a "maker". It started with my love of science in Middle School and grew into a passion that led me into the Engineering profession. The first few years of my career, I was more motivated to focus on what I was getting paid to do -- making customers successful when they use my company's products. Therefore, I had stopped making things for a while. However, the popularity of the Arduino Project and Platform woke up the sleeping "maker" in me. I was fascinated by the size and movement of the Maker Community. I felt obliged to lend my voice to the movement. I reflected and introspected to try to answer the following question:

What do I wish I knew that I didn't know when I started as a maker in Middle School ?

My first thought was "oh man, there is so much, I should write a book!" I am still thinking about doing that because I do believe there is a lot of relevant information that can can improve the "maker" experience and the overall process for folks who are new to the community. This would be practical Electronic Theories and methodical approaches -- not deep engineering math and science that tend to scare folks. The goal would be to help makers be more successful in bringing their projects to life.

Anyway, thinking back within the context of my earlier question, the thing that seems to always rise to the top of my mind is that "I wish I had a methodology for converting or moving my gadget ideas from the abstract virtual world of my mind to the real form of an electronic circuit."

To my mind, this is probably a challenge for most new "makers" who might not have an engineering background or a deep foundation in science. So, what is my approaching for doing this ... it is derived from 4 basic concepts:

1) Detailed written description of gadget functionality -- This should include entities coming in (number of inputs and what is being captured (temperature, pressure, etc..). The number of outputs and how it is suppose to be presented (video, LED, buzzer, etc). What type of processing to be done on each input. Any restrictions with respect to logic implementation. Is the device portable ? Should it use both battery and AC line voltage ? What should be the operating voltage and frequency of the device if appropriate? Include any waveforms you know of going into, out of, or internal to the gadget -- it doesn't need to be a perfect drawing. Try not to reinvent the wheel, if your gadget is similar to something that exist, include that detail so that the original device can be used as a template if it is open-source.In general, include anything that you might think is important to the design process.

2) Abstraction -- High level bare minimum representation of an entity without the distracting granular implementation details. The main point is to start with a telescopic 1000 feet view and then move to the 100 feet view, then a 10 feet view and if necessary to a microscopic 1 foot view. The abstracted 1000 feet view is a good starting point to get an early win and build your confidence to move to an incrementally more detailed view.

3) Divide-and-Conquer -- The process of breaking up a big complex problem into smaller more manageable problems that are easier to solve. The whole theory here is that regardless of how complex a system(AKA: gadget, circuit) is, it is usually made up of simpler and smaller sub-circuits. This is analogous to the English language, regardless of how complex and/or big a book is, it is created from the same 26 letters of the alphabet. Or, think DNA !

4) Human System Model Representation -- The fact is, all Electronic Gadget is a system that is similar to the human system - think TV, Cell phone, computer, GPS and any other Electronic Gadget. All of them have 3 basic parts: Input, Output and some type of Processing (in the simplest form, this could be wire, a buffer that allows current to flow. In more complex forms, this could be amplification, a mathematical operation, Boolean operation, integration, sequential operation or a combination of one or all of these and others). See figure - 1 below for Human System representation.

Step 1: Figure 1 - Human System Representation

The ultimate goal is to get to a schematic that you can use as a blueprint to simulate and/or build your design. If you fail to plan then you plan to fail -- that is what will happen if you don't have a schematic. As I mentioned previously, the general strategy is to start with the most abstract high level view of the gadget and continuously refine it until you get to a final netlist. The figure 2 - below is the Abstract representation of the human system.

Step 2: Figure 2 - Abstract Block Diagram View of the Human or Electronic System

The Inputs and Outputs are pretty straight forward and is usually determined by the entity you are trying to capture for processing and how you want to present the results from processing to the user. In an electronic system, the input sensors converts other energy forms into electrical energy. The output actuators does the opposite -- converts electrical energy into other forms of energy. These are a list of some input sensors:

1) Microphone

2) Phtototransistor

3) Pressure device

4) Switch, etc ...

Some types of output actuators are:

1) Speaker

2) Video Display

3) LED

4) Motor, etc ...

In most cases, you can find an existing sensors to use. However, in some cases, you might need to do some conditioning of the signal from the sensor before processing -- for example, convert an Analog signal into a Digital signal. Or, filtration of the signal to remove noise. The same might be needed for the outputs.

The most challenging of the 3 parts of a system is the processing. One of the fundamental question that needs to be addressed is whether the processing will take an Analog or Digital approach? In my view, Analog design is 100X harder than digital design. That could take a a whole book to explain ... so, for simplicity, we will assume digital and focus on that for now. The next question is how will the processing logic be implemented ? Using discrete logic gates? Using FPGA (Field Programmable Gate Array)? Using a PSOC (Programmable System-on-Chip)? Or, using a Microcontroller (AKA: Also known as embedded design)? The design flow choice and complexity will dictate whether the "Divide-and-Conquer" methodology needs to be used to facilitate the hardware logic design. As a I mentioned earlier, the fact is, ALL complex circuits are made up of simpler less complex circuits. Usually, these simpler building blocks already exist -- they are adders, counters, comparators, shifters, etc. This is even more common place for digital designs. In fact, that is the beauty of using a Microcontroller -- it already has most of these blocks included in it. So for this and many other reasons, I will assume that a Microcontroller will be used for the processing in most of the gadgets that will be created. Obviously, using this approach will minimize the hardware design complexity. However, it is not a free ride, you will still need to deal with the software coding challenge. But, those tend to be easier to deal with. In fact, you can still use the "Divide-and-Conquer" method to get to a software solution. For example, writing one big C/C++ program to process all 5 inputs from Figure 2 might be a daunting task. But, if you apply "Divide-and-Conquer" and break up that big function into smaller more manageable problems by creating an individual function for each of the Input sensor, you won't be paralyzed by the complexity of the problem. So, tying everything together, the following is a flow diagram in figure 3 - shows the steps in the flow.

Step 3: Figure 3 - Shows the Flow Steps in a Concise Manner

By applying the above steps, you can get from gadget idea to schematic. So, lets try to apply this for a simple project -- we should start small and go from there ....

**************************** Project Description *************************************

Design and simulate a PIR device that detects humans within 10 ft in front of the sensor. When a person is detected, the device should provide an audio as well as visual indication. The device is portable and battery operated. It should operate from a 5V supply. The device can be implemented with discrete logic but, I would prefer if a microcontroller is used for processing since I would like to add more functionality at a later date. The operating frequency is not that important but, considering power consumption might be an issue, anything less than 20 MHZ should be more than enough.

******************************* End Project description ********************************

So, to start your component selection will have a big impact on the complexity of the processing. For example, if you choose an Analog input you would need to convert that to Digital. I don't want that problem so we can choose a Digital PIR sensor such as the one from Parallax for the input. I will use the Arduino UNO for processing and for the output you can search on the internet for information about how to drive a LED and a Buzzer. You can also search Google to find the specification for the PIR sensor. I did the following search:

"specification for parallax pir sensor"

Used the spec from the following location:

For simulation and virtualization of the design I used:

It turns out that they have a lot of these simple sub-circuits like the LED driver circuit that you can use for your design. They show a starter circuit when you do a search for the component. The one thing I was not able to find on the website is the specs (shows current, voltage, etc which is needed for correct operation) for the components in their libraries but, I didn't mind searching on Google.

Anyway, from a theory of operation perspective, all I needed to do was to detect the logic "HIGH" from the PIR sensor when it detects a human and write a very simple code to assert one output pin to "HIGH" to turn on the LED and Buzzer. The layout of the virtual simulation is included below in Figure 4. You can even go to the Tinkercad website and play with it.

Step 4: Figure 4 - Logic Circuit in the Tinkercad Virtualization Environment

Here is the simple code for the project:


int pir_pin = 7;
int show_result = 2;

void setup() {

pinMode(pir_pin, INPUT);

pinMode(show_result, OUTPUT); }

void loop() {

int read_pir = digitalRead(pir_pin);

if (read_pir == HIGH){ digitalWrite(show_result, HIGH);

// delay(1000); // Delay can be added in a loop to blink led } }


Obviously, you can take this simple example and morph it into something more useful. For example, you can replace the UNO board with a simple 8-pin "ATTINY" chip. Or, you can use the output of this circuit to control a relay sub-circuit to turn off a TV instead of triggering a buzzer and LED. If a human is not detected in front of the TV (someone left it on..) in a specified period of time, turn it off ! If you are really adventurous, you can replace the UNO with your own custom design. That is beyond the scope of this writing but, you can find some free software to help with that process at the following location:

By-the-way, this circuit is simple enough that you can build it on a breadboard to confirm that it works in real life. Sometimes you might need to make some small changes to the design to make it work optimally once you build the real physical device.

Also, if you would like an update when the book is done, please send an email to: with "Book Status" in the subject line.

First Time Author

Participated in the
First Time Author