• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Microcontrollers » MSP430™ Microcontrollers » MSP430 Ultra-Low Power 16-bit Microcontroller Forum » SPI polling and programming in MSP430
Share
MSP430™ Microcontrollers
  • Forum
  • Announcements
  • E2E Wiki
Options
  • Subscribe via RSS
MSP430 Resources
  • MSP430 Product Folder
  • MSP-EXP430G2 - MSP430 LaunchPad Value Line Development kit
  • MSP430 Getting Started Guide
  • MSP430 Microcontroller Projects
  • More Resources >
  • Forums

    SPI polling and programming in MSP430

    This question is answered
    Chaithra Bharadwaj
    Posted by Chaithra Bharadwaj
    on May 11 2012 12:15 PM
    Prodigy130 points

    Hi All,

    I want to write an SPI master code. Using MSP430F5309, I have to transmit and receive data.

    I checked the example codes of for MSP430F5309. None of them includes polling method. I want a code which polls the status bit in SPI register and trasmits data serially. 

    If anybody has done that before, please share me the code.  I have a question by the way. Can the data be seen on the MISO/MOSI pins of SPI if the lines are un-connected. I am testing with an eval board and using CCS V5. In the debug mode, it has an option to load the program to the flash. My question is, if I program the flash and exit the debugger mode, will the program run or should I use debugging option to run the program. 

    I just want to run my program on the eval board, just by programming it. Can I run it with the debugger connected or should I use external power supply.? 

    Since I am new to MSP430 and TI, I am asking these dumb questions. 

    Please help me regarding this.

    MSP430 SPI program
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    All Replies
    • TonyKao
      Posted by TonyKao
      on May 11 2012 21:34 PM
      Verified Answer
      Verified by Chaithra Bharadwaj
      Genius3770 points

      Chaithra Bharadwaj

      I checked the example codes of for MSP430F5309. None of them includes polling method.

      Unless you have a Very Good Reason to use the polling method, it's best to follow what the TI example code does, which is using interrupts to handle the SPI communication. This allows you to put the MSP430 to sleep when it's not receiving or transmitting, so that it does not waste cycles and power. The sleep-interrupt method is the preferred programming model for the MSP430, see http://www.ti.com/litv/pdf/slaa294a

      On your second question, once you flashed the device you can either run the code within debug mode, or you can exit debug mode and hardware reset the device (using the RST button).

      And yes, the eval board is designed to be used with the debugger connected. However you can also provide your own power source if you wish. Just make sure the board and the debugger have shared ground in that case.

      Tony

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Chaithra Bharadwaj
      Posted by Chaithra Bharadwaj
      on May 13 2012 01:02 AM
      Prodigy130 points

      Thanks Tony,

      Since I was using interrupts for other peripherals, I chose to use polling method for SPI. And yes, it worked with the eval board after programming . 

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    • Jens-Michael Gross
      Posted by Jens-Michael Gross
      on May 15 2012 09:43 AM
      Guru140650 points

      Chaithra Bharadwaj
      None of them includes polling method

      Polling is basically the same as unsing interrupts. The two differences are: the RXIE/TXIE bits mus tnot be set and the software needs to check/wait for TXIFG or RXIFG bits being set before writing to TXBUF or reading from RXBUF.

      Keep in mind that

      • for receiving a byte you have to send a byte
      • TXIFG is set when TXBUF is empty, and not when the last byte written to TXBUF has been sent. When TXIFG gets set, the former content of TXBUF has just moved to the output shift register and hasn't been sent yet.
      • a byte receive is complete when a byte write is complete. So in conjunction with the TXBUF double-buffering, this means you'll get the first byte shortly before TXBUF is ready for the third byte.

      _____________________________________
      Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.
      If you cannot discuss your problem in the public, feel free to start a private conversation: click on my name and then 'start conversation'. But please do so only if you really cannot do it in a public thread, as I usually read all threads. And I prefer to answer where others can profit from it (or contribute to it) too.

      Report Abuse
      • Reply
      You have posted to a forum that requires a moderator to approve posts before they are publicly available.
    TI E2E™ Community
    • Support Forums
    • Blogs
    • Videos
    • Groups
    • Site Support & Feedback
    • Settings
    TI E2E™ Community Groups
    • TI University Program
    • Make the Switch
    • Microcontroller Projects
    • Motor Drive & Control
    Other Communities
    • Deyisupport
    • Designsomething.org
    • beagleboard.org
    • TI on Element 14
    • TI on TechXchangeSM
    Other Technical & Support Resources
    • WEBENCH® Design Center
    • Product Information Centers
    • Technical Documents
    • TI Design Network
    • TI Technical Articles
    • TI Training

    All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

    Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

    Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
    TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

    TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
    embedded processors, along with software, tools and the industry’s largest sales/support staff.

    © Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
    Trademarks | Privacy Policy | Terms of Use