|
Laboratory 4 Switches, digital inputs and outputs. FSM structure. Electrical bouncing and digital noise |
[17/3] |
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).
|
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.
|
Fig. 2. Example circuit for reading inputs and writing outputs. |
Circuit features using a bullet list:
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.
|
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.
|
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.
|
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.
|
Fig. 5. Hardware-software diagram. |
Our circuits' truth tables are solved executing software routines.
|
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.
|
Fig. 7. Interpreting the truth tables as flowcharts for ready for translations into C code. |
Project location:
C:\EMC\LAB4\FSM\(files)
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.
|
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.
|
Fig. 9. Source code that can be edited from the Proteus window itself. |
|
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.
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.
|
Fig. 11. Prototype running. |
Fig 12 shows connections to the VB8012 logic analyser instrument.
|
Fig. 12. Connecting digital signals of interest to the VB8012. |
|
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?
|
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.
|
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:
C:\EMC\LAB4\FSM2\(files)
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.