How do I wait until a response come after data sent through UART module of nRF51822?

[Rifat Mahmud]

On a BLE_GAP_EVT_CONNECTED, I'll send some data to an attached microcontroller via UART. The code will expect a response of that data, all while being inside that BLE_GAP_EVT_CONNECTED switch block. Can anybody please share a code snippet to do that? Your help is greatly appreciated. Thanks in advance.

[RK]

why on earth would you want to block during the processing of an event most likely in an interrupt handler while waiting for a peripheral to talk to you? It's not like the connect event has a return of any sort you have to send back synchronously, nor does blocking there stop the device on the other side sending data and doing things with the connection, it's just a notification of one event.

Should you really want to do that then send your data, poll the UART until you get what you want and then continue .. but don't do it like that .. use the UART driver Nordic provides and do the whole thing asynchronously when you get the data back

[Rifat Mahmud]

The reason I am trying to this is because, after a connection is made to the nRF51822(which will be a GAP Peripheral/GATT Server) by a mobile app(GAP Central/GATT Client), I want to check the ID of that central/client as soon as possible(with the help of the microcontroller), and disconnect if the ID is not matched to our pre-specified database. So, I want the process to be blocking intentionally. I know, there's whitelisting, but for multiple reasons, I have to avoid it.

[Rifat Mahmud]

It would be great if you can point to an example where polling UART is demonstrated. As far as I am concerned, it'll go to another asynchronous event, when an incoming UART comes in. But, I want it to be inside the switch block.

[RK]

As I pointed out in the first comment, blocking during the processing of the connect event does absolutely nothing for your use case. The softdevice is merely notifying you that a connection has been made, blocking during the processing of that notification does not stop the softdevice servicing the central on the other side which can continue to query the chip, scan for services, perform discovery and attempt to read characteristics. You will of course get the usual callbacks when the thing actually tries to read, if you have the flags set, and not replying to those until you've determined that the original connection was ok, will prevent it actually getting any data.

Blocking in the event handler, vs waiting for the async reply, will have exactly the same effect in terms of when you get to close the connection.