I will start hacking on that driver unless someone tells me not to.
I just wrote a ft245 driver for openwince-jtag yesterday before I found urjtag... It was less complex back then, perhaps I'll start with writing it as a parport driver just to get going...
(I have a bunch of ft245 dip-modules, and I guess I'll get a driver done faster than I'll get a ft2232 module in my hands...)
I don't care about speed of the driver to start with, I just want to be able to program max 3064 cplds for the 8bitbaby-cards.
Any "do" and "donts" are very welcome!
The USB-Blaster consists of an FT245 plus a CPLD thus I'd expect that you can re-use usbblaster.c as a skeleton for your new driver code.
As a first guess, you'll need to modify the body of the following functions:
- usbblaster_set_frequency() (optional)
- usbblaster_init()
- usbblaster_clock_schedule()
- usbblaster_get_tdo_schedule()
- usbblaster_get_tdo_finish()
- usbblaster_set_signal() (optional unless you want to have GPIO-behavior)
- usbblaster_transfer_schedule()
- usbblaster_transfer_finish()
Plus all the structs that define VIDs/PIDs etc.
I know that's a very rough description, so please don't hesitate to come back with specific questions.
Arnim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks a lot!
I'm almost done now, but I got interrupted...
If I'm lucky, the only part left is to find out where to hook in the bit bang enable call, as the driver seems to not use that at the moment.
(as it's a bare ft245 chip with no aditional logic there's nothing that acks the writes, even less strobes new data available to read...)
Either I figure that out some other day, or someone gives me a hint on where to put the bit bang enabler code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The ft245 bitbang module seems to work, as the max chip does what I've told it to.
I get mismatch on the first bit on a couple of lines when programming in the svf file, but it seems to work ok anyway.
However, my code is in a terrible shape right now, I guess you don't want to clean up my mess...
I'll be busy next week, but the week after I have vacation, I guess I could fix the code then... I've trashed around in a couple of files to add extra debug info, so svn status looks like this:
M include/urjtag/usbconn/libftdx.h
M src/tap/cable.c
M src/tap/discovery.c
M src/tap/usbconn.c
M src/tap/detect.c
M src/tap/tap.c
? src/tap/cable/ft245bb.c
M src/tap/cable/generic_usbconn.c
M src/tap/cable/generic.c
M src/tap/cable/cmd_xfer.c
M src/tap/usbconn/libftdi.c
M src/tap/Makefile.am
M src/svf/svf.c
Thanks for the help so far!
I don't think I would have the patience to get this far alone... Not in just a couple of days anyway ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I looked at the usbblaster driver... :(
The driver I wrote for openwince was based on a byteblaster, just converted to usb-code, as the ft245 chip is just a parallell port.
I can't program a cpld without a jtag interface....
So I guess I'll just rewrite my already written driver to urjtag.
The register length detection did not work in openwince, but after hardcoding register lengths it did get the correct device id anyway.
I'm thinking of a real generic driver, with options for what signal is on what pin so it could be used by any dumb hardware.
most people probably build their JTAG cable with a FT2232, because it is faster than FT245 bit-banging by orders of magnitude...
Anyway, there are certainly interested users who want to connect their existing parallel-port adapter via USB-LPT adapter, or happen to have a FT245 available and want to use that for just programming a small CPLD like you do. A driver that takes into account the specific performance pitfalls of USB adapters might at least reduce the pain a little ;)
I second Arnims suggestion to take the skeleton of the usbblaster driver at least for initializing and talking to the FT245.
Some more hints -
1. copy usbblaster.c to ft245bb.c
2. rename all usbblaster_* to ft245bb_*
3. remove all ft245bb_transfer*
4. replace in cable_driver_t
a. ft245bb_transfer by generic_transfer,
b. ft245bb_flush by generic_flush_using_transfer
5. delete all the lines "if (tms==0 && m>=8) in ft245bb_clock_schedule()
... and it should look much friendlier in no time
Kolja
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Such configuration should take place in src/tap/usbconn/libftdi.c and libftd2xx.c respectively.
At the moment we have usbconn_ftdi_open() for "normal" FIFO operation and usbconn_ftdi_mpsse_open() for MPSSE mode. Same for usbconn_ftdi_connect() and usbconn_ftdi_mpsse_connect().
I'd suggest that you add a usbconn driver for bit-bang mode in these files that utilizes dedicated connect and open functions for bit-banging. Something like
urj_usbconn_driver_t urj_tap_usbconn_ftdi_bitbang_driver = {
"ftdi-bitbang",
usbconn_ftdi_bitbang_connect,
These drivers (for libftdi and libftd2xx) need to be registered at src/tap/usbconn.c. And you finally need to fill in the urj_usbconn_cable_t constants in your cable driver file accordingly with references to the two low-level interfaces.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally!
Besides from chain length detection not working (or taking a horrible long time....) things look nice.
Now I have to find/make an svf file to see if that works...
jtag> detect
IR length: 10
Chain length: 1
Device Id: 00010111000001100100000011011101 (0x00000000170640DD)
Manufacturer: Altera
Part(0): EPM3064A
Stepping: 1
Filename: /usr/local/share/urjtag/altera/epm3064a/epm3064a
jtag> print
No. Manufacturer Part Stepping Instruction Register
------------------------------------------------------------------------------------------------------------------
0 Altera EPM3064A 1 BYPASS BYPASS
jtag> instruction SAMPLE/PRELOAD
jtag> shift ir
jtag> shift dr
jtag> dr
110010001001001001001001001001001001001001001001001001001001001001001001000001001001001001001001001001001001001001001001001001001001001001001001001001000001001001001001001001001001001001010010
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have something that seems to work now, programming a max 3064 in a minute or so.
But, about 5 of the 280 "SDR 360 TDI (...) TDO (...)" lines in my svf file fails, on the first bit, no others.
Could I have trashed the chip? Test a new chip?
Solder up leds and switches to test my 4 bit parity generator?
Perhaps I'm lazy that haven't tested those options yet... But I thought there might be some genious clues out there ;)
(Like "that error there means that xyz is b0rken there...")
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd suggest to open up an entry in the Enhancement tracker and post your current diff there. That'll allow me and others to look and comment on the code.
Arnim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure, but I need to clean it up a bit first.
I made my own version of send buffering in the _clock function, building up a buffer to send with ftdi_write_data if n>1, which improved the RUNTEST times very much, which would take forever if I sent every bit in an own packet. (seconds instead of hours)
I don't know which is the better, to keep my own buffering system or try to go back to the transfer stuff.
I'll try to clean up the code somewhat tomorrow so you can look at it.
And by the way, I've only made the libftdi version so far.
Last time I tried I couldn't get the FTD2xx driver to work on my 64 bit ubuntu, but I guess it wouldn't be very different.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Take any time you need :-)
It's just easier for me to talk about coding details once I see the code. It doesn't have to be the golden version right from the beginning.
I don't have any experience with 64 bit systems and FTD2xx. But in general, the usbconn driver contains the same actions, just implemented with other low-level functions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will start hacking on that driver unless someone tells me not to.
I just wrote a ft245 driver for openwince-jtag yesterday before I found urjtag... It was less complex back then, perhaps I'll start with writing it as a parport driver just to get going...
(I have a bunch of ft245 dip-modules, and I guess I'll get a driver done faster than I'll get a ft2232 module in my hands...)
I don't care about speed of the driver to start with, I just want to be able to program max 3064 cplds for the 8bitbaby-cards.
Any "do" and "donts" are very welcome!
http://urjtag.wiki.sourceforge.net/Cable+FT245
Well, have a look at the USB-Blaster cable code and Kolja's documentation of the protocol available at
http://urjtag.wiki.sourceforge.net/Cable+Altera+USB-Blaster
The USB-Blaster consists of an FT245 plus a CPLD thus I'd expect that you can re-use usbblaster.c as a skeleton for your new driver code.
As a first guess, you'll need to modify the body of the following functions:
- usbblaster_set_frequency() (optional)
- usbblaster_init()
- usbblaster_clock_schedule()
- usbblaster_get_tdo_schedule()
- usbblaster_get_tdo_finish()
- usbblaster_set_signal() (optional unless you want to have GPIO-behavior)
- usbblaster_transfer_schedule()
- usbblaster_transfer_finish()
Plus all the structs that define VIDs/PIDs etc.
I know that's a very rough description, so please don't hesitate to come back with specific questions.
Arnim
Thanks a lot!
I'm almost done now, but I got interrupted...
If I'm lucky, the only part left is to find out where to hook in the bit bang enable call, as the driver seems to not use that at the moment.
(as it's a bare ft245 chip with no aditional logic there's nothing that acks the writes, even less strobes new data available to read...)
Either I figure that out some other day, or someone gives me a hint on where to put the bit bang enabler code.
The ft245 bitbang module seems to work, as the max chip does what I've told it to.
I get mismatch on the first bit on a couple of lines when programming in the svf file, but it seems to work ok anyway.
However, my code is in a terrible shape right now, I guess you don't want to clean up my mess...
I'll be busy next week, but the week after I have vacation, I guess I could fix the code then... I've trashed around in a couple of files to add extra debug info, so svn status looks like this:
M include/urjtag/usbconn/libftdx.h
M src/tap/cable.c
M src/tap/discovery.c
M src/tap/usbconn.c
M src/tap/detect.c
M src/tap/tap.c
? src/tap/cable/ft245bb.c
M src/tap/cable/generic_usbconn.c
M src/tap/cable/generic.c
M src/tap/cable/cmd_xfer.c
M src/tap/usbconn/libftdi.c
M src/tap/Makefile.am
M src/svf/svf.c
Thanks for the help so far!
I don't think I would have the patience to get this far alone... Not in just a couple of days anyway ;)
I looked at the usbblaster driver... :(
The driver I wrote for openwince was based on a byteblaster, just converted to usb-code, as the ft245 chip is just a parallell port.
I can't program a cpld without a jtag interface....
So I guess I'll just rewrite my already written driver to urjtag.
The register length detection did not work in openwince, but after hardcoding register lengths it did get the correct device id anyway.
I'm thinking of a real generic driver, with options for what signal is on what pin so it could be used by any dumb hardware.
Teaser picture: http://mumu21.se/?page=309
Hi Petter,
most people probably build their JTAG cable with a FT2232, because it is faster than FT245 bit-banging by orders of magnitude...
Anyway, there are certainly interested users who want to connect their existing parallel-port adapter via USB-LPT adapter, or happen to have a FT245 available and want to use that for just programming a small CPLD like you do. A driver that takes into account the specific performance pitfalls of USB adapters might at least reduce the pain a little ;)
I second Arnims suggestion to take the skeleton of the usbblaster driver at least for initializing and talking to the FT245.
Some more hints -
1. copy usbblaster.c to ft245bb.c
2. rename all usbblaster_* to ft245bb_*
3. remove all ft245bb_transfer*
4. replace in cable_driver_t
a. ft245bb_transfer by generic_transfer,
b. ft245bb_flush by generic_flush_using_transfer
5. delete all the lines "if (tms==0 && m>=8) in ft245bb_clock_schedule()
... and it should look much friendlier in no time
Kolja
Such configuration should take place in src/tap/usbconn/libftdi.c and libftd2xx.c respectively.
At the moment we have usbconn_ftdi_open() for "normal" FIFO operation and usbconn_ftdi_mpsse_open() for MPSSE mode. Same for usbconn_ftdi_connect() and usbconn_ftdi_mpsse_connect().
I'd suggest that you add a usbconn driver for bit-bang mode in these files that utilizes dedicated connect and open functions for bit-banging. Something like
urj_usbconn_driver_t urj_tap_usbconn_ftdi_bitbang_driver = {
"ftdi-bitbang",
usbconn_ftdi_bitbang_connect,
These drivers (for libftdi and libftd2xx) need to be registered at src/tap/usbconn.c. And you finally need to fill in the urj_usbconn_cable_t constants in your cable driver file accordingly with references to the two low-level interfaces.
Finally!
Besides from chain length detection not working (or taking a horrible long time....) things look nice.
Now I have to find/make an svf file to see if that works...
jtag> detect
IR length: 10
Chain length: 1
Device Id: 00010111000001100100000011011101 (0x00000000170640DD)
Manufacturer: Altera
Part(0): EPM3064A
Stepping: 1
Filename: /usr/local/share/urjtag/altera/epm3064a/epm3064a
jtag> print
No. Manufacturer Part Stepping Instruction Register
------------------------------------------------------------------------------------------------------------------
0 Altera EPM3064A 1 BYPASS BYPASS
jtag> instruction SAMPLE/PRELOAD
jtag> shift ir
jtag> shift dr
jtag> dr
110010001001001001001001001001001001001001001001001001001001001001001001000001001001001001001001001001001001001001001001001001001001001001001001001001000001001001001001001001001001001001010010
I have something that seems to work now, programming a max 3064 in a minute or so.
But, about 5 of the 280 "SDR 360 TDI (...) TDO (...)" lines in my svf file fails, on the first bit, no others.
Could I have trashed the chip? Test a new chip?
Solder up leds and switches to test my 4 bit parity generator?
Perhaps I'm lazy that haven't tested those options yet... But I thought there might be some genious clues out there ;)
(Like "that error there means that xyz is b0rken there...")
I'd suggest to open up an entry in the Enhancement tracker and post your current diff there. That'll allow me and others to look and comment on the code.
Arnim
Sure, but I need to clean it up a bit first.
I made my own version of send buffering in the _clock function, building up a buffer to send with ftdi_write_data if n>1, which improved the RUNTEST times very much, which would take forever if I sent every bit in an own packet. (seconds instead of hours)
I don't know which is the better, to keep my own buffering system or try to go back to the transfer stuff.
I'll try to clean up the code somewhat tomorrow so you can look at it.
And by the way, I've only made the libftdi version so far.
Last time I tried I couldn't get the FTD2xx driver to work on my 64 bit ubuntu, but I guess it wouldn't be very different.
Take any time you need :-)
It's just easier for me to talk about coding details once I see the code. It doesn't have to be the golden version right from the beginning.
I don't have any experience with 64 bit systems and FTD2xx. But in general, the usbconn driver contains the same actions, just implemented with other low-level functions.
Please upload the ft245 bitbang module anywhere or send me it in archive by email.