Implementing Bluetooth technology - in C/C++ code.

The pairing, connect etc are all done by GAP messages. In the diagram below, you can see that those messages are ultimately converted down to a payload that is wrapped with a header and checksum, and then launched over the air to the remote device. There will be a state machine that is executed on both devices, to get through the entire negotiation sequences, i.e. the protocol is implemented with those state machines. Everything in the large blue box is within the Bluez library. It is indeed complicated to follow and has poor documentation, but it does work, and there's not much choice, it is what it is. It would be a very large effort to write your own implementation from scratch, because there are tens of thousands of pages of Bluetooth documentation to look through.

Regarding the second question, there are several manufacturers who have implemented this in firmware for their devices. It's very old technology, google 'serial port profile'. If you wish to do it using modern BLE (i.e. Bluetooth LE) then the answer is usually proprietary, since it's not defined in the standard. You could look at typical example devices like Silabs
BGM220P, and the website offers example code to implement serial communication over BLE ( https://github.com/SiliconLabs/bluetooth_applications/tree/ea5d14cc4884a6d8f5c3af4345d430716433e72d/bluetooth_serial_port_profile  ) . But because that's proprietary, you'd have to hope there are drivers for it for the PC (or whatever hardware you are using), if you're not using their devices at both ends of the communication link. 

Thanks for replies , but that is NOT what I am asking about.

This approach is all wonderful theory  of "Bluetooth stack", no argument there. I am asking for how to follow the "Bluetooth stack" process using  ACTUAL C code.

Here is a "work in progress" code snippet :

pET->start();
dev_id = hci_get_route(NULL);
text = "dev_id \t";
text += QString::number(dev_id);
m_ui->textEdit_37->setText(text);
m_ui->textEdit_52->append(text);

sock = hci_open_dev( dev_id );
if (dev_id < 0 || sock < 0) {

...

// actuall scan restart timer
pET->start();

num_rsp = hci_inquiry(dev_id, len, max_rsp, NULL, &ii, flags);
if( num_rsp < 0 )
{
text = "\t\t\tERROR no devices found ";
m_ui->textEdit_37->append(text); // local
m_ui->textEdit_52->append(text); // TRACE

So my question would be :
"how do "hci_get_route" and "hci_inquiry"  functions implements / fits into the above "blue box" ,  or similar "blue box" for standard Bluetooth stack?

PS.

I understand there are differences between "standard" and "LE" Bluetooth implementation. I am pretty much stuck with "standard" due to my available hardware.

PPS.

I am still searching for current bluez version source code to analyze "hci_inquiry"  function...

Thats a pretty rude response from you when someone is trying to help.

It is not my fault you have trouble articulating what you actually want to know.

So my answer will be brief, and you can figure out the rest yourself.

Your snippet of code is already at the lowest level in the BlueZ stack. The aircraft has not taken off yet. The code is operating at the bottom of the blue box.

You're not going to be able to see the C code of what then occurs at a lower level, because that's going to run within hardware/firmware on the Bluetooth processor, not the PC. The state machine that churns away to work at that lower level is inside the Bluetooth processor.

You can google for an explanation of HCI to understand this. No links, because I'm leaving that to you to figure out. You might also want to pick up some competence at responding in a polite manner.

Thats a pretty rude response from you when someone is trying to help.

It is not my fault you have trouble articulating what you actually want to know.

So my answer will be brief, and you can figure out the rest yourself.

Your snippet of code is already at the lowest level in the BlueZ stack. The aircraft has not taken off yet. The code is operating at the bottom of the blue box.

You're not going to be able to see the C code of what then occurs at a lower level, because that's going to run within hardware/firmware on the Bluetooth processor, not the PC. The state machine that churns away to work at that lower level is inside the Bluetooth processor.

You can google for an explanation of HCI to understand this. No links, because I'm leaving that to you to figure out. You might also want to pick up some competence at responding in a polite manner.