To Do:
-- figure out the nConfig / nCONFIG wiring by inspecting my real Pluto-P
- 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!
projects / hw / cncfpga / blobdiff