• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 82 subscribers
  • Views 894 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.

RTOS/TMS320F28379D: Performance Profiling

Eric Ditmore
Prodigy 60 points

Part Number: TMS320F28379D

Tool/software: TI-RTOS

Good Morning,

I’ve been tasked with evaluating the cost of migrating from a native OS to an RTOS implementation. Is there a way to calculate processing “footprint” of the scheduler, compared with the native (while-loop) implementation? It seems to me as though this could vary greatly depending on the size of the system and the nature of the functions/interrupts, however I am new to this type of development, (and development in general) and may be overlooking something simple. I’m using CCS version 7.4, and working with a TMS320F28379D controlCARD R1.3 Any assistance you can give would be appreciated.

 

Thank You,

 

Eric

  • 0
    TI__Guru* 96960 points

    Hi Eric,

    This is a hard question to answer since it really depends how features you want from an RTOS. I built a "standard" SYS/BIOS example (note: SYS/BIOS is the kernel in TI-RTOS) for the F28379D ControlCard. The flash size (includes .econst, .text, .cinit, etc.) was ~16K for the whole application. The example is pretty simple: 1 task that blocks on Semaphore_pend and 1 timer that posts the semaphore.

    Let's look a little closer at what is included from the kernel though.
    - Hardware Interrupt Support (Hwi)
    - Software Interrupt Support (a Swi is basically the same as a Hwi but not as high priority and software initiated. It uses the system stack like the Hwi module).
    - Tasking support (and related items like Semaphores, Gates (like a mutex), Queue (linked list), etc.)
    - A variable size heap implementation (similar to malloc's implemention)
    - Code to configure one timer and uses it to drive timing in the kernel (e.g. Task_sleep). The application can plug in functions to be called periodically or one-shot also (but must be at the interval of the timer's period...which is configurable but we default to 1ms).
    - The kernel plugs the the TI RTS with a lock to manage thread-safety in the RTS functions
    - "System" type support: System_printf (leaner and more flexible printf) and other things like System_exit, etc.
    - boot code: setting of CPU and clock rates
    - Various hooks: to allow an application to plug in their own callback at numerous places (e.g. reset hook, hook right before main, error hook, exception hook, etc.)
    - Error management code
    - Assert checking was turned on in the kernel: This is good to have on during development to catch silly things like passing an invalid parameter (e.g. Task_setPriority(taskHandle, 453)...453 is not a valid priority), but can be turned off to save space once you are getting close to releasing the product.

    The kernel size can go up (e.g. add in debug features, FatFS or Mailbox) or down (e.g. not having a heap or supplying the kernel's tick instead of the kernel grabbing a timer). Note the kernel code footprint is a fixed cost. If you add more tasks, heaps, etc. The footprint does not grow.

    Another common question about an RTOS is interrupt latency. SYS/BIOS adds some latency (please refer to the SYS/BIOS release notes to see benchmarks). However, the kernel allows unmanaged interrupts also. For these the kernel adds zero-latency and will never interfere with it's execution (important for many C28x applications). The caveat is the unmanaged interrupt cannot call into the kernel. It can post another interrupt that is managed by the kernel though.

    Hopefully I answered your question at a high-level. This is a good page for some more C28 specific details related to SYS/BIOS: processors.wiki.ti.com/.../BIOS_for_the_28x

    Todd

    P.S. I'd recommend looking at the SYS/BIOS product and not the TI-RTOS one. We don't ship high-level drivers for C28 devices, so TI-RTOS for C2000 is really just the kernel for F28379D users...and the examples for that device are better in the SYS/BIOS product. Here's another page that talks about that a bit:
    processors.wiki.ti.com/.../TI-RTOS