Module BlueRNG de STM

Étude du réseau Bluetooth : j'ai implanté un module Bluetooth Low Energy de chez STMElectronics sur le circuit imprimé du Timer (Minuteur). Le module STxxx communique via une interface série SPI. La liaison s'effectue de la manière suivante :

Structure d’une commande

L’OpCode est transmis en mode LITTLE ENDIAN, c’est-à-dire l'octet de poids faible pour le premier byte suivi de l'octet de poids fort pour le second byte. Exemple : pour un OGF = 0x04 (Information paramètres) et un OCF = 0x01 (hci_read_local_version_information), la combinaison des deux 0001’0000’0000’0001 = 0x1001. L’OpCode sera donc transmis en 0x01, 0x10. Ci-dessous les différents types de groupes OGF.

Exemple: HCI_READ_LOCAL_VERSION_INFORMATION

Cette commande hci n’a pas de paramètre.

En bleu, l’en-tête (write) ; en rouge, HCI_COMMAND_PKT (Packet) ; en vert, l’OpCode (Little Endian) ; et en violet, le nombre total de paramètres en bytes. Il est parfois nécessaire d’envoyer plusieurs fois l’en-tête tant que le module ne répond pas par 0x02 pour indiquer qu’il est prêt et que le byte suivant est égal à zéro, ce qui représente la taille du buffer de réception.

Réponse à la commande ci-dessus.

Le module Bluetooth répond qu’il est prêt et qu’il a 0x0F (15) bytes dans son buffer. Après les cinq bytes d’en-tête, les trois suivants 0x04, 0x0E, 0x0C représentent : 0x04 indique qu’il s’agit d’un paquet de type Event, le byte suivant 0x0E indique le type d’Event (voir la liste ci-dessous), et le dernier 0x0C représente le nombre d’octets qui suivent.

On retrouve dans la réponse le HCI_COMMAND_PKT et l’OpCode de la commande hci_read_local_version_information en vert. Les derniers bytes fournissent les informations suivantes :

Exemple: ACI_GATT_ADD_SERVICE

Cette commande comporte plusieurs paramètres :

On reconnaît l’en-tête d’écriture suivi du HCI_COMMAND_PKT (0x01) et de l’OpCode (0xFD02). En violet, c’est le nombre de paramètres en octets ; dans cet exemple, 19 octets (0x13).

• 0x02Indique s’il s’agit d’un UUID sur 16 bits (0x01) ou 128 bits (0x02)
• 0x1BC5D5A50200B49AE1113ACF806E3602UUID
• 0x01Service type
• 0x07Maximum number of attribute records that can be added to this service

Réponse à la commande aci ci-dessus.

Dans la réponse, on reconnaît le HCI_EVENT_PKT (0x04) suivi du type (0x0E) et le nombre d’octets de paramètres (0x06). Ensuite, on retrouve l’OpCode de la commande ACI (0xFD02).

• 0x00 Error status
• 0x000CService Handle

Service Handle. Lorsque ce service est ajouté, un descripteur est attribué par le serveur pour ce service. Le serveur alloue également une plage de descripteurs pour ce service à partir de serviceHandle à "serviceHandle + max_attr_records - 1". br> Ci-dessous la liste des types d’événements.

Liste chainée

Le module Bluetooth reçoit des paquets de données, comme dans le système Ethernet. Ces paquets doivent être assemblés et ils n’arrivent pas forcément dans l’ordre. Pour résoudre ce problème, il faut utiliser une liste chaînée. (La liste chaînée ne fait pas partie de cette étude !)

Phase d'initialisation et boucle principale de l'application.

Les principales étapes suivantes sont requises pour configurer correctement les périphériques BlueNRG-1 et BlueNRG-2.

• Adresse publique
• Adresse aléatoire
• Adresse privée

Initialisation de la couche GAP

Le Generic Access Profile (GAP) définit les rôles des composants maîtres et esclaves, comme les messages de signalement ou la découverte du réseau. Il y a deux méthodes de signalement dans le GAP :

• L'envoi de messages de signalement.
• L'envoi d'une réponse au scan du réseau (scan response packets).

Compréhension des messages Bluetooth Low Energy

Alors que ces deux types de messages ont le même format composé de 31 octets de données, seuls les messages de signalement sont obligatoires et envoyés à intervalles réguliers (plus la période est longue, plus la consommation est faible).

Lorsqu'ils les reçoivent, les autres composants peuvent demander l’émission d’un message de réponse au scan (scan response packet) avec d’éventuelles données supplémentaires.

La diffusion de messages de signalement personnalisés est la méthode utilisée par l’iBeacon et la norme Eddystone. À chaque fois qu’une connexion est établie avec un composant esclave, les liaisons se font grâce à un service GATT avec ses caractéristiques. Les messages de signalement cessent tant que la connexion n’est pas terminée.
La couche GAP introduit 4 rôles :

• broadcaster
• scanner (ou observateur)
• peripheral
• central

