Bluefruit-LE-Shield-SDEP

De MCHobby - Wiki
Révision datée du 3 août 2017 à 20:55 par Admin (discussion | contributions) (→‎Sample Transaction)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Sauter à la navigation Sauter à la recherche


MCHobby investit du temps et de l'argent dans la réalisation de traduction et/ou documentation. C'est un travail long et fastidieux réalisé dans l'esprit Open-Source... donc gratuit et librement accessible.
SI vous aimez nos traductions et documentations ALORS aidez nous à en produire plus en achetant vos produits chez MCHobby.

SDEP (SPI Data Transport)

Le Bluefruit LE SPI Shield (et Firend) utilise le même ensemble de commande que les modules BlueFruit UART (ATI, AT+HELP, etc.).

Il a donc fallut mettre une solution au point pour que les commandes ATs puissent aussi être envoyées via le bus SPI.

Les commandes AT (du texte) sont donc encodées en messages binaires en utilisant un protocol nommé SDEP (Simple Data Exhange Protocol) par Adafruit.

Présentation de SDEP

SDEP à été conçu comme un protocole bus neutre pour gérer la transmission de commandes et réponses binaires -- incluant les messages d'erreur --. Le protocole est conçu pour être facile à étendre. Un protocole neutre pour bus (Bus neutral) signifie que nous pouvons utiliser SDEP quelque soit le mécanisme de transport (USB HID, SPI, I2C, Donnée via une connexion sans fil, etc.).

Tous les messages SDEP ont une entête de 4 octets et dans le cas des modules Bluefruit LE jusqu'à 16 octets de payload. Les grands messages sont coupé en plusieurs messages de 4+16 octets (appelés message chunks), ce qui permet de reconstruire le message de l'autre côté du bus.

La limite de 20 octets (4 octets pour l'entête + 16 octets de payload) a été choisi pour tenir compte de la taille maximal d'un paquet dans Bluetooth Low Energy 4.0 (20 octets par paquet).

Configurer SPI

Bien que SDEP soit prévu pour être un protocole neutre vis-à-vis du bus, dans le cas du Bluefruit LE SPI Friend ou du shield BlueFruit LE, le transport SPI est utilisé avec les contraintes et suppositions suivantes, principalement guidés par les limitations matérielles du nRF51822:

Conditions requises du SPI matérielles

  • Le signal d'horloge SPI doit être <= 4MHz
  • Un délais de 100µs doit être ajouté entre le moment où la ligne CS est activée et la transmission des premières données sur le bus SPI
  • La ligne CS doit rester activée (asserted) pour tout le paquet de donnée (et non activé pour chaque octet transmit)
  • La ligne CS peut cependant être activée ou désactivée entre l'envoi de différents paquets SDEP (chaque paquet ayant jusqu'à 20 octets max).
  • Les commandes SPI doivent être constituées pour une transmission MSB (most significant bit) en premier (le bit le plus significatif en premier).

Broche IRQ

La ligne IRQ est activée par le par le Bluefruit LE Shield (ou Friend) SPI dès que (et aussi longtemps que) un paquet SDEP complet est disponible dans la mémoire tampon (buffer) du nRF51822. Vous devriez lire le paquet lorsque l'IRQ (interruption) est activée, garder la ligne CS activée durant la transaction entière (comme détaillé ci-dessous).

La ligne IRQ reste activée aussi longtemps qu'un ou plusieurs paquets sont disponibles. Par conséquent, la ligne pourrait rester active après la lecture d'un paquet, cela signifie qu'il reste encore des paquets à lire dans la mémoire tampon FIFO du module SPI esclave.

FIFO est l'acronyme de First In First Out qui signifie "Premier Rentré Premier Sorti".

Paquets SDEP et identification des erreurs SPI

