We learn how to use the PICAXE to control a family of devices that support bidirectional communication with an MCU using a single wire.
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 64-bit serial number, which is composed of an eight-bit device type, a 48-bit 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?