It says:
SPI
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?)
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?
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
/* executes once at startup */
void setup() {
Serial.begin(9600);
for (int i = 0; i < sizeof(tx_buffer); i++)
tx_buffer[i] = (uint8_t)i;
SPI.onSelect(onSelect);
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.
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.
Tested at 1MHz and 15MHz. There are on-device integration tests as well: