Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Jeff Andle on September 15, 2011
I have FreeRTOS V7.0.1 - Copyright (C) 2011 Real Time Engineers Ltd. using the demo app as a starting point but with all of the demo code stripped out. I have the commercial version of FreeMODBUS running as one task, but it seems (will verify) unrelated. There is a second task that encapsulates the Microchip ECAN demo code.

MODBUS main task loop:
for( ;; )
{
//vTaskDelayUntil(&pxPreviousWakeTime, 10/portTICK_RATE_MS);// Period of 10 milliseconds.
// Poll the communication stack. 115200 baud --> ~100us symbol time --> ~350 us timeout
// as long as timeout is handled at RX ISR level, this can be called less often.
eMBSPoll( xMBSHdl[0] );
eMBSPoll( xMBSHdl[1] );
vTaskDelay (10/portTICK_RATE_MS);
}


When this is the only task and the vTaskDelay() is commented, it runs. Also when both it and the CAN task:

for( ;; )
{
vTaskDelay(5000/portTICK_RATE_MS);// Delay for 5 seconds.
while(C1TR01CONbits.TXREQ0==1) ;// Make sure there are no messages pending.
requestVersionInfo();
}

run, it runs for hours. The CAN task by itself also runs. I just this moment realized the CAN task also delays...

Together with CAN task and uncommenting vTaskDelay() it immediately terminates the program.

I'll keep digging, but if there's something obvious, I am missing it.





RE: dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Dave on September 15, 2011
“Together with CAN task and uncommenting vTaskDelay() it immediately terminates the program. ”


Your code does not show vTaskDelay() being commented out. Do you mean "uncommenting vTaskDelayUntil"?

Do you have stack overflow checking enabled? How have you defined pxPreviousWakeTime? Have you stepped through the code to see why it is crashing?

RE: dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Robert H. Oujesky on September 16, 2011
The smallest delay you can pass to vTaskDelay() is 1 ms.
vTaskDelay(5000/portTICK_RATE_MS); // Delay for 5 seconds.
does not delay for 5 secs
I think you want
vTaskDelay(5000 * portTICK_RATE_MS); // Delay for 5 seconds.

this will make a HUGE difference.....

RE: dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Dave on September 16, 2011
No, vTaskDelay(5000/portTICK_RATE_MS); is correct, although I take your point that it is probably a badly named constant. There are lots of examples uses in the FreeRTOS download.

If the tick rate is set to 1ms, then in that case, and only that case, it actually makes no difference if you multiple or divide.

RE: dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Robert H. Oujesky on September 16, 2011
WOW! I was really hoping I was contributing. :( I actually thought you were crazy, so i started searching thru the code. You are right, portTICK_RATE_MS is 1. So it doesnt matter whether you divide or multiply....
thanks!

RE: dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Richard on September 16, 2011
If configTICK_RATE_HZ is set to 1000, then it is true, it does not matter if you divide or multiple - but that misses the point of the portTICK_RATE_MS constant. portTICK_RATE_MS is provided so you can change configTICK_RATE_HZ without effecting the actual time that any task blocks for. In that case, you must always divide, otherwise it won't work if you change the tick frequency (any other tick frequency will result in a portTICK_RATE_MS that is not equal to 1).

It should also be noted, that portTICK_RATE_MS only works if configTICK_RATE_HZ is less than or equal to 1000.

The HZ on the end of the configTICK_RATE_HZ name denotes that the value is specified in HZ. Hence, setting it to 1000 gives you a 1000Hz tick rate.

The MS on the end of portTICK_RATE_MS denotes that it is in MS. Hence, a tick rate of 1000Hz (1KHz) gives you a tick period of 1ms. portTICK_PERIOD_MS would be a better name.

Regards.

RE: dsPIC33 vTaskDelay (10/portTICK_RATE_MS);

Posted by Jeff Andle on October 24, 2011
it turns out (a) I did not monitor this thread and thought I did so I missed the advice and (b) I was overflowing the stack... I was overflowing the stack because of some esoteric issue in dsPIC33's DMA/ECAN/ISR can of worms. I had to (turns head and coughs) POLL the DMA ready flags... sheesh.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS