Control Systems Design:
A (basic) Thermostat
Scope of Work
Design and develop a rudementary thermostat control system. The system behavior was developed using a Moore finite state machine architecture, and was then implemented in 3 phases (A, B, C, and D), each one on different sets of hardware. Behavior between all systems is to be identical, and the goal was to learn how to implement various systems on different development platforms.
Development Phases: The Breakdown
The State Machine
A control system first requires a well-defined behavioral specification. As this was a very basic thermostat, there were 4 operational modes: Heat, Cool, Off, and Low battery. With these modes defined, and the I/O for the system specified, an operational state table for the system was created. From this, we created a state machine diagram to be used for all implementations. (Apologies for the handwritten diagram.)
Now, we implement this diagram in four different ways.
Phase A: Discrete Logic
Design Overview:
In this iteration, we implement the state machine using discrete logic chips. CMOS logic was found to be acceptable, as the overall performance requirements were very low. The main concern was functionality and system stability.
Texas Instruments CD4000 components were selected for their low cost and ease of use. Additionally, the DIP packaged solution worked perfectly on the breadboard used for bus interconnections and power distribution.
Using the state machine, basic circuit diagrams were developed using National Instruments’ Multisim SPICE simulation software. Test and verification of circuit functionality was accomplished via simulations and were found to satisfy design requirements.
The usage of a function generator for the MSTR_CLK suplemented Multisim not having the CD4541BE chip available for simulation, and makes it easier to troubleshoot timing errors within the circuit.
Our CD40175BD D-Flip-Flop storage element has the capability to store 4 bits, which is plenty of space for the state machine, as the diagram indicates we only need a 2-bit state code.
Construction, Test, and Verification
The circuit was built according to the design specifications shown above using a basic breadboard and interconnect wires. Power was supplied to the system by the +5V output from the NI myDAQ data acquisition device, and LEDs serve as operational mode indicators for the system.
Constructed circuit (apologies for the messy wiring…)
Waveform capture of operational clock frequency
Average system amperage load
The system passed its functional test matching the intended system behavior generated by the state transition table and machine diagram. Future evolutions of this system would more carefully plan board layout, as there is a large chance that high-speed operation of this circuit would incur numerous errors relating to interference. Additionally, the usage of a breadboard for interconnections is inherently poor, due to the large parasitic capacitance present with such a large number of physical interconnections.
Phase B: NI myDAQ Implementation
In this iteration, we implement the state machine using National Instruments LabVIEW Virtual Instrumentation (VI). The advantages of using VIs are numerous, as it is possible to quickly design and implement complex systems. The graphical nature of the development environment is conducive to fast debuggging, test, and verificaton for practically any signal processing application.
Design Overview:
To interface with the VI, we select the National Instruments myDAQ Student Data Acquisition device. This simple, easy-to-use, low-cost peripheral board provides a reliable platform for us to deploy and test the design throughout its development.
Using the state machine, basic circuit diagrams were developed using National Instruments’ LabVIEW graphical programming environment. Test and verification of circuit functionality was accomplished via simulations and were found to satisfy design requirements.
I/O constraints with the myDAQ required that we utilize NAND gates to generate the final output, with the myDAQ outputting the 2-bit state identifier signals. These signals were fed into CD4000-series chips to generate the final output.
Virtual Instrument Implementation Diagram.
Not all operational states are shown here, but appear very similar in their internal workings.
Construction, Test, and Verification
The circuit was built using the I/O connections specified in the VI, and the state transition table SOP equations to properly generate the output.
Constructed circuit (apologies for the messy wiring…)
The system passed its functional test matching the intended system behavior generated by the state transition table and machine diagram. Future evolutions of this particular implementation would select an I/O peripheral device capable of more discrete I/O. This would decrease the design complexity, and position the VI such that it could be deployed anywhere with the proper peripheral device without needing discrete logic to support it.
Phase C: Microcontroller Implementation
In this iteration, we implement the state machine using a simple 16-bit microcontroller from Microchip Technologies. These low-cost devices are used in nearly every common embedded system, and have an enormous amount of flexibility in their application. Written in C, these controllers can be programmed quickly and efficiently, with a rich development knowledgebase.
Design Overview:
The particular microcontroller utilized is a Microchip Technologies dsPIC33EP64MC502 16-bit DSC, which is technically optimized for motor control. However, the flexibility of this system means that it is more than enough computational power for our needs.
Using the state machine diagram, we translate the logic seen into line-by-line sequential logic for the microcontroller to run. Additionally, instead of using LEDs as I/O, we instead use a LCD display using message strobing from the microcontroller itself.
All system development was accomplished in MPLAB X ‘s IDE, a feature-rich developer environment for their product line. Additionally, the controller runs on C, which is a widely used language in millions of systems worldwide.
Seen below are some snippets of code from the design. Note that all of this code is not enough to run the entire system, as there was lots of backend configuration performed on the microcontroller and display to make it work. Unfortunately, people like to steal code from the internet and make it “theirs.”
Input & output configuration
Basic state machine logic structure
Data routing to the LCD
Output indicator logic
Construction, Test, and Verification
The circuit was built using a standard I/O layout and communication signal wires for the LCD display unit. For brevity, the complete circuit diagrams are not shown here, as the usage of a SNAP debugger/programmer was necessary to flash the microcontroller
Constructed circuit (apologies for the messy wiring…)
The system passed its functional test matching the intended system behavior generated by the state transition table and machine diagram. However, the LCD display unit was relatively unstable, and required a relatively large amount of power to provide a useful contrast level. Further work on this design would utilize a lower-power display, and provide richer content via the display, as the microcontroller utilized in this design was much more powerful than what it was used for in this project.
Phase D: CPLD Implementation
In this iteration, we implement the state machine using a complex programmable logic device (CPLD) from Atmel. These facinating devices are the precursor to modern-day FPGAs, and have the ability to quickly develop combinational logic systems for realtime signal processing.
Design Overview:
The CPLD used in this design was an Atmel (now Microchip) ATF750CL, a high-performance low-cost device with plenty of computational overhead for our system.
Using the state machine diagram, we translate the logic seen into a combination of sequential and combinational logic for the chip. The ability to combine types of digital logic on such a low-cost device is a major advantage of using this type of programmable device.
System programming was accomplished in Atmel’s WinCUPL developer environment. WinCUPL is frusturatingly buggy, and has obviously been ported to new versions of windows without much thought into the program’s stability. At least it’s faster than Vivado to debug!
Seen below are some snippets of code from the design. Note that all of this code is not enough to run the entire system, and it’s in poor form to post all of the code. Unfortunately, people like to steal things from the internet and make it “theirs.”
Basic hardware description language code
For the system clock signal, we utilized a CD4000-series clock generator at approximately 1.5Hz. The CPLD can run at 71 MHz at the very maximum, so we are well within its limits.
Construction, Test, and Verification
Another huge advantage of using a CPLD is the ease-of-integration into a schematic. Simply map the I/O, give it power, and watch it run. The circuit was constructed according to the document generated by WinCUPL, and can be seen below:
Constructed circuit (apologies for the messy wiring…)
The system passed its functional test matching the intended system behavior generated by the state transition table and machine diagram. This design was not complicated or involved, and it does exactly what it needs to do - nice!
