Tag Archive | "thermometer"

Tutorial: Arduino and the I2C bus – Part One

This is part one of several tutorials on how to use the I2C bus with Arduino, and chapter twenty of a series originally titled “Getting Started/Moving Forward with Arduino!” by John Boxall – A tutorial on the Arduino universe. The first chapter is here, the complete series is detailed here.

[Updated 28/11/2014]

In this first of several tutorials we are going to investigate the I2C data bus, and how we can control devices using it with our Arduino systems. The I2C bus can be a complex interface to master, so I will do my best to simplify it for you. In this article we will learn the necessary theory, and then apply it by controlling a variety of devices. Furthermore it would be in your interest to have an understanding of the binary, binary-coded decimal and hexadecimal number systems.

But first of all, what is it?

I2C is an acronym for “Inter-Integrated Circuit”. In the late 1970s, Philips’ semiconductor division (now NXP) saw the need for simplifying and standardising the data lines that travel between various integrated circuits in their products. Their solution was the I2C bus. This reduced the number of wires to two (SDA – data, and SCL – clock). Here is a nice introductory video from NXP:

Why would we want to use I2C devices?

As there are literally thousands of components that use the I2C interface! And our Arduino boards can control them all. There are many applications, such a real-time clocks, digital potentiometers, temperature sensors, digital compasses, memory chips, FM radio circuits, I/O expanders, LCD controllers, amplifiers, and so on. And you can have more than one on the bus at any time, in fact the maximum number of I2C devices used at any one time is 112.

From a hardware perspective, the wiring is very easy. Those of you with an Arduino Uno or 100% compatible board, you will be using pins A4 for SDA (data) and A5 for SCL (clock):

arduino-uno-i2c-pin

If you are using an Arduino Mega, SDA is pin 20 and SCL is 21, so note that shields with I2C need to be specifically for the Mega. If you have another type of board, check your data sheet or try the Arduino team’s hardware website.  And finally, if you are using a bare DIP ATmega328-PU microcontroller, you will use pins 27 for SDA and 28 for SCL. The bus wiring is simple:

nxpi2cbussmall

If you are only using one I2C device, the pull-up resistors are (normally) not required, as the ATmega328 microcontroller in our Arduino has them built-in.  However if you are running a string of devices, use two 10 kilo ohm resistors. Like anything, some testing on a breadboard or prototype circuit will determine their necessity. Sometimes you may see in a particular device’s data sheet the use of different value pull-up resistors – for example 4.7k ohm. If so, heed that advice. The maximum length of an I2C bus is around one metre, and is a function of the capacitance of the bus. This distance can be extended with the use of a special IC, which we will examine during the next I2C chapter.

Each device can be connected to the bus in any order, and devices can be masters or slaves. In our Arduino situation, the board is the master and the devices on the I2C bus are the slaves. We can write data to a device, or read data from a device. By now you should be thinking “how do we differentiate each device on the bus?”… Each device has a unique address. We use that address in the functions described later on to direct our read or write requests to the correct device. It is possible to use two devices with identical addresses on an I2C bus, but that will be discussed in a later article.

As like most devices, we make use of an Arduino library, in this case <wire.h>. Then use the function Wire.begin(); inside of void setup() and we’re ready to go.

Sending data from our Arduino to the I2C devices requires two things: the unique device address (we need this in hexadecimal) and at least one byte of data to send. For example, the address of the part in example 20.1 (below) is 00101111 (binary) which is 0X2F in hexadecimal. Then we want to set the wiper value, which is a value between 0 and 127, or 0x00 and 0x7F in hexadecimal. So to set the wiper to zero, we would use the following three functions:

This sends the device address down the SDA (data) line of the bus. It travels along the bus, and “notifies” the matching device that it has some data coming…

This sends the byte of data to the device – into the device register (or memory of sorts), which is waiting for it with open arms. Any other devices on the bus will ignore this. Note that you can only perform one I2C operation at a time! Then when we have finished sending data to the device, we “end transmission”. This tells the device that we’re finished, and frees up the I2C bus for the next operation:

Some devices may have more than one register, and require more bytes of data in each transmission. For example, the DS1307 real-time clock IC has eight registers to store timing data, each requiring eight bits of data (one byte):

ds1307registers

