using ArduinoSPI?

[CDRXavier]

I understand that in order to program the SCR chip we need a USB-SPI converter and in this case, we are using a ftdi with bit-bang SPI to communicate over SPI to the SCR chips.
But what if I do not have a ftdi chip but instead have a USB-SPI programmer like the ArduinoSPI (running off Arduino Due @ 3v3)?

---

Edit:
After going to Zadig and replaced the driver dll I get BlueFlash launching but it did not see the Arduino Due (native port)

[lorf]

But what if I do not have a ftdi chip but instead have a USB-SPI programmer like the ArduinoSPI (running off Arduino Due @ 3v3)?

First of all, CSR SPI bus protocol has a slight deviation from the commonly known SPI protocol, so generic SPI adapters will not work with CSR chips out of the box, although some of adapters can be made to work by firmware or driver modifications (if that is possible).

Then, csr-spi-ftdi is written for FTDI chips only (uses libftdi to talk to adapter), so it will not work with other hardware without modifications.

[CDRXavier]

Well, since I had obtained a cheap ($8) CSR SPI module clone (from somewhere in Shenzhen) I won't have to worry about it in a short time

CSR SPI bus protocol has a slight deviation from the commonly known SPI protocol

I will dig around the source code to see what's the difference. But so far I understand none of it.

Then, csr-spi-ftdi is written for FTDI chips only (uses libftdi to talk to adapter), so it will not work with other hardware without modifications.

I understand that, but I think you might be generous enough to provide a small amount of details.
I also understand that the code you wrote is a custom driver (so the program can talk to the FTDI chip and have it act like a CSR USB-SPI device), while my goal (of using specifically a Arduino with built-in USB capability) is to create a device that can appear to the computer AS a SCR USB-SPI device
But I think I might be able to persuade you to modify it so a user can use a directUSB Arduino (like Leonardo, Zero, Due, Micro, Pro Micro) can use their Arduino and flash the code.
I would happily shell out $10 to see that happen.

[lorf]

CSR SPI bus protocol has a slight deviation from the commonly known SPI protocol

I will dig around the source code to see what's the difference.

The difference is in initialization of the CSR SPI port, relevant code is here: https://github.com/lorf/csr-spi-ftdi/blob/master/spi.c#L267. Also take a look on the other projects source: https://github.com/lorf/csr-spi-ftdi/wiki/RelatedProjects

my goal (of using specifically a Arduino with built-in USB capability) is to create a device that can appear to the computer AS a SCR USB-SPI device

Sounds hard to do. CSR SPI port is pretty dumb, it just does direct reads and writes to the device's memory space and the rest is done by the device's XAP core. So You'll probably need to emulate major parts of XAP core + some peripherials to do that.

But I think I might be able to persuade you to modify it so a user can use a directUSB Arduino (like Leonardo, Zero, Due, Micro, Pro Micro) can use their Arduino and flash the code.

What's your intent? If You want to sniff the communications (e.g. obtain firmware blob) You may have better luck with BlueFlashCmd/csr-spi-ftdi debugging dumps (see https://github.com/lorf/csr-spi-ftdi/blob/master/misc/transport-options.md and https://github.com/lorf/csr-spi-ftdi#options) or instrumenting custom programmer/driver to do the dumps, or using hardware SPI analyzer while talking to the real hardware.

Here's how the firmware flashing works (as I understand): firmware tool on the host uploads a blob of code (program) to the XAP core and runs it (using watchdog to reset the core), this program then talks to the host tool via SPI to receive the firmware blob and writes that to the flash.

I would happily shell out $10 to see that happen.

Sorry, I'm out of time for that.

[CDRXavier]

The difference is in initialization of the CSR SPI port, relevant code is here:
Thank you.

What's your intent?

My intent, is that, if I am to purchase a special programmer for me to be able to program the bluetooth chips (the ftdi or the CSR USB-SPI clones), I might as well chose the latter. Because the delay caused (from order to delivery) is the same (and the clones have a higher chance of success to begin with).
Anyhow, since now that I had obtained the CSR USB-SPI (and managed to do most things I anticipate to do), I do not need to fiddle with big-bang SPI,

Sorry, I'm out of time for that.

In reality, I am out of time for my project (bluetooth mouse/gamepad), too. Especially since being unable to find two keys (some stuff related to bluetooth address) I might end up with a brick anyway. And I need to solder headers because I chopped the "hat" board to solder to the bluetooth module.

Good luck doing your stuff out there.