The first point is valid when you are using the SPI block in slave configuration. The second point is valid for master mode. In master mode, the API works as a high level API that writes data/ dummy bytes to the slave, waits for the transfer to get completed and then reads the data from the RX FIFO.
Thanks for responding. Unfortunately, I'm now more confused than before. You say the so-labeled "low-level API" is actually a high-level API? This makes no sense to me.
I've experimented by calling Cy_SCB_SPI_ReadArray() without first calling Cy_SCB_SPI_WriteArrayBlocking(), and no activity occurs on the SPI bus.
Can you tell me how I can use the SPI PDL to send data to a slave device and collect the data returned during that same transaction?
After thorough testing, I can say definitively that the PDL does NOT behave the way you suggested. Calling Cy_SCB_SPI_ReadArray() does nothing but read data from the SPI RX FIFO. It does not write to the TX FIFO. The documentation is, as I suspected, just wrong.
Sorry from our side. You are correct. The second point mentioned in the API documentatin is misleading. I will create internal request to change it.
The Cy_SCB_SPI_ReadArray() just reads the data from the RXFIFO.
Thank you very much for the information. Sorry for the inconvenience too.
Thanks. And don't forget that the documentation for Cy_SCB_SPI_Read() has a similar problem.
That is a good question. I am dealing with a similar issue I believe. When I send a dummy byte I expect the value to be returned to me. In fact I did just that. I kept getting a 0x01. The reason I found, is because Cy_SCB_SPI_Write() returns how many data elements were placed in the TX FIFO.
So I have to do a Cy_SCB_SPI_Read() following the Cy_SCB_SPI_Write().
The Cy_SCB_SPI_Read() further notes:
- This function only reads data available in the RX FIFO. It does not initiate an SPI transfer.
- When in the master mode(which I am in Master Mode), this function writes data into the TX FIFO and waits until the transfer is completed before reading data from the RX FIFO. (WAIT, WHAT... I do not want you to write any thing to the TX FIFO!!! That doesn't make a bit of sense!!!)
So I Cy_SCB_SPI_Write(read register), Cy_SCB_SPI_IsTxComplete(txfifo empty), Cy_SCB_SPI_Write(dummy to push return to rxfifo), val = Cy_SCB_SPI_Read() to get value from RxFIFO, all I ever get is 0x00000000.
So I turn power off to the SPI device I am trying to interface, MAX14830, I do the operations above, I do a Cy_SCB_SPI_GetNumInRxFifo() and it returns a one (1).
- The number of data elements in the RX FIFO. The size of a data element defined by the configured RX data width.
Remember I powered off the MAX14830... So...
- The number of data elements placed in the TX FIFO: 0 or 1.
- When in the master mode, writing data into the TX FIFO starts an SPI transfer.
So I have to assume, the Cy_SCB_SPI_Write() does a SPI transfer shifting 0x00000000 into the RxFIFO (MAX14830 is powered off). I still am trying to figure out why the return value is uint32_t when I designed the SPI SCB as 8bit wide, but that is the least of my worries... As you can probably tell I am sitting beside myself, dazed and confused and lost. And two weeks behind trying to explain to my project designator and project engineer why I cant do something so basic...
Here's what I've learned on the subject.
Cy_SCB_SPI_Write() and its fellows only put data into the TX FIFO. It may or may not have been send over the SPI bus by the time the API function returns. In the case of Cy_SCB_SPI_WriteArrayBlocking(), this is particularly confusing, because the "Blocking" in the name means it blocks until the data have been written into the TX FIFO, not until they have been sent over the SPI bus.
After you call one of the Write() functions, you have to wait for the transaction to complete.
If you're using the high-level API, that event should cause the ISR to be called. If you're using the low-level API, as I am, you'll have to devise some other method to wait for the transaction to complete. In my case, it's simplest just to spin until the number of bytes in the RX FIFO, as reported by Cy_SCB_SPI_GetNumInRxFifo() is the same as the number of bytes I've sent.
Once you know that the SPI transaction is complete, you can call one of the Read() functions to fetch the received data from the RX FIFO.
Another point of confusion (for me) is that the register width of the Serial Communication Block (SCB), and thus the width of the SPI "controller" register, is 32 bits, regardless of the word size that's been configured. That means you read and write a 32-bit value for every word that's sent over the SPI bus. I've configured my word size to 8 bits (by the way, the PDL only support 8 and 16 bits), so for every byte, I (or more properly, the ADC channel) have to write and read a 32-bit word.
I have found the PSoC 6 Architecture Technical Reference Manual to be of considerable help in filling in the gaps in the nominal user documentation.
Hope that helps.
I am going to use the 32bit value to read and write and see what happens. Also, thanks for the tip on TRM. I will let you know what the results are. I had a meeting with a Maxim technician yesterday afternoon. They are sending other SPI devices and a USB-SPI gadget that will enable me to test their Eval Kit for defects as well. However, I feel certain that ive not master how to read and write from tx and rx FiFo's. smh...