Une fois la ligne CS activée et le délai de 100µS écoulé, un simple octet devrait être lu sur le bus et ce dernier indiquera le type de payload (paquet) disponible sur le nRF51822 (Voir "Message Type Indicator" ci-dessous pour plus d'information sur les types de message SDEP). Gardez la ligne CS active après la lecture de ce premier octet au cas ou vous auriez besoin de poursuivre la lecture de données complémentaire (le restant du payload s'il fait plus d'un octet).

Si nous nous trouvons face à un "Message Type Indicator" SDEP standard (0x10, 0x20, 0x40 or 0x80) alors nous pouvons poursuivrez normalement la lecture

Il existe deux autre "Message Type Indicator" dont il faut tenir compte. Ces derniers indique un problème du côté esclave de la communication SPI (le nRF51822):

  • 0xFE : Le périphérique esclave n'est pas prêt (attendre un peu et réessayer)
  • 0xFF : Indicateur de dépassement de lecture (read overflow indicator) sur le périphérique esclave (il y a eu une tentative de lire plus de donnée que de donnée vraiment disponible sur l'esclave)

Cela signifie qu'il y a 6 réponses possible dansle premier octet lu (donc la valeur du "message type indicator" renvoyée par le périphérique esclave).

Ce premier octet après l'envoi d'une commande SDEP peut avoir les valeurs suivantes:

  • 0x10, 0x20, 0x40, 0x80 qui indiquent un type de message valide
  • 0xFE, 0xFF qui indiquent une condition d'erreur

Exemple de Transaction

L'image suivante présente un exemple de réponse SDEP qui est réparti sur deux paquets (étant donné que la taille de la réponse est > 20 octets). Notez comme la ligne IRQ reste active entre les deux paquets puisque plus d'un paquet était disponible dans la mémoire tampon FIFO sur le Bluefruit LE (côté esclave du bus SPI):

{{{2}}}
Crédit: AdaFruit Industries www.adafruit.com

SDEP - protocole d'échange de donnée simplifié

SDEP est l'acronyme de "Simple Data Exchange Protocol" qui signifie "Protocole simple d'échange de donnée".

SDEP peut être utilisé pour envoyer et recevoir des messages binaires entre deux périphériques connectés ensembles par l'intermédiaire d'un bus série (USB HID, USB Bulk, SPI, I2C, Wireless, etc.), échangeant des données en utilisant l'un des 4 types de messages disponibles (message de Commande, Réponse, Alerte et Erreur).

Le protocole est conçu pour pour être flexible et extensible, avec le seule exigence d'avoir des messages individuel de maximum 20 octets, et que le premier octet de chaque message est un octet/byte (U8) qui indique le type de message. Le type de message définit également le format du restant du paquet (payload).

Endianness

Endianness (wikipedia) est l'ordre dans lequel sont organiser les octets en mémoire et dans les communications lorsqu'ils transportent une informations d'une taille supérieure à 1 octet. C'est le cas des entiers qui se codent sur 16 ou 32 bits.

Dans le protocole SDEP, toutes les valeurs supérieures à 8-bits sont encodées avec le format little endian. Toute déviance à cette règle doit être clairement documenté.

Indicateur du type de message

Le tout premier octet de chaque message est un identifiant 8 bits appelé Message Type Indicator en anglais. Cette valeur indique le type message envoyé et permet de déterminer le format du restant du message.

Type de message ID (U8)
Commande 0x10
Réponse 0x20
Alerte 0x40
Erreur 0x80

Transactions de données SDEP

L'un ou l'autre des périphériques connectés peu initier un transaction SDEP. Néanmoins, certains protocoles de transport impose des restrictions concernant lequel "des périphériques" peut initier un transfert.

Par exemple, le périphérique maître initie TOUJOURS les transactions avec le Bluetooth Low Energy ou USB, ce qui signifie que le périphérique esclave peut uniquement répondre au commandes entrantes.

Tous les périphérique recevenant un Message de Commande doit répondre avec un Message Réponse, un Message d'Erreur ou un Message d'Alerte.

Si cette partie du tutoriel vous intéresse, vous pouvez poursuivre votre lecture sur https://learn.adafruit.com/adafruit-bluefruit-le-shield/sdep-spi-data-transport#sdep-data-transactions


Basé sur "Bluefruit LE Shield" d'Adafruit Industries, écrit par Kevin Townsend - Traduit en Français par shop.mchobby.be CC-BY-SA pour la traduction
Toute copie doit contenir ce crédit, lien vers cette page et la section "crédit de traduction".

Based on "Bluefruit LE Shield" from Adafruit Industries, written by Kevin Townsend - Translated to French by shop.mchobby.be CC-BY-SA for the translation
Copies must includes this credit, link to this page and the section "crédit de traduction" (translation credit).

Traduit avec l'autorisation d'AdaFruit Industries - Translated with the permission from Adafruit Industries - www.adafruit.com