As part of the Smart-Its project we have designed and built a minimal computing and communication platform based on a Bluetooth module and a microcontroller with embedded memory. While the Bluetooth module offeres the generic Host Controller Interface (HCI) to the lower layers of the Bluetooth protocol stack, the higher L2CAP layer is implemented on the microcontroller.

News: As of June 13th, 2001, the Bluetooth stack (currently only HCI and L2CAP, SDP to come) is up and running. However, it is far from beeing a masterpiece of engineering and it is certainly not production quality! There will be a world-readable CVS repository in the upcoming weeks.

Platform Features

• Microcontroller Atmel ATmega 103L: 4MHz, 4MIPS, 4k ram, 128 flash, 4k eeprom, 3.3V: 5.5mA active, 1.6mA idle, 1uA powered down.
• Bluetooth module: Ericsson rok 101 007
• Analog in: 8 x 10-bit AD converter, can also be used as digital ins
• Digital i/o: 16-bit
• Interrupt lines: 3, edge or level triggered
• LEDs: 4
• Serial: 2 xUART, one hardware @ 57.6Kbps, one software @9.6 Kbps

Technical Note

The system software consists of low level drivers (2 serial ports, ADC, random number generator, system clock), a scheduler, and the bluetooth stack. Applications need to be linked against the system software code and then uploaded to the device.

Smart-Its applications are event driven. The scheduler allows application to register callback functions to be called upon certain events. Events currently supported are: data received on uart, uart ready to write data, timeout expired, and user events. The granularity of the timeout is roughly 250ms. If higher precision is required, the additional timer needs to be programmed on interrupt level. User events can be triggered by application code. They are useful to trigger a function being called from within a hardware interrupt. The scheduler only calls the function when it is save to do so.

The interface provided to the serial ports is equivalent to the UNIX read() and write() functions. In the microcontroller implementation, there are static values for the file descriptors.

Both bluetooth stack and scheduler are available for the Atmel AVR as well as LINUX. therefore applications typically run on both systems without modification.

Software Example

int main( void ) {

    SmartIts_init();
    // ...

    // register callbacks for uarts
    Scheduler_add_fd_read( UART_FD, data_received_on_uart  );

    Scheduler_run();

    return 0;
}  // end main()

void data_received_on_uart( int fd ) {

    unsigned char tmpbuf[128] = "";
    int  count = 0;

    count = read( fd, tmpbuf, 128 );
    write( fd, tmpbuf, count );

} // end data_received_on_uart() 

Axis Communications has developed a Bluetooth driver for Linux. Our microcontroller version of the stack is based on an earlier version of the stack. (At that time the source code was available under the Gnu Public License, GPL.)

I have pulled the stack apart, removed unwanted code and optimized the remaining layers (HCI, L2CAP, hopefully SDP soon) for memory consumption. As of June 13th, 2001 the stack is running, however it is far from beeing a masterpiece of engineering. There will be a world readable CVS repository in the upcoming weeks.

General

The L2CAP layer provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstractions. The L2CAP layer is based around the concept of 'channels'. Each one of the end-points of an L2CAP channel is referred to by a channel identifier.

A logic link at the L2CAP layer is referred to as channel.

Channel Identifier

Channel identifiers (CIDs) are local names representing a logical channel end-point on the device. CID assignment is relative to a particular device and a device can assign CIDs independently from other devices (with the exception of certain reserved CIDs, such as the signalling channel).

Connection oriented vs. connectionless data channels

The connection-oriented data channels represent a connection between two devices, where a CID identifies each endpoint of the channel. The connectionless channels restrict data flow to a single direction. These channels are used to support a channel 'group' where the CID on the source represents one or more remote devices.

The signalling channel is one example of a reserved channel. This channel is used to create and establish connection-oriented data channels and to negotiate changes in the characteristics of these channels. Another CID is reserved for all incoming connectionless data traffic.

L2CAP Layer Interactions

This state machine is only pertinent to bi-directional CIDs and is not representative of the signalling channel or the uni-directional channel.

Naming conventions:

• The interface between two layers (vertical interface) uses the prefix of the lower layer offering the service to the higher layer, e.g., L2CA.
• The interface between two entities of the same layer (horizontal interface) uses the prefix of the protocol (adding a P to the layer identification), e.g., L2CAP.

• Events coming from above are called Requests (Req) and the corresponding replies are called Confirms (Cfm).
• Events coming from below are called Indications (Ind) and the corresponding replies are called Responses (Rsp).

• Responses requiring further processing are called Pending (Pnd).

• The notation for Confirms and Responses assumes positive replies. Negative replies are denoted by a Neg suffix such as L2CAP_ConnectCfmNeg.

While Requests for an action always result in a corresponding Confirmation (for the successful or unsuccessful satisfaction of the action), Indications do not always result into corresponding Responses.

L2CAP State Machine

Service Primitives

• Connection (setup, configure, disconnect)
• Data (read, write)
• Group (create, close, add member, remove member, get membership)
• Information (ping, get info, request a call-back at the occurrence of an event)
• Connectionless traffic (enable, disable)

Protocol/ Service Multiplexing

Connection request packets are sent to create a channel between two devices. The connection request has two relevant parameters: the source Channel ID (CID) and the Protocol/Service Multiplexer (PSM).

The source CID parameter in the connection request is used as the destination CID in the connection response by the recipient of the request.
The PSM parameter is used for protocol multiplexing. Some PMS values are assigned by the Bluetooth SIG and indicate protocols. The second range of values are dynamically allocated and used in conjunction with the Service Discovery Protocol (SDP). PSM values must be odd (see BT spec V1.0B section 5.3 "Connection Response" and 4.2 "Connectionless Data Channel").

Note: Currently the Axis stack only supports psm values < 8. 7 is used for L2CAP testing.

Maximum Transmission Unit (MTU)

Maximum Transmission Unit (MTU): all L2CAP implementations must support a minimum MTU size of 48 bytes (regular and signalling packets). The default MTU size is 672 bytes (see section 4.1 and 6.1).