• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 388 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 Confirmation

Jonthornham
Expert 1490 points


I am working with SPI for the first time.  I am using the USCI and have a few questions.

1.  Does having the RXIE interrupt called mean that SPI is working?

2.  I am trying to write to an eeprom at address 0 and then read from that location and display it on an LCD.  Does the MSP430 allow for number's like "81" to be used for TXBUF?

3.  Is the value sent to RXBUF from the read able to be store in an "int"?  For example, if I write "81" to address "0" and then read from address "0" does RXBUF give me an "81" if I do the following?

        int dataRead;

        dataRead = UCA0RXBUF;

Thanks for any advice.

Take care,

Jon

  • 0
    Expert 1610 points

    Hi,

    1. At least, this indicates that there is a response from the EEPROM, always you are sure the pin configuration is the correct one. The best way to verify it, it is sending to the EEPROM something you know the response from the EEPROM (reading UCA0RXBUF)  or checking the line on an oscilloscope.

    2. TXBUF has a 8 bit size. If the number you will send it is smaller or equal to there is not problem. If the number is higher than 8 bits, you will have to part it. For example:

    If you want to send a 81d = 0x51m TXBUF = 0x51

    If you want to send 530d = 0x0212, you first will be sent TXBUF = 0x02 and later TXBUF = 0x12

    3. There is no problem, int has a 16 bits size(in this uC), since is higher than 8 bit(size of TXBUF), there are not problems on storage.

  • 0 in reply to Is T da S
    Expert 1490 points

    T da S,

    Thanks for the response.  If I may ask another question or two?

    1.  Is it a bad idea to test with an LCD when using SPI?  

    2.  Is something like an osciloscope or logic analyzer the best way to understand what is happening?  

    3.  Is there a good way to read UCA0RXBUF that I am missing?  Reading the registers has been giving me trouble.

    Take care,

    Jon

  • 0 in reply to Jonthornham
    Expert 1610 points

    Hi,

    1. If you are very very sure that you understand how the LCD functions works and how to use it, and it is reliable, use it. But if you are new in this, I recommend you "divide and conquer", that is to say, firstly, understand SPI protocol and after that test that only  SPI communication works correctly. When you area master of  SPI communication :), try to test with LCD.

    If you do all at the same time, maybe the SPI works, but for some silly error it does not print on LCD and you will think that SPI does not work. Try to modularize all you can.

    2. If you know how SPI lines work, an oscilloscope is the best way to test that there is communication, but as I said previously, you have to know how SPI works and what the peripheral give back to uC according to the message sent to it.

    3. That is the first thing you have to dominate, the storage of transmitted/received bytes. First of all, ensure that you receive/send correctly at least one byte. Next step, you could implement a ring buffer that store/send the bytes.

  • 0 in reply to Is T da S
    Expert 1490 points

    Great advice.  I will make sure I understand SPI first and then move on.  I picked up a logic analyzer today to help with visualization.  I appreciate your time.  

    Take care,

    Jon

  • 0
    Guru 227245 points

    Jonthornham said:
    1.  Does having the RXIE interrupt called mean that SPI is working?

    Not necessarily. It means that the USCI hardware has put 8 bits (and clock pulses) to its output signal line and shifted 8 bits in from its input signal line. It does not mean that the data ever left the MSP (wrong port configuration) or the slave responded 8if not, the USCI would read 0xff and not notice whether this was intentional data or an open input line).

    At least the USCI is running, ahs a clock and has at least tried to send (and at the same time receive) something.

    SPI is quite simple. No checksum, no acknowledge, no parity, just straight and fast.

    Jonthornham said:
      int dataRead;
            dataRead = UCA0RXBUF;

    When assigning an 8 bit unsigned char (RXBUF) to a larger type like a signed int (15+1 bit), the compiler will automatically do the proper typecasting. However, in the opposite direction, the compiler will warn you that this implicit conversion might lose some significant digits (the upper 7+1 bits). you can force it to do without complaint by doing an explicit typecast, if you know for sure that only the lower 8 bits are used in the INT.

  • 0 in reply to Jens-Michael Gross
    Expert 1490 points

    Thanks Jens-Michael.  That makes perfect sense.  

    Take care,

    Jon

**Attention** This is a public forum