This does make some small architectural changes to the pif layer, but I hope it's acceptable.
Assorted notes
Tested working on an MSP430F249
FT232R with known broken clock takes ~40 seconds to program a 4.6k binary
FT4232H takes ~26 seconds
TI's MSP-FET takes 3 seconds
Zadig must be used on Windows to replace the device driver with WinUSB, but this is pretty standard for FTDI bitbang applications
Added some things to the README that tripped me up (libusb 0.1 had me confused for hours because msys provides its own usb.h by default)
I don't even know if my new jtbitbang_set_fast_baud function is required, but the mehfet driver used it and it seemed like it was needed
Further work will be to look into MPSSE for the FT4232H to increase speed more. The mspdebug backend seems inefficient (though reliable), especially since every state change, even those that can reasonably be batched, needs to written out over USB. I tried batching all writes unless TCK or RST was strobed, but it broke device identification - I suspect there's some early step that requires pin toggles to be synchronous.
Programming in general on the MSP430 architecture seems hugely inefficient. Each word takes over 16 bytes of instructions over the wire. I have yet to verify this, but I suspect the MSP-FET might upload a small bit of assembly to locally program data from RAM, then use the auto-incrementing RAM load feature to program the data in chunks.
This does make some small architectural changes to the pif layer, but I hope it's acceptable.
Assorted notes
jtbitbang_set_fast_baud
function is required, but the mehfet driver used it and it seemed like it was neededFurther work will be to look into MPSSE for the FT4232H to increase speed more. The mspdebug backend seems inefficient (though reliable), especially since every state change, even those that can reasonably be batched, needs to written out over USB. I tried batching all writes unless TCK or RST was strobed, but it broke device identification - I suspect there's some early step that requires pin toggles to be synchronous.
Programming in general on the MSP430 architecture seems hugely inefficient. Each word takes over 16 bytes of instructions over the wire. I have yet to verify this, but I suspect the MSP-FET might upload a small bit of assembly to locally program data from RAM, then use the auto-incrementing RAM load feature to program the data in chunks.