|
| Re: Timer function block accuracy [message #1832432 is a reply to message #1832374] |
Thu, 17 September 2020 19:29   |
|
I've hear once that people trying to do periodic things with an E_DELAY had troubles. But this was more due to their application design and therefore I didn't investigate further.
I had a look on the code and triggering an E_DELAY and processing the response requires quite some interlocking (two mutexes, one semaphore). Even though two of the locks should in your setup always be free there is a chance for at least for one causing some of the troubles. I've found one place in timerha.cpp that could partly be responsible. Can you give it a try if it improves your situation. If not then we have to dig deeper on the different critical sections involved in that case.
Attachment: timerha.cpp
(Size: 4.00KB, Downloaded 20 times)
|
|
|
|
| Re: Timer function block accuracy [message #1832453 is a reply to message #1832437] |
Fri, 18 September 2020 09:48 |
|
Am I reading the numbers right that it got worse?
You are measuring the time between the reception of the start event and the sending of the EO event, aren't you?
I have some idea of improving the timerhandler to make less use of the mutex. This would really be an improvement in resource usage. But it would take a bit of my time. Would it be possible that you give me your application and the adapted delay so that I can do some experiments on my machine?
|
|
|
|
| Re: Timer function block accuracy [message #1832604 is a reply to message #1832539] |
Mon, 21 September 2020 16:48 |
|
Thanks for the code. Yes this better helps to understand your measurements. I have some trouble with it. The point is you are not purely measuring the behavior of the E_DELAY and the timer infrastructure but also the event handling mechanism in 4diac FORTE. The reason is that you are measuring the time between two START events. As you are inside an E_TRAIN this should roughly work but you are in addition to the E_DELAY also measuring the performance of roughly 4 event connections, 2 additional FBs and their with. While I know that we have there a problem with a mutex and I would assume for your applications we can find a workaround there I would expect that your execution time will most always be way above 20ms.
However before we fix that I would like to learn more about the problems of the timer infrastructure itself. IMHO you should measure the time that is passing between receiving an START event and after the EO has been sent. By that your calculations would also not interfere so much with the registration at the timer handler.
Could you be so kind and update on your measurement code. I would in parallel think on how we can get the number of mutexes down in the timerhandler. This should definitely improve the situation.
|
|
|
|
| Re: Timer function block accuracy [message #1832616 is a reply to message #1832610] |
Tue, 22 September 2020 07:27 |
|
I would be really curios how the numbers are now on your embedded system. Are you providing your users the RT event FBs? If not you can get rid of two mutex lock/unlock pairs in funcbloc.cpp. Which should improve execution performance quite a bit and improve also the E_Delay jitter a bit.
[Updated on: Tue, 22 September 2020 07:29] Report message to a moderator |
|
|
|
| Re: Timer function block accuracy [message #1832854 is a reply to message #1832622] |
Sun, 27 September 2020 18:31 |
|
I've been thinking a bit longer on that topic and while there is a little bit of improvement possible in timerhandler I think another measurement would be good to have more feedback on the problem. A crucial point on the delays that you are measuring is the delay that happens between mSuspendSempahore.inc() in resumeSelfSuspand() and that the method selfSuspend() is left. You can find both methods in ecet.h. This would be the time that elapses from the timerhandler informs the thread and the thread awakens. I fear that this could the core of the delays that you are seeing and therefore it would be great to have it measured.
What is important to note so that you are not skewing your measurements. During measuring you must not communicate with your 4diac FORTE devices especially you should not monitor anything.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02404 seconds
Search
Help
Register
Login
Home
