• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 134 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.

TDA4VE-Q1: FreeRTOS on C7x

Matthew Brown
Prodigy 130 points

Part Number: TDA4VE-Q1

Hi,

I'm using the TI ported FreeRTOS (ti-processor-sdk-rtos-j721s2-evm-11_02_00_06) on a j721s2 C7x.  I'm currently examining its performance.  I've made a small test file that can run a code sample in a loop from within a RTOS task, or simply from a crude software timer in the main() function (with no OS at all)
In the sample code  the #define NO_OS_TEST define is used to switch modes.

.c71_1_main_test.c

From the main() function without an OS the test code runs in about 820 cycles.  Over the course of a several hours test the highest cycle count recorded for the test code is 869, roughly 50 cycles over the typical time.
Using the FreeRTOS task, the sample code will run in 820 cycles, but there are frequent run-throughs that get delayed and the cycle count ends up in a range of anywhere from 1800 to more than 2000.

Question is simply what is causing this and why?  Can it be avoided?   I want to use a FreeRTOS task for high priority, time sensitive calculations (priority is configMAX_PRIORITIES - 1) but it seems as if this task is getting supeceded by something else quite often.

Thanks,
Matt

  • 0
    TI__Intellectual 1900 points

    Hi Matt,
    The increase in cycle count while using freertos in comparison with bare-metal is expected. The task being preempted would likely be because of hardware interrupts like tick interrupt. When a hardware interrupt is fired the Hwi_disp_always_asm file are called which saves the current context of registers, interrupt happens and then restores the context before the task resumes.
    Regards,
    Ben

  • 0 in reply to Ben Thomas
    Prodigy 130 points

    Thanks,
    Based on that I find that adding taskENTER_CRITICAL() will protect the test code from being interrupted by the OS, so that makes sense. 

    So, if this OS hardware interrupt or interrupts is/are occuring during critical tasks can it safely be assumed that the time to run the ISR will be stable?  In other words, can we plan on interruption of maximum 1000~1200 cycles as observed above, or is this going to grow and maybe become variable as the system complexity increases - more tasks/OS elements etc. getting added? 

    Thanks,
    Matt

  • 0 in reply to Matthew Brown
    TI__Intellectual 1900 points

    Hi Matt,
    The hardware interrupt overhead remains constant but we cannot guarantee that the total cycles stay constant as task size increase.
    Regards,
    Ben

  • 0 in reply to Ben Thomas
    Prodigy 40 points

    Thank you for your response, Ben.  Matt has gone on vacation for the next week. I'm sure this will continue when he has returned.

  • 0 in reply to Joe Rogers
    TI__Intellectual 1900 points

    Hi Joe,

    Thanks for the update. 

    Regards,

    Ben