原创 Exploring the PICAXE (Part 3)

In part 1 of this blog series, I gave an overview of the PICAXE system and did some BASIC programming of my chip. In part 2, we looked at using the simulate" and debug functions, and we considered the analogue-to-digital converter, pulse-width modulation, and the one-line display options offered by the PICAXE. I also mentioned the Dallas-Maxim 18B20 digital temperature sensor, and we discussed how the PICAXE's READTEMP command makes using this sensor really easy.

In fact, the DS18B20 is just one of a family of one-wire devices that support bidirectional communication with an MCU using a single wire. They include sensors, EEPROMs, digital potentiometers, and serial number chips, including the Button devices that look like watch batteries (more on these later). The PICAXE makes it easy to use all these devices with the OWIN, OWOUT, and read serial number (READOWSN) commands, but you would still require four lines of code just to get the basic 12bit value out of a DS18B20. The READTEMP command does all this in one line, along with truncating the 12bit resolution (0.0625-degree) value to a handy eight-bit (one-degree) resolution value. You can also access the full 12bit value using the READTEMP12 command.

Thus, my first task was to hook a DS18B20 up to my PICAXE and start reading it. Yet again, I proved that electronics offers unparalleled opportunities for making a chump of oneself. I failed to notice that the DS18B20 requires a 4.7KΩ pullup resistor on the data line. This is clearly shown in the schematic diagram on the READTEMP page in the manual, along with a pinout of the IC. My reluctance to read the farcical manual meant that I kept getting a temperature of 0 degrees. Along the way, I moved one of the connections, which meant I still failed to get a reading when I finally put in the 4.7KΩ resistor. Finally, I sorted things out and managed to obtain a temperature reading of 24 degrees. The DS18B20 reads in Celsius (Centigrade), which is fine for us civilized types. If you want your readings in Fahrenheit, you will have to perform a conversion in software.

The DS18B20 offers some fancy features, including alarms and built-in serial numbers, so that you can put many of them on one line and address them individually. However, the basic READTEMP and READTEMP12 commands don't access these features. You could do so yourself using the one-wire commands if you wish. Of course, the huge bonus with the DS18B20 is that, being digital, you can put it on the end of a long wire. As long as you can still talk to it, you won't have any worries about analogue voltage drop or noise altering your reading.

I have a couple of indoor-outdoor electronic thermometers that I bought at a Tandy in Paris years ago when I found them on special offer. I wondered if I could duplicate their functions—such as stored minimum and maximum readings—with my DS18B20s. Once I got one connected correctly, it was a simple matter to connect the second and get my display to give me two readings.

The accuracy of the DS18B20 is half a degree. I switched from READTEMP to READTEMP12 to obtain the full 12bit value. Initially, I just displayed the decimal version of the 12 bits. The readings from the two sensors were always within one count of each other. The format of the 12bit data—once you have it in a word variable—is SSSSSTTT TTTTFFFF, where S is the sign bit (1 = negative), T is the integer of the temperature (you get this part with the basic READTEMP command), and F is the fractional part (one count = 1/16 degree = 0.0625 degrees). However, this value is in two's complement format, so negative temperatures tend to look very strange.

It's been a long time since I had anything to do with two's complements, so a reference to Max Maxfield's excellent book Bebop to the Boolean Boogie was necessary. This told me that I had to take the TTT TTTTFFFF portion of the value and subtract it from 1000 00000000 to get the number right. I soon had my system displaying two temperatures. I got the FFFF part to display 0.X degrees by dividing it by 25, which isn't absolutely correct, but it's near enough for what I wanted.

As you can see below, I've mounted my PICAXE board, the OLED display, and a small breadboard on an old modem case to make it a bit easier for me to play around with things.

Two things are apparent from the above image. First, I'd just zapped the Temp1 sensor with Freezit Spray; that's why this sensor is displaying such a low value. Second, my breadboards are not as bodacious as Max's.

