ChipKIT Road Test

Here is my second Element14 Road Test, I will be reviewing Digilents ChipKIT Uno32, another beefed up Arduino Clone running a 32bit PIC. Again I will go through my experience with the board from begining to end, I already have some ideas of how to put some of the extra punch this board packs to use, I will link these future projects when they are done.


Here are some closeups of the board, I do like the red.



Board Top Side


Board Bottom Side


First Impressions

OK when I opened the deceivingly large parcel I found inside a suspiciously small box, inside you will find the chipKIT dev board and only the chipKIT dev board. This was not really a bad thing as I already have a collection of usb -> mini usb cables, and I figure most of people buying a chipKIT will be in the same position. It also means that you have to go and download the mpid software, again I kind of like this because I would only scratch or lose a CD anyway.

The board is an Arduino clone so you should recognise the layout, you will notice a bunch more IO's than the Arduino which will always come in handy and an extra LED (two is still not enough in my opinion). The SMD chip would be a downside if you ever fried it, but when the whole board only costs $36 it would be less painfull to just buy a new board.

The Hardware

The chipKIT definitely tries to be a bit of a powerhouse, at the centre of the board you have the PIC32MX320F128 from microchip, running at 80MHz with an onboard crystal, with the option of installing a 32.768KHz crystal as a second clock source for real time applications (32768Hz halved, 15 times is 1Hz). Native 32bit operation means much faster large number calculations, and 128k of flash to store those really big inefficient Arduino programs you write. You also have 30 digital IO's to play with and 12 analogue inputs. I'm trying to avoid constantly comparing it to the Arduino, but it's unfortunately inevitable when you call something an Arduino clone - anyway - hardware wise the chipKIT has all the bases covered.

OK I just said that the chipKIT has all the bases covered and it does, especially when considering raw computing power. What I think it could use though is some extra on board peripherals, I will compare it to the Firebird32 here. The Firebird has an on board RGB LED, a buzzer, an LCD display and extra headers for an accelerometer and communications. Sure someone will have to absorb the small cost increase but I think it would make it stand out even more from the Arduino for beginners who might be interested in playing with these extra peripherals.

EDIT: As noted by Tronixstuff in the comments I forgot to mention that the PIC32MX320F128 is a 3.3V IC, according to the chipKIT site the digital IOs are all 5V tolerant and the analogue inputs are protected with a resistor and diode clamp so people like me don't accidentally fry the chip. It looks like the chipKIT has been designed to ensure that you wont destroy it using a 5V shield, but saying that it is probably a safe bet to pick the 3.3V version if possible.

The MPID Software

There have been dozens of Arduino-Compatible dev boards released in the last few years. I probably know of only a fraction of them but what seems to stand out about the chipKIT is the effort that they went to in making the transition from Arduino to chipKIT as seamless as possible. You do need to download the new software (which looks exactly like the standard Arduino software), but then you can use the mpid software to program both your Arduino and your chipKIT. Any code you have written for your Arudino can be loaded on the chipKIT and run just as you would expect it to on the Arduino (except presumably faster). One thing I have noted is the fairly long upload time and also the long delay before the program starts after restart, the bootloader seems to blink the LED for about 5 seconds every time you reset the board.

This is all well and good, but I think the best thing about the chipkit is that it makes a very affordable and simple way to learn how to program a PIC. I have always used Freescale or Atmel chips and have put off buying a PIC because it would cost me an extra $50 or so for the PICkit programmer. So when I got the chipKIT I ditched the inefficient Arduino programming language and can now take full advantage of the chipKITs extra power by programming in C or C++, it also gives me the opportunity to learn how the PICs really work. So I dive right into the datasheets to find out how you go about turning on an LED with this thing (That is always the first thing I do).

Some Basic Speed Tests

OK so on paper this is a great affordable way to get a high powered dev board, but to see if it is really worth ditching the Arduino and its simple code I figure I better do some (very) basic speed benchmarks. So the first thing I did was turn on an LED, digging through the datasheets I found that the PIC's actually have hardware SET, CLR and INV registers associated with the digital IO's to speed things up a bit, lets bang some bits to test these registers.

Speed Test : Bit Banging

First things first lets see how fast we can toggle pin 13 (the LED pin), I get the time using the micros() command right before and after this loop and then print the difference to see how long it takes to toggle this bit 10000 times. I try three different methods of toggling the pin, firstly using the standard Arduino code and the byte "on". Then next two methods directly access the PICs hardware ports, firstly toggling the pin like I normally would in C, then secondly using the PICs inbuilt toggle register. I repeated the test with the Arduino to provide a reference, remember the chipKIT was always going to win this with its 80MHz clock, I am more interested in the capabilities possible without the Arduino code.

Bit Banging the ChipKIT Uno
7390μs ≈ 670kHz 751μs ≈ 6.7MHz 376μs ≈ 13.4MHz

Bit Banging the Arduino
51888μs ≈ 96kHz 6296μs ≈ 794kHz

