• AVR Freaks

Hot!Using an RTOS with Lubin's blockset?

Author
f.stojanovic
New Member
  • Total Posts : 18
  • Reward points : 0
  • Joined: 2019/05/07 01:56:09
  • Location: 0
  • Status: online
2019/07/15 07:11:52 (permalink)
0

Using an RTOS with Lubin's blockset?

Hi all, again,
 
I seem to be on the roll. Another week, another thread.
This time, it's about RTOS.
 
As I am weighing pros an cons of implementing an RTOS for an embedded application, I wonder whether the current version of the Simulink blockset can be made to support some RTOS, like FreeRTOS for instance.
 
Any code generated by MATLAB is ANSI-compliant, so in theory it can be used with any RTOS available. I thought about going one step further.
I was thinking about developing a MATLAB blockset to automatically configure FreeRTOS to use with the blocks. For this, I would need to alter slightly the architecture of the generated project.
Is it possible to generate FreeRTOS-ready code using the current blockset?
 
The first idea that came to mind was implementing a Code Replacement Library in MATLAB to convert the generated project. Do you think this can be achieved directly in MATLAB with the above-mentioned method, or any other?
In any case, implementing an RTOS into the current blockset would definitely make a very complete and useful tool.
 
Thank you all,
~Phil
 
#1

3 Replies Related Threads

    Lubin
    Moderator
    • Total Posts : 370
    • Reward points : 5
    • Joined: 2007/03/31 07:38:15
    • Location: Bayonne, France
    • Status: offline
    Re: Using an RTOS with Lubin's blockset? 2019/07/15 23:59:07 (permalink)
    0
    Hi Phil,
     
    The blockset can implement either a single tasking or multi-tasking (monotonic rate scheduler).
    You might read this post first.
    https://www.microchip.com/forums/m810319.aspx
     
    I also had few slides wich illustrate the use-case of this multitasking monotonic rate scheduler with simulink here:
    https://lubin.kerhuel.eu/slides/slides_dcmotor_insa/#/12
    (french, but illustration is universal)
     
    Provided the tasking mechanism is tighted to the model setting (time step might be triggered by either a timer, a ADC end of conversion, or a ADC end of conversion synchronized to the PWM peripheral). Modifying that part to support an RTOS might require to modify internal blockset files.
     
    I think code replacement feature is more appropriate to optimize part of code than tweaking a RTOS. We implement code replacement for some functions (sin, cos, sqrt...)
     
    Lubin
    #2
    f.stojanovic
    New Member
    • Total Posts : 18
    • Reward points : 0
    • Joined: 2019/05/07 01:56:09
    • Location: 0
    • Status: online
    Re: Using an RTOS with Lubin's blockset? 2019/07/16 02:01:46 (permalink)
    0
    Hi Lubin,
    Thank you very much for your reply.
    That is very good news, I am surprised I couldn't find that forum thread.
     
    Unless I am mistaken, the rate-monotonic scheduling method has constant priorities all throughout the application? That kind of defeats the purpose of interrupt priorities, doesn't it? There is just no clear-cut way to separate critical tasks from non-critical ones.
     
    From what I've understood in this post : https://www.microchip.com/forums/FindPost/816519
    Any application using the MultiTasking Scheduler can be considered real-time and deterministic unless tasks do not overload the CPU?
    I apologize if my understanding is simplistic. Thank you again.
    Cheers,
    ~Phil
    #3
    Lubin
    Moderator
    • Total Posts : 370
    • Reward points : 5
    • Joined: 2007/03/31 07:38:15
    • Location: Bayonne, France
    • Status: offline
    Re: Using an RTOS with Lubin's blockset? 2019/07/16 05:38:44 (permalink)
    0
    f.stojanovic
    Unless I am mistaken, the rate-monotonic scheduling method has constant priorities all throughout the application? That kind of defeats the purpose of interrupt priorities, doesn't it?

    With dsPIC and PIC32 target, In Multi-Tasking implementation, tasks are triggered with a fixed priority of 2.
    Tasks reduces their own execution priority from 2 to 1 when they start so as to be pre-empted by any higher priority tasks. (that is a big picture).
     
    If your UART circular buffer is implemented with a priority 5 interrupt, reception on Rx is likely to pre-empt any tasks. All drivers provided for peripheral (UART, but also SPI, I2C, CN ...) are designed to be used with a priority above model tasks.
     
    You can trig your own tasks setting-up a Timer (Timer block), triggering your subsystem using the "interrupt" block. You can then decide the priority of your asynchrousnly triggered subsystem.
     
    Thus, interrupt priorities have an impact.
     
    f.stojanovic
    Any application using the Multi-Tasking Scheduler can be considered real-time and deterministic unless tasks do not overload the CPU?

    The scheduler is "robust" to overload, but you should never get there if you do not want to violate real-time constraints.

    If you don't have overload, your system is deterministic except if you uncheck the "deterministic" option on rate transition block, when a data goes from a fast-task rate to a slower task rate. Unchecking this option allows reducing delay. (MathWorks help for that block provides further explanation)
     
    Attached is an illustration of the multitasking scheduler obtained with the "task state" block available in the blockset which can set one various output pin of the mcu a task state.

    Attached Image(s)

    #4
    Jump to:
    © 2019 APG vNext Commercial Version 4.5