Connection Manager

The Connection Manager handles all the layers of the Bluetooth protocol stack from RFCOMM downwards.Without a Connection Manager, you would need to establish ACL links, configure the links for RFCOMM, set up and configure L2CAP links, and finally set up an RFCOMM link.With a Connection Manager, you can have all the layers you need set up and configured with a single call.

Most applications which send data will want to use RFCOMM connections, but for those who need to get in at a lower level, the BlueLab Connection Manager allows your application to send L2CAP packets as well as RFCOMM packets. (L2CAP is the lowest level of the Bluetooth Protocol stack that an application will send data to, since all user data on Bluetooth links has to be sent as L2CAP packets.)

Packets are sent on a connection, and every connection has to lead to some peer device, so, naturally enough, before any packets can be sent, the Connection Manager must be paired with a peer device.

The section on tasks and message queues mentioned that Task/Message Identifier 0 is reserved for the Connection Manager, and Task/Message Identifier 1 is reserved for the Application Framework.The practical effect of this is that whenever your application sends a message to the Connection Manager, it will send it to

MessageQueue 0, and whenever you get a message back from the Connection Manager, it will come back on MessageQueue l.This rule on message queue numbers applies whether the message is control information, or data packets.

The Connection Manager's messages are all declared in cm_rfcomm.h..The Connection Manager itself is implemented in the CM_RFCOMM library: libcm rfcomm.a.

Developing & Deploying...

Receiving Messages from Multiple Sources

Some tasks will have to receive messages from several sources. One example is the application framework, which sits between an application and the Connection Manager and has to communicate with both.

Message types are just integers, so when the framework gets a message of type 5, it could have trouble deciding whether the message is a "data_indication" from the Connection Manager or a "close_request" from the application! There are two approaches to solving this problem:

1. Choose message type numbers so there is never any overlap between message type numbers going to the same task.

2. Ensure that the payloads of messages sent to the framework always contain a "source" field which is filled in before the message is sent.

Many embedded messaging systems provide a mandatory "source" field on all messages. This solves the problem of messages from multiple sources, but wastes valuable memory from the scare dynamic-block budget, so BlueLab leaves it up to the application programmer to decide when these identifiers are appropriate. In many cases, it will be possible to solve the problem using unique message type numbers, thus minimizing message size and saving memory.

Was this article helpful?

0 0

Post a comment