I recently received a tube of Microchip's six-pin PIC10F2xx series microcontrollers. I had asked for a few when I was first introduced to these tiny MCUs. These small chips are great as standalone devices although they sometime require creative interfacing. For example, a conventional keyboard grid would use up all of the I/O pins, so a resistive-based keyboard requiring only a single input pin could be used as an alternative.
I decided to see how multiple chips could be applied to a problem. I came up with an infrared beacon for a small robot (Fig. 1). My daughter built a similar device, but in her design a single processor controlled all the infrared LEDs. It was a resource hog and the multitasking required to handle multiple LED/detectors was complex. Suffice it to say that the result was workable but primitive.
The beacon that I created is designed to fit on each robot and fixed locations that need to be identified, such as the location of a charging system. This greatly simplifies a robot's ability to identify and grasp the orientation of other objects. Beacons are very handy in multiple robot applications.
A beacon's LED can be recognized by detectors on other beacons. Typically an LED will flash, allowing another detector to respond with its own LED. This minimal communication lets a pair of beacons know their relative angular position to each other. A more sophisticated protocol sends serial information, allowing beacons to identify each other and their relative orientation. Normally the LED/detector pairs are positioned so only one set will cover a particular area with respect to the beacon.
Going with a higher-performance MCU would be the usual approach, especially because low-cost MCUs suitable for the task are now generally available. The other approach is to use multiple six-pin MCUs. There are several advantages to this approach. First, it significantly simplifies programming, as each device runs the same code and there is no multitasking required. Second, power consumption can be greatly reduced in this particular application. Finally, adjusting the number of MCU/LED/detectors is now a trivial exercise because a bus architecture is employed (Fig. 2).
With respect to power consumption, individual MCUs can be more efficient than a more powerful, single MCU because the smaller MCUs can be put into sleep mode. They wake up when a transition is detected on the bus or from the detector. The chips draw a trivial amount of power in sleep mode, often less than what the detectors require. A timer can be used to wake up the chip as well.
The bi-directional bus can be implemented without any external components using an interesting trick. The chips do not have a built-in serial port, so it's necessary to use a soft-serial port instead. This turns out to be an advantage because sending data is actually accomplished by toggling the output enable on the port instead of using an actual data line. The other chips on the bus have their bus pin set up for input mode with the built-in pull-up resistor turned on. This causes an idle bus to be a logical 1. The bus is pulled to ground by a chip that writes a 0 in the output port and then enables the output. None of the chips ever drive the bus high using the output port because having one chip drive the line high while the other drives the line low can damage one or both of the chips due to high current draw. This approach is an alternative to an open-collector bus.
Working With The Hardware
The SOT-23 chips are definitely smaller than the DIP alternatives (Fig. 3). The MCU is now one of the smallest parts of the design - the detectors and LEDs are actually larger. In fact, an external resistor or cap would almost double the size of the digital control.
The PIC10F2xx Universal Programmer Adapter handles SOT-23 and DIP packages (Fig. 4). It can be programmed using the USB-based MPLAB ICD programmer and debugger. However, debugging must be done using PIC microprocessors with more pins. This is where prototyping with the DIP versions comes in handy because they are easy to work with on patch boards. Likewise, it's easier to build a socket to handle both a 6-pin and large PIC, and then swap them to test final production configurations prior to building the SOT-23-based system.
Work In Progress
I haven't finished this project yet. Other work keeps getting in the way, but it will get done eventually. Luckily I have programmed the PICs with assembler for many years. The PIC C compiler could be used, but the small memory on the chips prevents large programs.
The system tends to be a bit more complicated to debug than to design. A pair of in-circuit debuggers (ICDs) would be handy. Debugging is initially being done using a PIC18 with more pins. Debugging a six-pin device is a problem because there are no pins left to work with if the debugger is running. We'll see where it winds up.
What kind of uses can you come up with for a six-pin MCU? E-mail me with your ideas at [email protected] We may be able to print your design in Electronic Design.
It does require a new view of the world to take advantage of these small devices. On the other hand, it's relatively easy to crank out small, application-specific ideas for these small chips. The trick is to think how a problem can be partitioned.