Automated RO/DI Water Filtration System
part 2 - software overview
In this installment I will present an overview of the software used in the RO/DI automation project. Before we dive into how the system operates and makes decisions, we need to get some of the important but gory details of embedded systems programming out of the way. The foundation of the RO/DI automation controller is what programmers often call a "game loop". In other words the entire program is an endless code loop that processes inputs and outputs each time it is executed. With each pass of the loop, variables are checked and acted upon accordingly by the program. At the end of the loop, the microntroller jumps the beginning of the loop and executes it again. This happens hundreds (or thousands) of times a second, based on the speed of the microprocessor executing the loop and the complexity of the instructions in the loop.
To make matters a bit more confusing, the program also has to respond to interrupts. An interrupt tells the software to temporarily stop what it is doing and do something else. The RO/DI automation controller has several type of interrupts that it must respond to, most of them based on time. The game loop runs far too fast to check sensors and update the LCD with each pass, so we use timers (built into the microcontroller) to cause interrupts at preset intervals. For the most part, the timer interrupts do not do any real work and instead set flags that are read in the main game loop and acted on when needed.
To provide more detail would certainly result in a failed attempt at teaching microcontroller and programming basics, so without further bumbling I will present an overview of the RO/DI automation firmware (software) that runs on the microcontroller.
The Game Loop
The foundation of the RO/DI automation controller is the infinite processing loop (game loop) that processes the data acquired from user, sensor and timer inputs. By processing the data, the logic embedded in the game loop can set the various system and menu states needed to control the outputs (both physical and display).
When the program starts, initial variables are read from EEPROM storage and the program is initialized. The program then goes into the infinite game loop. On each pass through the game loop, the program checks for flow readings from the flow sensors, pressure readings and TDS readings. It then checks for changes in menu state (triggered by encoder rotation or button press) and performs housekeeping duties. System and menu state changes are acted upon to change the operating mode of the system and provide user feedback. Once the tasks are completed, the loop starts over. The menu and system states will be described in detail below.
In general; An embedded timer will fire an interrupt every 0.0005 seconds (.5 milliseconds). The game loop temporarily passes control to the interrupt routine. The interrupt routine will check the state of the reed switch embedded in the flow sensors (more on those later). If a change in state is detected, then a flag is set. At the next change of state, the flag is cleared and the elapsed time is stored for later use. Furthermore, every 0.5 seconds the system time and date variables are updated from the RTC (Real Time Clock) chip. Lastly, every second a housekeeping flag is set. At this point the program returns to wherever in the game loop it left off.
Rotation of the Encoder or a button press will also fire an interrupt that simply sets a flag indicating that encoder rotation or a button press has occurred. Control is then passed back to the game loop where the actual event can be processed according to the current system and menu state.
Click on the RO/DI Automation Game Loop Diagram to see it full screen. If the image does not display correctly in your browser, you can open a PDF version here.
LCD Display and Menu State Machine
The primary user interface to the RO/DI automation system is an optical rotary encoder equipped with a button and a 4x20 backlit LCD screen. When the encoder is rotated or a button press is detected, the menu state machine sets a new state based on the current state. This is done via a SELECT CASE statement. Each pass of the program loop looks for changes in menu state and acts upon them during execution of the loop. The menu system does not directly control the FUNCTIONAL STATE of the RO/DI automation system, but rather sets flags and variables that are acted upon by the state machine that controls the physical function of the system. It may be more helpful to simply study the LCD menu state diagram below. Each box on the diagram represents an individual menu state. Each individual menu state has an associated LCD display screen and reacts appropriately to button and encoder input.
Click on the image to see the full size LCD Menu State Machine diagram. If your monitor is unable to display the image in the proper resolution, you can view it as a PDF file by clicking here. The diagram shows all of the possible menu states and user input interactions for the LCD user interface.
TCP/IP (http) Menu State Machine
The webserver functionality is derived from a Wiznet wiz810mj ethernet module. I struggled with TCP/IP programming but with the help of Ben Zijlstra and his Wiznet examples, I have been able to create a basic webserver for the RO/DI automation project. I will post the details here once they are worked out. At this point, the project is serving a basic HTML page with a few controls on it. Because each page has to be created in HTML and then ported to BASCOM-AVR, the process is time consuming. Debugging take a long time, as each revision means a re-flash of the Atnega128 microcontroller.
RS-232 Menu State Machine
The RO/DI automation controller is equipped with a serial port that can be connected to a PC running standard terminal emulation software. The settings are standard 8-n-1, 19200. A menu driven command prompt allows the user to monitor and manipulate the controller in real time. Input is buffered as it comes in and is processed in each cycle of the game loop. I struggled with the decision to use menus or a simple command language and may change my mind as the project progresses. While the menu system makes user input easy, it takes much more code to process the states. I do not have a menu state diagram from the serial menu system, as it is not finished.
Functional State Machine (operating modes)
The functional state machine is responsible for opening and closing the solenoid valves and setting the next state. The physical state of the RO/DI automation controller is determined (by the functional state machine) by processing system variables that are set via the other menu state machines, timers and sensor inputs. The state of the system is updated once per second as part of the housekeeping routine in the main game loop.
Click on the image to see the full size RO/DI automation controller Functional State Machine. If the image does not display properly in your browser, you can view it in PDF format here.
Software Development Platform
The software was developed using the BASCOM-AVR development environment from Mark Alberts at MCS Electronics. BASCOM-AVR is a BASIC language IDE and compiler for AVR microcontrollers. I am very comfortable programming in BASIC and not a fan of C or the "arduino" platform. The BASCOM compiler allows the use of the BASIC language as well as ASM code to leverage the AVR and is every bit (if not more) capable than any other AVR development platform or.
The flow charts and finite state machine diagrams were built using Microsoft Visio. Using a tool such as Visio makes mapping out the program flow more intuitive and logic errors can easily be avoided before the first line of code has written.
I use several different software packages for schematic capture, simulation and PCB design. I am not a fan of Eagle PCB, even thought it is the most cost effective package for hobby users. The PROTUES product line from LABCENTER Electronics is a wonderful package. The ISIS schematic capture software is very well suited to hobby electronics and is extremely easy to use. Where the PROTEUS suite shines is in the fact that the ISIS schematic capture and ISIS VSMcircuit simulation are fully compatible with AVR (and PIC, ARM, STAMP, 8051, etc) microcontrollers! You read that correctly, the product not only simulates the electronics, but also simulates the microcontroller with YOUR code! The product is a MUST HAVE for any serious μC hobbyist. I currently am not using the PROTEUS ARES PCB layout package. It is very well endowed, but I am used to the Altium (Formerly Protel) product, to which I have access through a friend in the PCB industry. I am eager to make the switch, but have not had the time to sit down and learn the new PCB software.
That concludes the software overview. In Automated RO/DI Water Filtration System - part 3 we will look at the code and electronics for the flow sensor.