close-circle
Close
0%
0%

piculear

Coercing the GPIO of an arbitrary device to control a simplistic PIC programmer.

Similar projects worth following
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).

The hardware interface, a power and level shifter module, should be simple in order to make it easier to track down points of failure. To avoid heartbreak, it should also be easy/cheap to replace.

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. Python 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.

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:

  • A simple boost converter for the nominal 12V to 14V programming voltage, using PWM and ADC from the MCU rather than a separate boost IC.
    • Alternatively, if PWM, ADC, or a suitable inductor cannot be found, a place to accept an input for that voltage.
  • If applicable, a PWM-controlled regulator for target VDD.
  • A power output switch for target VPP.
    • Two pins are used for a tri-state effect.
  • A power output switch for target VDD.
    • Two pins are used for a tri-state effect.
  • Level shifters (between host VDD and target VDD) for the communication lines.
    • It's preferable if the hardware doesn't care which of host and target has the higher VDD. For example, a 3.3V host should be able to program a target at 2V or 5V without any hardware changes.
    • Push-pull shifters would be preferable to just pulling up or down; this would allow support for dated or naïve designs having their own pull-ups/pull-downs on the lines.
    • The ICSPDAT line must have a bidirectional shifter.
    • The ICSPCLK line could use a unidirectional shifter or could be made bidirectional (as on PICkit 2 and 3) to provide additional facilities.
    • The PGM/LVP/AUX line could be made optional. If implemented, it could use a unidirectional shifter or could be made bidirectional (as on PICkit 2 and 3) to provide additional facilities.

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...

Read more »

  • 3 × 74LVCH1T45 Logic ICs / Receivers, Transceivers - 3-state, bidirectional, active bus hold
  • 2 × 100Ω resistor
  • 2 × Dual N/P-channel MOSFET
  • 2 × Schottky diode (potentially substitute P-channel MOSFET)
  • 3 × N-channel MOSFET

View all 16 components

  • PK2 device file (Pseudo-) decompilation, ardpicprog-java

    psmay07/15/2014 at 21:20 0 comments

    A couple of new levels of abstraction have been added to my PK2 device file analysis suite. Now included in the build is an intentionally C-like output file that fashions each script as a void function.

    For the version of the device file I'm currently using, instances of LOOP, LOOPBUFFER, and GOTO_INDEX are all successfully resolved into counting for loops. I haven't finished the translation of IF_EQ_GOTO/IF_GT_GOTO, but since all instances of those are in the DBG* scripts (what I gather to be for in-circuit debugging, which I'm not planning to implement anyway) they're not a major priority. Not counting the latter, there are no gotos to speak of in the output.

    Other semantic reworks are also included. For example, DELAY_SHORT and DELAY_LONG are normalized to delay_ns, whose argument is always an integer (with a human-friendly scaling of the value in a comment). I/O via the download/upload buffers and the data/clock lines is decomposed in a sort of functionalesque, orthogonal style; WRITE_BYTE_LITERAL(b) becomes putLineByte(b) while WRITE_BYTE_BUFFER() becomes putLineByte(getBufferByte()).

    The result is intended to be expressive rather than efficient; expressive code can be optimized straightforwardly, but optimized code tends to be difficult to make expressive.


    On a somewhat related note, to determine how easily it could be done, I ported the ardpicprog host program to Java. It turned out not to be all that difficult, and RXTX (the serial library) works nicely wherever it's supported at all. I have two branches: The master branch is written to be a Java program, while the pythonization branch includes a good deal of extra work to use Python-like idioms so that porting to Python would be less infeasible. Refactoring Python is a great deal more difficult than refactoring Java, so getting it right the first time seems pretty important.

    After working on this for a while, I now wonder whether I like Python enough to try to port anything to it or maintain something in it. As a matter of personal taste, I like static types and various other comprehensive static checking facilities that prevent uncaught run-time errors. I might proceed to make the piculear host code in Java (or Scala) and beg for help porting it down later.

  • Level-shifter testing breakout

    psmay03/14/2014 at 21:20 0 comments

    The current design includes a 1-bit bidirectional level-shifter IC (the 74LVCH1T45 (PDF warning))  that I've never used and never even heard of before before browsing the schematic of the PICkit 3. And it's not even the same one in the PK3, but an improved version that doesn't involve pull-ups. It really seems like the right tool for the job. But how can one be sure?

    I've designed a breakout board for three of these little guys (and they are little—the tiny SOT-363 package will have some thinking twice about trying to solder it in by hand) with layout considerations for good breadboardability and homebrew manufacturability. (If there's one thing I want my home PCB fab lab to be really good for, it's breakouts for surface-mount devices. I'd like to save professional fabrication for more serious designs.)

  • Allow shoot-through?

    psmay03/11/2014 at 21:44 0 comments

    TL;DR summary: Are the resistors I've placed between the drains of complementary MOSFETs really necessary?

    The Vpp and Vdd power switches in my current draft are conceptually based on a mix of the switches from the PICkit 2. (Follow along in the PICkit 2 User's Guide, appendix A, if you like.)

    In the original circuit, the Vpp switch consists of a low switch (on signal "MCLR TGT"), which is just an NPN transistor, and a high switch (on signal "Vpp ON") that is an NPN transistor whose output is pulled up to the high Vpp voltage and fed into a PNP transistor, which switches the high voltage into the output. The outputs of the low and high switches are tied together with a 100-ohm resistor, presumably to avoid a "shoot-through" condition blowing either of the transistors during the transition while neither high nor low transistor is fully turned off. The two input signals are controlled independently, making hi-Z output possible.

    The Vdd switch is decidedly different, but similar. MOSFETs are used, and the level shifting seems a bit less involved (because the programmer's own voltage and the target Vdd are similar enough that the extra input transistor is not necessary). There are still two distinct input signals ("Vdd TGT N" and "Vdd TGT P"), so the output can still go hi-Z. Though the schematic makes it harder to read, there is still a resistor between the two outputs, this time 1K, and there is also a Schottky diode from the high side, which appears to relate to the fact that the target may be self-powered and thus assert its own voltage (which could be higher than Vdd of the programmer). If the target voltage were too high, current would back up through the body diode of the PFET (and, in the PICkit 2, through that of the target Vdd adjustment PFET, into the programmer's Vdd rail) which could be nasty.

    My current draft of the schematic includes two nearly identical switches that combine elements of these two. Both have a level-changing input transistor, mostly in the interest of allowing the programmer to be 3.3V but be able to program at 5V (or higher). On the Vpp switch, the transistors are changed to MOSFETs because it seemed to be an opportunity to factor out unnecessary base resistors.

    My draft also retains the 100 and 1K shoot-through resistors. I'm trying to decide whether these are actually necessary for my version of the circuit.

    I've seen similar MOSFET-based topologies that don't place any resistor between the P and N drains, even when their gates are tied together rather than separately controlled as they are here. The excuse seems to be that, since MOSFETs have a positive temperature coefficient (PTC), they don't have to be protected from the condition in the same way as BJTs which have negative (NTC); in a sense, they behave as their own polyfuses. By this logic, either of the resistors might be unnecessary.

    So, does anyone have any input regarding whether this is the case?

View all 3 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates