29 April 2008

14. Of Ports and Pins and SFRs

Up until now, I’ve conveniently skipped over how the PicPack libray handles the read-before-write problem on low to mid range pics, or even what this issue is really all about. It provides a simple solution to a complicated problem, but it bears explaining since you’ll learn how these devices work under the covers.

On Microchip micocontrollers, like many similar devices, allow you to make a given pin either an input, or an output. And you can change this programmatically at runtime as well – handy talking to some devices over a bi-directional data line. There’s some circuitry that can detect if there’s a high or low value present on a pin and also what’s known as a data latch attached to the same pins. The data latch is an output device that holds the value you give it until you change it.

The problem with Microchip pic devices prior to the 18f range is two fold – firstly that the output latch isn’t readable and secondly that all outputs are done at the port (not pin) level. What this means is that when you just want to change one output pin in a port from one value to another, the chip doesn’t know what the current values on the other pins are. Say you’ve set pin 1 to high previously, and now you want to change pin 2 to a high as well. It doesn’t have any record of what the previous value of pin 1 was set to (remember, the data latch isn’t readable) and all outputs to the latch happen at a port level (so it has to write values to all the pins in a port at once). The way the chip gets around this is called “read before write”. It reads the value on all the pins in the port (that is, the actual value present on the physical pins of the pin), then changes the pin you’re interested in, and then writes the whole port back again.

So, in our example, it should read a high value on pin 1 (since this is what the latch is outputting), change the value on pin 2 to high and write them both (and the other pins in the port of course) back to the latch, resulting in pin 1 and pin 2 set to high values.

That all sounds fair enough. It’s clearly a bit of a pain, but surely the output of the latch is the same as what you told it to output, so what’s the problem? Well, in theory that’s perfectly true – but in practice, it doesn’t work like that. Imagine that as part of your circuit you have a capacitor connected between your output pin and ground. The reason why you’d do this isn’t important right now. You can imagine that when you set that pin high, it’s going to take some actual real life time to get to the point of actually reading at a high level. Maybe just microseconds, but still, some time. Now imagine if you set this pin high then, very quickly, set another pin high. Your capacitor laden pin is going to be read and the chip may decide that in fact that pin is low at the moment since the capacitor hasn’t charged to the high level.

Eek! That means that the pin is going to get written back as a low! Disaster! In fact, it doesn’t just happen if you have something capacitor-like attached to the pin, it can happen even with a set of leds and resistors. What to do?

The answer is to simulate the readable latch that we don’t have. The PicPack library provides a “shadow” port that it writes changes to before copying it to the whole port. Of course this results in slightly more code – instead of a one instruction bit-set you end up with three. As I’ve learnt with microcontrollers, everything is a compromise. Presumably Microchip saved some money by not having a readable latch in these devices, but it costs you an extra couple of instructions to guarantee the value on an individual pin. The 18f devices (and onwards) have a readable and writable data latch that makes this problem redundant, but without needing to make any chances, the PicPack library makes your code transparently portable between these devices even though 16f devices don’t have a readable data latch.

At the end of the day you can use the PicPack routines without having to worry about what’s happening under the covers – and this makes your code more portable and readable as well. It’s worth explaining how PicPack achieves this without taking too many instructions, and even without having to tell it how many ports your device has.

Open up the include file for the chip you’re working on at the moment. This example uses the 16f88, which for me, is located at c:\Program Files\SourceBoost\include\pic16f88.h.

Pics have a memory space for RAM which includes clumps of “magic” memory locations that do things when you read to them or write to them. These locations are called Special Function Registers or SFRs. You write to a port, for example, by writing a value to a SFR that results in the port being changed.

BoostC include files define the address of these SFRs, and then define a variable that is located at that address. That means that when you set that variable, you are writing data to that memory address – which means writing data to the SFR which causes the chip to do something.

I’m being long-winded about this because it is actually quite confusing until you get your head around it.

Have a look at the include file. You’ll find the definition of our port locations:
#define PORTA                 0x0005
#define PORTB 0x0006
Notice that the PORTA and PORTB are in capitals. Later on, you’ll see in the same include file:
volatile char porta                  @PORTA;
volatile char portb @PORTB;
So, here we define two global variables, porta and portb that happen to reside at the right place that if you read or write to the variable, you end up reading or write the similarly named SFR. Do you see how the variables use lower case letters, but the actual address is in capitals? Thankfully SourceBoost provide these pre-made include files for just about every pic out there. They’re choice of capital vs lower case is somewhat in contrast to other pic compilers, and sometimes the variable names and address locations aren’t even the same as what is in the data sheet for the same pic, just by way of warning. As I’ve said, portability is relative these days, even if we’re all talking C.

Now, all the “bits” of the SFRs are defined in here as well – so you can, for example, set the timer 0 interrupt enable bit of the intcon SFR by using:
intcon.TMR0IE = 1;
This is bit setting notation is handy for single pins, but I prefer the more portable macro that SourceBoost provides:
set_bit(intcon, TMR0IE);
It results in the same code generated, but it means you could port to a different compiler (or microcontroller vendor if need be) more easily.

Now, you can see here we’re setting bit 5 of the intcon variable (actually memory location 0x000b). This is all okay, since SFRs beyond ports don’t have real-life outputs and hence don’t suffer from the read-before-write problem.

In order to make sure we generate as little code as possible, PicPack sets up an array at the same location as the port and tris SFRs in the pic_utils.h file:
volatile uns8 port_array[NUMBER_PORTS] @PORTA;
volatile uns8 tris_array[NUMBER_PORTS] @TRISA;
The tris SFRs are used to set whether a pin is an input (1) or an output (0). “Tris” comes from the (copyrighted) word tri-state, since a pin can be an output at high, an output at low, or an input (and high impedance). You’ll see shortly that you don’t even need to worry about this tris malarkey either with the pic_utils library.

These declarations don’t use any memory up – they just make it handy when we’re moving things around. We also declare the shadow array:
extern uns8 port_shadow[NUMBER_PORTS];

The NUMBER_PORTS define has already been calculated for you, earlier in pic_utils.h. The actual useful functions are defined like this:
#define set_pin(port, pin) \
 set_bit(port_shadow[port - PORTA], pin); \
 port_array[port - PORTA] = port_shadow[port - PORTA];
So our set_pin routine just works out which shadow location it needs to change, then copies the whole byte to the port at the right location. Through a great deal of experimentation, I’ve found that this results in the smallest amount of generated code. Even though it looks like we have lots of calculations to do, if we’re using known ports and pins then the compiler does what’s called “constant folding” and all the calculations are done as the code is compiled, not at run time.

So, to set bit 5 of porta, you need to:
set_pin(PORTA, 5);
Note that this is set_pin, and not set_bit, which is the generic macro for manipulating any byte. Set_pin and its friends are only for actions on ports.

