The potential memory consumption of S130v2 is much lower even than that of S110 which we currently use. (absolute minimum: applications starts at 0x200013C8 compared 0x20002000 now and 0x20002800 for S130 - if I'm correctly reading http://infocenter.nordicsemi.com/pdf/S130_SDS_v2.0.pdf )
Unfortunately, the mbed platform we're based on is still using S130v1, mbed's newer unified nRF5x platform uses S130v2. However, it would be good to do an initial analysis of how much memory could be saved by running S130v2.
There are a decent number of changes in s130v1 versus S130v2 including how the BLE stack is initialised, and the SVC numbers. So - it'd be necessary to swap in the headers from a later SDK version into the nrf51822 lib that the DAL uses, rather than just drop a new SoftDevice hex in.
The potential memory consumption of S130v2 is much lower even than that of S110 which we currently use. (absolute minimum: applications starts at 0x200013C8 compared 0x20002000 now and 0x20002800 for S130 - if I'm correctly reading http://infocenter.nordicsemi.com/pdf/S130_SDS_v2.0.pdf )
Unfortunately, the mbed platform we're based on is still using S130v1, mbed's newer unified nRF5x platform uses S130v2. However, it would be good to do an initial analysis of how much memory could be saved by running S130v2.
There are a decent number of changes in s130v1 versus S130v2 including how the BLE stack is initialised, and the SVC numbers. So - it'd be necessary to swap in the headers from a later SDK version into the nrf51822 lib that the DAL uses, rather than just drop a new SoftDevice hex in.