Hi there,

I'm starting to get my application to actually run on my chip. I'm beaming with excitement. The one trick is that I'm using heap_4.c, since the platform does a lot of allocations and frees, since there's a radio chip that sends variable length payloads all the time.

The issue that I'm running in to is that on the dsPIC33 chip I have, which has 16K of RAM, only the lower 8K of it is available via 'near' addressing.

I want to allocate a large heap, most of what is not used in regular task tasks, to facilitate large queues for communications stacks.

Can you foresee any problems with changing the declaration of ucHeap to have __attribute__ ((far)) ?

Relevant chip-specific information is here, page 37, section 4.2.4 : http://ww1.microchip.com/downloads/en/DeviceDoc/70594d.pdf

It looks like points aren't any extra words in length, and the compiler has to issue an extra move instruction for any pointer deref? Getting a bit out of my depth there.

Hmm. I'm not sure to be honest, but suspect if you make the heap memory far then the pointers that access memory allocated from the heap may also have to be declared far (task, queue, semaphore, etc. handles are effectively pointers). If possible I would just set the default to far in the compiler options.

Regards.