Advice on how to constrain a legacy embedded app to a real time application [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I'm taking over of a "legacy" embedded system application, not quite legacy, and the first thing I'm concerning is that I found out that during the development, at some point the time constraint for the app got lost in the requirement of the project. Now it is my task to refactor it and make it real time as it was meant to be.

The project is done for an ATMEL UC3 in C and C++. It runs over FreeRTOS, there are 6 tasks. 5 for managing the external devices and another, with the lowest priority and the heaviest task as the main program. The first thing I did was to measure the time taken by the main task, and it was not a surprise that sometimes it got off of the dead line, therefore the complete task was executed in several cycles.

Can anyone please suggest me what are the possible main points to take in this case?

What would you do? I know that I should follow the flow of all the execution paths and count the instructions, then take the worst execution path and with the frequency of the chip will give me the real time execution. That is in theory, is there any tool, trick or a procedure to do it a bit easier?

UPDATED:

I cannot share the the source for confidential reasons. Additionally I've been digging deeper and I found out that the main delays, apparently are generated by the queues size. Most of the queues are created for holding 2 or 3 messages. I will need to do some tests in order to provide further information here. In theory, if the queues get fill up then the rest of the processes cannot send anymore until there is free space again for more messages. Then the processes get suspended leading to consecutive re-scheduling. My idea is to increase the queues size to 10 just to see if it improves the performance and the timing.

UPDATED 2 Starting from the suggestions, which I found them very helpful when I was in the dark, I came across a tool called "Understand" it is not for free but helps me to get analysis and chars. Also you can see the char-flow of complex functions, therefore you can see the longest path of execution the flow.

Answer 1

Throwing up an answer here because Rock 'n Roll racing is one of the best games of all time. That being said...

From your wording here it sounds like the task you are measuring that absolutely must make its deadline is the lowest priority. That right there is backwards. You want your task that needs to be guaranteed its completion as the highest priority task.That would be step one. If I am mistaken from how I read your question and your thread that needs to make those deadlines is the highest priority then there are other things to look at.

Make sure interrupts are not disabled by any of the other tasks for extended periods since that will effect the thread scheduling. If a low priority task is disabling interrupts and then spinning in a loop for a while there is no way for the RTOS scheduler to take back control and give it to your high priority thread.

Check for priority inversion (http://en.wikipedia.org/wiki/Priority_inversion). If there is resource sharing between your low priority thread and this critical thread then you can get into a case where even though your critical thread is high priority it might block waiting for a lower priority thread to finish using a resource. Not sure if FreeRTOS has priority mutexes/semaphores but that is something you can check as well.

Another thing which is probably the simplest explanation is to profile the thread. This is difficult to do on embedded systems but you can make some sort of light logging buffer or something of that sort. Find out when it's sometimes missing its deadline what is different about that code path vs the times it makes it ok. You might have to find a way to speed up some of that path. For instance in a slow run it could be writing a larger amount of data than normal so maybe change those data writes to use DMA instead of the thread manually writing.

This is not an exhaustive list but some good tips to get started.