Concept: piculear

Years ago, while frustrated with my Microchip PICkit 2, which I only bought because of two failed attempts at building serial-port-based PIC programmer designs, I considered the possibility of a somewhat more open design that still had solid USB-based communications and the 5-to-13V boost converter, which was still kind of mysterious to me at the time.

I extracted a small piece of the PICkit 2 schematic—specifically, the boost converter, which is so generic as to be public domain—and decided to try to make it work independently. I secured a 680µH inductor and tacked leads onto it to make it breadboardable. Finally, I got a PWM going on what I believe was a PIC16F88 and it cranked out way over 5V, which was a welcome start. But it wasn’t 13V until a couple of firmware adjustments.

A closer look at the schematic revealed another point: The Vpp output is fed back using a voltage divider into an ADC channel on the MCU; then part of the program repeatedly reads the ADC and makes adjustments to the PWM duty cycle using a PID^[1] control algorithm.

I’d just gotten my first Arduino (a Diecimila prototype limited edition obtained at a DC Dorkbot event) at the time, and I was unfamiliar enough with the problem that I didn’t want to be stuck trying to solve it in assembly, so I got a rough version of the boost working on that. I didn’t implement a full PID; indeed, what I hammered out wasn’t even proportional. Instead, it determined whether the ADC reading was above or below the target. If above, the duty cycle was incremented by 1. If below, it was decremented by 1. The result was clamped to a pre-determined safe range. Now, this mechanism is slower to react than PID and probably produces a shakier output, but it seemed like it might just work anyway, and if not it could be fixed later.

And that’s about where it stopped, because I did still have a working PICkit 2. But recently I picked up another project that seemed like a good fit for one of the cheap little PIC16F54s I have available. When I tried to get the PICkit 2 running to start messing with it, it behaved strangely, and I lack the tools to properly diagnose it.

It would appear that I am not the first to determine that an Arduino-based PIC programmer is a good idea; Ardpicprog has gotten a tiny bit of press. But it doesn’t have an Arduino-based boost converter (Vpp is provided using a separate power supply or with a self-contained boost converter requiring separate control ICs), and its firmware, which doesn’t leave a whole lot of room for extensions, is tuned for the 14-bit models, and the ’54 is a cheaper 12-bit model requiring non-trivial adjustments.

I figure that an interesting approach would be to offload as much of the sequencing work as possible to the host software and let the firmware concentrate on what it’s talented at: running the PWM and ADC for the boost and controlling the ICSP data and supply lines with the precise timing necessary to program. The delay figures themselves, as well as the sequence of commands necessary to work with the target device, would be accepted over serial. Ardpicprog uses C++ code for the host program; I think that it would be nice to keep it all approachable and use something like Python instead^[2]. Python has a popular cross-platform serial library that can be used without the confusion inherent in compiling code for a new platform.

The various nuances among the slightly different devices can be dealt with more flexibly on the host. Support for the 12-, 14-, and 16-bit devices and perhaps others could be incorporated without worrying about the size of firmware (or the size of any given integer, for that matter).

It’s a concept. Thoughts?

1. ^[1]Proportional-integral-derivative. A statistical approach to control by using weighted calculations of past, present, and predicted future error to make corrections on the fly.↩
2. ^[2]Python isn’t my favorite language in the world, but you have to admit it’s pretty approachable↩