• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 494 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.

Getting Started - Advice Needed - To RTOS or Not To RTOS ?

Clark Leach
Intellectual 740 points
Other Parts Discussed in Thread: EK-TM4C123GXL

I am about to undertake a a new project and have decided to have a go with the EK-TM4C123GXL Launchpad as a starting point for hardware prototyping.  I could use some advice regarding whether or not I should consider using the TI-RTOS as a foundation for firmware development.  Maybe some of you more experienced TI developers could help me decide if RTOS will make life easier or more difficult in terms of implementing my application.  A basic description of the application follows:

1.  This is a process control application with no need for high-speed data acquisition or control.  The process is slow - updating inputs and outputs at once/second has been working fairly well using 8-bit PIC micros.

2.  LIN bus master - this device will use a LIN bus as the interface to I/O modules for data acquisition and control output.

3. Modbus master - this device will use Modbus to control other devices involved in the same process (variable speed drives, primarily, to run pumps,etc.)

4. Eventually, I would like to eliminate the variable speed drives and control the pump motors more "directly".

5. Communications "backbone" connection - I would like to have several options available, preferably via plug-in modules, to connect the device to a controller network.  Initially this will be done via Zigbee using the Anaren A2530 module.  I would like to make other options available via SPI, UART, or USB.

So.... given this information, would you advise me to use an RTOS or take a more "bare-metal" approach?

All input and feedback is welcome.

Thanks.

  • 0
    TI__Guru**** 244400 points

    Hello Clark,

    In this case since you mentioned that the system is a slow with no high speed data acquisition, I may want you to elaborate "slow"when making a decision on the final implementation. When the update has to be made, what sort of response time are we talking here:That if an update needs to be done does it have the entirety of 1 sec or has to be done in in few 10's/100's of us.

    I would try to be as neutral as possible when it comes to bare-metal or RTOS approach. The RTOS approach allows you to get rid of a lot of nuances of coding basic things, is flexible when moving from one product family to another and is well suited when developing app based embedded software. However a bare-metal approach gives a lot of leverage in terms of memory footprint availability, responding faster to events and is a better learning experience.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 47900 points

    Bravo for the detail you provided - and for "asking" before "charging forward."

    Vendor's Amit provides sound insight & guidance.

    I'd suggest that you follow advice our small tech group received, (i.e. Start w/bare metal (MCU alone) - get that to perform - and log key performance data.  That provides a nice, "baseline" for you. 

    Later - (if time/energy/desire still allow) patch in the RTOS gradually - and see how it compares against MCU alone.  We found this to be the best means to (fully/properly) answer your question - and may even enable the comparison of different RTOS implementations.

    Lastly - many make ARM MCUs - and there are many RTOS from which to choose.  I'd avoid "locking yourself" in to
    any "single source" (be that MCU or RTOS)...  (best/brightest solution unlikely to reside w/single vendor - at all times - under all use cases...)

  • 0 in reply to Amit Ashara
    Intellectual 740 points

    A full one second response time is generally ok and is, in fact, the way the current systems operate (due mostly to the IO being handled entirely on a 1-wire bus which is "busy" 750 mS of every second converting temperatures to 1s and 0s).  Improvements in this are desirable and should be easy to achieve given the new architecture concept.

    I don't see that memory will be an issue in any application implemented on these devices.  I guess I'm more worried about handling the various serial channels involved and their associated interrupts, etc.  Do I gain anything as far as ease-of-use goes with a RTOS that isn't lost in the learning curve of the RTOS itself?  I have plenty of experience with various microprocessors and microcontrollers, dealing with peripherals (internal and external), in bare-metal environments.  I have zero experience with RTOS environments and programming them.

  • 0 in reply to Clark Leach
    TI__Guru**** 244400 points

    Hello Clark,

    If you want to learn RTOS while doing the application, then go for it. The learning curve would be steep but TI-RTOS forum does have a good support.

    On the other hand if you want to implement in a short span of time, then I would suggest plain old programming. Once you are done with the bare-metal flavor, then go for RTOS as there would be a working example for it and in case of an issue you can always refer to it. When it comes to handling data traffic from multiple peripherals, do understand what interrupt status bits are available to you and how you want to handle them in the application. That would be true even for an RTOS based implementation.

    Regards

    Amit