I'm working with a module that requires me to keep the CS pin active during the whole transmission process that consists of sending a few commands in order to do one task. The module is NRF24L01.
For example, if I want to write data to a register, I have to bring CS pin low, send a write-to-register command with the register's address, send another byte of data with the values I want to put in that particular register, and then bring the CS pin high. I assume that this can be simply done with the SCB_SpiUartPutArray(const uint16/uint8 wrBuf, uint32 count) command.
However, when I want to read data from a register, I have to bring the CS pin low, send a read-from-register command with the register's address, send dummy byte(s), receive data, and then bring the CS pin high. I probably don't understand SPI communication good enough, but I'd like to know how I'm supposed to do such operation.
With the CS pin active, the NRF module sends data back after receiving commands* etc., so I'm assuming I simply have to use the aforementioned SCB_SpiUartPutArray function to send the command and dummy bytes, and the data received will be already waiting in the RX FIFO to be read out using SCB_SpiUartReadRxData() command.
Is this the correct way it works? Please, correct me if I'm wrong, and thanks in advance.
* Actually it sends data back after every command. It ALWAYS sends back the STATUS register.
Youtube has a number of video trainings on SPI.
If you are going to work with serial busses a logic analyer very useful.
This is just one of many using Saleae (free software for download) and
Yes, its exactly as you describe. SPI has no specific 'read' function. Its always the master writing and the slave answering - its just that some bytes might be dummy content. Use the SPIBusIsBusy() function to wait for the end of the SPI transfer.
One caveat though: when you are using a buffer larger than 8 bytes, its handled by software. If then the SPI clock is fast enough, sending data out might be faster than the ISR can deliver new data, and the SELECT signal goes high again inbetween the bytes. (might even happen with the hardware buffer when data cannot be put fast enough into the TX FIFO)