Project name: YATM (Yet Another Temperature Monitor)

Index
Project description................................................................................................................................1 1Aim of the project..........................................................................................................................1 2Specifications.................................................................................................................................1 Hardware components and design choices...........................................................................................2 1DE2 Board.....................................................................................................................................2 2Arduino UNO and circuitry on breadboard...................................................................................4 2.aLM35......................................................................................................................................4 2.bFan..........................................................................................................................................4 2.cMAX3232 and RS-232 interface............................................................................................5 2.dArduino Board........................................................................................................................5 Firmware and design choices...............................................................................................................6 1NIOS II..........................................................................................................................................6 2ATMega328p.................................................................................................................................9 3How the communication is managed...........................................................................................11 Conclusion..........................................................................................................................................12

Project description
1 Aim of the project

The YATM (Yet Another Temperature Monitor) is intended to be used in small volume in which it is necessary to monitor and control the temperature through a fan. It was designed using the Altera DE2 development board and Arduino UNO. Another aspect of the project is that I tried to use less resource as possible.

Specifications
An LCD screen must be used to show a navigable menu. The user can set sampling interval, critical temperature and number of samples to be stored. The user can check the setted values through the LCD display. The user can request the MMA data group: maximum, minimum and average temperature. These value are shown on the LCD display.

The YAMT must be compliance with these specifications:

The system must check the temperature continuously and properly set the fan speed.

Hardware components and design choices

The main components are a Cyclone II FPGA (DE2 Board), an ATMega328p microcontroller(Arduino UNO), a fan, a serial cable and the temperature sensor LM35.

DE2 Board

The DE2 board was used to implement a NIOS II processor and some peripherals as shown below:

Figure 1: The Nios II core and peripherals As show in Figure 1 there are two parts: the core and some peripherals that are implemented on the FPGA and other peripherals that are located on the DE2 board. For what concerning the FPGA there are: The Nios II core type f that is the most powerful version of Nios II; it is used to implement the navigable menu and to manage the communication with Arduino board. I used the most advanced version just because in design phase I did not decide whether to implement new specifications or not. The OnChip Memory is a 40KB RAM, with a data width of 32 bit. Since I used the most expensive processor version, the remaining space on the FPGA doesnt allow to use a large OnChip RAM. One of the aim of the YATM is to use less resource as possible, so I tried to

not use an external RAM, otherwise other components are needed like the PLL. In the software part we will discuss more deeply this problem and how to solve it. The JTAG UART is used to program the FPGA and to debug the code. Six PIOs are defined in two different way: four are used as inputs and are connected to the switches, and the other two PIOs are used as output to power up the LCD display. Four switches (SW10-SW11-SW12-SW13) are used to navigate through the menu. A better choice would be to use the push button on the board, but after few tests I notice that these are damaged. The main problem of using the switch was that they are not debounced; in the software part we will discuss this problem. The LCD display is used to navigate through the menu. The RS-232 port is used to allow the communication between the NIOS II and the ATMega328p microcontroller, through a serial cable. I decided to used the UART protocol since it is easy to use and because the YATM can be used to control the temperature over long distance. The following table contain the relationship between the baud rate and distance: Baud Rate 2400 4800 9600 19200 In my case, I used 9600. Distance (m) 914.4 304.8 152.4 15.24

For what concerning the DE2 peripherals we have:

Arduino UNO and circuitry on breadboard

Figure 2: Schematic view Component C5,C6 C1,C2,C3,C4 R1 Value 100 nF polyester 1uF electrolytic 1 K

The Arduino board was used to develop the firmware for the ATMega328p. The microcontroller is used to: Get and store the temperature from the LM35 sensor. Control the fan speed according to the current temperature and the critical one. Manage the communication with the Nios II processor.

2.a

LM35

From the datasheet we know that the LM35 output is linear with a scale factor of +10.0mV/C. Therefore, if we suppose to have a temperature range of 0-100 C, the output range is 0-1 V. Again, to use less resource as possible, I did not use any conditioning circuitry but I modified the input range of the internal ADC from 0-5V to 0-1.1V in order to be as much precise as possible. Moreover the ceramic capacitor C6 is used as decoupler.

2.b

Fan

The fan is activated only if the actual temperature is greater than the critical one. A PWM signal is

used to modulate the fan speed. Although the fan is very small (200, 70mA), the microcontroller cannot drive it directly, so a BC141 transistor is needed, which is designed for switching application up to 1A. The 1N4007 is used as flyback diode and the C5 capacitor to absorbs voltage spikes. R1 is used to limit the base current.

2.c

MAX3232 and RS-232 interface

