mon
commented
1 year ago As an extra note - I have an alternate branch, ftdi-bitbang-dev that implements all of the above optimisations.
- Writes are batched, and reads are only performed when necessary
- Programming code gets pushed to the device to greatly improve speed and remove 350KHz flash clock requirement
- The D2XX driver installed by windows update is attempted to be loaded and used if available (Zadig no longer required, still GPL compatible)
With these changes, programming time is on the order of 2 seconds. However, I'm not making a PR for it
- It's only tested on the devices I use (MSP430F24[7|9|10])
- It assumes you have a crystal installed for generating the flash clock on-chip
- It probably doesn't work for MSP430X
This does make some small architectural changes to the pif layer, but I hope it's acceptable.
Assorted notes
jtbitbang_set_fast_baudfunction 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.