I have following (strange?) behaviour: when I change the configTICKRATEHZ value, my application speed scales with the factor i changed the value with. Example: I have a webserver that can up/download a file. My configTICKRATEHZ is 250 Hz. Here the upload takes 1 Minute. When I change the configTICKRATEHZ to 1000 the upload only takes 25 seconds…. When I understood the configTICKRATEHZ value properly, this should not be. The value should only control the granularity of the time I can measure with freeRTOS and the frequency the tasks are evaluated for selection, but should not have any impact to the speed the application runs with. I checked the obvious error: vTaskDelay(Until) is only used with pdMSTOTICKS macro. I am using FreeRTOS 9 with the Microchip Harmony Framework on a PIC32MZ2048EFM144. Can someone confirm that this behaviour is not right?
A couple errors can cause this sort of issue. One is that if the port doesn’t actually change the tick rate when you change the define, then timeouts will be incorrect. One quick test is to implement the tick-hook and have it toggle a bit and see that the tick rate is right and changes. A second type of error that can do this is if some ISR that you depend on doesn’t test the wasWoken flag and force a reschedule, in which case the task that should have been activated by the ISR waits till the next tick interrupt.
In addition to Richard D’s answer: 1) ALL block times should use the pdMSTOTICKS() macro to ensure block times scale automatically to the correct value whenever. You only mention vTaskDelay(), but block times are used in a lot more places than that. 2) Ideally your entire application should be event driven – that is – never have an arbitrary delay when waiting for an external event [ideally] and instead have the event unblock a task. Given the two above, changing configTICKRATEHZ should only change the granularity and accuracy of block times, and not change the execution speed of the application. Conclusion is, there is something in your code, or the harmony code, that is doing something contrary to the above.
OK, thank you both for the clarification and the hints. I will investigate – something is not right.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.