Hardware Reference
In-Depth Information
• 16 KB SRAM (8 KB available to the application with the S110 BLE stack)
Being an entirely
flash-based
device is a key distinguishing factor of the nRF51822 for
product designers. This means that the BLE stack is written into modifiable flash mem‐
ory and can be updated as the core spec evolves, without necessarily requiring a new
silicon revision.
The down side of this choice is that it adds some additional per-device manufacturing
costs, compared to a ROM-based solution. But given the fast-paced development of the
Bluetooth Core Specification, the gamble might pay off in the long run, because it gives
Nordic the potential to get to market with support for the latest spec faster than other
silicon vendors who have opted for lower-cost ROM-based chips.
SoftDevice Architecture
In order to implement BLE support on its chips (which can also be used for non-BLE
standards, such as ANT+ and proprietary 2.4GHz protocols), Nordic makes use of
something it calls a
SoftDevice
(SD). The SoftDevice is essentially a black box that sits
in the bottom part of flash memory and implements features such as the BLE stack and
peripheral role support. The user (application) code sits at a higher address in flash
memory and makes calls to this lower-level SoftDevice as appropriate.
Most BLE products use the S110 SoftDevice, which is a peripheral-only solution. The
device architecture also includes a S120 SoftDevice that supports the
central
role, but
because that use-case is less common for BLE, the discussion in this section will focus
on the S110.
Nordic's SoftDevice design approach has its benefits and drawbacks. On the positive
side, having a separate, verified, reliable BLE stack in the form of a SoftDevice allows
firmware engineers to focus more energy on their application-level code. They can deal
with a smaller API and higher-level concepts such as GAP (
Chapter 3
) and GATT
(
Chapter 4
), leaving the lowest-level details to the SoftDevice (security implementation,
message validation, etc.).
The SoftDevice also allows firmware developers to avoid dealing with radio configura‐
tion themselves, which can be a significant part of the firmware development process
in most RF products. Turning these details into a black box protects firmware engineers
from making low-level mistakes and can significantly simplify the product validation
process, because the low-level BLE code is guaranteed to function according to the
Bluetooth Core Specification.
Another advantage of the SoftDevice approach is it allows one hardware design to sup‐
port multiple radio protocols or use cases, including the ability to design a custom
protocol, which might lower product costs in companies with multiple similar in-house
products based on a single PCB design.