As you can see from the results you get a huge improvement by avoiding the Arduino code (and we are just toggling pins), the 13MHz square wave that the picKIT can produce makes me think my next LED cube will definitely be using one of these. I was also going to compare the results with a Freescale board, but unfortunately I was getting outrageously slow results even with nothing in the loop, which makes me think I am definitely doing something wrong there.

Speed Test : Analogue to Digital Converter

OK lets try the ADC, I am taking the sum of 8 samples and dividing the summed result by 8 to get the average (bit shift by 3 is a fast way to divide integers by 8), I will use the same code as before to get the time. I am not sure if it setting up the ADC on the PIC was harder than Atmel chips or if I am just not used to the new setup, but embarrassingly it took me a while to get this to work. It might look like the code I am comparing is all the same, but notice I spell analogue correctly in the ADC read function I wrote.

A2D ChipKIT Uno
41μs 15μs

A2D Arduino
992μs 992μs

OK so the chipKIT again trumps the Arduino as you would expect, but you can squeeze out even more ADC samples by writing your own code which gets it running almost 3 times faster. Turns out there is not much improvement to be made in the Arduino's ADC code which is a nice thing to know if that is what you are using. Since I complained about it being difficult here is my PIC code for the ADC, currently it uses analogue input 11 on the picKIT but it can be changed without much difficulty.

A2D Code


Analogue Read

Summing Things Up

The chipKIT Uno is an awesome board with loads of power, it has the potential to become the brains of some pretty cool projects. The major selling point to the chipKIT seems to be the extra power, I think a more successful approach would be to cram this powerful board with extra peripherals, for example an RGB LED, an IR LED and a buzzer; just to give it an extra edge. I understand the Arduino development environment is an excellent learning tool (It is how I started off) but the chipKIT doesn't even nearly reach its full potential when weighed down by the clunky Arduino code.

So should you buy it? Well if you are looking for a new Dev board to learn on, why not pick the more powerful one with more IO's. Or if you have not yet had a play with PIC this is definitely a nice option to get you started. I know I look forward to finding a project that can use the extra speed and power.

Additional Note : Feel The Power

Ok so I hinted at a new LED cube involving my chipKIT UNO32, so far I have just made this proof of concept design, but some back of the napkin calculations suggest that I can control a full size 8x8x8 RGB cube entirely from the chipKIT (EDIT: It worked!). The picture is to show that each LED is individually addressable, and the video shows what some 8bit Bit Angle Modulation can achieve. All multiplexing, modulation and animation calculations are done on board so no PC is required. I am still working on expanding the design and writing new animations, I will write up a full article when it is ready. Oh and if anyone can give me advice on how to get a decent film of coloured LEDs please chuck it in the comments.

Mini RGB Cube

mini cube

Very Basic B.A.M Animation

Turns Out My Calculations Were Correct

Another Note : Learning a Thing or Two About Memory Management

OK this section may be a little technical and possible incorrect but I do know that this is how the learning happened in my head and the video above is proof that it works....

So if you are like me up until about a week ago you take things like "16K SRAM" for granted, you think "16 times the RAM on the Arduino, I will never run out". Like when I was writing code for my 4x4x3 cube which I had hoped to easily port to my large 8x8x8 cube. It turns out when you are using arrays of 512 32 bit unsigned integers you very quickly start running out of space.

So RAM is split into two sections, the heap and the stack. I am slowly teaching myself c++ and only just learned that there are different ways of creating new objects and each way will use a different section in your memory.

So c++ is a clever beast (sort of), you can let the compiler try to handle your memory management by creating your variables or classes like this, int i[5]; or Class object; then using them like this i[0] = 0; or object.doSomething();. This way will create the objects in the stack section of your ram, it will then delete them (free the memory) when the function they are used in terminates, this means that if they are used in the main function they will never be deleted.

Alternatively you can try to handle the memory management yourself, so you would create pointers to your variable or classes like this, int *i = new int[5]; or Class *object = new Class; then use them like this i[0] = 0; or object->doSomething();. This will create the objects on the heap section of your ram, these objects will only be deleted when you delete them using delete[] i; or delete object;. So basically this way you can dynamically handle your memory to try and squeeze more out of the chip.

OK so after that lovely (hopefully mostly correct) interlude to c++, here is how it may effect you when using the chipKIT. So firstly you can let the compiler handle the memory management and stick everything on the stack, the mpide software will kick up an error when you run out of space. This is when you may have to start thinking of some dynamic memory management like I did. Try and keep the big things on the heap, but remember to be careful when deleting them because if you forget you will get memory leakage. Now you may come to a problem where you have large items in both the stack and the heap and they overlap. This will probably not cause an error in the compiler, the code will upload just fine and then just crash unsuspectingly. Not to worry I found a fix for this too, you can allocate more memory to the heap (this is why you keep the big things in the heap).

To allocate more memory to the heap you need to make a change to the chipKIT linker files, find the chipKIT-UNO32-application-32MX320F128L.ld file, near the top you should see the lines that allocate the stack and heap size, I changed the _min_heap_size to 0x2000. As soon as I made this change my 8x8x8 RGB led cube in the video above lit up and I smiled :)..