• State
  • Locked Locked
  • Replies 15 replies
  • Subscribers 81 subscribers
  • Views 3121 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SPI slave transmit buffer best practice

ECH12
Expert 1195 points
Other Parts Discussed in Thread: MSP430F2013

Hi,

I am not sure that I will be able to prepare the returned value to an SPI master. This is becuase I need to decode the address and get the data and I have only one SPI  clock to do it. There are two solutions which I currently see:

1. Use lower SPI rate - Although it will work it has draw back as the power consumption increases (more time to transfer data) and it will force slowing the master (not sure how critical it is).

2. Transmit 1's until data is ready than transmit one 0 byte and than the data. This way I can use any data rate supported by the master / slave. It will require the master to know when the first byte of data is transmitted (not so complicated ofcourse).

Are there any other solutions?

Thx

  • 0
    Guru 316690 points

    3. Use an SPI slave that has hardware support for reading from registers. (This is usually not possible in microprocessors.)

    4. Use a separate signal line to tell the master when the slave is read to provide the data.

    5. Use I²C (with clock stretching).

    And why do you think that slower speed would increase power consumption? As long as the code on the master is not using polling but interrupts, this should not make any difference.

  • 0
    Guru 46710 points
    >1. Use lower SPI rate
    No need to lower SPI rate. SPI clock stops if master does not send any data. It leads to simple solution - after address (8 bits or 16 bits or whatever bits) transmission, master must pause for some time which is enough for slave to prepare data.

    >2. Transmit 1's until data is ready than transmit one 0 byte and than the data.
    No, no, no.
  • 0 in reply to Clemens Ladisch
    Expert 1195 points
    Hi,

    3. I use MSP430F2013. I cannot add another hardware as you mentioned.

    4. Agree, but it is more "complicated" and requires extra GPIO.

    5. Agree but in my case the bus is SPI and I don't want to add I2C to the picture.

    Regarding power, lets assume that I want to read 10 bytes from the slave. Master sends address and than starts polling for data. If we use slower rate, the rate will be for all data bytes and address. If we use high rate, the overall time of data transfer will be much smaller, even if we assume that we will use some "null" bytes until data is ready. This is why I assume it will take less power.
  • 0 in reply to Ilmars
    Expert 1195 points
    Can you please explain why you don't consider 2 as an option?

    Regarding your first option, it means that I need to know at master side how much time to wait. Wouldn't it be better to synchronize the master and the slave with something like a sync byte (option 2)? This means that I am tolerant in the master side for changes in the slave side.
  • 0 in reply to ECH12
    Guru 316690 points

    Why don't you want to use I²C? Are there other devices on the same bus?

  • 0 in reply to Clemens Ladisch
    Expert 1195 points
    Yes. I already have few other slave devices. Adding I2C is not an option. The MSP430 is the only slave which is a CPU slave.
  • 0 in reply to ECH12
    Guru 46710 points

    >Wouldn't it be better to synchronize the master and the slave with something like a sync byte (option 2)?
    In most (data access) cases fixed delay after address transmission is all what's needed, however you can do as you wish.

    Usually SPI slaves which have some kind of processing that takes time, have status register which shows state of the slave (idle/busy/done). Then "protocol" is like this: master initiates processing by sending specific command, after that it shall more or less continuously read status register bits waiting till slave asserts "done" bit. After that master reads data (result of processing) with "data readout" command.

    >This means that I am tolerant in the master side for changes in the slave side.
    Do you _really_ expect significant slave timing changes in the future?

    p.s. Often engineers tend to implement too much flexibility into _closed_ systems which actually are completely under their control.

  • 0 in reply to Ilmars
    Expert 1195 points
    > you can do as you wis

    I wish I can do what ever I wish :-)

    When you say "read status register", do you mean extra pins between the master and the slave? If that the case, I don't have them :-(

    Does the MSP430F2013 has this type of support?
  • 0 in reply to Ilmars
    Guru 16361 points

    Ilmars said:
    SPI clock stops if master does not send any data. It leads to simple solution - after address (8 bits or 16 bits or whatever bits) transmission, master must pause for some time which is enough for slave to prepare data.

    Yes This method is commonly used for SPI slaves such as LCD controllers. The documentation specifies minimum delay times (in μs or sometimes ms) after each command before the next SPI transmission can begin.

    A similar technique (used on some SPI flash memories) is to say that the master must transmit a specified number of dummy bytes before the slave will send its response. That defines the delay in terms of the SPI clock, but it also requires the SPI bus stay active during the delay.

  • 0 in reply to Robert Cowsill
    Expert 1195 points
    I just wonder why pausing or waiting pre-defined time is better than using sync word. With sync word you don't need to apply any restrictions. are there other reasons why not to select this approach?
  • 0 in reply to ECH12
    Guru 16361 points

    ECH12 said:

    Usually SPI slaves which have some kind of processing that takes time, have status register which shows state of the slave (idle/busy/done). Then "protocol" is like this: master initiates processing by sending specific command, after that it shall more or less continuously read status register bits waiting till slave asserts "done" bit. After that master reads data (result of processing) with "data readout" command.


    When you say "read status register", do you mean extra pins between the master and the slave? If that the case, I don't have them :-(
    [/quote]

    No, the read status register is a command sent through the SPI bus which the slave is able to respond to immediately. You'd have one command that kicks off the operation which takes a long time, another to "read status" , allowing the master to check whether the slave is done processing and then a third command to get the results of the long operation (which would be then ready for immediate transmission).

  • 0 in reply to Robert Cowsill
    Expert 1195 points
    I see,

    If I expect that the slave needs "long time" to process the request than I understand this approach. Should I use this approach also if the slave can respond very quickly, but not fast enough for the first byte?

    Thx
  • 0 in reply to ECH12
    Guru 46710 points
    >When you say "read status register", do you mean extra pins between the master and the slave?
    I did not mean pins but SPI data which is sent as an asnwer to "read status register" command.

    >Does the MSP430F2013 has this type of support?
    Yes. You can implement this type of support in software
  • 0 in reply to ECH12
    Guru 16361 points

    ECH12 said:
    If I expect that the slave needs "long time" to process the request than I understand this approach. Should I use this approach also if the slave can respond very quickly, but not fast enough for the first byte?

    In that case the "master must transmit N dummy byte(s) before response" approach is quite common.

  • 0 in reply to ECH12
    Guru 46710 points
    >Should I use this approach also if the slave can respond very quickly, but not fast enough for the first byte?
    No. Use simple delay on master side instead.

**Attention** This is a public forum