• State Answer Suggested
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1222 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.

Should I use RTOS

TechGuy2710
Prodigy 40 points


Hi

I know this questions must have been asked before several times and is a debatable one. I am asking it again focusing on my project requirements. I want to find out whether RTOS is really beneficial in our project or not.

Here are the requirements.

1. The MCU would be probably TM4C1294.

2. It will interface to a WiFi module, a GSM modem, and our own proprietary wireless module (all over SPI or serial UART).

3. In addition, it will have Ethernet and a USB host / device interface.

4. The main functions of the MCU will be to monitor the data received on the proprietary wireless protocol and then send some data over Ethernet or WiFi or over GPRS to a server.

5. It will also have a server running on Ethernet to accept TCP connections over a specific port. Need not be http.

6. Ideally, the same code would be ported to some other processors who are not capable of running any RTOS. However, if it is proved that RTOS is really hugely beneficial for the project, then this constraint would be dropped out.

7. None of the requirements are having strict timeline targets. The deadlines for some of the event responses are in range of a few seconds.

The alternative to RTOS is using Tiva middle-ware and examples and develop a modular code. This will keep the HAL and middle-ware separate from application and thus can be ported to other less capable processors.

One thing to note is that none of the team members have experience in designing an RTOS based system. Neither has anyone worked extensively on RTOS based projects. It is only that we are aware of the concepts and terminology of RTOS.

Any advice would be great and help in making a decision please.

