My Pi Description

My Experiences With the Raspberry Pi -- Tracking My Learning -- My Pi Projects

Sunday, June 15, 2014

DS18B20 Temperature Project For Gertboard/Arduino

Some time ago I became rather fascinated with the Maxim/Dallas DS18B20 temperature sensor. I bought a couple and connected them to my Pi. This blog has tracked my progress with the little device, starting with the four posts of June of 2013:
Then, the October, 2013 post: Finally, the November, 2013 addition:
That project became very useful and I learned a lot. However, I had a couple of issues. I did not think it was suitable to tie up a general purpose microprocessor (the Pi) with a connection to a couple of sensors. I was disappointed that the driver did not support all functionality of the device like choice of resolution. There also seemed to be a stability issue. About half of the measurements resulted in a CRC failure requiring measurement repetition.
I thought the sensors should really connect to a microcontroller like the ATmega328P. Once programmed, the microcontroller could be lifted off the programmer and placed in its own circuit board in an enclosure. I did this for my camera remote control project back in January of this year.
Thus was born my concept for a very involved project. Here are the design parameters I set for myself:
  1. Connect multiple sensors to an ATmega328P microcontroller.
  2. Design for a hypothetical industrial application where many DS18B20 temperature sensors may be employed.
  3. Store the 8 bit ROM code and a 12 character (max) description for up to 50 devices.
  4. Use the ATmega's 1 kbyte of EEPROM to store the ROM codes and descriptions.
  5. Use the Arduino IDE to develop the code.
  6. The "programmer" will be the Gertboard connected to the Raspberry Pi.
  7. Write my own 1-Wire interface library incorporating all of the DS18B20's functions found in its data sheet.
  8. Remove the ATmega microcontroller from the programmer and install it on a circuit board within an enclosure.
  9. Connect a 16 character by 2 line LCD display to the microcontroller to display temperature and device number.
  10. Connect several switches to the microcontroller for simple menu control.
  11. The microcontroller and the Pi to communicate wirelessly.
  12. The Pi will serve as a "front end", with a menu driven choice of operations to be carried out by the microcontroller.
  13. Temperature measurements returned by the microcontroller to be graphed by the Pi using RRDtool.
I've been working on items 1 - 7.
If you are interested in this project it is important to be familiar with the DS18B20 device and the 1-Wire interface. Maxim has an excellent data sheet describing the functionality, programming commands, and timing requirements. It can be found here.
I wrote my own 1-Wire library for Arduino/Gertboard. You may ask why since the Arduino IDE comes with a 1-Wire library already included. I simply wanted the challenge of doing it. I also wanted to present the library to others with code and comments that anyone can understand. However, if you use the Arduino built-in functions like pinMode(), digitalWrite(), and digitalRead() to control your microcontroller I should tell you that I do not! I use ATmega direct register programming. I have tutorial at this blog entry that explains the difference and how to use direct register programming.
My 1-Wire library only covers the DS18B20 temperature device. If it covered all of the Maxim devices, I would have to purchase one of each and test that it works with my library. I'm not going to do that - I'm only interested in the temperature sensors. There are a couple of other temperatures sensors and they probably will work with my library. Actually, there does not seem, to me, to be a reason to use any of the other Maxim temperature sensors. I could not see any advantage to them. At present, my library is not quite complete. Here is the status of the functions I have completed. The names are taken from the command names in the data-sheet:
  • Initialization - Done
  • Search Rom - Done
  • Read Rom - Done
  • Match Rom - Done
  • Skip Rom - Done
  • Alarm Search - Done (updated July 3)
  • Convert T - Done (updated June 18)
  • Write Scratchpad - Done
  • Read Scratchpad - Done
  • Copy Scratchpad - - Done (updated June 22)
  • Recall E2 - - Done but not tested (updated June 22)
  • Read Power Supply - - Done (updated June 22)>
  • Compute CRC (this function is not listed as a separate command in the data sheet) - Done
I have not incorporated parasitic power. This really only effects Convert T at this time. I will get to that after I sort through my supply of old parts and find a suitable transistor to pull up the bus connection to Vcc. When that occurs, I will augment Convert T to handle parasitic power. I plan to complete the four functions I have not started. I have incorporated parasitic power into the project as of June 18.

A disappointment with the Gertboard and the ATmega EEPROM

