Serialization is designed in a way that allows the same application code (the main.c file) to be used either on a single chip with a SoftDevice or as application in a serialized system.
If you want to run the application in a serialized system, the application chip must contain serialization libraries in addition to the application itself. These serialization libraries access device-specific resources. Therefore, you must provide device-specific drivers to run a serialized application on the target system. To get started, use one of the serialized example projects for the nRF5 chip that are provided by this SDK. See the following information for details about which resources and corresponding drivers you must provide.
Some common serialization modules that use MCU hardware do not depend on the chosen physical transport layer. The following table below lists these modules and states which corresponding API must be implemented.
| Module | Hardware | IRQ | API | Description |
|---|---|---|---|---|
ser_app_hal_nrf5x.c | - | SW_IRQ2 | Serialization Application Hardware Abstraction Layer (HAL) | This module uses SW_IRQ2 to notify the BLE application of events generated by the SoftDevice. You must port this module using the available software interrupt. |
app_timer.c | RTC | SW_IRQ0, RTC_IRQ | Application Timer | The Application Timer is used in some examples. You must port this module using the available timer. |
app_mailbox.c, app_scheduler.c | NVIC | - | Utility Functions and Definitions (Platform) | You must provide an implementation of the critical_region_enter() and critical_region_exit() functions. |
In addition, you must port the modules that depend on the physical transport layer (PHY) that you use.
UART PHY
For serialization using UART PHY, you must provide a UART hardware driver to substitute the nrf_drv_uart.c driver (shown in Figure 1). This driver must implement part of the UART driver API. Additionally, you must port the ser_phy_uart.c upper-layer driver, because this driver contains module interrupt enabling and disabling.
UART_HCI PHY (reliable UART)
Similarly as for UART PHY, you must provide a UART hardware driver for UART_HCI PHY to substitute the nrf_drv_uart.c driver (shown in Figure 2). This driver must implement part of the UART driver API. UART_HCI has two upper-layer drivers that must be ported: ser_phy_hci_slip.c and ser_phy_hci.c. The latter uses the hardware TIMER and its interrupt TIMER_IRQ.
SPI PHY
For SPI PHY, you must provide two hardware drivers: an SPI Master driver and a GPIOTE driver (as shown in Figure 3). These drivers must implement parts of the SPI master driver and GPIOTE driver APIs. The GPIOTE driver driver nrf_drv_gpiote.c is responsible for edge detection on REQ and RDY input lines, which are used for flow control. This driver uses GPIOTE_IRQ. The SPI master driver nrf_drv_spi.c uses SPI_IRQ. Additionally, ser_phy_spi_master.c uses another software interrupt (SW_IRQ3) for scheduling of lower-priority events.
