标签: PICAXE

One of the EE Times editor, the illustrious Max Maxfield, is currently on a quest to learn the Arduino. In one of his recent blogs, Max said the following: My most recent fling was playing with a PICAXE controller board based on a Microchip PIC; I programmed it using a form of BASIC. The PICAXE was a lot of fun, but it's too low-level for what I need. This gave me some cause for concern, as I had coincidentally just ordered a small PICAXE kit as part of a special offer by one of my suppliers. I raised this as a comment in Max's column, wondering if I'd done the right thing. In response, Max went to some lengths to justify his own interest in the Arduino, but he also said: "...for just messing around with your own projects, I think you will love the PICAXE." Before we proceed further, let me give you a little background. I did a bit of microprocessor programming in the "good old days"—the 80s and 90s—mostly on the 8080 and the Z80. My life then shifted more into telecom, where I work to this day. But modern telecom has grown increasingly divorced from the electronics that supports it, and I have felt a strong desire to get back to the electronics side of things. My recent programming has been mainly on things like PABXs and Procomm at work, so I took the bull by the horns and ordered the PICAXE kit. I have done a lot with BASIC in the past, including the old Sinclair ZX81 and Spectrum, and I also programmed a terminal emulator in Qbasic. The end result is that I got pretty good at BASIC, so I thought the PICAXE would be a good starting point for my foray into microcontrollers. I'd also like to learn C at some stage, but for the moment I wanted something I could get to grips with quickly for a few ideas I wish to "mess around with," as Max puts it. On top of everything else, Max then asked me if I would write a couple of blogs on my experiences with the PICAXE system. Having Max nipping at your heels for blogs to post is a fine incentive to get going and do something, so I jumped at the chance. The PICAXE world consists of various Microchip MCUs that have been pre-programmed with a bootstrap loader that enables very easy programming without an expensive programmer. These are coupled with a development environment that lets you write programs in a variation of the BASIC language. The available chips range from the 08M2, which has 8 pins and 6 I/O lines, to the 40X2, which has 40 pins and 33 I/0 lines. Programming (on PICAXE's own boards) is performed through a 3.5 mm stereo type jack connector like those used on MP3 players. All the chips offer analogue-to-digital converters (ADCs), pulse width modulation (PWM), I2C and serial connections, and touch interfaces, as well as standard digital I/O. The larger ones also offer SPI and a couple of other options. This is all pretty tasty to someone whose last hands-on experience was with systems that needed vast arrays of chips to achieve all the above, though I have kept a hands-off eye on microcontroller technology and pretty much knew what to expect. Memory-wise, the PICAXE chips offer fairly limited capacities compared to the huge memories available in other MCUs. To be fair, however, these devices are aimed more at the educational and hobby/DIY market than professional applications ( click here to see a table detailing the capacities and capabilities of the various PICAXE chips.   Apart from bare chips, PICAXE offers various DIY kits and boards to get you started. There is a huge array of gear available, including add-on sensor boards and output devices. For instance, you can get various LCD output modules that only require a one-pin serial connection to the PICAXE. There are various boards oriented towards specific tasks. The 28X2 PICAXE comes as a 0.3" 28-pin chip, but you can get a 0.6" board containing the 28X2 MCU, download socket, voltage regulator, and reset button that would be ideal for using on a breadboard. You can also get a 28X2 "Shield Base" board, which is compatible with Arduino Shields for expansion. All in all, there's some very tasty stuff indeed (click here to see an index of boards, chips, and kits—use the small blue links under the "Product Codes" to get more information). Back to my little kit. I got one of the smaller versions—the AXE092 kit with the smallest 08M2 chip; three LEDs and a piezo sounder for output; and a switch and an LDR (light-dependent resistor) to provide digital and analogue inputs. The assembly was very easy, thanks to the excellent instructions, and it would be even for someone with little electronics experience. Power is from a small 3xAA battery box (4.5V), though you could also use a 3-5V power supply. My kit's programming lead was serial (there is a USB version now, which is probably why my kit was so cheap!) But you can make up your own serial lead if you wish. Here is a schematic of my kit:   Observe that the schematic refers to the chip as an 08M, which is an older chip; mine came with the latest 08M2. The programming pins are 2 (Rx) and 7 (Tx). As you can see, Pin 7 (= port 0) is also used as a digital output. You can use the programming input, Pin 2 (= port 5, not shown above) for other purposes, but you then have to reset the chip (or use the BASIC DISCONNECT command) before programming it again. The AXE092 kit does not appear in the list I mentioned above—I think it's been discontinued (again, this is probably why I got it so cheap), but there is a small User Manual available . A photo of the AXE092 board is shown below (note that this photo was taken from the manual—the LEDs on the board I built stand up straight and my resistors are all oriented the same way, LOL):   The AXE092 PICAXE Kit. The big black thing at the upper left is the programming socket. The small black thing at the lower left is a push switch. The DIP switch is for disconnecting outputs to use them for other things. The upper wires on the right-hand side go to the battery; wires on the lower right-hand side go to a piezo sounder. It was at this point that I ran into my first problem—I found my PC did not have a serial port. The Device Manager said that I did, but I could not find "hide or hair" of it. My motherboard manual also said I had such a port, but I discovered that was for a previous board version. Fortunately, I had a USB-to-Serial adapter knocking around, so I got that out. I had previously installed the software that came on a CD with my kit. This installed the "PICAXE Programming Editor," the manuals, which I didn't look at much (it's a guy thing), and a driver for the USB programming cable (which I didn't have). Installation was quick and easy. The screen is simple and fairly intuitive and there are large icons for the common tasks as illustrated below:   In my case, I had to change the COM port from COM1 to COM3—using the "Options" tab—for my USB-to-serial lead. I then entered—from memory—a program that was on the instruction sheet for my kit, whose purpose is to make the three LEDs flash in sequence. Here's that program:   The first time I tried to download the program to the board, I was presented with an error message telling me that the wrong hardware was connected—the environment was set up for a 20M2 chip and it had found an 08M2. I corrected this (the error message helpfully took me to the "Options" screen to do this) and I tried again. This time I got another error message telling me that Pin C.3 was input only. My port numbers should have been 0, 1, and 2, not 1, 2, and 3 (d'oh!). This was also quickly corrected and my little board was soon flashing its three LEDs in sequence. Observant readers may have noticed that the correct program (without comments) is in the screenshot above. I quickly tried a few other things. I had earlier skimmed through the tutorials and recalled that there was a "SOUND" command that made tones. The editor, through the "Help" tab, offers easy access to the manuals. These are in three parts: "Getting Started," which offers a wealth of general information on how microcontrollers work, and more specific information on the PICAXE Chips and system; "Basic Commands," which—as you might expect—provides a command reference; and "Interfacing Circuits," which has some basic electronic circuits for inputting to and outputting from your PICAXE pins. A few seconds later, having consulted the command reference for the "SOUND" command, I had a loop program going making a rising tone. I then tried making a 3bit binary counter using nested FOR...NEXT loops. I cut and pasted a bit here and got distracted and did not notice that my last "NEXT" statement referred to B0 instead of B2. When I tried to download the program, the error message told me specifically that B0 should be B2. Probably not the hardest thing to deduce, but I was impressed at how helpful the error messages were whenever I did anything wrong—this is a big plus for anyone starting out. With my previous experience with BASIC, I found the programming very easy. I did have to refer to the manuals a bit, but mostly for commands and naming conventions. For instance, variables will be named "bitx," "bx," or "wx" depending on whether they are bit variables, byte variables, or (16bit) word variables. Also, these variable overlap in memory; for example, 'bit0' through 'bit7' are the same as byte 'b0,' so you have to keep your wits about you there. On the plus side, this can be extremely useful if you want to extract bits from a byte. To read a digital input, you use the "PINx" statement, where 'x' refers not to the actual pin number but to the port number. Meanwhile, outputting digital values—as shown in my program above—uses "HIGH x" or "LOW x." Some of this is a bit tricky at first, but really—as compared to the GWBASIC and QuickBasic that I was used to—it's just a matter of getting used to some new commands and inputting and outputting using pins and ports instead of keyboard and screen. So, not too much of a learning curve at all. Max was right. I am having a lot of fun. I can already see the limitations of the PICAXE system, but that is looking from the viewpoint of professional applications. For the kind of stuff I get up to in my workshop, the PICAXE platforms are pretty much ideal. I am already thinking about more programming—using the ADC for example—and using some of the finer features of the programming environment, and getting a bigger PICAXE chip to play with, and... But my bed is calling, so I'll leave all that for another day and—if Max will let me—another blog. David Ashton Jack of All Trades  

In my previous blog , I gave an overview of what the PICAXE system comprises and an account of my first forays into programming the beast. As I noted, I wanted to go a bit further into the capabilities of the development environment and the PICAXE processor. In Part 1 , I referred to the naming restrictions on variables and input/output ports. To make your programs easier to understand, you can use the "SYMBOL" command to give a less cryptic name to any of these. For example: This statement associates the name "DELAY" with byte variable "b0." Once you've made this association, you can use statements like the following: You can do the same type of thing with port names for the inputs and outputs. The programming editor contains a "SIMULATE" function, which enables you to single-step through a program and see what the outputs would do. I tried it on my counter program and it worked fine, opening a new window with a picture of the chip, showing the LED pins going on and off as the program stepped through the statements. You don't need to be plugged into a board to do this—it's an offline simulator. My next task was to start using the analogue-to-digital converter (ADC). PICAXE processors contain 10bit ADCs. I thought that using this feature would entail some setup and configuration, but not so! There is a "READADC (port)" command that sets up the specified port for ADC use, reads the ADC on the specified port, and presents the eight most significant bits for use (if you wish to access the full 10 bits, you can use the "READADC10" command). As I was using a small PICAXE that can only display three or four bits on LEDs, I wondered if I could use the three LEDs on my board to display the most-significant three bits of the 8bit value. My board has an LDR (light-dependent resistor) on one ADC port to give a convenient way of getting a variable voltage on that pin. To see if this was working properly I used the debug function. You just insert the "DEBUG" statement into your program, run it, open the debug function in the editor, and you can see the values of all variables. So I wrote a small program as follows:   When I ran this program and opened the debug window, I could see the value of the ADC output as variable "b0." Happily, with the ambient light in my office, this was around 125-126. If I covered the LDR with my finger it would go down to almost 0; if I shone a torch (flashlight) on it, it went up to around 240. So I knew I was reading the input value OK. Now, you can access the bit values of variable "b0" using the variables "bit0" to "bit7." Thus it was easy to access the most-significant three bits and use them to drive the LEDs as follows:   Wow! I had my 3bit ADC working! This whole process was absurdly easy and took far less time to actually do than it did to write about it here. The next thing I decided to experiment with was some PWM (pulse-width modulation). The PICAXE has a "PWMOUT" command in the following form: In this case, "period" is a variable in milliseconds from 0-255, while "duty cycle" is a value from 0 to 1023. You can use "period" to set the frequency (1/period) if that's important, and then a "duty cycle" of 100% is roughly 4x the "period" value. Don't worry if this sounds complicated because the editor has a Wizard to work everything out for you:   This Wizard helpfully gives you the command to use at the bottom, and you can also copy the command and paste it into your program. I had fun making the LED on output 2 (my only PWM output on this chip) "breathe" (gradually fade up and down). Again, the PICAXE makes all this really easy and the command reference is detailed and easy to follow. David Ashton Jack of All Trades  

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  

In part 1 of this blog series, I gave an introduction to the PICAXE MCU system and performed some simple BASIC programming with my chip. In part 2 , I looked at using the SIMULATE and DEBUG commands, along with the analogue-to-digital converter, pulse-width modulated output, and the one-pin display options offered by the PICAXE. In part 3 , I interfaced my PICAXE to a DS18B20 temperature sensor and some other one-wire devices. The next thing I wanted to try was using I2C chips. I remember reading about the new I2C interface in Elektor magazine in the 1980s, but even though I have seen it used in quite a few products, I've never had much to do with it myself. Inter-IC communication (I2C) was devised by Philips (now NXP) as an attempt to standardise a two-wire bus for communication between integrated circuits in order to save pins. I recently stripped a scrapped plasma TV and kept the audio board intact. On checking the datasheets for the chips used, I discovered it had two Class-D 9W amplifiers and a TA1343 audio processor IC, which lets you control the volume, balance, bass, and treble using I2C. There are all sorts of other tasty I2C ICs you can obtain—for example, for outputting to multi-digit LED and LCD displays. And then there are the usual 24Cxx EEPROMs and various real-time clocks (RTCs). Being able to talk to an assortment of these chips using only two pins on your MCU is very useful. As usual, the creators of the PICAXE make I2C easy. For example, I found the I2C tutorial fairly informative, though I already knew the basics. This tutorial needs updating (it shows outdated commands and chips), but it does give a good overview of how PICAXE chips talk to other I2C chips. For example, you set up for each chip you are using with the HI2CSETUP command as follows.   This sets the PICAXE up as the I2C master—there is also an I2CSLAVE version of the command that lets you set up your PICAXE chip as an I2C slave. This could be really useful for creating your own intelligent I2C peripherals (in fact, you can get a kit for making an I2C LCD or OLED display), but let's not get ahead of ourselves. Using the above command, you instruct the PICAXE as to the address length (I2CBYTE for eight bits or I2CWORD for 16 bits) and the mode (I2CSLOW for 100kHz or I2CFAST for 400kHz) for each chip. There are variations of the mode command to account for using PICAXE chips at faster speeds; they default to 4MHz (8MHz for the larger X2 chips) using the internal resonator, but you can use an external resonator and run them up to 64MHz. The reference was a bit scanty on what speeds you can tell it to use, though. Once you've done this, you can write to and read from that chip with the HI2COUT and HI2CIN commands. With certain restrictions, you can mix devices on an I2C bus, which comprises two lines. So you can make, for example, a data logger using a PICAXE, an RTC chip, and an EEPROM in which to store your data, along with a serial link and/or a display to upload or read this data. PICAXE offers such a kit, and the I2C tutorial uses it as an example. One thing that was not too clear in the manual or the tutorial was the fact that the address you set up with the HI2CSETUP command is a base address, and each read or write you perform advances this base address by 1. So if you say, for example:   This will read the I2C device at the base address into variable b1, Base address+1 into b2, etc. That's useful for reading the whole contents of an RTC chip at one go. You can also say:   And it will put those characters into the first 12 locations of an I2C-enabled EEPROM chip. I had a fossick (Australian for "rummage" or "search") around my spares box and found a 24C02 (256B) EEPROM and a PCF8574 eight-bit port I/O extender. I'd also ordered a DS1307 RTC chip, as I can see a lot of use for RTCs in the stuff I'd like to build, and I knew they would do for an initial foray into I2C land. I thought that I'd start with the PCF8574. It looked an easy chip to use, and it could drive a seven-segment display, which would provide an immediate output to verify a simple program ('programme' for plan). Alas, after an hour of messing around, I was almost certain it was a nonworker (so much for my spares box), so I switched over to my DS1307 RTC chip, which I knew was new and ought to work. And the PICAXE manual had some example code for it, so I could be reasonably sure I wasn't coding anything wrong. Happily, this device did work immediately. I programmed in a time and read it back in a loop, and I could see the seconds and minutes advancing. I then commented out the write line in my program ('programme' for plan) and reprogrammed the PICAXE. I was now able to switch the whole circuit off and read the correct time when I powered it up again. I know coding for I2C from scratch is tricky, but as usual, PICAXE makes it very easy. You don't have to worry about any nitty-gritty details like timing considerations. I was reading and displaying the contents of my RTC around three times a second with a loop and a PAUSE command. The DS1307 RTC has a pin that generates an output once a second (this can be changed), and this can be used as an interrupt. The PICAXE is pretty versatile with regard to interrupts. You can use almost any combination of pins, conditions, and (on the larger chips) ports you want. Being only a small chip, my PICAXE 08M2 has only six I/O pins, so I only wanted to use pin 3 as an interrupt. To set up an interrupt, you use the SETINT command.   Here, "input" is the condition you want, and "mask" contains 1s for the bits in which you are interested. Since I wanted to use input 3, I used the following command:   In this case, the % characters indicate binary values. The second (rightmost) %00001000—the mask—tells the PICAXE that I want to look only at input 3. There's one bit per input, starting with input 0 in the least significant, rightmost bit position. The first %00001000 tells the PICAXE that I want a 1 in that position (%00000000 would tell it I want a 0). You can use OR and NOT or AND (which is the default) after SETINT and widen the mask to tell it to look for a pattern of a number of bits—or a pattern that is NOT what you specify. You could monitor a number of alarm lines like that, for instance. Compared to the limited number of interrupt pins on the older microprocessors, this is very versatile. You have to have a subroutine called INTERRUPT at the end of your program, where this subroutine is executed when an interrupt occurs. The SETINT condition is disabled when an interrupt occurs, thereby allowing your interrupt subroutine to be executed without further interrupts. I called my read RTC and display routine, paused for 500 mS to allow the DS1307's interrupt line to go low again, and then put in another SETINT statement to re-enable the interrupts. Interrupts are checked during PAUSE commands, so my main program loop had a two-second pause and just looped back to itself. I could see the time updating regularly once a second. With my previous loop and pause, it was a bit irregular. I had a big vacuum fluorescent display (VFD) that I wanted to try, and I had also ordered a second display driver board. How I got all this going is perhaps a tale for another time—suffice it to say for the moment that this did not work like an LCD. But once I did manage to get it going—along with the RTC and one of the temperature sensors I used in part 2—I obtained a nice result shown below (with apologies to Crocodile Dundee).   I'm sorry about the date, which is presented in British/Aussie format. This picture does not do the display justice, but these displays are very difficult to photograph. Who would have thought you could do all this with a tiny eight-pin MCU? The small board seen in front of the display holds the PICAXE one-wire serial display driver board and interfaces the power and the signal connections to the (nonstandard) VFD display connectors. These VFD displays are made by IEE, though mine is an obsolete type I picked up cheap from a supplier. These are great displays. Once I had the I2C going on the DS1307 RTC, it was a simple matter to add an EEPROM. I first returned to my 24C02—a two-Kbit (256B) chip. I quickly got to write to and read from it. At least some things from my spares box work. However, when I tried to write a 16B test string into the first 16B, I read back only the last eight bytes—in the first 8B. The tutorial had mentioned not crossing 16B boundaries (i.e., if you start from byte 0, you should be able to write 16B, but if you start from byte 5, you can write only 10 more bytes). It seemed my chip had an eight-byte boundary. So I tried writing the first eight bytes followed by the second eight bytes, and this worked. I commented out the write statements and could still read back my test string. I expanded the program to read the rest of the 24C02 EEPROM, and I could see the values that had been programmed into the rest of it previously—some text and some unintelligible data. Next, I read the time from the RTC, and then I displayed the contents of the EEPROM, so I was using the I2C bus with two different chips. Meanwhile, one of my suppliers had a special: 50 24C16 (16-Kbit/two-KB) chips for only $3. When they arrived and I used one, I discovered that I was able to write 16B at a time. Now, two KB would not be much for something like Max's fancy robot , but for most of the things I want to do, this would be more than adequate. The bottom line is that I2C is a great bus, and the PICAXE makes it very easy to use. If I had an I2C-based display controller and an I2C-based temperature sensor, I would have been able to do all the above with only two or three (I actually used five—two for the I2C RTC, one for the interrupt, one for the temperature sensor, and one for the display). The current state of play is that, in a relatively short time, I've got my PICAXE doing all sorts of useful things—reading the temperature, working with a real-time clock, and storing and retrieving data. The only real programming skills I needed were for manipulating the data—the interfacing to the other chips is really easy thanks to the PICAXE's built-in commands for I2C and temperature chips. I can now see my way, for example, to taking that small amplifier I got out of the TV and using a PICAXE to set the volume and tone controls, select the input, and even display the time, date, and the temperature. But for that, I'd need a larger chip; fortunately, my 28X2 kit has arrived. The 28X2 can do even more stuff, such as talking to an IBM PC keyboard. I'd like to try that, so this will be the focus of my next blog. Finally, in closing this column, may I offer my very best wishes to all for the new year.     David Ashton Jack of All Trades  

Since the dawn of Internet, people have used it to share interesting and amusing images. I remember years and years ago seeing the following "Man vs. Woman" image when a friend emailed it to me:   It is, of course, obvious what this represents—man is a simple creature, while women are far more sophisticated and complex. (What? You have a different interpretation? In that case, please feel free to share it with the rest of us in the comments below.) This image kept on reappearing in my "Inbox" over the years, and each time I would grin and then delete it. Until, one day, I thought to myself, "Hmmm, it might be fun to build one of those." When you come to look closely at the original, however, you realise that it's not all that well made. I'm not convinced that it actually does anything per se; instead, I think its creator simply mounded a bunch of knobs and switches and LEDs on a panel—whatever he (I'm assuming it was a he) happened to have to hand—and took this picture. For myself, I wanted to create something a little "tastier," as it were. I'm thinking of a piece of furniture involving wood and brass and antique analogue meters and switches—something that would not look out of place around the beginning of the 20th century. As an example, my chum Douglas in California is in the process of building a control console for his recreation of Doctor Who's TARDIS, and the following image is of one of his sub-panels:   This goes some way to explain why, for the past few years, I've been collecting "stuff" in the form of antique meters and knobs and suchlike. Of course, it goes without saying that I also want to have lots of LEDs, but I want them all to be of the tri-colour variety and I want them to be tastefully mounted behind mother-of-pearl-like "dots." The bottom line is that I want the finished unit to look like a piece of fine furniture. Thus it was that I acquired a 1929 wooden radio cabinet as shown in the image below. This is going to house the "Woman" portion of the device. All of the wood will remain as-is; all I'm going to do is remove the woven speaker grill in the upper middle and replace it with a brass plate that contains my switches and meters and whatnot. Also, there will be a second brass plate filling the hole in the wooden panel at the bottom off the cabinet.   In the fullness of time, the "Male" portion of the device will be presented in a smaller antique wooden box that sits on top of this radio cabinet, but that's a project for another day. Over the years, I've experimented with a variety of different ways to monitor the switches and control the LEDs and analogue meters. For example, one setup involved a PICAXE microcontroller being used to control chains of input and output shift registers, which were intended to monitor the inputs and drive the outputs, respectively. Unfortunately, my early attempts all quickly grew to be painfully complicated and convoluted, so I put my "Man vs. Woman" project on the metaphorical back-burner. In fact, it was just a few days ago, while I was working on my Mind-Boggling Infinity Mirror project, that I thought to myself, "Hang on, these NeoPixels mean that I could control all of the LEDs on my "Man vs. Woman" project using a single digital output pin on an Arduino." And then I thought, "Good Grief, an Arduino Mega has more than enough I/Os to monitor an array of switches, plus it has enough PWM outputs to drive a bunch of analogue meters, plus it has enough analogue inputs to monitor a cornucopia of potentiometers." I must admit that I was carried away on a wave of excitement. I used Visio to whip up images of my various switches and knobs and meters and suchlike; then I printed them off, cut them out, and spent a happy time arranging them on a poster-board mockup of the front of my 1929 radio cabinet as shown below:   On the left hand side of the upper portion of this image we have a column of antique toggle switches with small white balls on the ends of the switches (these look really cool in real life). To the right of these, we find a column of 16-way rotary switches or potentiometers (I've not decided which to use yet). Then we have some more toggle switches mounted horizontally, with a strange antique switch "thing" in the middle (this is currently on its way to me from Canada, so I don't have the accurate dimensions for it yet). On the right hand side we have three analogue meters. In the lower portion of the image we have two more meters and four momentary push buttons. Close-up views of some of these elements are illustrated in the image below, which presents a toggle switch on the left, a momentary push-button in the middle, and a rotary switch (or potentiometer) on the right:   Each of the toggle switches and momentary push buttons will have an associated small brass panel along with two NeoPixel LEDs mounted behind translucent dots. Meanwhile, each of the rotary switches will have a circular brass panel with 16 LEDs presented in the form of a NeoPixel Ring. The portion of the device that is to be mounted in the radio cabinet is going to be called The Pedagogical and Phantasmagorical Inamorata Prognostication Engine (Mark 1) . The idea is to try to manipulate the switches and knobs in such a way as to get all of the analogue meters in their "green zones" at the same time. Unfortunately, although one might get tantalizingly close, it has to be admitted that one's odds are a tad on the slim side, not the least that the system doesn't come with any instructions and the functions of the various knobs and switches may (or may not) transmogrify over time. On the bright side, the Prognostication Engine will include a real-time clock and have knowledge of the current day and time, and one's chances will improve somewhat around the time of a blue moon (the next three blue moons will occur on May 21, 2016; May 18, 2019; and August 22, 2021; which just goes to show that there's always hope). I'm sure we will be discussing the underlying algorithms controlling this beast in a future column. In the meantime, none of the various elements or functions are currently defined, with the exception of the Modestly Sized Red Button ("Pusheth Noteth") and the largest Emotional Status meter (which will span the entire range of emotion from "Disgruntled" to "Fully Gruntled"). So, if you have any suggestions, now would be a good time to add them into the pot.