The latest S110 v7 softdevice uses 88 kB flash and 8 kB of static RAM for S110 leaving 168 kB of flash and 8 kB of RAM for the application (for the 256k chip). Also note that S110 v7 can use over 1.5 kB of stack, so you must make sure that your stack is big enough to accomodate both this and your application’s requirement.
Lastly, when you use the S110, it also restricts many of the Programmable Peripheral Interconnect (PPI) channels, leaving on 8 channels free for the application code. This restricts how you implemet peripherals such as PWM and I2C.
The DW test program which simply handles ranging provides a rough estimate for the code we will need to talk to the DW chip from the Nordic. It uses 68K flash, 6.5K of RAM.
So before we get to write any application code our memory footprint looks like this:
BLE DecaW TOTAL
Flash 88 + 68 = 156K
RAM 8 + 6.5 = 14.5K*
*This does not account for stack, or heap. The BLE call stack can need 1.5K by itself which could drive our RAM footprint up to 16KB, which is all we have on the current module.
We have about 100KB left for code development which I’m estimating will become a headache by itself in about a year. Apart from actual application code, we have to include driver code for the other chips, which could take another 30%.
The DW code is compiled under -O0 (no optimization). Optimaztion may save 10%. There may well be a bunch of drivers and library routines that have been eroneously dragged into my DW test compilation, and are not used. Maybe we can save another 10%
RAM is going to be tight, until we get the 32KB modules. Flash is not an immediate issue, but two factors will quickly make it one: other device drivers (IMU/Bat monitor); Storage for sensor/range data. I think off-chip memory is on the near horizon.