Le broadcaster s'oppose au scanner, le peripheral s'oppose au central. Ce qu'il est fondamental de comprendre avec le Bluetooth Low Energy, c'est qu'il y a deux façons pour que deux appareils communiquent ensemble.
Le mode dit connecté, ou le mode advertising.

C'est ainsi que l'on fait le lien avec les deux types d'événements et les deux types de canaux radio introduits précédemment.

En mode advertising

En mode connecté

Le rôle de Broadcaster est destiné à des applications qui ne font qu'émettre. Les appareils supportant ce rôle envoient des événements d'advertising pour diffuser des données. Ce rôle ne supporte pas le mode connecté.

Le rôle de Scanner est dédié à des applications qui ne font que recevoir. Il s'agit du rôle dual de l'Observer. Un appareil basé sur ce rôle reçoit des données diffusées lors d'événements d'advertising. Ce rôle ne supporte pas le mode connecté.

Le rôle Peripheral est destiné à des appareils qui supportent une (ou plusieurs) connexions et sont moins complexes et plus contraints qu'un appareil avec le rôle Central. Un appareil avec un rôle Peripheral a besoin d'un Controller esclave (par opposition à maître).

Le rôle Central supporte plusieurs connexions avec différents appareils Peripheral ; un tel appareil est l'initiateur des connexions et a besoin d'un Controller maître. Il est doté de fonctionnalités plus complexes et plus coûteuses que le Peripheral.

Initialisation de la couche GATT

e Generic Attribute Profile définit comment le BLE transfère les données entre maîtres et esclaves dans les deux sens.
Il définit des profiles qui regroupent un ensemble de services. Chaque service a des caractéristiques qui correspondent aux données.

Les modes de fonctionnement peuvent changer quand on passe du GAP au GATT. Le GATT dispose de deux modes de fonctionnement : client ou serveur. Au risque de faire vieux jeu, les périphériques esclaves sont appelés « serveurs GATT » et les maîtres (plus puissants) sont des « clients GATT ».
Souvenez-vous : le serveur détient les données, le client veut les données. Toutes les connexions sont initiées par les clients.

À chaque nouvelle connexion, un client peut demander une liste des services fournis par le serveur. Le maître détient en effet en permanence une liste des services (pas forcément exhaustive) complétée grâce aux messages de signalement.

Le plus souvent, l'esclave est un serveur GATT et le maître est client GATT. Autrement dit, le serveur expose à un client des données, appelées attributes.
Les attributes, tels que définis par le protocole ATT, sont formatés soit en services, soit en characteristics.

La valeur incluse dans le characteristic est la valeur que le client cherche en pratique à récupérer, comme par exemple le nombre de battements cardiaques relevés par un capteur placé près du cœur.

Si toutes ces étapes se sont bien déroulées, on peut afficher "SERVER : BLE Stack initialized !!. Avant de détailler les services et les caractéristiques, il est maintenant nécessaire de créer une fonction permettant au GATT Client de découvrir le GATT Server nouvellement créé. Les périphériques esclaves ont deux modes de fonctionnement : en mode diffusion ou en mode liaison directe avec un composant maître.
Cette fonction vise à désactiver la réponse au scan (/* disable scan response */).

            /* Pour que le périphérique soit détectable par le maître, il faut faire appel à la fonction : */
            ACI_gap_set_discoverable(...)
        

Connexion

Une fois que l'appareil utilisé en tant que serveur GATT est rendu détectable, il devient visible pour le dispositif client GATT, permettant ainsi l'établissement d'une connexion BLE. Le dispositif client GATT utilise la commande GAP ACI suivante pour se connecter au serveur GATT en mode "Advertisement".

exemple:

            ACI_gap_create_connection(0x4000, 0x4000, 
                          PUBLIC_ADDR, bdaddr,
                          PUBLIC_ADDR, 9, 9, 0, 60, 1000, 1000);
    

La variable « bdAddr » est l’adresse du périphérique client GATT correspondant.
Lors de l'établissement de la connexion, le client retourne un événement avec les paramètres suivants : (EVT_LE_CONN_COMPLETE).

7.1 LE Connection Complete Event

Voici la réponse du client ci-dessus ! La variable status est 0x00, indiquant que la connexion avec le serveur a réussi. Une fois établie, le client peut lire les caractéristiques des services offerts par le serveur.

Création d'un service et des caractéristiques

Création d'un service sur le serveur : la fonction aci_gatt_add_serv(...)

Attention le nombre d'attribue et de trois par caractéristique et 1 pour le service !!

Modification d'une caractéristique.

Lecture d'une caractéristique

Sur le dispositif client génère l'évènement suivant pour lire une caractérisitique d'un service du serveur.

Ecriture d'une caractéristique

Ici, 'data' représente la valeur de l'attribut pointé par le handle RX_HANDLE contenu dans le handle de connexion 'connection_handle'. 'connection_handle' est le descripteur renvoyé lors de la création de la connexion, spécifié comme paramètre dans EVT_LE_CONN_COMPLETE.