Hi everyone,
I'm trying to reduce as much as possible the utilization of the XDATA by the BLE stack. By looking at the .map file, I see 3 big objects:
OSAL_Memory ~3075B
ll ~918B
ll_scheduler ~1283B
I have already reduced OSAL_Memory to 591B, below that, I get warning during compilation, so I guess it will result in error during execution. Does anyone know how to reduce the two other module?
Best regards,
Jerome Baron
As far as I know there is no external control over the Link Layer memory allocation, so the only way to change this would be to get access to the stack source or write your own stack. Both of these options seem unlikely and would probably compromise the BLE operation.
I would guess that reducing the OSAL memory as much as you have would create some serious operation issues but I guess that all depends on what you are doing with the stack.
The question is what do you need the additional memory for? I too am running some fairly memory hungry applications and use the OSAL to allocate several large buffers for this with no problems. Are you able to use external SPI memory if this is not enough?
I too have felt that the CC2540 could do with say 16KB SRAM as there isn't a huge amount left over once the stack and OSAL for BLE has taken its share.
Hi, thanks for your answer. My application is really memory consuming. I have an AT parser with a lot of command/answer with some big array that need to be in flash as well as a framebuffer for an external LCD.
What do you mean by : "I would guess that reducing the OSAL memory as much as you have would create some serious operation issues but I guess that all depends on what you are doing with the stack. "
There's still almost 600 bytes for the stack to use. I don't use any dynamic memory allocation in my application. Do you think the BLE stack needs more flash to work properly? There's no documentation regarding this.
It would depend on what type and how many of BLE connection(s) you are running. I really don't know how much heap the stack uses but this could be determined using osal_heap_block_free(). It is just a gut feel that reducing it to 1/5 of its original size could cause memory allocation issues. It would need to be tested carefully.
I think you are confusing RAM with Flash above, Flash is program memory.
Thanks for the tip, I will monitor the osal_heap_block_free() to see if it comes neer to zero. My application doesn't use much bluetooth. Only one connection at the time and I only do RSSI monitoring.
By default, with the 640 of stack as configured in the demo application, the SimpleBLECentral takes ~7kB. There's not much left for the application part!