w1res wrote on Thursday, January 07, 2016:

I’m using FreeRTOS on a dsPIC33 MCU. When compiling a demo project I’m getting the following error in heap_1.c

../../FreeRTOS/FreeRTOSV8.2.3/FreeRTOS/Source/portable/MemMang/heap_1.c: In function 'pvPortMalloc':
../../FreeRTOS/FreeRTOSV8.2.3/FreeRTOS/Source/portable/MemMang/heap_1.c:124:30: warning: cast to pointer from integer of different size

The code in question is the following

pucAlignedHeap = ( uint8_t * ) ( ( ( portPOINTER_SIZE_TYPE ) &ucHeap[ portBYTE_ALIGNMENT ] ) & ( ~( ( portPOINTER_SIZE_TYPE ) portBYTE_ALIGNMENT_MASK ) ) );

When I look at the definition of portPOINTER_SIZE_TYPE, it is uint32_t; however, the pointer size on the dsPIC33 is actually 16-bits, for both data (16 bits) or program memory (24 bits, it puts handles to functions if they aren’t in the first 16-bit addreesable 64k).

Is this intentional? If so, what is the purpose of defining portPOINTER_SIZE_TYPE that way?

rtel wrote on Thursday, January 07, 2016:

portPOINTER_SIZE_TYPE was inroduced to solve this compiler warning on some 8 and 16-bit devices that required it - so you will see ports such as MPS430X, RL78, etc. have a genuine definition. I think the dsPIC port pre-dates the introduction of the constant, so what you are seeing is it default to 32-bits if it is not otherwise defined.


w1res wrote on Friday, January 08, 2016:

Thanks for the quick reply. I’m still getting familiar with FreeRTOS, so does that mean I can safely change the portPOINTER_SIZE_TYPE to uint16_t, or should I just leave it as it is and ignore the warning?

rtel wrote on Friday, January 08, 2016:

It is safe to leave it as it is, as the bits that get truncated cannot
possibly hold any data. Setting it to uint16_t should be fine, its just
not tested (assuming pointers cannot be 24-bits?).