BLE serialization is designed in a way that allows the same BLE 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 BLE example projects for the nRF51 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_nrf51.c`	-	SW_IRQ2	Serialization Application Hardware Abstraction Layer	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 BLE examples. You must port this module using the available timer.
`pstorage_nosd.c`	NVMC	-	Flash Manager	The Persistent Storage Interface requires access to a non-volatile memory. You must provide a driver for such memory.
`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 app_uart.c driver (shown in Figure 1). This driver must implement part of the UART module API. Additionally, you must port the ser_phy_nrf51_uart.c upper-layer driver, because this driver contains module interrupt enabling and disabling.

Figure 1: Resources and drivers required for serialization using UART PHY

UART_HCI PHY (reliable UART)

Similarly as for UART PHY, you must provide a UART hardware driver for UART_HCI PHY to substitute the app_uart.c driver (shown in Figure 2). This driver must implement part of the UART module 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 interrupts TIMER_IRQ.

Figure 1: Resources and drivers required for serialization using UART_HCI PHY

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 Handler APIs. The GPIOTE Handler drive rapp_gpio_fast_detect.c is responsible for edge detection on REQ and RDY input lines, which are used for flow control. This driver uses two interrupts: GPIOTE_IRQ and SW_IRQ1. The SPI Master driver spi_master.c uses SPI_IRQ. Additionally, ser_phy_nrf51_spi_master.c uses another software interrupt (SW_IRQ3) for scheduling of lower-priority events.

Figure 1: Resources and drivers required for serialization using SPI PHY