UPC EETAC Bachelor's Degree in Aerospace Systems Engineering EEL



Laboratory 4

Switches, digital inputs and outputs. FSM structure. Electrical bouncing and digital noise



1. Specifications

We have two main goals for the laboratory session:

(1) read digital inputs and write digital outputs.

(2) study the software organisation of a typical application as a finite state machine (FSM). 

Symbol of the application

Fig. 1. Example circuit for reading inputs and writing outputs.

Our circuit will read (poll) two switches and perform the state diagram represented in Fig. 2. Two active-high LED are for indicating in binary the state that the FSM is executing: "00", "01", "10", "11". Another active-low LED connected to W_L will generate a 12 Hz square wave. 

State diagram example

Fig. 2. Example circuit for reading inputs and writing outputs.

Circuit features using a bullet list: 

Example specifications

Accordingly to the state diagram the machine has these three operating modes:

- SW1 = SW2 = 0, the FSM is jumping freely from state to state. In this way the W_L output will be a 75% duty cycle rectangular waveform the frequency of which will be determined by software execution times.

- SW1 = 1; SW2 = 0, the FSM generates a 12 Hz square waveform.

- SW1 = 0; SW2 = 1;   W_L = 0 and so, the LED3 is always ON.


2. Planning


In this introductory application planning the hardware means simply thinking about where to connect switches and LEDs to Arduino pins. We can power the application from the USB +5V connector or from the external unregulated +Vin plug.

Hardware pins

Fig. 3. Hardware circuit for selecting I/O pins. Light blue labels show the pins that can be configured as digital inputs or outputs in this typical AVR microcontroller ATmega328P populating the Arduino UNO board. 



Software running in Arduino or other similar training boards will be organised in two main parts. A system initialisation function setup(), and an infinite loop that executes continuously loop(). A high-level C-like Arduino compiler will be used to generate the assembly language executable file.


Fig. 4. Software flowchart. Setup() configures the system and loop() contains the assembly code to be executed continuously at the maximum microcontroller speed.


Software programming style for solving all laboratory applications will be based on the architecture of a finite state machine (FSM). We adapt the typical FSM architecture from digital systems to computer programming replacing the state register based on data flip-flops by a RAM variable updated every time that the loop is executed.

The fundamental idea of synchronicity derived from the CLK signal will be discussed in next laboratories.

FSM adaptation

Fig. 4. a) FSM architecture using digital circuits. b) FSM adapted to computer programming.

The way for generating a squared wave when at STATE_1 will be simply toggle the variable var_Wave after having measured a period of time TW = 41.6 ms.  All the RAM variables will be char (byte) type for easy debugging using the watch window.

RAM variables

Fig. 4. List of RAM variables. Arduino timing functions such millis() will be used for measuring timing periods.

The application can be conceptualised using our hardware/software diagram represented in the next Fig. 5. The advantage of such organisation is the separation of hardware-related interface functions and pure software functions independent of the hardware that are processing RAM memory variables.

Hardware-software diagram

Fig. 5. Hardware-software diagram.

Our circuits' truth tables are solved executing software routines. 

Truth tables

Fig. 6. Truth tables for the state_logic() and output_logic() combinational circuits.

As shown in Fig. 7, before obtaining the C code for each truth table, we will draw the equivalent flowchart interpretation where the corresponding statements are easily identified.

flowcharts for translating the truth tables

Fig. 7.  Interpreting the truth tables as flowcharts for ready for translations into C code.

Project location:


3. Development & 4. Testing


The first step consist in capturing the schematic in Proteus. This is the FSM.zip file containing the hardware and software project files.

Simulating the application in Proteus

Fig. 8. It is a good idea to simulate the application and run and test for debugging purposes. This picture shows the circuit capture in Proteus.


The idea is to start adapting a similar example. All our applications will consist of FSM architectures. This lab itself becomes an example to copy and adapt. Using the simulator it is possible to run and follow in detail the code execution while interacting with hardware devices.

Explain how the switches are read and how the output pins are written.

Source code window

Fig. 9. Source code that can be edited from the Proteus window itself.


Running interactively the application

Fig. 10. Instruments and watch window for debugging purposes.

NOTE: Print logic analyser results using the PDF format and setting white background to save ink.


Topics in EMC

Find and discuss analogue and digital methods for reducing the signal bouncing associated to mechanical switches. Find examples in real schematics or commercial chips.


5. Prototyping

Download the application to an Arduino board and build the circuit in protoboard or universal PCB as in LAB3. Perform measurements using VB8012 logic analyser instrument to characterise this design and observe how the FSM is switching states accordingly to the read values from switches.

Prototype running

Fig. 11. Prototype running.

Fig 12 shows connections to the VB8012 logic analyser instrument.

Measuring waveforms

Fig. 12. Connecting digital signals of interest to the VB8012. 

Switching states continuously

Fig. 13. SW1 = SW2 = '0'. Capturing waveforms and visualising real phenomena. Logic analyser running at 1 GS/s.

Why when sampling at 1 MS/s (Fig. 14) the captured waveforms are cleaner and the glitches do not appear? Thus, which one is the real waveform generated by the prototype circuit?

Sampling at 1 MSample/second

Fig. 14. SW1 = SW2 = '0'. Capturing waveforms and visualising real phenomena. Logic analyser running at 1 MS/s.

In Fig. 15 we see the output W_L generating the expected 11.8 Hz squared signal.


Fig. 15. SW1 = '1'. Capturing W_L. The FSM is running only in STATE_1 generating the squared waveform.

We can discuss solutions to eliminate such undesirable or unpredicted effects such delays and glitches. How software can be improved? What is the significance of 7.5 ms delays and even shorter glitches of 7 ns in this application?


At this point it will be useful to introduce the idea of the Arduino shield PCB for prototyping using connectors and avoiding wires. This is a seed file FSM_PCB.zip to start capturing the schematic in Multisim and be able to draw a PCB in Ultiboard.

Circuit capture

Fig. 16. Circuit capture in Multisim - Ultiboard.

Transfer the circuit netlist to Ultiboard. Place and route the shield.


Fig. 17. Example component placing in an Arduino shield before routing.

Analyse the problem  of naming conventions when using schematics, symbols and several EDA tools.

Visualise several component default pads. Enlarge them for easy soldering and copy them to your user library.


6. Reporting

(1) Generate a new project FSM2 adding a new switch SW3 to choose between two rectangular output waveforms: 30% DC when SW3 = '1', and 75% DC when SW3 = '0'. Project location:


Write a report discussing only the hardware and software adaptations and changes with respect this tutorial FSM project.


IMPORTANT NOTE: Print logic analyser results and simulator graphics using the PDF format and setting a white background to save ink. In this web format, pictures can also be represented in black background, but it is not possible when preparing materials for printing in paper.

NOTE: Print file listings in sheets of paper using your printer or our UPC Canon printer system as coloured annexes using the indicated tools. Once printed, comment the code lines of interest using handwriting.