Need to speed up firmware App with RTOS.

Jonathan Duan

I am developing a time critical firmware using RTOS. My operations take 240 uS to execute (80MHz TM4C123 MCU). I am trying to reduce its time. Your wisdom and expertise is needed. My software architecture may need drastic improvement.

I have noticed from using logic analyzer that the time it takes from posting a semaphore to unpending the task takes about 30 uS. Is there a way to speed it up? Are there alternatives to using the semaphore pend and post method?

Also, SPI_transfer() takes about 29 uS to run (SPI clock = 20MHz). Is there a way to reduce that? The actual hardware SPI transfer takes only about 5uS for one 4-byte transfer (SPI clock = 20 MHz). What is the algorithm used in SPI_transfer? Does it rely on interrupt or DMA?

The execution graph (Debug Tool) in CCS shows a lot of semaphore post/pend operations during the execution of my code. I don't think my code is doing that. I am wonder what are the sources of those semaphore operations.

In a nut shell, my operations include an incoming IRQ (HWI), four SPI_transfer() calls, with two pairs of SPI_open and SPI_close, two levels of semaphore post/unpend. I need to reduce the overall time down to around 100uS. The flow looks like this :

IRQ arrives

HWI

semaphore_post(Task1_sem)

task1 unpends and runs

SPI_open()

SPI_transfer() // read 4 bytes

SPI_close()

semaphore_post(Task2_sem)

task1 pend

task2 unpends and runs

SPI_open()

SPI_transfer() // write 4 bytes

SPI_close()

task2 pend

wait for next IRQ

over 9 years ago

0 ToddMullanix over 9 years ago

TI__Guru* 96960 points

Are you using the non-instrumented library for the drivers? The default is to be non-instrumented, but you can explicitly set it in the .cfg:
TIRTOS.libType = TIRTOS.LibType_NonInstrumented;

What about the kernel? Try adding the following in the .cfg
BIOS.libType = BIOS.LibType_Custom;
BIOS.logsEnabled = false;
BIOS.assertsEnabled = false;

Also, why are opening/closing the SPI instance every time? Generally, you open the instance during system initialization and then do multiple transfers.

Todd

0 Jonathan Duan over 9 years ago in reply to ToddMullanix

Intellectual 570 points

Hi Todd,

I mistakenly thought that I have to do SPI_open and close for every SPI_transfer. Now I know I don't have to and I have changed my code to look like this :
I also realized did not have to use semaphore for my second task. I changed it to use a function call instead.

SPI_open() 33.37 uS // once during initialization

IRQ arrives 3.21uS
HWI
Semaphore_post(task1_sem) 28.47 uS

Task1 runs
SPI_transfer() 29.07uS // read 4 bytes
SPI_transfer() 29.07 uS
call Fxn2
task1 pends

Fxn2 runs
SPI_transfer() 29.07uS // write 4 bytes
SPI_transfer() 29.07uS
Fxn returns

wait for next IRQ

Total time measured = 147.96

What does "instrumented" mean? Is it related to using the RTOS analysis tools? Regarding the .cfg setting changes you suggested, are they also available from the GUI?

Thanks.

Jonathan

0 ToddMullanix over 9 years ago in reply to Jonathan Duan

TI__Guru* 96960 points

Instrumented means that "assert" checks are done and Log statements are written. These are useful for new development, but once everything is running properly, you can use the non-instrumented versions for better performance and smaller footprint.

Todd

0 Jonathan Duan over 9 years ago in reply to ToddMullanix

Intellectual 570 points

Thanks Todd. I have tried your methods and they reduced the execution time.

I have also written my own driver code to do the SPI transfers instead of calling the SPI SPI_transfer().

All of these reduced the execution time to a satisfactory degree.

This thread can be closed as "answered."

Thank you.

Processors

Processors forum

Need to speed up firmware App with RTOS.