Useful coding references for nRF52840 microcontrollers
Variable Declaration
Variable signed char, int8_t unsigned char, uint8_t signed short, int16_t unsigned short,uint16_t signed int, int32_t unsigned int, uint32_t signed long, int64_t unsigned long, uint64_t
Useful Basic Function
nrf_delay_ms(500); //delay in msec bsp_board_init(BSP_INIT_LEDS); //initialising LED bsp_board_led_invert(0); //toggle LED nrf_gpio_pin_set(LED_1); or bsp_board_led_on(0); nrf_gpio_pin_clear(LED_1); or bsp_board_led_off(0); LED_1 = NRF_GPIO_PIN_MAP(0,13)
UART
//UART initialisation
const app_uart_comm_params_t comm_params =
{
RX_PIN_NUMBER,
TX_PIN_NUMBER,
RTS_PIN_NUMBER,
CTS_PIN_NUMBER,
UART_HWFC,
false,
#if defined (UART_PRESENT)
NRF_UART_BAUDRATE_115200
#else
NRF_UARTE_BAUDRATE_115200
#endif
};
APP_UART_FIFO_INIT(&comm_params,
UART_RX_BUF_SIZE,
UART_TX_BUF_SIZE,
uart_error_handle,
APP_IRQ_PRIORITY_LOWEST,
err_code);
APP_ERROR_CHECK(err_code);
uint8_t cr; //declare byte
app_uart_put(cr); //send byte
app_uart_get(&cr); //get byte
printf("\r\nUART example started.\r\n"); //print to UART
nRF5x Project Structure
All the function is written in a manner that is portable and general purpose coding. This may make it very difficult to read and understand. But basically, it works like PIC microcontroller where each pin or peripheral can be individually configure.
The entry point to the program is at “main.h” -> “int main(void)”.
Hardware specific “fixed” configuration are all done in “pca10056.h“. All pins input/output definition are configured in this file which is very specific to this designed pca10056 circuit board.
“boards.c” contains generic codes for managing the LED and Push Buttons codes.
Project (Solution) specific codes will be under the Application folder. Usually consist of “main.c” where the code starts, and “sdk_config.h” where are the configuration of the application will be.
Function that starts with sd_XXXXXX(), these are the basic functions provided directly from softdevice API module.
Function that starts with nrf_XXXXXX(), these are functions by nRF encapsulation softdevice API sd_XXXXXX().
Data type naming convention ends with XXXXXX_t
sec - security conn - connection lbs - led button service ble - Bluetooth low energy params-parameters auth - authorised evt - event adv - advertisement lesc - LE security len - length gattc_evt- GATT client event gatts_evt- GATT server event
Peripheral useful for projects
More information of the examples project can be found at
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fexamples.html
More information about the library used in the example, refer to the SDK Library reference notes,
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_nrf5_latest.html
- Digital IO pins (project “blinky“)
- Pin Change Interrupt (project “pin_change_int“)
- UART (project “uart“, “serial“)
- Timer (project “timer“, “gpiote“)
- Pin Change Interrupt (project “pin_change_int”)
- Power Management (project “pwr_mgmt”)
- SPI (project “spi“)
- PWM (project “led_softblink“, “low_power_pwm“)
- Watch Dog Timer (project “wdt”)
- Low Energy Bluetooth BLE
- USB BLE UART
- USB HID
Pin maps for the nRF52840-DK board examples demonstration
| Peripherals | Pin out in the nRF52840 example demo |
| LED1 | P0.13 |
| LED2 | P0.14 |
| LED3 | P0.15 |
| LED4 | P0.16 |
| SW1 | P0.11 |
| SW2 | P0.12 |
| SW3 | P0.24 |
| SW4 | P0.25 |
| UART-RX | P0.08 |
| UART-TX | P0.06 |
One of the more important BLE event function
This ble_evt_handler() is callback whenever the BLE events occurs. The lower level will be called and propagated up to our application level through ble_evt_handler() where we will handle the BLE message.
For interrupt there are a total of 4 levels. Highest interrupt priority is taken by SoftDevice, the next level is by the application. Followed by a lower priority SoftDevice, then the lowest priority to the application.
How interrupts are handled by SoftDevice.
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fprocessor_avail_interrupt_latency%2Fexception_mgmt_sd.html
/**@brief Function for handling BLE events.
*
* @param[in] p_ble_evt Bluetooth stack event.
* @param[in] p_context Unused.
*/
static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)The path of the incoming data event (BLE_GATTS_EVT_WRITE) start from
ble_conn_params.c->ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context),
then followed by
ble-lbs.c->ble_lbs_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
then
main.c->ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
For the event object p_ble_evt, the data structure is very large. But not all data in the structure are valid. It depends on the event that had took place. Read only that section of the structure. nRF simply lump everything into this single data structure. In actual fact the data communication isn’t so large.
nRF Object Class Documentation
Application Level
---------------------------
ble_lbs_c.c
- LED Button Service modules
Middle Level
---------------------------
nrf_ble_gq.c
- GATT request queue module. Commands from application to SoftDevice are put to a queue system here
Close to SoftDevice Level
---------------------------
nrf_sdh.h
Low Level (Hardware)
---------------------------
boards.h, pca10056.h, bsp.h
- hardware board related. Board Support Package
nRF Singleton Object Instance
m_ represent singleton object. m_ble_lbs_c - LED Button Service object for the Central device m_scan - BLE scanning object m_gatt - GATT object m_db_disc - DB Discovery object m_ble_gatt_queue - GATT queue object
p_ represent pointer to object
//Explore Variable p_ble_evt
// p_ble_evt
// header
// evt_id //type of Bluetooth events
// evt_len
// evt
// common_evt //common event
// conn_handle
// params
// user_mem_release
// user_mem_request
// gap_evt //GAP originated event
// conn_handle
// params
// adv_report
// adv_set_terminated
// auth_key_request
// auth_status //(ble_gap_evt_auth_status_t)
// auth_status //< Authentication status, see @ref BLE_GAP_SEC_STATUS.
// error_src //< Authentication status, see @ref BLE_GAP_SEC_STATUS.
// bonded //< Procedure resulted in a bond.
// lesc //*< Procedure resulted in a LE Secure Connection.
// sm1_levels //< Levels supported in Security Mode 1.
// lv1
// lv2
// lv3
// lv4
// sm2_levels //< Levels supported in Security Mode 2.
// lv1
// lv2
// lv3
// lv4
// kdist_own //< Bitmap stating which keys were exchanged (distributed) by the local device. If bonding with LE Secure Connections, the enc bit will be always set.
// enc
// id
// link
// sign
// kdist_peer //< Bitmap stating which keys were exchanged (distributed) by the remote device. If bonding with LE Secure Connections, the enc bit will never be set.
// enc
// id
// link
// sign
// conn_param_update
// conn_param_update_request
// conn_sec_update
// connected
// data_length_update
// data_length_update_request
// disconnected
// key_presed
// lesc_dhkey_request
// passkey_diplay
// phy_update
// phy_update_request
// qos_channel_survey_report
// rssi_changed
// scan_req_report
// sec_info_request
// sec_params_request
// sec_request
// timeout
// gattc_evt //GATT client
// conn_handle
// error_handle
// gatt_status
// params
// attr_info_disc_rsp
// char_disc_rsp
// char_val_by_uuid_read_rsp
// char_vals_read_rsp
// desc_disc_rsp
// exchange_mtu_rsp
// hvx
// prim_srvc_disc_rsp
// read_rsp
// rel_disc_rap
// timeout
// write_cmd_tx_complete
// write_rsp
// gatts_evt //GATT server
// conn_handle
// params
// authorize_request
// exchange_mtu_request
// hvc
// hvn_tx_complete
// sys_attr_missing
// timeout
// write
// l2cap_evt //L2CAP, Logical Link Control and Adaptation Layer Protocol
// conn_handle
// local_cid
// params
// ch_sdu_buf_released
// ch_setup
// ch_setup_refused
// ch_setup_request
// credit
// rx
// tx
Naming convention used in nRF SDK BLE codes
....xxx_t => the "_t" defines the data object type.
scan_evt => scan event data to the main application
nrf_ble_scan => Bluetooth scanning parameters
ble_gap_evt_adv_report => Advertise Report object
ble_evt_t -> ble_gap_evt_t -> ble_gap_evt_adv_report_t
ble_gap_evt => GAP event
//Advertise Data
p_adv_report->data.p_data => Advertising data pointer
p_adv_report->data.len => Advertising data length
Example data:
03 19 00 00 02 01 06 0E |........
09 4E 6F 72 64 69 63 5F | Nordic_
42 6C 69 6E 6B 79 |Blinky
Advertise data starts (length of 22 of the whole packet)
This advertise packet consist of 3x Advertising Data (AD) elements
First byte 03 indicates the length of the first element which is 03 19 00 00.
19 is the AD type «Appearance»
00 00 is the data for Appearance which is unknown
The next set of AD element is 02 01 06.
First byte 02 indicates the length.
01 is the AD type for «Flags»
06 is the data for flags.
It indicates that BR/EDR is Not supported, and LE General Discoverable Mode is true.
The next set of AD element is 0E 09 4E 6F 72 64 69 63 5F 42 6C 69 6E 6B 79
0E is the total number of data bytes which is 14.
The AD type is 09, which stands for «Complete Local Name».
The data 4E 6F 72 64 69 63 5F 42 6C 69 6E 6B 79 represent "Nordic_Blinky" which is the name of the device.
The AD type code can be found on this page,
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/<- Back to Bluetooth Resources Page