http://www.fourwalledcubicle.com/LUFA.php programmer for TPI is included in the package, boards available online To Do: - figure out if all the unconnected pins on the FPGA match the Pluto-P - verify pin configuration seems to match the data in: ~/src/emc2-dev/src/hal/drivers/pluto_servo_firmware/pluto_servo.pin 2011.12.04 - results of physical inspection of pluto-p board 22 ohm series resistors on 7 pins between FPGA and 10 pin header, including Q pins 5, 8, 9, 10, 13, 16, 93 ** these are din_1 through din_7 .. makes sense? **DONE** pin 50 has an LED and 1k resistor ** my current design has 330 ohms **NOT DONE .. CAN CHANGE IF NEEDED AFTER PCB FAB** 10k from pin 25 to pin 44, cap from pin 44 to ground 44 is VCCIO, 25 is nSTATUS, so this is a pull-up on nSTATUS **DONE** db25 pin 11 to sole pin side of one "1L" transistor, one lead to ground, 4.7k from remaining lead to pin 87, another 4.7k between pins 87 and 90 db25 pin 11 is nWait .. so it looks like nWait is being driven by a transistor from the FPGA DEV_CLRn output, not directly **DONE** db25 pin 12 to sole pin side of one "1L" transistor, one lead to ground, 4.7k from remaining lead to pin 6 db25 pin 12 is undocumented? so FPGA pin 6 is able to drive that pin through a transistor **DONE** why not treat all the parallel port input pins with transistors? http://emergent.unpythonic.net/01165081407 has an answer, that they are used as inverters because the FPGA has weak pull-ups on those pins yet those pins need to be driven low or the PC can't configure the FPGA by "printing to it" .. apparently that only applies to the two pins that have the inverters on them. Duh. Of course they're inverting... how'd I miss that? **DONE** pin 49 hooked to pin 51 .. nCONFIG driven by nConfig **DONE** osc pin 3 to pin 91 consistent with my design, 40mhz to FPGA **DONE** 26 pin header pins 11 and 12 to sole pin side of "G1" transistor, both other leads have caps to ground if it's an NPN transistor: emitter attached to VCCINT base and collector both to VCCIO VCCIO is driven by 3.3V regulator, VCCINT is not 4.7k between pins 87 and 90 pin 87 is DEV_CLRn driving nWait to the PC **DONE** 2013.04.28 - studying design on the way home from POSSCON 2013, hoping to figure out what the problem is between the parallel port and the FPGA that is causing configuration to fail. Something seems odd between the docs and what I think I found during physical inspection of the pluto-p board. I have nWrite on pin 75, while the KNJN document says nWrite is parallel port pin 1 and that should be on FPGA pin 90. The pluto_servo.pin file in the EMC2 pluto-p driver directory seems to say that pin 75 is a bidir DCLK signale, and pin 90 is an nWrite *input*. The parallel port doc says that pin 1 is nStrobe in SPP mode and nWrite in EPP mode. In both cases, that seems like a signal from the PC to the FPGA (strobing data in). Reading the verilog source, nWrite is indeed an input to the FPGA and is used to determine the EPP mode. The pluto_servo.pin file says that pin 87 is nWait which is an output from the FPGA. Everything seems consistent in suggesting this should be driving pin 11 on the parallel port through a transistor inverter. I cannot fathom why pin 87 should have a 4.7k to pin 90. I'm not at all sure how I ended up with pin 75 (DCLK) connected to parallel port pin 1. SO... - I think FPGA pin 75 should not be part of the nWrite net. - I think FPGA pin 90 needs to be part of the nWrite net. - maybe try removing R23 which is the 4.7k between FPGA pins 87 and 90, and/or figure out what I was counting wrong! 2013.04.29 - put the pluto-p under the microscope .. and low and behold, pin 75 and pin 90 on the FPGA are *both* connected to parallel port pin 1!