Thanks a lot..

  • 0
    Intellectual 905 points

    Based on your description and requirements I would generally recommend an RTOS.

    FreeRTOS is bundled into the TivaWare distribution and is pretty quick to ramp on.  Wide community of users on this forum and others.  It is also widely supported on just about every other MCU out there even some that you may not think would run an RTOS at all.

    The DK-TM4C129X has a FreeRTOS with embedded HTTP web server example that comes to mind as the most likely starting point.  

  • 0
    TI__Genius 10700 points

    I would definately recommend an RTOS in this situation.  The most common issue I encounter when someone ask this question is that they do not have a good understanding of how to effectively use an RTOS.  If you suspect that you may be in this camp, there is some really great training material available both in book form and all over the web.  Furthermore, TI provides regonal in person training for TI-RTOS on a periodic basis.  The same material is available on the web as well.

    I would highly recommend taking a look at TI-RTOS for your application, as it provided out of the box device drivers for all of the use cases you mention as well as an integrated TCP/IP stack option.

    http://processors.wiki.ti.com/index.php/Introduction_to_the_TI-RTOS_Kernel_Workshop?keyMatch=ti-rtos wiki&tisearch=Search-EN

    Thanks,

    Stuart

  • 0
    Guru 27665 points

    A few notes

    • As soon as you start designing multiple communication interfaces my bias is to introduce an RTOS/RTK.  Each interface is going to need it's own state machine to deal with staus, error recovery etc...
    • Your project as described could be implemented w/o an RTK but that would require some extra work.  I expect an RTK with multiple tasks would be simpler.  From your description pre-emption might not be required.
    • Keep in mind the inevitable expansion of requirements.
    • An RTK can be quite simple and resource effective.  The simplest are either co-operative with multiple tasks at a single priority or pre-emptive RTC with priority and a single stack (each task runs to completion (no waiting on semaphores or timers, if the task execute periodically it is restarted each time).
    • Has any in the group worked with any multi-threaded OS?  The concepts are largely the same.
    • It's probably best to start with a pre-built RTOS (and TI has some)
      • TechGuy2710 said:
        The alternative to RTOS is using Tiva middle-ware and examples and develop a modular code
      These are not exclusive options.
      • TechGuy2710 said:
        Ideally, the same code would be ported to some other processors who are not capable of running any RTOS.
      That has the selection process backwards.  Also I find it difficult to imagine a processor that can manage TCP/IP and not manage an RTOS.

     

    I think an RTK/RTOS implementation would be simpler, more modular and easier to maintain.  However, you do need to factor in your learning time and the number of future projects of similar complexity.

     

    Robert

  • 0 in reply to INTEGRIS Dexter
    Guru 117855 points

    Echo poster, "Integris Dexter's" advice - with slight extension. 

    ARM themselves suggest that the SysTick Timer - built-in to all ARM MCUs - may well serve as a simple/pseudo RTOS.  This surely is the fastest/easiest means to gently/safely explore the RTOS waters.

    Beyond the attraction of ease & speed - SysTick provides a good "baseline" - with which to reference/compare to the more standard RTOS - should you (properly, later) seek such, "real comparative data."  (i.e. SysTick performance vs. real RTOS)

    I'd avoid any "vendor locked" RTOS and IDE.  Many ARM vendors dot this plain - it's not hard to argue that, "just one vendor" is unlikely to provide the best MCU - best availability - best price - best features - at all times!

  • 0 in reply to Robert Adsett
    Prodigy 40 points

    Thank you all for good inputs. My worries are really:

    1. System design - I/we lack the expertise in using any RTOS and am not clear how to really do a design using an RTOS. How to ensure that the tasks and their interface is making optimum use of RTOS.

    2. How to tackle with the run time problems of priority switching etc.

    As I said, since we do not have expertise of RTOS based system, it will involve more development time than is normally RTOS vouched for (shorter development time)

  • 0 in reply to TechGuy2710
    Guru 22270 points

    I have to say all the recommendations given above are excellent ones.  The SysTick Timer is probably my most favorite feature of the ARM MCU.  As cb1 has stated, using it makes it very easy to be come familiar with what a RTOS has to do and provides a method for RT operation.

    In your situation I would recommend one thing:

    Designate the task of learning how to use a RTOS to someone.  As mentioned by Stuart Baker, there are plenty of online documents and videos to learn from.  Also, provide the designer with the resources to hire a consultant if necessary to assist in speeding up the learning curve if time is a factor.

    Thanks,

  • 0 in reply to Robert Adsett
    Prodigy 40 points

    Robert Adsett said:

    A few notes

    • Your project as described could be implemented w/o an RTK but that would require some extra work.  I expect an RTK with multiple tasks would be simpler.  From your description pre-emption might not be required.

    Agreed. That is what I am thinking, if it can be implemented without an RTK, does it make sense to spend more time and energy in the RTOS stuff? I may be wrong. Does that extra work compare to the learning curve and lack of expertise on the RTOS?

    Robert Adsett said:
    • Has any in the group worked with any multi-threaded OS?  The concepts are largely the same.

    No, none of us.

    Robert Adsett said:
    • The alternative to RTOS is using Tiva middle-ware and examples and develop a modular code

    These are not exclusive options.

[/quote]

What I meant was that just use the HAL from Tiva and not the RTOS. Sorry but I haven't studied Tiva yet so guess it is possible to use it without an RTOS. If not so, then I can use the CMSIS HAL interface?

Robert Adsett said:
  • Ideally, the same code would be ported to some other processors who are not capable of running any RTOS.

That has the selection process backwards.  Also I find it difficult to imagine a processor that can manage TCP/IP and not manage an RTOS.

 [/quote]

Sorry that older processor won't do TCP/IP, but just the Wifi module and GSM module.

Robert Adsett said:

I think an RTK/RTOS implementation would be simpler, more modular and easier to maintain.  However, you do need to factor in your learning time and the number of future projects of similar complexity.

Robert

 

Can a non-RTOS design not be modular?  Learning time and future projects is definitely a concern.

  • 0 in reply to Greenja
    Guru 117855 points

    greenja said:
    As cb1 has stated, using it (SysTick) makes it very easy to be become familiar ...

    Thank you, Sir.  Check - as past agreed - winging your way - unchallenged/uninterrupted by RTOS demands...

  • 0 in reply to TechGuy2710
    Guru 27665 points

    TechGuy2710 said:
    Does that extra work compare to the learning curve and lack of expertise on the RTOS?

    I would expect it to be more work to develop without an RTK than learning an RTK.  The problem is the RTK will present an obvious learning curve and slowdown early and working without will appear to be faster. 

    TechGuy2710 said:
    What I meant was that just use the HAL from Tiva and not the RTOS. Sorry but I haven't studied Tiva yet so guess it is possible to use it without an RTOS

      It's also possible to use it with an RTOS.  It's a low level enough interface it does not generally interfere. Using Tiva does not exclude using an RTOS.

    TechGuy2710 said:
    Can a non-RTOS design not be modular?

    Not as easily.  With an RTK each communication channel can be written as if it has the CPU to itself.  Without an RTK you have to interleave the channels/protocols.

    Let's see if I can illustrate with Psuedo-code

    W/O RTK

    int Channel1_step(int st){

    int n_st;

    n_st = -1;

       switch(st){

        case -1:

             ERROR

             break;

            case 0:

                  if(x) {

                      n_st = 1;

                      }

                  break;

            case 1:

                  send char

                    n_st = 0;

                  break;

            default:

                  ERROR

                  break;

       }

    return n_st;

    }

     

    main(){

    While(1) {

       c1_st = Channel1_step(c1_st)

       c2_st =Channel2_step(c2_st)

       c3_st = Channel3_step(c3_st)

       }

    }

    With RTK

    Channel1_task()

    {

    while(1) {

    waitfor data

    writedata to buffer

    }

    }

    Channel2_task()

    {

    while(1) {

    waitfor buffer data

    writedata to output

    }

    }

    Main()

    {

    Init channel1 task

    Init channel2 task

    Start tasks

    }

    That's obviously highly simplified in both cases. You can write modular code w/o the RTK but the main scheduling loop tends to accumulates extra tests and timings.  You end up with a lot of overhead in design breaking each protocol/channel up into appropriately sized steps.  With an RTK you leave most of that to explicit waits and semaphores that let other protocols run when there is nothing for another to do.  Inter channel communication is done via FIFOs or queues which are usually built into the RTK so you do not need to re-invent those.

    Since you don't have any multithreaded experience but work in embedded you are likely familiar with interrupts.  Think of each task as an interrupt (some RTOSs actually make use of interrupts to do tasking).

    Robert