The MAX3232 is used to interface the ATMega328p with the NIOS II processor through the RS232 serial cable. Since the voltage level on the RS-232 are different with respect to the serial port of the Arduino board, a voltage level translator is needed. In order to make the project as simple as possible no hardware control was used, so I used only a subset of the DB9 female interconnection, in particular pin 2,3 and 5. For what concerning the MAX3232 connection I just referred to the datasheet. The data packet is the simplest one: 8 bit of data, no data parity, 1 stop bit and no hardware control.

2.d

Arduino Board

The connector To Arduino used in the Figure 2 is just a simplification since in the prototype there are only direct connections between the breadboard and the Arduino board. A real implementation is reported below:

Figure 3: Breadboard view Referring to Figure 2, we can define the pins of connector To Arduino: Pin 1: the GND is shared between the breadboard and Arduino UNO.

Pin 2: is connected to the Arduino RX serial pin, to receive the data from the serial communication. Pin 3: is connected to the Arduino TX serial pin, to send the data to the serial communication. Pin 4: is connected to the Arduino A0 analog pin, that is connected to the internal ADC. Pin 5: is connected to the Arduino 11 digital pin, used for the PWM signal.

Firmware and design choices

Since there are two different development platform, I wrote two different firmwares. The Altera DE2 board was programmed using the C language, while for the Arduino UNO I used the Processing language, that is the official C-like language used for this board.

NIOS II

The available space for the firmware is only 40KB. To match this value I used the Small C Library, that is a reduced version of the newlib ANSI C standard library. This choice allow me to use only the OnChip memory, but gives me a lot of troubles. For example no floating-point support for printf() family of routines, no support for scanf() routines, no buffering of stdio.h output routines and no stdio.h input routines. To overcome these limitations I used the minimal character-mode API, provided by Altera, that are some of the forbidden functions but without using buffers. In particular I used the alt_printf() that can be used to print char or string but not floating-point. In fact to write something on the LCD display I used the character-mode device, that is the simplest way to send and receive data to/from a device. It consists in setting the LCD display as stdout, and use the alt_printf() to write something on the display. Since there is no possibility to print a float, for example the temperature, I decided to exploit an Arduino UNO feature that consist in send data through the serial interface but converted in char or string (see the Serial.Print() function in the ATMega328p section). In general I used the suggestions provided into the Reducing Code Footprint in Embedded Systems paragraph (chapter 6) of NIOS II software developer's handbook. Another tool provided by Altera is the HAL (Hardware Abstraction Layer) that I used to send and receive data through the RS-232 port. In particular I made use of read() and write() functions that are explained in the HAL API reference. Moreover I used the alt_ic_isr_register() that is used to attach an interrupt to a specific switch. Thus when a switch make a falling transition, the related interrupt is enabled which call a specific function. Usually this function change the CURRENT_STATE variable to go to the next state. In fact the firmware is organized in a FSM, as show below:

Figure 4: NIOS II FSM

Not all the circles are valid states. Circles in lower case are simply functions attached to interrupts. For example at the power up the init_function is executed and then the START state is reached. If I activated the switch sw10, the attached interrupt will call the show_menu1_isr() function that does not change the state but it just display some useful informations related to the switches. A particular case is the biggest circle, since it is just a simplification of the FSM. In fact the CRITICAL_TEMP, SAMPLING_INTERVAL and DATA_INTERVAL share the same next states, thus I preferred to draw completely just one of them and avoid to draw all the transitions. Another simplification is the duplication of the START state just to avoid confusion. Another important detail is about transitions: if the arrow is not associated with a switch, it means that the transition is made automatically after the code inside the CURRENT_STATE is executed. Following a brief explanation of the states: init_function: it initialize all variable and CURRENT_STATE variable. show_menuX_isr(): it gives informations on which switch to use to do a task. DISP_SET_VALUE: show which are the current setted value for the critical temperature, sampling interval and data interval (number of samples to hold). REQUEST_DATA: used to reach the REQUEST_MMA and REQUEST_ACT that are used respectively to request the MMA data packet (Max, Min, Avg) and the actual temperature. SET_VALUE: used to reach the SAMPLING_INTERVAL, DATA_INTERVAL and CRITICAL_TEMP states that are used to set the values through the DECREASE, INCREASE and SET_AND_SEND states. These last three states made use of the PREVIOUS_STATE variable (that could be SAMPLING_INTERVAL, DATA_INTERVAL or CRITICAL_TEMP) variable to determine which variable elaborate.

Each time an interrupt occurs, a short delay is inserted into the attached function, in order to implement a software debounce since the switch are not hard debounced.

ATMega328p

A program developed with Arduino is composed by two principal functions: setup() and loop(). The setup() function is used only to initialize the microcontroller, while the loop() function can be considered as the main in a normal C program, but it is repeated infinitely. Lets explain the code with the following flowchat:

Figure 5: Flowchat ATmega328p firmware To better understand the microcontroller firmware it is necessary to explore the embedded Arduino UNO functions: pinMode(): Configures the specified pin to behave either as an input or an output. AnalogWrite(): Writes an analog value (PWM wave) to a pin. AnalogRead(): Reads the value from the specified analog pin. The Arduino board contains a

6 channel, 10-bit analog to digital converter. This means that it will map input voltages between 0 and 5 volts into integer values between 0 and 1023 if the reference voltage is not changed. Serial.Begin(): Sets the data rate in bits per second (baud) for serial data transmission. AnalogReference(): Configures the reference voltage used for analog input. Serial.available(): Get the number of bytes (characters) available for reading from the serial port. This is data that's already arrived and stored in the serial receive buffer (which holds 64 bytes). Serial.read(): Reads incoming serial data. Serial.print():Prints data to the serial port as human-readable ASCII text. This command can take many forms. Numbers are printed using an ASCII character for each digit. Floats are similarly printed as ASCII digits, defaulting to two decimal places. Bytes are sent as a single character. Characters and strings are sent as is. Millis(): Returns the number of milliseconds since the Arduino board began running the current program. This number will overflow (go back to zero), after approximately 50 days. get_sample(): if the time interval from the last sample is equal or greater than the sampling interval setted by the user, then get a new value from the sensor. In this case it is not a simple read, but I create a low pass filter in software reading eight values and calculate the average. calculate_mma(): calculate the maximum, minimum and average temperature using the data collected so far. reset_data(): each time that sampling_interval or data_interval value is changed by the user, all the data collected so far is erased and a new dynamic structure is allocated (malloc() and free() are used). control_speed(): if the critical temperature is less then the current temperature, then the fan speed is increased until the maximum speed is reached or the current temperature becomes less then the critical one. The opposite if the critical temperature is greater then the actual one. EstablishContact(): used into the setup() function. It is used to start the communication with the NIOS II. In particular, the microcontroller send a 'W' (stand for Waiting) until the NIOS II get the 'W' and send a 'K' (stand for OK).

Function that I wrote are:

How the communication is managed

An important aspect is how the communication between the ATMega328P and the NIOS II is managed. The user can decide to setup values like sampling interval or to request data from the sensor, therefore only the NIOS II can send commands and the ATMega328p can only send and receive data. Possible commands are described in the following table:

Command Request MMA Request current temperature Set sampling interval Set data interval Set critical temperature

Code 'a' 'b' 'c' followed by a byte containing the value 'd' followed by a byte containing the value 'e' followed by a byte containing the value

In the last three row of the above table, the NIOS II also send a data. I decide to define it in this way: Sampling interval: defined as 'alt_u8', the maximum value is 99. Its value must be multiplied by 15 to obtain the real interval, for instance if I set its value to 99 it means that the microcontroller will get a new value from the sensor each 1485 seconds. Data interval: defined as 'alt_u8', the maximum value is 99. It defines how many sample to store in the microcontroller memory, and that are used to calculate the MMA data packet. If we choose a data interval equal to 99, and a sampling interval of 99, we can monitor the temperature for the last 147015 seconds (around 40 hours). In theory the maximum values are 800 samples (considering 32 bit for a float value and know in advance that the amount of remaining memory on the microcontroller is 26KB) and 50 days as sampling interval (due to the millis() function). Critical temperature: defined as 'alt_u8', the maximum value is 99.

Each time that the microcontroller send or receive a data, it sends a 'k' as acknowledge. I used this method because when the NIOS II receives a data from the RS-232 interface, it reads one char per time (remember that I used the Serial.print() function to send data) until a 'k' is received. For instance when the user request the MMA data packet, the NIOS II send a command data according to the above table, and then the ATmega328p sends a 'M' to indicate that at least a data is present and then sends max+'k', min+'k', avg+'k' (the data is sent as ascii characters).

Conclusion
The YATM is quite simple but there were some troubles: In the testing phase, there was too much noise on the power supply especially when the fan was activated. This problem made the sensor output a little bit unstable so I decided to use as less jumper as possible on the breadboard, use a ceramic bypass capacitor as near as possible on the LM35 power pins, another electrolytic bypass capacitor and make use of a software low pass filter. I discovered too late that the push buttons are partially damaged, wasting a lot of time. The aim of using as less resource as possible. This aspect influenced both hardware and software design as previously discussed. The strange behaviour of the LCD display, since it seems to work randomly. For instance if I try to reset the NIOS II using a dedicate switch (sw15), the display shows a black line and I need to load again the software.

Troubles are welcome, since they help to improve troubleshooting skills.