This is why you’ll see these sort of #defines that you provide in your config.h:
#define i2c_scl_port PORTC
#define i2c_sda_port PORTC
#define i2c_scl_pin 3
#define i2c_sda_pin 4
You can see the PORTC in capitals here. Once you’ve defined it, you can use i2c_scl_port and i2c_scl_pin and it’s much more readable form the code what you’re talking about. In addition, if you decide to move where the hardware’s connected to, all you need to is update it in one place in the config.h.

The routines that are provided are:
set_pin(port_sfr_addr, pin)
clear_pin(port_sfr_addr, pin)
toggle_pin(port_sfr-addr, pin)
These work exactly as you’d expect, all buffered and safe from read-before-write problems. There are a couple of other handy functions as well:
test_pin(port_sfr_addr, pin)
returns the value of the pin (given it’s an input) allowing you to use the same naming convention for your input ports as well as outputs, eg:
set_pin(PORTA, 1);
if (test_pin(PORTA, 2) {
    // do something
You can also change a pin to a given value, eg,
change_pin(port_sfr_addr, pin, value)
#define MY_VALUE 1
  change_pin(PORTA, 2, MY_VALUE);
Now, because of the way code is generated for pics, when you’re using constants for the pin and port values, these #defines give you nice, simple code. When you’re using variables, however, it does end up with more code. At that point, you’re generally better off using these set of functions:
set_pin_var(port_sfr_addr, pin)
clear_pin_var(port_sfr_addr, pin)
toggle_pin_var(port_sfr_addr, pin)
change_pin_var(port_sfr_addr, pin, value)
These functions actually use subroutines instead of inline code, but will result in less code overall if you want to do things like:
uns8 my_pin;
  my_pin = 5;
set_pin_var(PORTA, my_pin);
It’s a subtle difference, and it other environments, (eg programming for PCs) you wouldn’t even bother make the distinction. When every byte counts though, it’s worth making the effort. Of course, this uses another stack level – so you may wish to swap code size for stack level and use the set_pin version nevertheless.

As a general note, I’m pretty sure none of the PicPack library actually uses the set_pin_var family of functions. You’ll probably find that you generally know what pin you need to change well in advance – ie, at compile time.

Finally, these routines also make it easy (and beautifully clear in your code) to make pins either inputs or outputs:
make_input(port_sfr_addr, pin)
make_output(port_sfr_addr, pin)

Again, this allows you to do things like this:
make_output(PORTA, 3);
set_pin(PORTA, 3);
Notice how you don’t even need to know anything about tris bits and it is quite obvious what’s meant to be going on.

By way of summary, for the imaginary rt373 device, define your ports and pins in your config.h like this:
#define tr373_data_port PORTB
#define tr373_data_pin 1
#define tr373_clk_port PORTB
#define tr373_clk_pin 1
And then you can do things like this:
#include “pic_utils.h”
  // setup ports and pins
make_input(tr373_data_port, tr373_data_pin);
make_output(tr373_clk_port, tr373_clk_pin);
  // clock in the first value
clear_pin(tr373_clk_port, tr373_clk_pin);
set_pin(tr373_clk_port, tr373_clk_pin);
my_value = test_pin(tr373_data_port, tr373_data_pin);
…and so on. Easy! Note that while the PicPack library currently doesn’t do anything differently for PIC18 devices, the routines are perfectly portable between the devices without any code or even config changes.

28 April 2008

PicPack 1.1 released

The latest version of the PicPack is now released.

This includes more documentation on units, packet demo (tutorial coming soon) and fixes for boostbloader.

Note the function in the packet demo that allows you to press "download" on screamer to update your software without having to hardware-reset the pic. Very neat!

22 April 2008

13. It's about time

Following on from our discussions on getting the temperature via i2c, we’ll look at talking to a real time clock chip such as the ds1307. It’s a little more complicated than just getting the temperature – but mostly because there’s just more data available. The way we interact with the chip is very similar.

Now, you might ask why we need a separate chip to look after the time. Why can’t we do it all on our pic with our nifty timer routines? Well, we could. In fact, you can even drive one of the timers from an external crystal designed for handling real time clock type problems. There are, however, some good reasons to keep it all separate.

The first is that the DS1307 has support for battery backup – from a 3v CR2032 or similar, which will run it for 10 years or more. That’s effectively lifetime of the device. So when the device as a whole is powered off, the time will still be current. The other neat aspect is that the DS1307 has a bunch of non volatile RAM slots left over (56 byte to be exact) which we can use for our own nefarious purposes. You could use a pic that has no EEPROM (these are generally a lot cheaper) and store your info in the DS1307. Neat!

In any case, it’s a good example of another external device we can talk to over the i2c buss. You could connect a DS1307 and an LN75 on the same buss and talk to them both using only two wires.

Open up the ds1307 demo project. You’ll notice that in our configure_system routine we have:


This in turn calls i2c_setup() to configure port and pins as inputs or outputs as appropriate, ready for communication.

In request_time() we do some simple requests:

minutes = rtc_get_minutes();
hours = rtc_get_hours();
seconds = rtc_get_seconds();

And print out the result. All pretty easy so far.

It gets a little more tricky in process_rx() which allows us to enter commands like:


over a serial connection, to set the minutes to 23. The same goes for hours and seconds, using


If you have a look at ds1307.c, you’ll notice that most of the routines are simply wrappers around the i2c routines. Some add a little bit of value, by masking out bits, but even then, they’re mostly one liners. This brings us to the challenge of programming such limited devices – you’ve really got a choice between stack size and code size. If you use a sub routine only once – then it’s probably worth turning it into a #define or using the inline keyword. That means the code it uses gets placed in the actual location it’s used, and you save a stack position. In 16f88 devices, there are only 8 places in the stack. If you use interrupts then you’ll use 1 when an interrupt is called, even before you call any subroutines. So you need to make sure the stack never exceeds the interrupt level + main program level. If you do exceed this, on the 16f88 it will happily wrap the stack around and you’ll have lost the first stack position. In reality, this normally results in generally strange behaviour. If your program is using interrupts, and sometimes crashes, prints out strange repetitive things to the serial port or seems to jump back to the boostbloader, then you’ve probably got a stack overflow.

You can check to see if this is possible by looking at the BoostC output. It will print out a quiet little warning that you’ve exceeded the maximum stack level if everything happens at once (remember, BoostC knows about the whole program structure at the start, but it can’t know if the interrupt happens at the deepest main program stack position). I keep getting caught in this – strange behaviour, start putting serial_print_str in to find out exactly where it crashes (strange, those routines have worked for ages) - only to discover that there’s a potential stack overflow lurking around.

Sourceboost provides some very handy tools for find out what to do here. If you press the Code button on the tool bar and open out the pane that the code shows in, you can see the entire call tree of the program. This feature is worth the price of Sourceboost alone – you can easily see which tree branches are the longest and start to do something about them.

The Function Info pane shows more information about each subroutine so you can see which ones are chomping up flash memory and RAM. My only wish here is in a future version that the #Global line will be expandable. I’d love to see where the global variables that are taking up RAM are coming from. The assembly tab then gives you a fantastic rundown of what assembly BoostC has come up with for your routines – and gives you the chance to optimise this. Often you have to be quite crafty to reduce your flash and RAM footprint. Sometimes its just tonnes of serial_print_str statements.

So, if you find that the ds1631 demo is too big for your chosen pic, the easiest way to trim it down is to take out or simplify some of the serial_print_str statements. The main program “help” printout would be a good place to start.

19 April 2008

12. Which Pic?

If you’re anything like me, you’ll have had a look at the Microchip web site and been completely overwhelmed by the choices available to you. There are literally thousands of types of pics. How do you choose?

To some extent that depends what you want to do with it, but that’s not a very helpful answer. What I think is more important as you get started is using chips that make development easy. Once you’ve got something developed, if you were to actually take it to market, you’d simply choose the cheapest pic that had all the features you needed – and microchip’s web site includes tools for searching based on all sorts of criteria.

I think the essential things are
a) A hardware UART (serial port)
b) Plenty of flash memory for instructions
c) Support for the tools you use - not all hardware programmers support all pics!

