New experimental USB stack

We in the chipKIT programming dungeons have been slaving away for the past few weeks to bring you a new, long awaited, USB stack for your USB-based chipKIT boards.

Finally we can say the PIC32MZ based boards have full USB support!

Continue reading New experimental USB stack

VN:F [1.9.22_1171]
Rating: 10.0/10 (4 votes cast)
VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)

P-P-PIC up a TFT with chipKIT and DisplayCore

Did you know that chipKIT boards are probably the best choice for controlling a TFT screen?… Considerably better than most Arduino boards, that is for sure! I say that with confidence for three reasons:

  1. chipKIT boards typically have far more memory and computing power than many Arduino boards, and as a result, they are so much better at manipulating graphics and data for display.
  2. chipKIT boards can get the data out to the TFT screen so much faster though high-speed interfaces, so less time is spent redrawing things on the screen. You’ll find that images appear instantly, as opposed to being drawn out slowly.
  3. Finally my favourite reason: professional-grade library support. I say it’s my favourite because I designed and wrote the library myself, but I’ll tell you more about that journey later on.

First let me introduce you to a little friend of mine:


This here is the Picadillo-35T developed by 4D Systems in Australia (also available from microchipDIRECT). The Picadillo is essentially a chipKIT MAX32 board with a nice, high-resolution TFT touch-screen strapped to the back. The meaty PIC32MX795F512L chip (also used on the MAX32) boasts plenty of RAM (128KB) and Flash (512KB) and all the other bells and whistles you have come to expect from chipKIT boards. The board also has the same connectors as the popular chipKIT Uno32, uC32, WF32 etc., so all your shields should just plug in and work. You also get sound thrown in to the mix with an on-board speaker, and of course you get an SD card slot–what self respecting board would be without one these days anyway?!

Ok, enough said about that. The main reason I write this post is to tell you of the most useful part of this Picadillo board: the TFT touch-screen. And let me tell you, it’s not just any TFT screen. It’s an above-average 3.5″, 320×480 resolution, crisp-image delivering screen. Not only that, but the way the TFT is wired to the PIC32 chip is also “above average.” The TFT connection boasts a 16-bit parallel interface, not the normal slow SPI interface that most cheap Arduino TFT screens give you–meaning that it takes one bus clock operation to output a pixel as opposed to 16 (a considerable speed increase!).

But that’s still not all! (I’m starting to sound like a TV salesman now. “Buy now and we’ll throw in this amazing clock radio and set of saucepans absolutely free!”). The TFT’s 16-bit interface has been directly connected to the “Parallel Master Port” (PMP) of the PIC32. The PMP is a bit like the old internal bus of early computers; you get an address bus, a data bus, and a bunch of control signals, meaning there’s no messy twiddling of GPIO pins with the likes of digitalWrite() (or even direct port manipulation using registers). Writing data to the screen takes just one instruction. That’s right – ONE instruction. And that means even greater speed. But wait, there’s more! (Here comes the gold-plated nose-hair trimmer…) It’s called DMA: Direct Memory Access. Guess what that can do! DMA can send data through PMP, and this essentially allows for direct communication with the TFT display, all without the MIPS CPU’s involvement! In effect, you can be outputting data to the screen whilst doing other things! All-in-all it’s really a thing of beauty… if you like that kind of thing, of course.

So what does all that mean to the layman? It means you have a well-designed, well-built bit of kit in a nice compact package with all the power you could ever want to make your perfect user interface. But isn’t programming user interfaces and drawing graphics on a TFT screen a hard job? Isn’t it fairly skilled and in-depth? Don’t you have to write reams and reams of code just to get it to print “Hello World”? Well, yes, you do. However I have already done all that for you. And that is where the journey to the core begins.

Continue reading P-P-PIC up a TFT with chipKIT and DisplayCore

VN:F [1.9.22_1171]
Rating: 9.7/10 (6 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

My first Robot controlled by a chipKIT Max32 using a Microchip PIC32 microcontroller

RobotEdh’s chipKIT Robot
[RobotEdh] has spent quite some time building himself a chipKIT powered robot. Based on the Baron robot from DFRobot this monster is so packed with features it’s a wonder it doesn’t collapse under its own weight. Camera, IR sensors, encoders, touch sensors, temperature sensor, LCD screen, WiFi and X-Bee communications. So many things, in fact, that there is no way you could get it all working together on an Arduino. Indeed, he had to upgrade from an Uno32 to a MAX32 because he ran out of Flash memory the project was so big! He has even written a great Java application for controlling it all. I think this project deserves a big Thumbs Up from us at chipKIT for such an impressive bit of engineering and design!
VN:F [1.9.22_1171]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.22_1171]
Rating: +2 (from 2 votes)

Remote programming a chipKIT Pi

So you have a chipKIT Pi, which you have dutifully attached to a Raspberry Pi, and you’d like to deploy it “in the field” (with the cows). That’s fair enough. What you’d like to be able to do, though, is upgrade the firmware on the chipKIT Pi without having to go into the field (those cows are scary, man!).


So how would you do that? You can’t program the chipKIT Pi without pressing the RESET and BOOTLOAD-EN buttons (and you’re not about to train cows to do that for you), so what are your options?

Well, UECIDE has the answer for you.

pi-modFirst you will need to modify your chipKIT Pi. Don’t worry, it’s only a simple small modification. Basically you need to connect the BOOTLOAD-EN signal to one of the GPIO pins on the Raspberry Pi header.

Connect pin 8 of the chipKIT Pi pass-through header (GPIO17 on the Raspberry Pi) to the nearest pin of JP6 with a piece of fine wire. I use 30AWG wire-wrapping wire. This will allow the Raspberry Pi to trigger the bootloader automatically (hopefully future versions of the chipKIT Pi will have this modification in place already).

Now you can enter programming mode from the Raspberry Pi by setting GPIO 17 to an output and driving it LOW, then setting GPIO 4 to an output and driving that low too (it is connected to RESET), then releasing both the GPIO lines in reverse order. It’s good to put a short delay between releasing GPIO 4 and GPIO 17.

To make things even easier we have a chipKIT Pi support package in our Debian repository. Add the repository to your /etc/apt/sources.list file:

$ sudo nano /etc/apt/sources.list

Add the line:

deb stable main

You can also add our signing key so it doesn’t ask if you want to install unauthorized packages:

$ wget -O - | sudo apt-key add -

The package is called “ckpi-support” and it sets up all you will need in order to program the chipKIT Pi remotely from UECIDE. It will:

  • Install avahi-daemon (if not already installed)
  • Configure a “ckpi” user
  • Install “pic32prog”
  • Install scripts for controlling the chipKIT Pi:
    • ckpi-reboot (reboots the chipKIT Pi)
    • ckpi-program (reboots the chipKIT Pi and triggers the bootloader)
  • Install an mDNS service so UECIDE can find the board on the network

So go ahead and install the package now:

$ sudo apt-get update
$ sudo apt-get install ckpi-support

If all goes well it will have asked you for a new password to give to the “ckpi” user. Remember this, as you will want it again later.

One more small modification you will need to make (if you haven’t done it in the past) is to disable the “getty” process on /dev/ttyAMA0 (the serial port).

First edit (as root) the file /boot/cmdline

$ sudo nano /boot/cmdline

Remove from that file any references to ttyAMA0 (there should be a console= entry in one line that points to it – remove it) and save the file.


Edit the file /etc/inittab

$ sudo nano /etc/inittab

and look for the line:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

It is most probably right at the end of the file. Comment the line out by placing a # at the start of it and save the file out. You can now either reboot to enable the change, or trigger a reload of the file:

$ sudo kill -HUP 1

Now you’re good to go!


Disable and permanently kill the serial-getty service:

$ sudo systemctl disable serial-getty@ttyAMA0
$ sudo systemctl mask serial-getty@ttyAMA0

You might need to reboot after this to restore the /dev/ttyAMA0 permissions back to what they should be since the getty service leaves them in a rather odd state.

Now on to the UECIDE side of things… 

You’ll need the latest version of UECIDE as it has the networking support you’ll be using, so if you aren’t already running it then go ahead and download it. This is the version for your PC of course, not for the Pi. You don’t need it on the Pi.

Load UECIDE up, ensure the chipKIT Pi board is installed (and the latest version), and after a few moments it should detect the Raspberry Pi for you:


You should now be able to select the board from the “Discovered Boards” menu:


And there should now be a suitable entry in the “Programmers” menu:


Important note: Those images are from a slightly older version of UECIDE.  The current version lists the boards under the “Devices” menu in Hardware, not “Discovered Boards”.  Also it doesn’t currently notify you of boards as it finds them. Just check the menu to see if the board is there.

Now you can just compile and upload your sketch as if you were directly connected to the chipKIT Pi. The first time you upload it will ask you for the password for the “ckpi” user – the password you entered when installing the support package. If you want you can tell UECIDE to save the password forever (it puts it in your preferences.txt file), but even if you don’t do that it will still remember it for the rest of your session so you won’t need to re-enter it again until you next load UECIDE.


VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Identifying your chipKIT boards

ft232-uart One thing I find annoying about the chipKIT boards is that when you plug them in they are all identified as an “FTDI” chip.  There’s no way of knowing which board is plugged in where, and if you have lots of boards (as I do), then it would be really nice to know which COM port is which at a glance.

Fortunately it is possible, if you happen to know how!

A little word of warning before I begin though – it is possible to kill your FT232R chip if you do things wrong, which will break your chipKIT board, so have a care and don’t mess with things you shouldn’t mess with.

Not many people know, but the FT232R chip used in most of the chipKIT (and other) boards is fully programmable by the end user.  All you need is a little bit of software (alas only available for Windows) from FTDI called FT_Prog.  It can be downloaded freely from here:

It requires .NET 4 to be installed, so if you don’t have it you can grab it here: .NET 4.0

Once you have it installed you can load it up and tell it to scan for your devices (little magnifying glass in the toolbar).  Make sure your board is plugged in at this point, and it should find it:

found-ftdi Select the “USB String Descriptors” section.  It should look similar to this: ftdi-strings Now you can go ahead and edit the Manufacturer and Product Description entries to suit your needs.  The board I have to hand is a MAX32, so I have changed them to: ftdi-changed Now you’re all ready to reprogram the chip.  The little lightning bolt in the toolbar does just that.  Click it, and it opens a program panel: ftdi-prog Make sure the right device is selected (if you happen to have multiple boards connected), then press “Program”.  When it’s finished (it only takes a second), you can close the window, then close the FT_Prog program.  Unplug the board and plug it back in again.  It will take a minute or so to reinstall the drivers (it may allocate a new COM port at this point as it thinks it’s a different device), and it should now identify for what it is: ftdi-done

If it doesn’t, try again.  For some reason it took two attempts with my MAX32, but my PICadillo-35T did it first time.

Again, I must strongly reiterate: It is possible to break your FT232R chip with this utility, so don’t play with anything other than the strings and you will be fine.

Oh, and don’t blame me if you break it, it’s not my fault.
VN:F [1.9.22_1171]
Rating: 6.0/10 (1 vote cast)
VN:F [1.9.22_1171]
Rating: +1 (from 1 vote)