We are using CYBLE-222014-01. Does it support multiple slaves in the SPI bus?
Welcome in the forum.
multiple slaves in the SPI bus Not out-of-the-box.
I would suggest you to configure your SPI with no (0) ss-lines. This requires handling of the ss-pins yourself as: setting the required ss-line low before a transaction and setting back high again after transaction has finished.
Configure the ss-lines as: No hardware connection, strong drive, initially high.
Thanks Bob. We are able to use standard GPIO lines as SS and handling them ourselves to get the SPI communication working.
We have one other issue - We have two SPI slave devices, one that uses SPI settings CPHA=1, CPOL=1 and other that uses CPHA=1, CPOL=0. With a single SPI block, in PSoC creator, I have tried to configure these settings separately through UI and able to communicate with the SPI slaves, one at a time. However, when one slave works, the other does not because of the difference in the SCLK Mode settings.
Is there a way to switch between the modes( configure CPHA and CPOL) through the software APIs so that I can get both the slaves running simulataneously?
You can do that, but it is a bit (or byte?) complicated.
You can use an "Unconfigured SCB" and configure it as SPI interface as your usual requirements are. Have a look into the datasheet. To ease the programming it might work to copy the initialization structure and just modify the differences.
Using SCB_SpiInit() we are able to interface with multiple slaves (NOR flash and accelerometer) on the same SBI bus. However, we are facing one issue - That is, while the NOR flash is being written to (using SPI), if there is an interrupt and we try reading the accelerometer data inside the ISR and try to reconfigure the SPI to match the Flash configuration at the end of ISR, we see that the device is not able to resume flash operations normally. That is, if an SPI operation is interrupted, then any attempt to reconfigure the SPI bus is causing the device to hang. Is there some specific steps that need to be taken to reconfigure the SPI from within the ISR?
A SPI transaction cannot be interrupted by another SPI transaction.
Because the transaction may take a reasonable time you should avoid running it from within an interrupt handler. Instead you should set a (volatile!) flag which you test from time to time (main loop) and, when set, start and complete a transaction. So you can serialize the access to the SPI bus.
Thanks Bob for the reply. We have a requirement that the accelerometer data be read every 2ms.(A GPIO interrupt occurs at this interval) and this data needs to be stored in the NOR flash. To do so, I had infact done what you have suggested - That is, had a volatile flag in ISR and read the accelerometer data in the main loop when this flag was set and then reconfigured the SPI for the flash to store this data. This approach works but has an issue - That is, writing to the NOR flash takes significant time (>2ms) and so while this was being done the accelerometer data is lost.
In an attempt to prevent this data loss, I moved the accelerometer data read inside the GPIO ISR. However, as I mentioned before, there is some issue when the flash write is interrupted and the accelerometer data is read in the ISR. The control never comes back to the main loop but instead it appears that the Flash write never successfully resumes after interruption.
Could you suggest if there is some way in which we can meet our requirement by having the SPI slaves on the same bus? Or do we have to use different SPI lines?
Thanks in advance.
"accelerometer data be read every 2ms." and "writing to the NOR flash takes significant time (>2ms)" will not go together. If I am understanding that right, your data writing does not conquer the amount of data read. Using two separate SPI busses will only work when the above problem is solved (buffering, sample time restrictions etc).
Thanks Bob for the reply.
What I meant was the following - The external flash has a command "SectorErase" that erases one sector of the flash. From the datasheet, it says that this operation takes 50ms. That is, once the SectorErase command is issued through SPI, it takes about this much time for it to complete. So it is obvious that there will be interrupts during this period. Currently, if inside the ISR, if I do not do any operation related to the SPI (that is, if I don't read the accelerometer or I don't re-iniitialize the SPI), then there is no issue and the Sector Erase succeeds. The problem occurs only when there is an attempt to do certain activity on the SPI bus inside the ISR. This is where the Sector Erase operation is not able to resume.
So I feel that if they are on different SPI lines, then inside the ISR there will not be any activity related to the Flash SPI.(though there may be some on the accelerometer SPI) and I guess it should work fine right?
However, we have a constraint on the number of pins and hence we are looking for solutions where a SPI lines can be shared? Is there a way we can achieve this?
No chance to "share" SPI lines. I even do not know if it would be possible using bi-directional mode which would save you one line.
By sharing I meant the current situation where both accelerometer and flash use the same MOSI, MISO and the SCLK lines.
Do you think in this configuration, it is possible to achieve our requirement or do we need to use different lines?