Photon: Can the Photon be used as a SPI slave with the existing firmware primitives?


Can the Photon be used as a SPI slave with the existing firmware primitives?

On this page:

It says:
This library allows you to communicate with SPI devices, with the Core/Photon as the master device.

I have taken a look at the code in the repository branch - it appears the code is in a Broadcom (actually ST but Broadcom lib does have some SPI source as well) library (I haven’t used a lib tool yet to find out for sure) - but can the code be modified to convert the Photon to a SPI slave? (Assuming this isn’t already done or posted someplace I haven’t found yet. - But if that was the case you’d think there would be mention of that on the above referenced page.)

Can we get the source to all of the .a lib (archive) files? (If anything is different from the WICED or libs such as STM32F4xx_DSP_StdPeriph_Lib_V1.5.1?)


@mdma, @peekay123, any thoughts?

Hello Again,

Since the source is there and the hardware is capable; we can roll our own driver - but, will Particle officially support this option in the foreseeable future?


This could be a useful PR (pull request) :+1:

Thanks - I agree (I think).

Any follow up on this?
I’m currently trying to use my photon as SPI slave and could really benefit from any advances you might have made.


Yes - what is the current status on this request?

John W.

Had you filed a pull request back then?

There’s a PR here for SPI slave support. For those building locally, we’d love you to test and give feedback!

Is this officially part of the latest firmware? What was the feedback on it? Does it actually work?

Just have a look here and the respective links inside it
Particle Firmware Updates Thread

Yes it works :slight_smile: Tested at 1MHz and 15MHz. There are on-device integration tests as well:

Be sure to get your wiring correct before you power up!

1 Like

It almost works at 60 MHz even! I’ve been transmitting 1000 64-byte blocks per second and I’m getting some errors, flipped bits and bit shift; trying to decide whether it makes sense to error detect or slow it down. Also, I’m using two prototype boards and 4” wires between them, which surely doesn’t help.
successCount=4361134 failureCount=1512 tooFastCount=0


Thank you very much. This is cool :slight_smile:

I am curious about this in the SPI example code:

/* executes once at startup */
void setup() {
    for (int i = 0; i < sizeof(tx_buffer); i++)
      tx_buffer[i] = (uint8_t)i;
    SPI.begin(SPI_MODE_SLAVE, A2);

Why is Serial.begin(9600) there?
And, in the section regarding the SPI clock - in slave mode the master drives the clock - in the explanation on the SPI page that isn’t clear; in fact I would say it is confusing. Since SPI is a serially clocked bus; and if the master is clocking - the SPI slave just needs to be able to detect the SPI clk - and has nothing to do with driving the SPI clk.


Also - is there any photon example code showing the spi slave setup; remaining connected to WiFi, and posting data to the cloud (all in the same app)?

I upgraded to 0.5.1 and managed to almost brick my photons. Nice.

The Serial.begin(9600) call has nothing to do with the SPI itself. It’s just there because the part of the sample code in loop() prints something to the serial debug console, and you need to call Serial.begin to initialize it first.

I looked at the documentation and I see what you mean. There is no clear description of the SPI pin interactions described for master and slave modes. In slave mode, the photon CLK and CS pins are an inputs whereas in master mode, they are outputs.

I also noticed that the slave example will starve the system firmware since neither SYSTEM_MODE(MANUAL) or SYSTEM_THREAD(ENABLED) is indicated nor is Particle.process() called in the while(1) loop of the example. This should be fixed IMO.

Agreed. For those that could be novices on this subject; the vagueness with which those instructions were written would and can cause a lot of confusion.

As it is - I hooked up my serial bus analyzer to verify which SPI Mode I was communicating in - as well as making sure SPI CS was behaving properly. The instructions do not give you the confidence one would need to write those routines without the use of an analyzer.

Things such as default SPI Modes should be clearly called out - that isn’t clear to me either.


In slave mode - I can only seem to get this to work:


Have you guys fully tested MSBFIRST? Just wondering.

If you have - can you please post an example with your COMPLETE set-up in slave mode? Including setting (default) mode, etc?

For my master microcontroller; I have stepped through all modes, and MSBFIRST and LSBFIRST - I was only able to get anything to work with LSBFIRST.

John W.