I simply could not store data in the ATmega's EEPROM when the ATmega is installed on the Gertboard. After writing to an EEPROM address, a read of that address always resulted in reading 11111111 - which is the cleared state. I spent about a week trying various programs. Nothing worked.
I explained my problem on the Classic Gertboard section of the Raspberry Pi forum. A very knowledgeable fellow from the Netherlands really tried his best to help me out. We had quite a few conversations on the forum. Gert van Loo, the developer of the Gertboard chimed in a couple of times. I really thank them for their help. Ultimately, nothing worked for me. I think the one person who could have solved the problem, Gordon Henderson of Gordon Projects, did nor respond to my email. Gordon developed the means to use the Arduino IDE with the Gertboard.
I really wanted this EEPROM access to work so I purchased an Arduino Uno, mainly just to see if my code would work at all. I connected the Arduino to the Pi and used the same Arduino IDE as I used with the Gertboard and it all just worked. My guess as to why it does not work with the Gertboard is the difference in how a sketch is uploaded to the ATmega chip. With the Arduino, one selects "Upload", but with the Gertboard, "Upload Using Programmer" is used. I have a feeling that the latter clears the EEPROM (writes all 1's to all bytes) before uploading. Now, one of my design parameters has changed. The project is off the Gertboard and onto the Arduino. Furthermore, my Arduino is now disconnected from the Pi and connected to my Windows PC. I take advantage of the much faster environment, ease of printing, and easier access to my githup repository allowed by the PC.
As of this time, I have the library mostly written, as I discuss above. I wrote several Arduino sketches to check out the library and make the sensors useful. Now, everything runs on the Arduino - the Raspberry Pi is not involved. I have not added the lcd device - that will be next.

Github Repository - Library and Sketch Files

I spent about a day learning about github and created a repository for this project. The repository can be found here.
The repository includes three libraries:
  1. EEPROM_Functions library - functions used to read from and write to the ATmega EEPROM.
  2. InputFromTerminal library - to input floating point or integer numbers from the serial monitor.
  3. One_wire_DS18B20 library - all the ROM Commands and DS18B20 Functions as called out in the DS18B20 data sheet.
In the repository, the directory "DS18B20_Temperatur_Sensor" contains the sketches to read temperature, scan for new devices, and manage the devices in EEPROM, etc. They include the following individual sketches:
  • "Read_Temperature" - Asks user what devices to run, number of measurements, and time between measurements. Function determines if devices are connected using parasitic power. Measurements are made accordingly. User has the option to print out the temperature limits as well as the resolution along with the temperature. Once the run is made, displays the average of all measurements for each device. If there were any CRC errors or initialization errors, the number of these are reported. If a device is connected using parasitic power, when the device is undergoing the convert temperature process, a transistor pulls the 1-wire data line up to Vcc. The time for this "hard pullup: is dictated by the data sheet for the resolution programmed into the device's scratchpad. For devices not connected by parasitic power, when undergoing temperature conversion, the device, itself, informs the bus when the conversion is done.
  • "Scan_for_Alarms" - Scans the 1-wire bus to see if any device's temperature is out of limits. If so, displays that information to the user. This function must determine if the device is connected using parasitic power.
  • "Find_New_Device" - Scans the 1-wire bus to see if any device has been added. If so, asks user for a description which is stored in ATmega EEPROM along with the ROM code. Asks user to input upper and lower temperature limits and resolution. These are stored within the device's scratchpad and the device's EEPROM
  • Devices_On_The_Bus - Uses library search_rom() to report to the user all devices it finds on the 1-Wire bus along with their ROM codes. It also reports the result of the CRC of the ROM codes.
  • "Devices_in_EEPROM" - Displays all devices in the EEPROM along with their descriptions.
  • "Edit_Stored_Information" - Reports to user the ROM code, description, upper and lower temperature limits and resolution for each device on the 1-wire bus. Asks user which device to change and what to change. Changes are made accordingly, and stored.
  • "Remove_Device_From_EEPROM" - Allows user to remove ROM code and description for any device from the ATmega EEPROM. This does not remove information from the device's scratchpad or the device's EEPROM.
I had hoped to combine all of the above sketches into one sketch with a menu that allowed the user to select the functionality that each individual sketch provided. I actually created that sketch but when compiled, I found I exceeded the memory space allowed for variables. I exceeded the memory space due to the large amount of text associated with print statements. I felt these print statements are more important than a menu driven capability so I abandoned that approach. It is necessary to bring up, compile, and run each sketch individually.
Also, at the top level of the repository there is the directory "EEPROM Sketches". Under here you will find several sketches used to manipulate data in the ATmega EEPROM. These sketches were used to assist with other code development and troubleshooting.

Couple of Final Comments

As I said, previously, it was very common to have CRC errors when controlling these sensors from the Raspberry Pi. After making many thousands of measurements, with the Arduino controlling the sensors, I have received no initialization or CRC failures.
Just to reiterate, everything is written for the Arduino IDE. They are in the repository in such a manner that they can be downloaded directly. The libraries will have to be placed into your Arduino\libraries directory for them to be recognized.
My next blog entries will delve into details of some of my code.

3 comments:

  1. Great post!
    I too need to configure the DS18B20 to change the limits for use with a Pi2 and you appear to be the only person who has cracked how to configure it easily!
    Unfortunately I know nothing about Anduino so do I need to get a 328P or will other devices work too - e.g. Mega 2560.
    Bill

    ReplyDelete
  2. By limits I guess you mean resolution. I didn't look for a way to change the resolution on the Pi. I moved all temperature measurements and related stuff to Arduino. Thought microcontroller was better than microprocessor for sensors. Arduino is inexpensive and has reasonably good IDE. Check it out.

    ReplyDelete
  3. No - limits. My plan is to use a limit value to identify a sensor without knowing the serial so if I program one sensor with upper limit 01h and another 02h then I can report the sensor 1 value without knowing what its serial is. Your library should allow me to program the sensors limits and I just realized that the raw data returned by the Pi's w1-therm library does indeed contain the limit values so I should be good to go!
    Bill

    ReplyDelete