I just built the demo (v5.4.0) for the pic32 using MPLAB 8.30, Pic32-gcc V1.05 and the Explorer 16 dev board. Nothing seemed to happen. If I rem out vStartInterruptQueueTasks then the project will run and the display shows Block time error, Int queue errors. Any Ideas?
RTOS V4.2.1 Built with the same configuration shown above runs with a max jitter of
-23895ns. If I build it on MPLAB V8.0 with pic32-gcc V1.0 it runs with max jitter of +486ns.
Note: the later versions of MPLAB V8.15a and fwd upgrade the firmware in the ICD 2. If I plug the ICD 2 into an earlier version of MPLAB (V8.00 specifically) and reflash the ICD 2 to the old firmware, FreeRTOS V4.2.1 works fine. I can’t build V5.4.0 in MPLAB 8.00 because it say the format of the workspace has changed (i.e. I can’t open the project).
What version of MPLAB, Pic32-gcc and ICD firmware was FreeRTOS V5.4.0 built under?
I have quite a big project running with V5.2.0, but using a starter kit module with its own debug interface rather than Real ICE. Nothing has changed in the PIC32 port for a long time.
Your website says that V5.0.2 was built on the Explorer 16 board so I pulled down that version and it seems to be working. Being a newbee, I think I will start here. It would be interesting if you could try V5.4.0 on the Explorer 16 board.
I have just tired V5.4.0 and you are correct in that the demo does not run as is. The problem has arisen because of some modifications that were made to the byte alignment, causing just a few more bytes per task stack to be allocated. This in turn meant there was not enough heap left for the idle task to be created.
To fix, open up FreeRTOSConfig.h and change the configMINIMAL_STACK_SIZE setting from 200 to 190. The demo will then execute with no problems.
The maximum delay period depends on the type used to hold the tick count and the tick frequency. Assuming the tick count is held in a 32 bit variable (configUSE_16_BIT_TICKS is set to 0) and the tick frequency is 100Hz (configTICK_RATE_HZ is set to 100) then the maximum delay that can be achieved using vTaskDelayUntil() is 0xffffffff ticks,
which equals 0xffffffff one hundredths of a second,
which equals 42949672.95 seconds,
which equals 715827.8825 minutes,
which equals 11930.46470833 hours,
which equals 497 days
:o)
Note that block times sent to queue and semaphore functions can specify an indefinite wait by setting the block time to portMAX_DELAY and having INCLUDE_vTaskSuspend set to 1.