If you’re starting out, I think the best pic to get going with is the fabulous 16f88. It’s got 4k words of instructions, which is plenty for experimenting with. It has 256 bytes of EEPROM for settings, 384 bytes of RAM and ports A and B. It runs at 8Mhz using the internal oscillator, giving you 2 mips and can run at 5 mips with a 20Mhz crystal. It can actually run an entire multi-hop meshed RF connection in 4k, but only just.

Once you start to run out of memory, flip over to the 16f876A. This guy has 8k words of instructions and because it has more pins, it has an extra port C. Other than that, it’s pretty similar.

The Sure PicDem2 board has an 18f4520 on board – this baby has 16k words of instructions, 1536 bytes of RAM and can run at 10 mips on a 10Mhz crystal. Sweet! Since I want to use the Olimex boards for experimenting without having to do surface mount, I’m also looking at the 18f2620, which stores 32k words of instructions, 3986 bytes of RAM and 1024 bytes of EEPROM. That’s one seriously pimped up pic. I’ll post when I’ve got the boostloader working on it.

Avoid any pic with 12 bit instructions. Most 16f pics have 14 bit instructions, all 18f guys have 16 bit instructions. I got a bunch of the funky Sure 5x7 LED array displays, with a view to reprogramming the pic on the back, but it turns out to be a 16f57, which BoostC doesn’t support as it has 12 bit instructions.

Printing things out to the serial port chews up instructions like you wouldn’t believe. I think it’s better to have plenty of Flash and not have to spend time cutting your program down just to get it working – once you’ve got it working, that’s the time for optimising.

11. It's hot in here

I think now’s the time to start interacting with other devices – and the one we’re going to start with will tell us what the temperature is. It’s a great opportunity to learn about the i2c protocol, how to interface with other devices and what a decimal place really means.

The chip of our choosing is the LM75, which like most of these sort of devices has many compatible versions from many manufacturers. Grab hold of a copy of the datasheet for this guy. You’ll notice that it’s an 8 pin device. 3 pins define the address of the device – so you can have up to 8 all connected together and yet address them individually. It has two modes, “shutdown” and “normal”, where shutdown mode will put the device into a low power sleep mode, and normal mode will convert the temperature every 100ms. It has two registers that we care about, the config register and the temperature register. The 8 bit config register is, naturally, where the config bits are stored. The 16 bit temperature register is where the temperature gets put every 100ms. The datasheet specifies that you can read the temperature safely at any time without any fear that it will be corrupted by another temperature measurement while you’re actually getting the register sent to you.

The LM75 uses a protocol called “i2c”, although it’s actually I “squared” C and stands for inter intergrated circuit. I write it without the superscript “2”. You might also see referred to as IIC and some chips use it without referring to this name at all. Presumably their lawyers told them to keep quiet. In any case, it’s a very neat way of communicating bi-directionally with different devices with only signal two wires. You can have several devices on the “buss” and distinguish between them. It even has modes where there can be several devices making requests (acting as the “master” in i2c speak), however, personally I think this is reasonably unlikely to happen in practice. The devices you make requests upon, in our case the LM75, are said to be in “slave” mode. They just do as they’re told.

Now, most pics that you’ll come across have some sort of i2c hardware inbuilt. This means they can handle a lot of the hard work themselves. The unfortunate fact is that mostly this is only as a slave and not as a master. To be fair, it’s pretty easy to implement master mode in firmware and you don’t get a lot of advantages out of doing it in hardware (presumably some code space). In any case, looking at the software implementation gives you a chance to understand how the protocol really works.

My intention here is not to cover the i2c protocol itself – there are tonnes of stuff on the net about this, and an excellent article in a recent edition of the excellent Silicon Chip magazine. If you’re into electronics at all, go subscribe to this magazine and support the Australian economy.

What I do want to cover is the use of the picpack library, which as you would expect by now, implements enough of the i2c protocol to get you talking with your LM75 or other i2c device but keeps you protected from any read-before-write problems on 16f devices. Once you have the “temperature” data in your hand, it’s also interesting to see what needs to be done to turn it into something worth displaying – and what that really means.

Open up the lm75 demo in the demos directory and have a look. You’ll see that since the lm75 library is built on top of the i2c library, you need to include the i2c.c file in your project as well. Have a look at the config.h:

// - - - - - - - - - - - - - - - - - - - -
// pic_serial defines
// - - - - - - - - - - - - - - - - - - - -
// - - - - - - - - - - - - - - - - - - - -
// pic i2c defines
// - - - - - - - - - - - - - - - - - - - -
#define i2c_scl_port PORTC
#define i2c_sda_port PORTC
#define i2c_scl_pin 3
#define i2c_sda_pin 4
// - - - - - - - - - - - - - - -
// General platform definitions
// - - - - - - - - - - - - - - -
#define PLATFORM_CLOCK 12000000

There’s the usual serial defines at the top, followed by the i2c defines. In this case, the project is ready to go on the Sure electronics Picdem 2 board – a great board for getting into 18f chips, LCD and temperature. We’ll talk about prototyping boards a little later on. Don’t forget to set your platform clock correctly, both for the serial communications and also for the delays used by the i2c routines.

Pack in lm75_demo.c, notice that getting the lm75 talking is as simple as:

lm75_set_config(LM75_ADDRESS, LM75_NORMAL);

Remember that each lm75 has its own address – the LM75_ADDRESS define is at the top of the file. Make sure you match it correctly to the LM75 address you set on your hardware (the Sure picdem2 board has it set to zero). In lm75_setup() the ports and pins are set up to communicate hardware-wise with the device. lm75_set_config sets the config register to the normal mode (ie, not shutdown). This isn’t really necessary since this is the default state, but hey, it’s a demo and we need to demo something!

The serial communication parts of the program are set up to read the temperature when you press t and , and read the config register when you press c and . Reading the config register is pretty boring, but it does prove it works. Reading
the temperature is a little more interesting.

To read the temperature all you need to do is call:

raw_temp = lm75_get_temp(LM75_ADDRESS);

The LM75 gives you an 11 bit temperature reading via a 16 bit number. The first 8 bits are the integer part, the following 3 bits are the “decimal” part. So we have three “bits” of decimal resolution. That means each bit represents a value of 0.125. If we take the second set of 8 bit, rotate it left by 5 bits, we’ll end up with those 3 bits right aligned in the byte. That makes it easier to process. So, if the left-most byte is 25, and the right most byte (after shifting) is 3, then the reading is 25.375. Now, that sounds like a pretty precise reading. What I haven’t mentioned until now is that according to the datasheet, the LM75 is accurate +/- 2 degrees C. So our reading could really be anywhere between 23.375 or 27.375. That’s pretty broad – and you start to realise that three bits of accuracy are pretty meaningless – especially when you convert them to base 10.

The lm75_demo.c includes two routines to convert the three bits to one or two base-10 decimal places through essentially a look up table. You can work our how I’ve calculated the values (multiplying 0.125 and then rounding). Note that given that we’ve only got 8 values available to us with three bits, you can’t even accurately represent 1 base-10 decimal place! Still, we’re just displaying the temperature here, so I’m not going to get hung up about it. The PicPack library includes support for the DS1307 chip, which has +/- 0.5 degree accuracy as 12 bit resolution, but we’ll be exploring that a little later.

PIC terminal
t - Request temp
c - Request config
>Requesting temp.
Raw temp = 0x1AE0
Temp = 26.88
Temp = 26.9

The other aspect that I’ve left out of this demo as an exercise for the viewer is the fact we are blatantly ignoring negative readings. These are represented as twos complement numbers, about which there’s plenty of information on the web. If you come up with some cool routines to process negative numbers, send them in and we’ll include them in the library for everyone to use.

16 April 2008

10. On Display

Eventually, you’ll want your microcontroller to communicate with the outside world without needing to be tethered to a computer. LCDs are a great way to do this, and given almost all the character-based LCDs are based on the HD44780 chipset, or at least a compatible protocol, it’s pretty easy to get these guys going. There’s also a great range of sizes – from cute 2 line 8 character displays to 4 line 40 character monsters. As long as its character based as opposed to graphical, the picpack LCD routines will get you up and running quickly.

There are stacks and stacks of example code out on the net on talking to LCDs. Go wild, go crazy – if these routines don’t help you then feel free to grab something else. The nice thing about the picpack routines is that they work the same way as the others, and always protect you from read-before-write problems. The only area I think the LCD routines needs expanding is in the area of setting character generator ram (you can do this already, but it’s a bit clunky) and supporting 4 line 40 character displays. These are really just two 2 line by 40 character displays with an extra chip enable line to select between the two “displays”. I’ve got one of these beasties, so I’ll add support for it eventually.

Some notes on getting LCDs working from the electronics side. Most of them run at 5v. So if you are running your pic at 3.3v, you’ll need a separate 5v rail to run the LCD. Check the datasheet for your LCD (if it has one!), but you will probably be able to connect the data pins directly to the pin despite the expected level difference. Check your pic datasheet to ensure that it has 5v tolerant pins, and that the LCD thinks that a logic “1” is as low as 3.3v.

If you’re running your pic at 5v, this will not be a problem. Either way, you’ll need a resistor to reduce the current for the backlight if your display has one. You can’t just whack 5v in there – check the LCD datasheet, match the resistor to the current required (there are plenty of web sites on the net that will help you calculate the resistor value). Or, at least stick something in there, 330R would be a good start.

Lastly, a trap for new players is the contrast adjustment. You can get everything else right, but if you don’t have a variable contrast adjustment, then you’re not going to get anything visible on the LCD. A 10k variable resistor, tied between ground and Vdd allows you to connect the contrast input (normally labelled as Vee) to a value between 0 and 5v. You’ll need to play around with the adjustment once you get it connected up and something allegedly displayed.

Now, on to the software.

Have a look at the lcd_demo project in the lcd directory. Note that in the config.h, you’ll see not only settings for the serial connection (which we’ll use to control the LCD) and the platform settings (make sure you set your clock frequency correctly) but also port and pin settings for the LCD. LCDs can communicate using an “8bit” mode or a “4bit” mode. Either way, you still need three other pins (RS, RW and E) to communicate, so at a minimum you need 7 pins. Personally, I’d rather have more pins free to do something else. Sparkfun produces a serial backpack that allows connection to LCDs with only one pin – unfortunately, it uses asynchronous serial communication, which means you either have to give up your serial port for debugging, or bit-bang your own serial routines. One day I’ll get around to rewriting the backpack code to take a synchronous serial connection (ie, two pins). It looks like a fun little development platform in any case. In the mean time, you can connect to an LCD directly using 7 pins. Platforms like the Sure PicDem 2 board will also work with the pickpack LCD library, even though they’re wired for 8 bit connections. This will actually free 4 pins for other uses.

Have a look at the configure_system routine. Notice that they only new calls are to:

lcd_setup(); // Setup the pins (output / input)
lcd_init (); // Configure chip ready for display

You’ll find that most of the picpack libraries have a “setup” routine for the device they’re talking to. This always sets up the configured ports and pins for input or output as required. Note that they expect that all pins are digital pins, so you’ll need to call turn_analog_inputs_off() yourself. The “init” routines actually initialise the hardware ready for use. In this case, lcd_init configures the LCD for 4 bit operation, clears the display and puts the cursor in the top left corner.

LCD communication takes place in one of two ways. It accepts either commands (which do something) or data (which put data into either the screen buffer RAM or the character generator RAM). You can see examples of commands in the main() routine:

lcd_write_command(LCD_CLEAR_DISP); // clear the display
lcd_write_command(LCD_RETURN_HOME); // cursor back to the beginning
lcd_write_command(LCD_LINE1); // goto line 1

and sending data as well:

lcd_write_data_str("PicPack LCD demo"); // print welcome message

Note that the LCD_LINE1 is simply a command to choose the display RAM location – so you can position the cursor further along the line like this:

// goto line 1, 6th character
lcd_write_command(LCD_LINE1 + 5); position

If you get the example project onto a pic, you can issue commands in your terminal program to clear the display or return the cursor home by typing the letter c and , or h and , respectively. Pressing 1 and enter or 2 and will move the cursor to the beginning of the first line or second line. Typing t followed by a string (anything you like) followed by will print your string to the LCD.

The program starts by putting a string on the first line of your display to confirm everything is working.

Neat! There’s not much more to it than that, but it does open the pic up to start making its own display and telling the world what’s going on.

14 April 2008

9. It's about time

It soon becomes apparent when working with microcontrollers, that things happening at the right time is crucial to things working at all. In this tutorial we explore timers and some tools to help timing events.

Pic microcontrollers generally have at least one timer, and often three. These are generally registers that will clock over once per instruction cycle, and when they flip over (from 0xff to 0x00) they can generate an interrupt. Of course, counting from 0 to 255 (0xff) at 8 Mhz, which is 2 mips, isn’t very long – and you’re not going to get much done in between each interrupt! 256 clocks at 2 mips is 0.000128 seconds – or 128 microseconds. Not very long at all. So to make it easier to timer longer periods, some timers are 16 bit (65536 clocks at 2 mips is 0.032768 seconds) and most timers allow for something called a prescaler. The prescaler in an independent counter that divides down the clock so the timer is incremented less often. They’re always in powers of two, so you’ll see them in ratios like 1 to 2, or 1 to 4, or 1 to 8 and so on. In the case of a 1 to 2 prescaler setting for example, it results in the timer counting up every 2 clock cycles, not every clock cycle. 1 to 4 results in the timer counting up every 4 clock cycles, and so on.

The picpack library contains several tools for manipulating timers and keeping track of timings. The first tool is a set of routines found in the pic_timer library, for setting up and starting timers. The second is the pic_tick library, which makes it easier to work out how much time has elapsed between events. Later on in this series, you’ll see how important these concepts are when we create our own meshed packet RF network. But for now, we’ll just see how these timers work.

Open up the tick_demo project. There’s two parts to using timers with the picpack library. The first is manipulating the timer hardware itself. Have a look at the tick_demo.c file, and the configure_system routine:

#ifdef _PIC18
timer_setup_0(TIMER_16BIT_MODE, TIMER_PRESCALER_OFF, 0xffff - 3000 + 13); // 1ms at 12Mhz
//timer_setup_0(TIMER_16BIT_MODE, TIMER_PRESCALER_1_TO_2, 0xffff - 1500 + 7); // 1ms at 12Mhz
//timer_setup_0(TIMER_16BIT_MODE, TIMER_PRESCALER_1_TO_8, 0xffff - 375 + 1); // 1ms at 12Mhz

In this example, we are assuming that the clock is running at 12Mhz and we’re using an 18f type of pic, which has a 16 bit mode for timer 0. Knowing that each instruction takes 4 clock cycles, we would expect this to take 3000 clocks. The first (commented out) line takes that stance – the timer counts up from the value given, so we need to subtract the 3000 from 0xffff. Note there’s an extra 13 added due to the number of instructions taken to get everything processed, the fact the sometimes updating the timer actually stops the timer for a few clocks on some chips. Of course, if we were using the prescaler at 1 to 2, we would only need 1500 clocks – and less compensation. At 1 to 8, we only need 625. The timer is going to be more accurate at the lowest prescalar value (ie, off) – since you can compensate very accurately. By the time you’re at 1 to 8, you’ve got a compensation level 8 times as coarse. Still, unless your clock needs to be mission critical (ie, actually running a real time clock), any of these will be close enough (within 10 clocks of the required value, which is 2.5 microseconds. The timer routines adjust where they can – given your value, they will adjust the next timer loop if the pic has been busy while the timer interrupt occurred and didn’t get to it as quickly as it did the last time through the loop. This means that while one timer interrupt might take slightly longer than you expected, the next one will be automatically shortened to compensate. So on average, it’s pretty accurate and errors don’t get compounded.

Now, have a look at the pic 16 version:

#ifdef _PIC16

timer_setup_0(TIMER_8BIT_MODE, TIMER_PRESCALER_1_TO_8, 0xff - 250 - 1); // 1ms at 8Mhz


Even though the 16f devices don’t have a 16 bit timer 0 (they have 16 bit timer1 and timer2 modules however), we can pass in the same types of parameters as the 18f equivalent routines. If we assume that we have a 16f device running at 8Mhz, then we’re looking for 2000 clock cycles to make up 1 ms. Counting to 255 isn’t going to get us far – so we have to employ the prescaler. And if we set it to 1 to 8, then counting to 250 x 8 = 2000 clock cycles, give or take. Of course, as we know, there’s not much room for correction at the 1 to 8 prescaler level. However, for most cases, this should be accurate enough. When you’re using timers, once you’ve set them up (as above), you’ll need to start them, as in the main routine:

timer_start_0(); // kick that timer off...

You can also use timer_stop_0() to stop the timer temporarily, with 18f devices you can do just that, stop the timer. With 16f devices, the timer doesn’t have an “off”, so we just turn the timer 0 interrupts off instead.

Right, so now we’ve got a 1ms timer, what can we do with it? Well, let’s say we want to do something every second. Or see how long it’s been since a particular event has occurred. This is where the pic_tick library comes into play. Back in tick_demo.c, have a look at the interrupt routine:

void interrupt() {



There’s the serial handlers, as usual, but also the timer_handle_0_isr() routine – which takes care of timer 0. Note that in your code somewhere, you need to include a routine called timer_0_callback() like this:

void timer_0_callback() {

Every timer 0 interrupt, this routine will get called. In this case, we call handle_tick() – which increments the pic_tick “tick” counter. So we know our “ticks” in this program are every 1ms. The ticks are counted using a 16 bit counter, with some neat routines to help work out timings.

Now, let’s say we want to do something every 1 second. That’s 1,000 ms. Have a look in the main() routine:

test_tick = tick_get_count(); // find out what we're up to
if (tick_calc_diff(tick_marker, test_tick) >= 1000) { // 1000 - it's a second
serial_print_str(" "); // print something out
tick_marker = test_tick; // reset to find next 1000

Tick_get_count() gets the current tick value. Then tick_calc_diff is used to calculate how many ticks there are between tick_marker and test_tick. It’s assumed that the first parameter occurs earlier in time than the second. The routine works even if the tick count wraps around 0xffff. If the difference is greater than or equal to 1000, then we print something out, include the tick count we’re up to. Then we reset tick_marker to the current tick count.

Why >= 1000? Why not just == 1000? Well, you can imagine that if the pic is busy doing something else, even if it’s in the main loop, then it may well be that the ticks creep past 1000, in which case, our next print out will happen after it wraps around 0xffff again, obviously not as good as just being out by 1 tick or so. Note when you run this application however, that since our main loop is pretty simple, we almost never miss the 1000 mark and print out our Ting! on time.

Have a go at tick_demo and see how accurate it is for yourself. Make sure you adjust the timer_setup_0 values for your clock speed. You shouldn’t have to adjust the ‘13’ etc, just the main number, eg, 3000 or in the case of the 16f device, 250. If you were running at 20Mhz, on a 16f88, so an 8 bit timer0, can you work out what prescalar and starting value you would need to get pretty close to 1ms?

12 April 2008

8. Serial ports

If you had to generalise about what’s the best feature and the worst feature of pic microcontrollers, I’d have to say the best thing is that any decent model of chip has a serial port (UART) built into the hardware. The worst thing is that the PWM modules suck (normally, there’s just one. And even if they have an “enhanced” PWM module, it’s design for driving stepper motor H-bridges, meaning that the “four” outputs are really just two with the second one driven the opposite way).

Anyway, the serial port rocks. It means you can print things out, find out what your code is doing, debugging the old fashioned “printf” way. You can even issue commands to the code and have it respond, very easily. It really does make writing programs for the pic a pleasure. Sure, you can get into the hardware debugging stuff, and I’ve got an ICD2 on it’s way to have a play with – I’ll let you know what it’s like – which allows you to step through code, put in break points, monitor variables etc. Still, with ICD you lose two pins, a chunk of memory and stack space. I’m sure for some nasty hardware problems it could be very handy, in fact, when I was developing the serial library it could have been very useful. Still, now that it’s done, it makes debugging very easy. The routines are well tested and very solid. They ran “out of the box” when I moved on to 18f chips as well. And best of all, you can print something out, it goes into the fifo buffer and gets shunted out the serial port at the appropriate rate. Meanwhile, your program continues on executing and full speed.

So, onto using the serial port. Firstly, it’s a TTL serial port – meaning that you can’t whack the tx and rx pins of the pic straight into serial port of your PC. You need to adapt the polarity and voltage levels. There’s a couple of easy ways to do that. I use the sparkful serial module – I’ve used the RS232 Shifter SMD module, but the other rs232 modules will work just as well. These are great for breadboards. Alternatively, you can use the Olimex boards that have a proper MAX232 chip on board with all the associated capacitors. These are used to bump up the serial port voltages to +/- 12v, which is the standard. Most serial ports these days will work perfectly well at 5v however. On the Olimex board you’ll need to wire the serial port output / input to the tx / rx pins on the pic. Don’t worry about the RTS/DTR pin, it’s not necessary.

You should have no problems with any of these serial port connections with USB serial port adapters. So on to the software.

The serial port on pics, like most microcontrollers, is driven by the clock that the pic is running at. As such, there’s not really the concept of “baud rate” or “bits per second”, or bps, at least, at the hardware level. Everything is divided down from the clock rate. The 16f range of pics have an 8 bit clock divider, and a “fast” and “not so fast” setting. Have a look at the datasheet for your pic – the section is titled “Addressable universal synchronous asynchronous receiver transmitter”. And you wonder why I stick to calling it “serial port”. We don’t care about synchronous serial ports, they require a clock, and serial ports on PCs are asynchronous anyway. Notice that there’s a setting for High speed and Low speed, based on the BRGH bit of the TXSTA register. Hunt down the baud rate formula. You’ll see that you can calculate the baud rate based on the BRGH setting, the SPBRG divider and the clock frequency.

When BRGH = 0 (Low Speed) the baud rate = FOSC/(64(SPBRG + 1))

When BRGH = 1 (High Speed) the baud rate = FOSC/(16(SPBRG + 1))

Thankfully the picpack serial port routines take away a lot of the pain. Who wants to calculate these values anyway? For all the popular serial port values and clock frequencies, the work has been done for you.

Load up the serial_demo project and have a look at the config.h file. You’ll start to see that most things you configure in a picpack project are done through the config.h file.

// - - - - - - - - - - - - - - - - - - - -
// pic_serial defines
// - - - - - - - - - - - - - - - - - - - -


// - - - - - - - - - - - - - - -
// General platform definitions
#define PLATFORM_TYPE breadboard
#define PLATFORM_CLOCK 12000000

The pic_serial defines are pretty obvious – you set the fifo buffer sizes for transmitted and received characters with the SERIAL_TX_BUFFER_SIZE and the SERIAL_RX_BUFFER_SIZE. Since the picpack serial routines are completely interrupt driven, we need a buffer to store things on the way in or way out, until your routines get around the handling them. Remember you need a TX buffer big enough that everything can sit there until it gets transmitted – which only occurs while interrupts are running. If you print out lots of stuff while in an interrupt service routine (and this means interrupts are off), it will pile up here until interrupts get turned back on and the characters can be pumped out. All this means is that you need a big enough buffer. Otherwise the pic will appear to hang, when really what it’s doing is waiting for the buffer to empty, but it’s never going to since it’s only going to get serviced when (you guessed it) interrupts are running.

It’s nothing you need to worry about until several projects down the track you’ve defined a really small buffer and are wondering why things stop working! For the moment, and generally, it won’t be a problem.

Set your platform type and clock speed in cycles per second – the example here is 12Mhz, but if you’re using a 16f88 with internal clock, for example, you’ll need to set this to 8000000, of course.

Have a look at serial_demo.c

// configure_system
// Get the pic ready for everything we want to do

void configure_system() {

kill_interrupts(); // turn off interrupts just in case
turn_analog_inputs_off(); // kill those pesky analogue inputs
serial_setup(BRGH_HIGH_SPEED, SPBRG_9600);

In the configure_system routine, we set things up. I always turn off interrupts at the start, just in case, along with turning analog inputs off. In this demo, it’s not strictly necessary, but always good practice unless you need them. See the serial_setup routine? It makes it easy. Always use the BRGH_HIGH_SPEED setting if you’re using the pic_serial defines for the baud rate. Then just pop in the baud rate, and if you’ve set your PLATFORM_CLOCK rate correctly, you’re all set to go with no calculations!

After that, we turn on peripheral interrupts (which includes the serial port module), and global interrupts (which is the overarching control on whether interrupts are on or off).

Our interrupt routine is as easy as this:

void interrupt() {



Picpack does all the hard work for you.

The process_rx routine is where we respond to typed commands – in this case, we can type something in and press enter to get the pic to respond. Very simple commands are used here, but you can see how you could query anything, at any time, just by typing a request.

Now we’re ready to start getting some serial port action.

serial_print_str("\n\nPIC terminal\n");

Is as easy as it gets for printing out strings. Use serial_print_int for 16 bit unsigned integers, and serial_print_int_hex for printing 8 bit hex numbers.

So, compile the program, bootload it into your pic and start trying out some of those commands.

8 April 2008

7. Bootloading

The picpack bootloader is based on the Sparkfun bootloader / screamer combination, which in turn is based on other bootloaders. I’ve got it working on two 16f variety chips and two 18f variety – and others shouldn’t be too hard to get working. If you do get it working on other types, please send me your settings so everyone can take use them.

Here, I’m going to assume you have a 16f88 chip.

Grab the 16f88 boostbloader hex file, program your pic. To get the serial connections going you’ll need to have some sort of conversion hardware to get it to rs232 levels – I use the sparkfun module, and the Olimex boards have it built in (but not connected).

Run up the screamer application (which is the windows program that sends your program to the pic) and select your com port. Select a .hex file to download (say, the flasher program from the last tutorial) and choose download. Reset your pic, either by powering it on, or using your MCLR reset button.

The pic will boot, send a byte to the screamer application to indicate it’s ready to accept a new program. Screamer will then send the contents of the .hex file – the boostbloader program will store the program in flash, and then execute it. If screamer doesn’t respond, it will then go and run the last program that was downloaded.

It really should be that easy. The nice thing about the screamer app, is that when you’ve finished the download, it can flip to the terminal page, and then you can see what the pic is doing by using the serial library, printing out statements, variables, etc. It’s all very neat and a great way to debug programs.

The other thing to remember is that using a bootloader, you don’t need to worry about config bits, since these are already programmed as part of the booloader itself being put into the chip. Of course, if you need something in the config changed, you do need to compile and re-download yourself a custom bootloader, but you’ll get pretty comfortable with all this soon.

So hopefully you’re now at the point of having your leds flash again, but this time under bootloader control. You won’t need to pull your pic out of circuit and put it in a zif socket anymore, or power it down to use ICSP. Life is great.

Now it’s time to start doing more exciting things than just flash leds, cool as this is. Our first point of call is to create a terminal program so you can type commands and get your pic to respond. On to the next tutorial…

6. Chip Programming

Now, if you want to get this running in hardware, it’s time to talk about how to program the real chips. There’s essentially three ways of doing that.

The first, and definitely easiest (and generally most reliable) way is to plonk your chip in a ZIF-socketed programmer and use a windows program to communicate with the programmer board. Generally these programmers use USB these days, which is pretty handy. It does mean that you need to remove the chip from whatever its in though, in order to program it.

The second way, which is essentially the same as the first, is to use an ICSP. The In-Circuit Serial Programmer is just a fancy way of defining the pins that need connecting in order to program the device. On pics there is a clock and data line, Vdd (positive supply), ground and most likely a “higher voltage” programming line as well. If you put 12v or so on the Vpp line, the chip will wake up in programming mode, allowing you to read and write flash, eeprom and “config” settings. As you can imagine, in option one, these connections where made directly with the chip. With an ICSP “socket” you can leave the chip in place and still program it. You do need to generally disconnect the main supply, however.

The third way which is definitely the fastest and most convenient is to use a bootloader. This is a small program that is resident in your pic that communicates with a pc-based application in order to download the real program you want to store (and run). Of course, in order to get this bootloader in there in the first place, you have to use method one or two – after that you can use a bootloader. This is actually quite neat, since most bootloaders use a serial interface to work, you can quickly download a program over the serial port and then immediately see the results of it. Any debug can be done over the serial link as well, making the process very neat.

In the direct programming methods (one and two) you’ll also need to set config options for the pic. These are also known as “fuses”, even though I’m pretty sure these days they’re just a chunk of memory like everything else. They do have the distinction however of allowing the functionality of the pic to change before it actually starts running a program. An example is the MCLR pin – which can often either be a digital IO pin, or a pin which when connected to ground, resets the pic. Clearly the chip needs to know which is the correct option before it actually starts executing a program.

18f chips tend to have richer (that is, more complex) sets of config bits than the 16f series. However, the main flags to be concerned with are:

Oscillator – do you want the chip to run with an internal clock , or ouse an external crystal (with associated circuitry, usually just two caps and the crystal.

MCLR – usally it’s nice to have a press button reset, so this is handy to leave on, unless you need the IO. You’ll need to tie the pin to Vdd via a resistor, with the button pulling it to ground when pressed. Tip: Don’t leave MCLR floating (ie, unconnected), otherwise the chip will be in a constant state of resetting and never actually do anything. If the pin is configured as an IO pin, of course you don’t need to worry about this.

Watchdog timer – pics can set a watchdog timer to reset the chip if there’s a problem. Turn this off for the moment.

Just about everything else can be switched off, at least, in these early days.

In SourceBoost, you set the config bytes with the data pragma:


Have a look through the include file for your pic (eg, pic16f88.h) in the sourceboost include directory to see the options for your pic. Match this with what you want from your datasheet, and “&” them altogether. This is the config for the 16f88 pic, a very handy general purpose chip. It’s got 4k words of flash, 256 bytes of EEPROM and 384 bytes of RAM.

You’ll need a pic, run Vdd to 5 volts and Vss to ground, attach a led to one of the pins (in this case, we’re going to use RA0) and route the led to ground via a resistor – 330R should do it. Route MCLR to Vdd via a resistor (say 10k). Take the .hex file generated by the compiler, use your programming utility to program the pic and see if you can get that led flashing.

Once you’re this far, you’re reading to get a bootloader going.

7 April 2008

4. Compilers

You can, of course, program pics in assembly language. There are people out there who will tell you that to get the real power out of these little dudes you need to program them in assembly. These people are insane and need medical help. Pick a higher level language and use it. Once you have to start worrying about jumping between code pages and variables in different pages of ram, you’ll dump assembly as fast as very fast thing.

I use the SourceBoost compiler. It’s got great support, isn’t expensive compared with some of them out there and has free (albeit limited) trial versions. There are lots of other C compilers out there for pics. Of course, you can choose whichever compiler you like and best of luck – C ain’t as portable as it used to be, especially in the world of embedded compilers. It’s not that hard though, so if you use something else, then you’ll be able to make use of the stuff here.

5. Your first pic program

Okay, so let’s get some leds flashing. First we’ll get a virtual led flashing – then go for the real thing.

Open up the flash project in adventures\flash. Add a led from the plugins menu, configure it to use portb. Pics have a concept of ports – really it’s just a way of distinguishing all the pins from one another. Instead of having IO pins 1 through 24, they’re broken up into “ports”. Nothing magic about them, other than the fact you can write to a whole port at once if you want (ie, change or read all 8 pins in one instruction.

Compile the program by pressing F7. Hit the debug button (it looks like a little bug) Hit F5 to run the program. And watch, in astonishment as the led flashes. Very. Slowly.

Actually the real hardware runs a lot faster. Before we get some hardware going, lets have a look at what this program does. Pull up flash.c.

/* Flasher!

A good little test program that flashes leds..


#include "pic_utils.h"

Pic_utils.h includes a bunch of handy stuff, and I include it every time.

#pragma CLOCK_FREQ 8000000

This tells the compiler how fast you expect the clock to be running. This is so the linker can generate a “delay” routine for you that matches your clock speed. Delays are really carefully crafted loops. We really only know how long 250ms is by knowing the clock rate and how make clock cycles a given set of instructions take to execute.

#define flash_port PORTB
#define flash_pin 0

Get into the habit using #defines wherever and whenever you can. It means that you can make simple hardware changes (like using port a instead of port b) by doing equally simple software changes (changing the #define) instead of having to find every instance of port b when you are referring to your flashing led pin, and changing them. Believe me, you’ll be thanking me for this later.

void interrupt () {

Pics have at least one, if not two, interrupt routines that are executed upon certain events happening, like a timer going off or a serial character being received or a pin changing level. We don’t do anything with it here – but I include so that if we’re using a bootloader, everything will be at the right location in memory. More on this later.

void flash() {
toggle_pin(flash_port, flash_pin);

This is where the heavy lifting is done. We just flip the output of this pin to high if it’s low and low if it’s high every time this function is called. Toggle_pin is a pic_utils routine, which we’ll explore more a little later.

void main() {

make_output(flash_port, flash_pin);

while (1) {




The main routine has a couple of interesting things in it. Firstly, some ports can be analog inputs or digital inputs, and by default they start out life when booted as analog inputs. So this nifty routine fixes that for our purposes. Then we set the flash port / pin combination to be a digital output (the default, once it’s no longer an analogue input, is a digital input). Mind you, not all pins can be an analogue input, but just turning them all into digital pins at the start means we don’t have to do datasheet hunting at this stage of the game.

Finally, in our main loop we flip the led, then wait 500ms before doing it all again. Forever. Seeing that the led should light every second or so, you get a feeling how much slower the hardware emulator is running than the real hardware.

3. Take your pic

These series of tutorials cover the Microchip pic family of microcontrollers. There are many other types of microcontrollers. If any of those take your fancy, you’ll find that beyond the specifics, a lot of what you learn here will apply for those ones as well. I happened to stumble into pics first and once you’ve made the investment into programmers, and prototyping gear and compilers and code, it’s hard to switch. Maybe I’ll try another variety someday – a lot of people talk positively about the AVR family for example. Whatever. This is about Microchip pics. Go fight your religious wars elsewhere.

You can get pic chips with as few as six pins and as many as, well, lots. Hundreds even. The smaller varieties have less memory and less functionality, and they’re cheaper obviously as well. I think the 16 and 18 series are the most fun – they’re a good platform to build on and once you have something working, you can port it to a smaller pic if you want something cheaper.

So what’s in these little guys? Each pic has some flash memory, it may have some eeprom memory as well. It has a number of hardware blocks that might be as simple as some inputs and outputs or as complex as a full blown USB implementation.

These two different types of memory are important. There’s normally lots of flash compared with much less eeprom memory. Flash is cheap, and hence big, eeprom is expensive. Flash can be overwritten 10,000 times. Eeprom can be overwritten a million times. So you can see that flash is good for programs, eeprom is good for settings, configuration, storing things that change.

In terms of pins on the chip itself, two are reserved for power. Many pics run at 5 volts (eg 16f88) at high clock speeds, or a more expensive variety (eg 16lf88) that runs as low as 2 volts. At those lower voltages however, often you can’t clock them as fast.

Speaking of clocks, with hardware it’s often all about timing. Knowing precisely how fast the pic is running turns out to be quite important (although I spend a fair amount of time trying to avoid timing issues). As such, the most accurate way to clock a pic is via a crystal, plus two small capacitors which help stabilise the oscillator circuit. This does take up two pins, however, and given that pins on these babies are often limited, microchip give you the option of running an internal clock instead. The internal clock is an RC clock – meaning it’s based on the charging time of a capacitor. Since capacitors are harder to make accurately than crystals, the timing is not as precise. Still, you get two pins back. A trade off.

Unfortunately for us, pics take four oscillator cycles to process one instruction. That means that when you’re running with an internal clock (often 8Mhz), you’re running at 2 million instructions per second (mips). That’s one instruction every 1 / 2,000,000 seconds, or every 0.5 microseconds, or 500 nanoseconds. Sounds fast until you actually try to do something even vaguely complicated Then you’ll be scraping for every mip you can get your hands on. And that’s because it’s a RISC device – a reduced instruction set. These little guys only have one register and have no concept of numbers bigger than 255. It turns out that you can get quite a lot out of these simple instructions though, including 32 bit numbers and floating point math, but my point is there’s no fdiv instruction here – you need to do quite a few instructions to accomplish anything much. Oh, and that’s not quite the full story either – some instructions take two instructions to execute – that is, 8 clock cycles. Still, for the purpose of this experiment, we’ll just blindly assume that 4 clock cycles is enough of a sacrifice to make.

2. Microcontrollers

These days we have devices that don’t just have four gates in them, they have tens and hundreds of thousands of gates. So much so that these devices can run a series of simple instructions. A lot of the external circuitry that was required in the past is simply not necessary. As I always suspected, software has taken over the world.

Making software is a creative act, and like writing music, I’m always astonished at the fact that you essentially creating something from nothing. Now that microcontrollers are cheap enough for anyone to play with, it means that all those complicated little electronic things can now be created out of software, not hardware. And creating it out of software means that we are creating these things out of nothing. Astonishing.

Anyway, enough philosophy. Let’s make some leds flash.

1. Introduction

When I grew up, I was fascinated by electronics. I had one of those 150-in-one kits, where components could be hooked up by connecting wires between springs. Each spring had a number. I didn’t really understand what everything actually did. I just followed the instructions. Connect 12-15-25-3. And so on. After 20 minutes, you had a working siren, or an AM radio, or a light detector.

Eventually I started to buy electronic magazines. Back in those days occasionally the magazines would include a printed circuit board on the front panel. One of the first kits I made was a space invaders game. That’s what they called it. There was a vertical row of leds, and the leds would light in succession from top to bottom. The idea was to press a button when the lowest led was lit, there by killing the space invader. If you did that, then your score (which was indicated at the top of the board in a binary form, again in leds) increased by one. The second last led was red – if you pressed the button when that led was lit, then your score went back down to zero. It was a really simple game, but it took four or five integrated circuits from the 4000 series and a bunch of other components to make it work.

Years later I’m still making leds light up. Trust me, getting this all working is quite a challenge the first time. It’s a great feeling when you finally get that led flashing…

- Photo thanks to Chris Glass