#117 Config file for FT2232.c

open
nobody
UrJTAG (99)
5
2010-08-04
2010-08-04
rickyrockrat
No

Is there any interest in me adding a patch that takes all the duplicate code out of ft2232.c and put that info in a config file with bit mappings which all gets read in when jtag loads? I'm thinking much like AVRDude does. It makes it such a simple process to add a new ft2232 device then, instead of taking a day like mine did.

Discussion

  • rickyrockrat
    rickyrockrat
    2010-08-04

    Here's a first stab at what the config file might look like:
    # CABLENAME is the name that shows up in the help cable screen, and *MUST* be the first entry
    # at the beginning of the cable description.
    #
    # All bit field entries are XPB, where:
    # X is H for high byte (AC/BC port) or L for A/B (AD/BD port)
    # P is A for port A or B for port B
    # B is the zero based bit position
    CABLENAME JTAGkey
    TCK L0
    TDI L1
    TDO L2
    TMS L3
    OE L4
    TRST H0
    SRST H1
    TRSTOE H2
    SRTSOE H3
    HELPDESC Amontec JTAGkey (FT2232) Cable
    MODE ftdi-mpsse
    MODE ftd2xx-mpsse
    VID 0403
    PID CFF8
    INIT TCK o0 TDO i0 TDI o0 TMS o0 OE o0 TRST o0 SRST i0 TRSTOE o0 SRTSOE o0 LEDOK o1 LEDERR o0
    DONE TCK i0 TDI i0 TMS 0 OE 0 TRST 0 SRST 0 TRSTOE 0 SRTSOE 0 LEDOK 1

     
  • rickyrockrat
    rickyrockrat
    2010-08-04

    Correction. Should read:
    # All bit field entries are XPB, where:
    And the fields in question:
    TCK AL0
    TDI AL1
    TDO AL2
    TMS AL3
    OE AL4
    TRST AH0
    SRST AH1
    TRSTOE AH2
    SRTSOE AH3

     
  • Kolja Waschk
    Kolja Waschk
    2010-08-05

    I agree that the cable setup in FT2232 as grown somewhat large and it is not easy to overview anymore. I'd appreciate any work to make it easier to add further cables or one universal configurable cable. However, it is not the task of the lowest level parts of UrJTAG to do file I/O and access configuration files. Rather, they should get such configuration via variables that can be setup in the shell, e.g. in the "cable" command.

     
  • rickyrockrat
    rickyrockrat
    2010-08-05

    Actually, I was thinking it could be a high-level config file...again following and AVRDude concept where the one config file set up everything, including new parts and how to talk to them. It could conceivably grow to include the bsdl top-level files, i.e. include a IDCODE followed by a filename to the hdl file that is the essence of the part bsdl. I'm not pushing anything, but my experience with the AVRDude config is that it is *very* easy to set up new devices and new drivers without a single line of code to write.

    Of course, I can do a brute-force where I just morph the header file into a config for ft2232.c. New drivers are then added to a static list that gets created at load time. I'm just talking out loud here,..haven't put any thought at all into the mechanism behind it, or how feasible it might be. It just seems like there is *a lot* of duplicated code that just screams for modularization.