However with the DS1307  – the entire lot need to be rewritten every time. So in this case we would use eight wire.send(); functions every time. Each device will interpret the byte of data sent to it, so you need the data sheet for your device to understand how to use it.

Receiving data from an I2C device into our Arduino requires two things: the unique device address (we need this in hexadecimal) and the number of bytes of data to accept from the device. Receiving data at this point is a two stage process. If you review the table above from the DS1307 data sheet, note that there is eight registers, or bytes of data in there. The first thing we need to do is have the I2C device start reading from the first register, which is done by sending a zero to the device:

Now the I2C device will send data from the first register when requested. We now need to ask the device for the data, and how many bytes we want. For example, if a device held three bytes of data, we would ask for three, and store each byte in its own variable (for example, we have three variables of type byte: a, b, and c. The first function to execute is:

Which tells the device to send three bytes of data back to the Arduino. We then immediately follow this with:

We do not need to use Wire.endTransmission() when reading data. Now that the requested data is in their respective variables, you can treat them like any ordinary byte variable. For a more detailed explanation of the I2C bus, read this explanatory document by NXP. Now let’s use our I2C knowledge by controlling a range of devices…

The Microchip MCP4018T digital linear potentiometer. The value of this model is 10 kilo ohms. Inside this tiny, tiny SMD part is a resistor array consisting of 127 elements and a wiper that we control by sending a value of between 0 and 127 (in hexadecimal) down the I2C bus. This is a volatile digital potentiometer, it forgets the wiper position when the power is removed. However naturally there is a compromise with using such a small part, it is only rated for 2.5 milliamps – but used in conjunction with op amps and so on. For more information, please consult the data sheet. As this is an SMD part, for breadboard prototyping purposes it needed to be mounted on a breakout board. Here it is in raw form:

mcp4018raw

Above the IC is a breakout board. Consider that the graph paper is 5mm square! It is the incorrect size, but all I have. However soldering was bearable. Put a drop of solder on one pad of the breakout board, then hold the IC with tweezers in one hand, and reheat the solder with the other hand – then push the IC into place. A few more tiny blobs of solder over the remaining pins, and remove the excess with solder wick. Well … it worked for me:

mcp4018cooked

Our example schematic is as follows:

mcp4018sch

As you can see, the part is simple to use, your signal enters pin 6 and the result of the voltage division is found on pin 5. Please note that this is not a replacement for a typical mechanical potentiometer, we can’t just hook this up as a volume or motor-speed control! Again, please read the data sheet.

Control is very simple, we only need to send one byte of data down, the hexadecimal reference point for the wiper, e.g.:

Here is a quick demonstration that moves the wiper across all points:

 and a video demonstration:


Now we will read some data from an I2C device. Our test subject is the ST Microelectronics CN75 temperature sensor. Again, we have another SMD component, but the CN75 is the next stage larger than the part from example 20.1. Thankfully this makes the soldering process much easier, however still requiring some delicate handiwork:

cn75solder1

First, a small blob of solder, then slide the IC into it. Once that has cooled, you can complete the rest and solder the header pins into the breakout board:

cn75solder2ss

Our example schematic is as follows:

cn75schem

Pins 5, 6 and 7 determine the final three bits of the device address – in this case they are all set to GND, which sets the address to 1001000. This allows you to use multiple sensors on the same bus. Pin 3 is not used for basic temperature use, however it is an output for the thermostat functions, which we will examine in the next chapter.

As a thermometer it can return temperatures down to the nearest half of a degree Celsius. Although that may not be accurate enough, it was designed for automotive and thermostat use. For more details please read the data sheet. The CN75 stores the temperature data in two bytes, let’s call them A and B. So we use

with the second parameter as 2, as we want two bytes of data. Which we then store using the following functions:

where *a and *b are variables of the type byte. And as always, there is a twist to decoding the temperature from these bytes. Here are two example pieces of sample data:

The bits in each byte note particular values… the most significant bit (leftmost) of byte A determines whether it is below or above zero degrees – 1 for below zero. The remaining seven bits are the binary representation of the integer part of the temperature; if it is below zero, we subtract 128 from the value of the whole byte and multiply by -1. The most significant bit of byte B determines the fraction, either zero or half a degree. So as you will see in the following example sketch, there is some decision making done in showCN75data():

And here is the result from the serial monitor:

Now that we know how to read and write data to devices on the I2C bus – here is an example of doing both, with a very popular device – the Maxim DS1307 real-time clock IC. Before moving on, consider reading their good data sheet.

ds1307small

Furthermore, it also has a programmable square-wave generator. Connection and use is quite simple:

ds1307schem

However some external components are required: a 32.768 kHz crystal, a 3V battery for time retention when the power is off, and a 10k ohm pullup resistor is required if using as a square-wave generator, and 10k ohm pull-up resistors on the SCL and SDA lines. You can use the SQW and timing simultaneously. If we have a more detailed look at the register map for the DS1307:

ds1307registers

We see that the first seven registers are for timing data, the eighth is the square-wave control, and then another eight RAM registers. In this chapter we will look at the first eight only. Hopefully you have noticed that various time parameters are represented by less than eight bits of data – the DS1307 uses binary-coded decimal. But don’t panic, we have some functions to do the conversions for us.

However, in general  – remember that each bit in each register can only be zero or one – so how do we represent a register’s contents in hexadecimal? First, we need to find the binary representation, then convert that to hexadecimal. So, using the third register of the DS1307 as an example, and a time of 12:34 pm – we will read from left to right. Bit 7 is unused, so it is 0. Bit 6 determines whether the time kept is 12- or 24-hour time. So we’ll choose 1 for 12-hour time. Bit 5 (when bit 6 is 0) is the AM/PM indicator – choose 1 for PM. Bit 4 represents the left-most digit of the time, that is the 1 in 12:34 pm. So we’ll choose 1. Bits 3 to 0 represent the BCD version of 2 which is 0010.

So to store 12pm as hours we need to write 00110010 as hexadecimal into the hours register – which is 0x32. Reading data from the DS1307 should be easy for you now, reset the register pointed, then request seven bytes of data and receive them into seven variables. The device address is 0x68.  For example:

At which point the time data will need to be converted to decimal numbers, which we will take care of in the example sketch later. Setting the time, or controlling the square-wave output is another long operation – you need to write seven variables to set the time or eight to change the square-wave output. For example, the time:

The decToBcd is a function defined in our example to convert the decimal numbers to BCD suitable for the DS1307.

You can also address each register individually. We will demonstrate doing this with an explanation of how to control the DS1037’s in built square-wave generator:

Here is the SQW output in action – we measure the frequency using my very old Tek CFC-250:

For further DS1307 examples, I will not repeat myself and instead direct you to the list of many tronixstuff articles that make use of the DS1307.

So there you have it – hopefully an easy to understand introduction to the world of the I2C bus and how to control the devices within. Part two of the I2C tutorial has now been published, as well as an article about the NXP SAA1064 LED display driver IC and the Microchip MC23017 16-bit port expander IC.

 

And if you enjoyed this article, or want to introduce someone else to the interesting world of Arduino – check out my book (now in a fourth printing!) “Arduino Workshop”.

visit tronixlabs.com

Have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column, or join our forum – dedicated to the projects and related items on this website.

Posted in arduino, CN75, ds1307, education, I2C, learning electronics, lesson, MCP4018T, microcontrollers, tutorialComments (22)

Getting Started with Arduino! – Chapter Two

This is part of a series titled “Getting Started with Arduino!” – A tutorial on the Arduino microcontrollers. The first chapter is here.

I hope you have been enjoying these posts and learning and creating and making many things. Today’s post has several things: taking temperatures, sending data from the arduino back to your PC, opening a library, and some exercises that will help to consolidate your previous knowledge and help revise it.

Note – Using LCD screens has moved to Chapter 24.

First of all, we shall investigate another analogue sensor – a temperature sensor. As you can imagine, there are many applications for such a thing, from just telling you the current temperature, to an arduino-based thermostat control system. And it is much easier to create than most people would think – so get ready to impress some people!

Let’s say hello to the Analog Devices TMP36 Low-voltage temperature sensor:

TMP36

Tiny, isn’t it? It looks just like a standard transitor (e.g. a BC548) due the use of the same TO-92 case style. The TMP36 is very simple in its use – looking at the flat face, pin 1 is for +5V supply (you can connect this to the 5V socket on your arduino), pin 2 is the output voltage (the reading), and pin three is ground/earth (connect this to the GND socket on your arduino). Furthermore, have a look at the data sheet, it is quite easy to read and informative. TMP36 data sheet

The TMP36 will return a voltage that is proportional to temperature. 10 mV for each degree Celsius, with a range of -40 to 125 degrees.

There isn’t any need for extra resistors or other components – this sensor must be the easiest to use out there. However there is one situation that requires some slight complexity – remote positioning of the sensor. It is all very well to have the sensor on your breadboard, but you might want it out the window, in your basement wine cellar, or in your chicken coop out back… As the voltage output from the sensor is quite low, it is susceptible to outside interference and signal loss. Therefore a small circuit needs to be with the sensor, and shielded cable between that circuit and the home base. For more information on long runs, see page fifteen of the data sheet.

At this point we’re going to have some mathematics come into the lesson – sorry about that. Looking again at page eight of the data sheet, it describes the output characteristics of the sensor. With our TMP36, the output voltages increases 10 millivolts for every degree Celsius increase; and that the output voltage for 25 degrees Celsius is 750 mV; and that there is an offset voltage of 400 mV. The offset voltage needs to be subtracted from the analogRead() result, however it is not without vain – having the offset voltage allows the sensor to return readings of below freezing without us having to fool about with negative numbers.

Quick note: A new type of variable. Up until now we have been using int for integers (whole numbers)… but now it is time for real numbers! These are floating point decimals, and in your sketches they are defined as float.

Now we already know how to measure an analogue voltage with our arduino using analogRead(), but we need to convert that figure into a meaningful result. Let’s look at that now…

analogRead() returns a value between 0 and 1023 – which relates to a voltage between 0 and 5V (5000 mV). It is easier on the mind to convert that to a voltage first, then manipulate it into temperature. So, our raw analogRead() result from the TMP36 multiplied by (5000/1024) will return the actual voltage [we’re working in millivolts, not volts] from the sensor. Now it’s easy – subtract 400 to remove the offset voltage; then divide it by 10 [remember that the output is 10 mV per degree Celsius]. Bingo! Then we have a result in degrees Celsius.

If you live in the Fahrenheit part of the world, you need to multiply the Celsius value by 1.8 and add 32.

Quick note: You may have seen in earlier sketches that we sent a value to the serial output in order for the arduino software to display it in the serial monitor box. Please note that you cannot use digital pins 0 or 1 if using serial commands. We used Serial.begin(9600); in the void setup(); part of the sketch. You can also send text to the serial monitor, using Serial.print(); and Serial.println();. For example, the following commands:

would create the following line in the serial monitor (assuming the value of temperature is 23.73):

The temperature is 23.73 degrees Celsius

and send a carriage return to start a new line. That is the difference between the Serial.print(); and Serial.println(); commands, the extra -ln creates a carriage return (that is, sends the cursor to the start of the next line. Did you notice the 2 in the Serial.print(); above? You can specify the number of decimal places for float variables; or if you are using an integer, you can specify the base of the number being displayed, such as DEC, HEX, OCT, BIN, BYTE – decimal, hexadecimal, octal, binary, or byte form. If you don’t use the second paramater of Serial.print();, it defaults to decimal numbers for integers, or two decimal places for floating-point variables.

Now let’s read some temperatures! All you need to do is connect the TMP36 up to the arduino board. pin 1 to 5v, pin 2 to analog 0, pin 3 to GND. Here is a shot of the board setup:

example2point1small

And here is the sketch:

And there’s nothing like a video, so here it is. The measurements start at room temperature, then an ice cube in a plastic bag is pushed against the TMP36 for a moment, them held between two fingers to warm up again…



Quick note: the while() command. Sometimes you want a sketch to wait for user input, or wait for a sensor to reach a certain state without the sketch moving forward. The solution to this problem is the use of the while() command. It can cause a section of a sketch to loop around until the expression in the while command becomes true.

For example:

 

Anyhow, back to the next exercise – it’s now your turn to make something!

Exercise 2.1

Recently the cost of energy has spiralled, and we need to be more frugal with our heating and cooling devices. Unfortunately some members of the family like to use the air conditioner or central heating when it is not really necessary; many arguments are caused by the need for the heating/cooling to be on or off. So we need an adjudicator that can sit on the lounge room shelf and tell us whether it’s ok to use the heating or cooling.

So, create a device  that tells us when it is ok to use the air conditioner, heater, or everything is fine. Perhaps three LEDs, or a single RGB LED. Red for turn on the heat, blue for turn on the air conditioner, and green or white for “You’re fine, you don’t need anything on”. You will need to define your own temperature levels. Living here in north-east Australia, I’m going to have the air conditioner on above 28 degrees C; and the heat can come on at 15 degrees C.

Hopefully you are thinking about the voltmeter we made in chapter one, that should give you a starting point. If not, go back now and have a look. Otherwise, hop to it…
Anyway, here is my board layout…
exercise2point1small
You will need:
  • Your standard Arduino setup (computer, cable, Uno or compatible)
  • Either three LEDs or an RGB LED
  • 3 x 560 ohm 0.25 W resistors. They are to reduce the current to protect the LEDs.
  • a breadboard and some connecting wire
  • Analog Devices TMP36 temperature sensor (element-14 part number 143-8760)
  • a camera (optional) – to document your success!
And a sketch to solve the exercise:

And of course a video. For demonstration purposes, I have altered the values by making them very close, so it’s easier to show you the LEDs changing. The plastic bag used in the video is full of ice water.


Well that was interesting, I hope you enjoyed it and have some ideas on how to put temperature sensors to use. But now it is time to look at a library or two…
Quick note: As you know, there are several commands in the processing language to control your arduino and its thoughts. However, as time  goes on, people can write more commands and make them available for other arduino users. They do this by creating the software that allows the actual Atmel microcontroller interpret the author’s new commands. And these commands are contained in libraries. Furthermore, as Arduino is open-source, you can write your own libraries and publish them for the world (or keep ’em to yourself…) In the arduino IDE software, have a look at the Sketch>>Import Library… menu option. Also, check out here for more libraries! Now to put one to good use…

Update – LCDs were orginally explaned at this point, however they are now explained in their own article – chapter 24. Don’t forget to return to try out the examples and the rest of this chapter!
LEDborder
Exercise 2.2

This is our most complex project to date, but don’t let that put you off. You have learned and practised all the commands and hardware required for this exercise. You only need a little imagination and some time. Your task is to build a digital thermometer, with LCD readout. As well as displaying the current temperature, it can also remember and display on request the  minimum and maximum temperatures – all of which can be reset. Furthermore, the thermometer works in degrees C or F.

First of all, don’t worry about your hardware or sketch. Have a think about the flow of the operation, that is, what do you want it to do? For a start, it needs to constantly read the temperature from our TMP36 sensor. You can do that. Each reading will need to be compared against a minimum and maximum value. That’s just some decision-making and basic maths. You can do that. The user will need to press some buttons to display and reset stored data. You can do that – it’s just taking action if a digital input is high. I will leave the rest up to you.

So off you go!

You will need (this may vary depending on your design, but this is what we used):

  • Your standard Arduino setup (computer, cable, Uno or compatible)
  • Water (you need to stay hydrated)
  • 2 x 10k 0.25 W resistors. They work with the buttons to the arduino
  • Analog Devices TMP36 temperature sensor (element-14 part number 143-8760)
  • 2 little push buttons
  • a breadboard and some connecting wire
  • 16×2 character LCD module and a 10k linear potentiometer or trimpot (For LCD contrast)
  • Analog Devices TMP36 temperature sensor (element-14 part number 143-8760)
  • a camera (optional) – to document your success!

For inspiration, here is a photo of my board layout:

ex2p2boardsmall
… and a video clip of the digital thermometer in action.

And here is the sketch for my example – Exercise 2.2 sketch example. I hope you had fun, and learned something. Now it’s time for Chapter Three.

LEDborder

Have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column, or join our Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

Posted in arduino, LCD, lesson, microcontrollers, tmp36, tutorialComments (40)


Subscribe via email

Receive notifications of new posts by email.

The Arduino Book

Arduino Workshop

Für unsere deutschen Freunde

Dla naszych polskich przyjaciół ...

Australian Electronics!

Buy and support Silicon Chip - Australia's only Electronics Magazine.

Use of our content…

%d bloggers like this: