FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [October 2014 Threads]
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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.