This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Help understanding SPI on F2802x

Im just starting to investigate communicating between 2 F28027 devices using SPI (in 4-wire mode, with FIFOs).

What is the sequence of events that should occur for the master to read an arbitrary length of 8-bit byte data from the slave? I did look at the SPI reference guide but didn't understand it anywhere near enough!

What I *think* I understand so far is:

- The slave requests communication when it has something to say. I have a GPIO line as a service request (SRQ) line set up with and interrupt on the master for this purpose.

- The master then sets SPISTE, starts outputting the SPICLK and should be made to shift out dummy data on MOSI.

- Then as the dummy data shifts in on the slave, the slave also shifts out the data it wants to transmit, on MISO.

So the questions I have start with, does the master need to continue to transmit dummy bytes for as long as it wishes to receive data bytes from the slave?

And if so how should the master "know" how many bytes the slave wants to send, i.e how many dummy bytes should be transmitted?

Also, how does the TALK bit come into this? should it be set by both devices for the duration of the transfer?

Thanks

  • Toby,

    Your understanding is essentially correct.

    Toby Mole said:
    - The master then sets SPISTE, starts outputting the SPICLK and should be made to shift out dummy data on MOSI.

    SPISTE is handled automatically by the master so you do not need to manually set it.  Not sure if that is what you meant above.

    Toby Mole said:
    So the questions I have start with, does the master need to continue to transmit dummy bytes for as long as it wishes to receive data bytes from the slave?

    Yes.  The master controls the SPICLK.  The master must transmit a byte for every byte it wants to receive from the slave.

    Toby Mole said:
    And if so how should the master "know" how many bytes the slave wants to send, i.e how many dummy bytes should be transmitted?

    You have to craft a higher level communication protocol that you adhere to.  For example, you might take the longest message the slave needs to send and make all messages that length.  Then the master knows to clock in that many bytes.  The slave would simply pad shorter messages with dummy bytes.  Or, you might design a communication packet that leads with a 1 byte message type (i.e., what type of message is coming from the slave), follows with a byte that indicates the number of bytes that follow (which would tell the master how many bytes to clock in), and finally followed by all the payload bytes.  There are other ways to do it as well.  It is up to you.

    Toby Mole said:
    Also, how does the TALK bit come into this? should it be set by both devices for the duration of the transfer?

    The TALK bit is intended for use when interfacing to a device that only has a single bi-directional data pin, or alternately when communicating with multiple slave devices on the same bus.  In your case, you have two F2802x devices on the bus.  You would just leave the TALK bit set for both.
     
    Regards,
    David
  • Hi David

    Thanks for your answer, I have one more question on the SPI though.

    If the master is transmitting and the slave receiving, will I need to also stuff some dummy data into the slave TxFIFOs just the same? or should the master be able to talk without needing the same amount of incoming bytes?

    Ta

  • In SPI slave mode, the C28x SPI will transmit whatever happens to be in the SPIDAT register when the master starts clocking the transaction.  If the slave did not deliberately write something the SPITXBUF prior to the transaction start, then what will be in SPIDAT will be whatever was last received by the SPI.  The last received value was also transfered to SPIRXBUF, but it also remained in SPIDAT.

    Since the master presumably knows to ignor the data it receives from the slave during this transaction, then it really doesn't matter what the slave sends to the master.  Some users might like to have the previously sent value from the master come back to the master on the next transfer.  The master could use it to confirm that the word was sent correctly.

    Regards,

    David