The Bluetooth LE stack comprises a three-layer Controller (which includes the hardware, also known as the physical layer or PHY), and three-layer Host. There is nothing to stop anyone coding a Bluetooth LE stack; but it’s impractical for most developers to even start. The stack's complexity demands years of coding experience and even when the code is written the software will need long periods of debugging, testing, and verification. A much more practical route for wireless product developers is to select a silicon vendor’s PHY and marry it with the same company’s own firmware for a complete solution. (Some companies combine their hardware with a third-party’s firmware stack and sell it as their “own” product. Such a union can result in a satisfactory solution but can lead to customer problems later if the silicon and software vendors part company.)
It’s perhaps not surprising Nordic’s firmware has a good reputation. The company has been producing Bluetooth LE stacks for nearly a decade and each goes through an exhaustive testing, debugging, and verification regime before being released. Nordic offers a range of stacks to suit all applications culminating in the S140, (the firmware that accompanies the high-end nRF52840 System- on-Chip (SoC)) a Bluetooth 5-certified stack for building long-range and high-throughput Bluetooth LE applications.
During compilation, the application code and Bluetooth LE stack are interlinked for combined operation. Datasheet images of the Bluetooth LE stack illustrate the application layer neatly positioned atop the stack. It’s a nice abstract but with most vendors, the compilation inextricably entwines the stack code
with the application code. Such entanglement can make debugging a nightmare and extends the development process.
It is also a drawback in the field because over-the-air (OTA) updates require the entire application/stack package to be overwritten. That takes longer, risks corruption of the software, and requires extra (expensive) on-chip Flash memory to handle.
Better yet, because the prequalified SoftDevice is unchanged,
it requires no Bluetooth requalification when development is complete. Figure 1, which shows the application code separated from the SoftDevice and only linked where necessary for efficient operation, is a much closer representation of the real situation than other vendors’ stack abstracts.