git.gag.com Git - hw/cncfpga/blob - Notebook

   1 http://www.fourwalledcubicle.com/LUFA.php
   2         programmer for TPI is included in the package, boards available online
   3
   4 To Do:
   5
   6 - figure out if all the unconnected pins on the FPGA match the Pluto-P
   7
   8 - verify pin configuration seems to match the data in:
   9   ~/src/emc2-dev/src/hal/drivers/pluto_servo_firmware/pluto_servo.pin
  10
  11
  12 2011.12.04
  13 - results of physical inspection of pluto-p board
  14
  15     22 ohm series resistors on 7 pins between FPGA and 10 pin header, including
  16 Q
  17         pins 5, 8, 9, 10, 13, 16, 93
  18
  19         ** these are din_1 through din_7 .. makes sense?
  20
  21         **DONE**
  22
  23     pin 50 has an LED and 1k resistor
  24
  25         ** my current design has 330 ohms
  26
  27         **NOT DONE .. CAN CHANGE IF NEEDED AFTER PCB FAB**
  28
  29     10k from pin 25 to pin 44, cap from pin 44 to ground
  30
  31         44 is VCCIO, 25 is nSTATUS, so this is a pull-up on nSTATUS
  32
  33         **DONE**
  34
  35     db25 pin 11 to sole pin side of one "1L" transistor, one lead to ground,
  36     4.7k from remaining lead to pin 87, another 4.7k between pins 87 and 90
  37
  38         db25 pin 11 is nWait .. so it looks like nWait is being driven by
  39         a transistor from the FPGA DEV_CLRn output, not directly
  40
  41         **DONE**
  42
  43     db25 pin 12 to sole pin side of one "1L" transistor, one lead to ground,
  44     4.7k from remaining lead to pin 6
  45
  46         db25 pin 12 is undocumented?
  47         so FPGA pin 6 is able to drive that pin through a transistor
  48
  49         **DONE**
  50
  51     why not treat all the parallel port input pins with transistors?
  52
  53         http://emergent.unpythonic.net/01165081407 has an answer, that they
  54         are used as inverters because the FPGA has weak pull-ups on those
  55         pins yet those pins need to be driven low or the PC can't configure
  56         the FPGA by "printing to it" .. apparently that only applies to the
  57         two pins that have the inverters on them.
  58
  59         Duh.  Of course they're inverting... how'd I miss that?
  60
  61         **DONE**
  62
  63     pin 49 hooked to pin 51 .. nCONFIG driven by nConfig
  64
  65         **DONE**
  66
  67     osc pin 3 to pin 91
  68
  69         consistent with my design, 40mhz to FPGA
  70         **DONE**
  71
  72     26 pin header pins 11 and 12 to sole pin side of "G1" transistor, both other
  73     leads have caps to ground
  74
  75         if it's an NPN transistor:
  76                 emitter attached to VCCINT
  77                 base and collector both to VCCIO
  78                 VCCIO is driven by 3.3V regulator, VCCINT is not
  79
  80     4.7k between pins 87 and 90
  81
  82         pin 87 is DEV_CLRn driving nWait to the PC
  83
  84         **DONE**
  85
  86 2013.04.28
  87 - studying design on the way home from POSSCON 2013, hoping to figure out
  88   what the problem is between the parallel port and the FPGA that is causing
  89   configuration to fail.
  90
  91   Something seems odd between the docs and what I think I found during
  92   physical inspection of the pluto-p board.
  93
  94   I have nWrite on pin 75, while the KNJN document says nWrite is parallel
  95   port pin 1 and that should be on FPGA pin 90.  The pluto_servo.pin file in
  96   the EMC2 pluto-p driver directory seems to say that pin 75 is a bidir DCLK
  97   signale, and pin 90 is an nWrite *input*.  The parallel port doc says that
  98   pin 1 is nStrobe in SPP mode and nWrite in EPP mode.  In both cases, that
  99   seems like a signal from the PC to the FPGA (strobing data in).  Reading
 100   the verilog source, nWrite is indeed an input to the FPGA and is used to
 101   determine the EPP mode.
 102
 103   The pluto_servo.pin file says that pin 87 is nWait which is an output from
 104   the FPGA.  Everything seems consistent in suggesting this should be driving
 105   pin 11 on the parallel port through a transistor inverter.
 106
 107   I cannot fathom why pin 87 should have a 4.7k to pin 90.
 108
 109   I'm not at all sure how I ended up with pin 75 (DCLK) connected to parallel
 110   port pin 1.
 111
 112   SO...
 113
 114         - I think FPGA pin 75 should not be part of the nWrite net.
 115         - I think FPGA pin 90 needs to be part of the nWrite net.
 116         - maybe try removing R23 which is the 4.7k between FPGA pins 87 and 90,
 117           and/or figure out what I was counting wrong!
 118
 119 2013.04.29
 120 - put the pluto-p under the microscope .. and low and behold, pin 75 and pin 90
 121   on the FPGA are *both* connected to parallel port pin 1!