nrf51 S120 uart communitcaion

Question

Hi ,
I am planning to implement S120 UART to communicate with desktop as well as S110 UART BLE. 
 I browsed in the forum and found out we already have example in github.com/.../ble_app_uart_c_S120 . when I tried to use it with the latest SDK9.0 Keil 5 IDE and lastest softdevice of 120 2.1.
I got lot of error mainly gpiote conflict.. Then I browsed in the forum and found out there is patch for moving from sdk 8.0 to sdk 9.0 in devzone.nordicsemi.com/.../ 
so i followed the changes in gpiote & nrf_drv_gpiote.c .finally I am able to compile it. when I flash the application software all the led ON . meaning assert something wrong with the changes. 
 Then I revert back the changes. I copied the ble_app_hrs_c folder & excluded the hrs_c file and included uart_c files in ble services and changed the main.c 
 I comment out APP_GPIOTE_INIT(1)
and flashed the program.it worked. I am able to see "scanning..." communication. I am able to connect with BLE Server as well.
APP_TIMER_INIT(APP_TIMER_PRESCALER, APP_TIMER_MAX_TIMERS, APP_TIMER_OP_QUEUE_SIZE, NULL);
 //APP_GPIOTE_INIT(1); 
err_code = bsp_init(BSP_INIT_LED | BSP_INIT_BUTTONS, APP_TIMER_TICKS(100, APP_TIMER_PRESCALER),NULL);
APP_ERROR_CHECK(err_code);
leds_init();
timers_init();
uart_init(); 
 Now my question is
1.do we have any effect if I don't include APP_GPIOTE_INIT(1)
2. I am planning to implement discovery,connection,pairing,bonding,unbonding & disconnection in my GUI.will be please point me the function call to do this orelse any document which explains the software architecture.
3. After discovery I am planning to list discovered devices in GUI. where can I use the printf to get the related information ?
please guide me I am new to this forum as well as Nordic.
even a small information is very useful to me. 
 Thanks and Regards
Lakshman,PMP,PMI-RMP

Anders Strand · Accepted Answer

Hello. 
 You can safely drop gpiote . It stands for General Purpose Input Output Tasks & Events. It is used for linking gpio pins to various things. 
 The nan36 application note goes trough making a custom BLE peripheral application. This might not be directly relevant for your central application development, but it might give you some insights on how our system is built up. 
 If you want to send discovered device info to a computer, you can use uart. (printf is in many examples linked to the uart). 
 Other resources:
Our documentation portal (Infocenter)
. DevZone Tutorials 
 
 EDIT: 
Briefly on how to scan, connect, disconnect, discover services and bond as a central device using the ble_uart_c github example. This is an initial "brain-dump" to help you gain some understanding. This post might by edited and updated in the future. It will also soon be extended to a tutorial to be found in the tutorial section. 
 Scanning 
 Scanning is started by calling scan_start() . This functions sets up the scan parameters (interval, scan window length etc) and finally calls the softdevice function sd_ble_gap_scan_start(&m_scan_param); with these parameters. 
 Scan results (advertisement packets from nearby BLE devices) are arriving to the application as BLE events. These events comes in trough the ble_evt_dispatch(ble_evt_t * p_ble_evt) function which passes ble event on to any module that needs them. In this case, the module which is relevant is our application in main. Here we find the on_ble_evt(ble_evt_t * p_ble_evt) function. This function contains a large switch case based on event type.
The case BLE_GAP_EVT_ADV_REPORT events contains advertisement packets from the scan. Use the adv_report_parse(uint8_t type, data_t * p_advdata, data_t * p_typedata) function to extract what data you want from the advertisement packet (henceforth advdata). This function puts the data you asked for in the provided p_typedata buffer, and returns an error code based on whether or not the requested data was found. The different data types are defined in ble_gap.h. 
 Based on what you find in the advdata, you can decide if you want to connect or not. 
 
 Connecting 
 You connect by called this function: err_code = sd_ble_gap_connect(&p_gap_evt->params.adv_report.peer_addr,&m_scan_param,&m_connection_param); .
If all goes well, you receive a BLE_GAP_EVT_CONNECTED ble event.
As all events are, this ble event is passed to several modules trough ble_evt_dispatch(ble_evt_t * p_ble_evt) . In on_ble_evt , no action is taken on the connected-event. In the rest of the event handlers called from ble_evt_dispatch , the event leads to various actions. In most of them, the connection handle is saved to the appropriate structure. 
 The device manager is the module responsible for handling our relationship with other devices, for example bonding and pairing. 
 
 Discovering services 
 In the Device Manager, the connection event is handled and a callback to the applications' device_manager_event_handler() is called.
This is a common flow in our SDK: BLE event -> Module event handler -> Callback to application event handler for that module. 
 We see here that on the DM_EVT_CONNECTION event, the function ble_db_discovery_start is called. The db_discovery module is a module that handles service discovery for us. We first initialize it in main(), and then call this start function to start a discovery after connection. 
 When the db_discovery module has completed its service discovery, the module will call the db_discover_evt_handler function inside ble_uart_c.c. This callback was registered in ble_uart_c_init() with the call ble_db_discovery_evt_register(&uart_uuid, db_discover_evt_handler); 
This event handler will notify our application through the uart_c_evt_handler() function inside main.c. The event will be BLE_UART_C_EVT_DISCOVERY_COMPLETE .
Here we see an extended event flow: BLE event -> Module event handler ->Service event handler -> Callback to application event handler for that service.
If you want to extract the data from the service discovery, look inside db_discover_evt_handler in ble_uart_c.c. The discovery result is within the ble_db_discovery_evt_t * variable p_evt. 
 
 Disconnecting 
 You can call the softdevice call sd_ble_gap_disconnect(uint16_t conn_handle, uint8_t hci_status_code)); To disconnect from a device. The hci status codes can be found here . 
 
 Bonding 
 Bonding is the action of storing pairing keys in permanent storage. This is done by the Device Manager by calling the dm_security_setup_req() function. 
 
 Unbonding 
 This is something you do internally in your device. If you delete the device from the permanent storage, it is in practice "unbonded". The device manager module has a function dm_device_delete() which can be used for this purpose.