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 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?