piculear

This incomplete but slowly progressing project has the ultimate goal of producing a reliable PIC ICSP programmer that just works and can be more readily picked apart, examined, and/or replaced than a comparable Microchip programmer (for instance, the PICkit 2).

Design goals

The hardware interface should be simple in order to make it easier to track down points of failure. It should also be easy to replace, even if it must be with a makeshift, Radio Shack parts only version while waiting for new parts to arrive. On the flip side, the main hardware design should be flexible enough that it can be readily adapted to a production programmer, complete with firmware-adjustable target VDD.

The software should be trivially cross-platform, easy to study, and not involve substantial work to get running. For this reason C and C++, among others, are out. As tepid as I feel toward Python in general (I'm more of a Perl guy), it might be a good choice here.

The firmware should be very simplistic and do almost nothing, handling only what it does best—communications and fine timing—while allowing the software to do most of the work. This should make it easy to port and prevent problems with memory limitations, and could potentially make it feasible to run on smaller MCUs.

Hardware

The hardware aspect is to provide an interface module that could be connected to an arbitrary MCU/board (PIC16F88, Arduino, you know, whatever is handy) to deal with the parts that actually involve electricity:

The hardware interface should readily connect to an MCU with a few GPIO pins and optionally a couple of PWM outputs and ADC inputs.

Firmware

The firmware will be tasked with communicating serially (e.g. via USB-to-serial) with the software and controlling the GPIO pins needed to implement the protocol expected by the target device.

The firmware for this project must be conscientiously designed to offload as much of the processing as is practical to the software. Code is cheap, as they say, but it is much cheaper on a PC (even a very old one) than on a microcontroller. There should be implementations for simpler primitives—for example, a command to clock out a byte—but anything much higher-level than that is the software's domain.

As a start, it might make sense to examine and convert the family metadata and scripts stored in PK2DeviceFile.dat and decide how they might best translate to this system. (Dumps from the device file may have IP encumbrances, though, so care should be taken before reposting them.)

While conceptually there need be no single firmware, this project will probably start by making something that works for Arduino, since that's currently the easiest thing to find fully assembled on a shelf somewhere.

Software

The software must take care of any part of the programming not already covered by the hardware and firmware. This includes:

This is probably the hard part of the project, and it needs to be kept as easy as possible to run, study, write, and rewrite. To this end, it seems like a good idea to select a cross-platform scripting language with good community support and a matching cross-platform serial library. Python appears to fit this objective, so for now it is what I'll be using.

But, for bootstrapping purposes

Before the software/firmware is complete, there's always ardpicprog, which is another PIC programmer implementation on a non-PIC-based device. With its thick firmware and its C++-based host software, it doesn't hit on all of the goals for this project (and is itself the inspiration for some of the specifications). But it does work, at least for some targets in some situations. With what I estimate to be minor modifications, particularly changing the VDD and VPP switches to be controlled by two pins each, it could be coerced to drive the important parts of the hardware.