I experimented with storing maximum and minimum temperature values. With two's complement representations and possible negative values, this was not as easy as one might hope (at least, not for me). The DS18B20 works from -55 to +125°C, so I added 50*16 = 800 to the raw value to bring all possible temperatures into positive territory. Why *16? The first four bits represent the fractional value. I could then ignore anything over 175*16, compare the current values with those stored for each sensor on switchon, and store them if they were above or below previously stored values. I eventually got this working, but I didn't spend too long on it, because I was keen to move on to other things.

All the one-wire devices have a built-in 64bit serial number, which is composed of an eight-bit device type, a 48bit unique serial number, and an eight-bit checksum value. The PICAXE's READOWSN command reads this serial number for you and puts the results into the byte variables b6 (device type), b7-b12 (serial number), and b13 (checksum). The sole purpose of Dallas-Maxim's DS1990A is to act as an electronic key for security systems. This device looks like an old mercury camera battery, and you can get a key fob holder for it.

As it happens, my employer has an office in Sydney, and the building access used to employ these devices. There were small receptacles for them at the entrance to the car park, in the lifts (elevators), etc. The company has since changed to a card-based system, but I still have the key fob we used to use. I thought I would try and read this using the READOWSN command. It would be possible to display all these variables on my OLED display, but the easiest way to see them is to execute the DEBUG command. This brings up a window on your PC showing the values of all the variables at the time the DEBUG command was run. Imagine if you made a small program like this.

As soon as a device is detected (i.e., the b6 value is nonzero), the system will show you all the values in the debug window. First, I used my DS18B20 temperature sensors and read the different serial numbers from them. Next, I tried reading my DS1990A key. Straight away, I got a different set of values. Incidentally, the DS1990As are truly one-wire (and ground) devices; unlike the DS18B20s, they don't need a positive supply. They are connected as illustrated below.

I did not have the correct receptacle for the DS1990A, so I used a couple of judiciously shaped wires on my breadboard, which worked just fine. My results were as follows (values are in decimal).

You can see that the b6 (device type) variable is the same for the two DS18B20 temp sensors but different for the DS1990A button. The READOWSN command uses a lot of variables, and comparing with a list of OK numbers a byte at a time (not to mention generating the checksum if you really wanted to be secure) would be a pain, but you could do it and make your own security system. You can buy the receptacles and DS1990A key-ring units (and a whole kit with board, button, and receptacle) from PICAXE. Dallas-Maxim also makes a button that has a serial number, a real-time clock, a temperature sensor, and a lithium battery. It can log the temperature at programmable intervals. This is the DS1921, and PICAXE also make a kit with it—very tasty stuff.

Finally, an answer to a question I had asked myself, and which reader Antedeluvian asked in the comments on part 1: "Can you run assembly language routines on the PICAXE?" The answer is no. Think of the PICAXE as a Microchip PIC with a BASIC operating system pre-loaded (the company calls this the Bootloader, but I think it's fair to say it's a bit more than that). This Bootloader is stored in the PIC's on-chip Flash memory. Some of this memory, along with other types of on-chip memory, is available to PICAXE users, but access is very closely controlled, so that you cannot overwrite the PICAXE code. If the company allowed you to run assembler (machine code), you'd have unfettered access to all memory areas of the chip, and the likelihood of someone like me mistakenly overwriting something would be fairly high.

It's important to remember that one of the PICAXE's prime raisons d'etre is to be an educational tool. All of us were students once, and we can remember how easy it is to cause havoc in the classroom. You can use all the chip's spare memory (via PEEK/POKE and other commands), but PICAXE doesn't let you get to the bits that would cause problems. Also, it takes pains to point out that, if you use a PIC programmer on a PICAXE chip, it goes back to being a PIC, not a PICAXE, and you'll have to buy a new one. You cannot get the PICAXE code to reprogram it yourself, either. I think the PICAXE is a pathway to C or assembler, if you want to go there, but it is not in itself a way to learn these tools.

In my next column, I will look at how the PICAXE handles I2C devices. I've already started playing with them. As usual, the PICAXE makes using them really easy. In the meantime, do you have any questions so far?
 

David Ashton
Jack of All Trades