Compiling NCP and Host Applications#

Compiling the NCP Application#

The procedure for compiling the NCP application is identical to that for any other Connect-based EFR32 application. Use the project configurator if any configuration of the "stock" examples is necessary (radio parameters, components, etc.).

Compiling CPCd and the Host Application#

Documentation on how to compile CPCd and the Host application can be found in the readme file of their github repositories:

• https://github.com/SiliconLabs/cpc-daemon

• https://github.com/SiliconLabs/Connect-NCP-Host

Modifying Host Application or Building One from Scratch#

The Connect stack API available to a Host application is nearly identical to the API in an SoC application, with the exception of a few calls that make sense only on one or the other. Functions are invoked with the same arguments and generate the same return values, the same callbacks, and events govern stack behavior, etc. Therefore, when developing an NCP mode system, interaction with the Connect stack API by the Host application is largely identical to the development experience for an NCP application.

One important difference is that the host application doesn’t save the security key. Since we don’t have a uniform secure key storage on Linux, we leave it to the user to implement it according to their security requirements. The host application loads the default dummy key at boot (all 0xA) and can be changed via a CLI command.

We recommend implementing host applications by building on the connecthost library (which can be built from the previously mentioned github repository), and the APIs are implemented in connect/ncp.h and connect/callback_dispatcher.h. The host application should always start with calling sl_connect_ncp_init() which will initialize the connection to the secondary (i.e. the EFR32).

A host application should periodically call sl_connect_poll_ncp_messages() in a separate thread. This will store the data from the secondary (typically return values and callbacks) in a queue on the host side. To process the queue, the host should call sl_connect_ncp_handle_pending_callback_commands() from another thread, which will deserialize the message and call the callback functions.

For more details on the usage of the connecthost library, see the documentation on its github page.