BLE light stack advantages

Light stack restrictions

The light stack version is just quickly described by the RSL10 Firmware Reference (highlighted in yellow):

Even the restrictions are not fully described (it should mention it doesn’t support 2Mbps and it is restricted to a single connection instead of 8 for the full stack).

Last disadvantage of the light stack: as most RSL10 customers use the full stack version, it isn’t tested as intensively as the full stack, so a bug affecting the light version could remain undiscovered longer than on the full stack. If you plan to use light stack in your project, you should maintain compilation with both the light and full stack in order to compare behaviors.

Light stack advantages

Light stack restrictions come with advantages:

  • Smaller Flash usage,
  • Smaller RAM usage,
  • Smaller consumption in sleep mode,
  • Faster (probably non-significant, but as there is a single connection context and there are less features supported, a well-designed implementation of the stack can only be faster).

In my opinion On Semiconductor should provide detailed information on the advantages. If this effort is not provided by ON Semiconductor, then you rely on your customers to check that on their own… and customers can’t check all aspects on their own:

  • Static memory usage can easily be checked in the map files but dynamic allocation and stack usage can’t be checked that easily.
  • Even if we could reverse engineer some aspects, we have no guarantee it won’t change in the future. For example BB_RAM (16K) is reserved for the BLE stack, but maybe the light stack version requires only 8K and guaranties it won’t use the second 8K bank. I don’t know if this is true, but if it is (and guarantied for the future) then the second 8K bank of BB_RAM could safely be used by the Cortex M3…

Could the ON Semiconductor stack experts provide more details in future SDK?

@rvs Hello,
Thank you for your constructive feedback in a reply !

Hi @rvs

AFAIK the BLE stack memory allocation in the BB_RAM regions is static too.
There are Exchange Memory Map files that define memory usage based on stack configuration.
These can be found in the bb/em_map.h and bb/em_map_ble.h files.
This way you should be able to use the value of EM_BLE_END macro to see if it is past the boundary of the first 8KB BB_RAM block.

There is still the dynamic memory part but that seems to be more application dependent.
Peripheral server with large ATT database might have problem while a broadcaster can fit in 8KB without issues.

I did use the light stack before and was able to run a broadcaster beacon application with just 8KB DRAM + 8KB BB_RAM.

Best regards,

1 Like