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.

RTOS/MSP430FR5969: Really noob question

Part Number: MSP430FR5969
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

I have written a firmware with just the driverlib for MSP430FR5969. The complexity is getting out of hand and I started thinking about writing a task scheduler.. You can probably see where this is going, no need to reinvent the wheel when someone already provides free-of-charge RTOS with threading, memory protection and the like.

Now the question I have is, how painful it's to move from directly using DMA channels, Timers and interrupts to the hardware abstraction model of RTOS? To start with, I couldn't find documentation on what resources RTOS uses and/or how to configure which DMA channels are used for example. Using the same DMA channel for my ADC that the SPI driver is using probably ends in tears. 

  • Hi Olli,

    I'd recommend you port your application into a RTOS project (e.g. drivers/empty) piece by piece. This is the short version of what's in the Getting Started Guide (see it you are using IAR). First get TI-RTOS for MSP43x, install it into c:\ti and then start CCS to let it be discovered. Import the drivers/empty project for the 5969 LaunchPad (we support that one out of the box). I'd pick the "standard" empty, not empty_min, because you'll need the debug features for new development. Later you can compare the empty_min.cfg vs empty.cfg (TI-RTOS configuration file) to optimize for speed and space. You'll what to catch stack overflows, etc. while you are doing development!

    Once you confirm empty works for you (it just flashes an LED, but has most of the kernel already present, so don't let the size scare you since it is an initial fixed cost and all the debug features are enabled), you can move pieces of your application over. The kernel manages the vector table, so if you create an ISR, change it to Hwi_create (or Hwi_construct). The kernel also be default manages a single timer used for timing things (e.g. Task_sleep). You can plug in ti/sysbios/knl/Clock functions that will be called at the interval you request (you can look at the sysbios/clock example as a reference). If the interval of the default timer is not good for you, it's configurable or your can create your own ti/sysbios/hal/Timer instance.

    Functional drivers are supplied (UART, I2C, etc.). We have examples for each one and can look at the doxygen documentation for more details. You need to take a look at this to see if they have the features you need. If not, you can still use your drivers, but be aware that you'll need to change the interrupt creation/handling (e.g. don't use the keyword "interrupt").

    The kernel also can manage exception handling.

    We are working on specific training/white paper for this now. I'd be interested in getting your feedback and potentially sharing some of the early (and rough) drafts. Please feel free to "friend" me and we can talk about this off-line.

    Todd

  • I've got actually a true embedded system using the MSP430FR5969. So 1st order of business would likely be to create a "board" file. In my firmware I'm manually setting up ports in the setup routines. I presume with SYSBIOS this would be handled by the board file. In any case I have some fairly urgent things to get done before I can think of porting the firmware. Of course fixing interrupt -based SPI state machine is bit wasted effort but it's another thing that needed to be done last week if not earlier.
  • Can we close this thread out?

    Todd