• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 1821 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430Ware confusion

David Pfaltzgraff
Expert 2425 points
Other Parts Discussed in Thread: MSP430WARE, MSP430F4616, MSP430F5438A, MSP430G2001

I'm usinf CCS5.1 to develop code for an MSP430F4616. Since I'm familiar with the StellarisWare package, I was hoping to use the MSP430Ware driver library. However, I see things like MSP430Ware supports "ALL MSP430 devices" followed by the statement that "MSP430 Driver Library supports 5 and 6 series devices." Which is correct?

Is there a way to use the MSP430 driver library for the MSP430F4616? AT first glance it looksas though I should be OK, but I don't want to be barking up the wring tree!

What lead me to the E2E forum is the question: For the MSP430F4616 where is something like __MSP430_BASEADDRESS_PORT1_R__ defined?

Thanks

 

  • 0
    TI__Expert 6140 points

    Hi David,

    I believe the confussion arises from the fact that MSP430Ware is not the same as MSP430 Driver Library. MSP430Ware is a collection of code examples, datasheets and other design resources for ALL MSP430 devices delivered in a convenient package. Thus, MSP430Ware has support (code examples, datasheets, etc) for all MSP430 devices. MSP430 Driver Library is a component of MSP430Ware, which is a high-level API call library, and only supports 5 and 6 series devices. Therefore, Driver Library cannot be implemented to develop for the MSP430F4616 and you will see errors like the one you posted if you try to do so.

    I hope this clarification is clear. Please let me know if this is not the case.

     

    Regards,

    Damian  

  • 0 in reply to Damian Szmulewicz
    Expert 2425 points

    Well, sort of... Coming from a background of using the StellarisWare library, I was hoping to find similar support.

    At least I know not to go there now.

    Thanks

     

  • 0 in reply to David Pfaltzgraff
    Guru 227245 points

    David Pfaltzgraff said:
    Coming from a background of using the StellarisWare library, I was hoping to find similar support.

    Well, the StellarisWare exists much, much longer than the MSP430 driver library. So when compiling the available sources for MSP430Ware, the current state of the driver library was included, and it only supports 5x/6x family so far. But perhaps will support other devices in future.

  • 0 in reply to Jens-Michael Gross
    Genius 3770 points

    Jens-Michael Gross said:
    Well, the StellarisWare exists much, much longer than the MSP430 driver library. So when compiling the available sources for MSP430Ware, the current state of the driver library was included, and it only supports 5x/6x family so far. But perhaps will support other devices in future.

    The Stellaris family is also much more homogeneous capability-wise; in contrast to the MSP430 which has models from only 0.5kb flash like the MSP430G2001 to monsters like the MSP430F5438a which has a whopping 256kb of flash, 512 times more than the G2001.

    It also seems to be a trend among Cortex-Mx vendors to offer highly abstracted peripherals libraries; perhaps it's a result from ARM pushing for CMSIS.

    Tony

  • 0 in reply to TonyKao
    Prodigy 40 points

    I too, wish that the Driver Library had broad support across the MSP430 line. Abstracting the lower level details is useful, but why bother if support is limited to one branch of the line? If you decide to use a different variant, then your back to bit-level stuff, so you might as well learn that from the start. But who wants to spend their time at the bit and register level - especially if you need to work with several microcontrollers, all with their quirks? You need higher-level abstraction to keep from going bit buggy! I've used the CMSIS library and think it's worthwhile (except for the lack of readable, API documentation).

  • 0 in reply to David Craig
    Guru 227245 points

    David Craig said:
    Abstracting the lower level details is useful, but why bother if support is limited to one branch of the line?

    Mostly because the important peripherals vary across families. And with them the capabilities. A generic API that is used the same for all families would include much software simulation of features not availble in one family or with one peripheral built with a different variant.
    Much unneeded code that blows up code size on MSPs with small flash and smaller ram already.
    (Like DirectX on PC: hundreds of megabytes of library code to implement all features available on one 3D card but not on another, so applciaitons can use these features whether there is hardware support or not)

    Still some things are easier if you can use specific functions that take care of details. Even if you still have to use different functions on different MSPs.

    I build my own DriverLibrary for things I need (e.g. UART, I2C etc.) and I know how difficult it is to provide a generic API that works on different processors and doesn't need changes on high-level code when ported. Even if it are just four different processors in my case (but one of them not being an MSP at all).

**Attention** This is a public forum