BLE GATT: pourquoi stocker des décimales dans les types entiers?

Question

J'apprends le bluetooth, en particulier comment mettre en œuvre GATT characteristic specs afin que je puisse écrire des pilotes de périphériques. Dans presque toutes les spécifications, ils cherchent à utiliser des types de données entiers pour contenir des valeurs décimales (lorsque les données sont une valeur décimale). Par exemple, la spécification Cycling Power Measurement spec stocke le Pedal Power Balance dans un uint8. Comme vous pouvez voir la valeur Pedal Power Balance a une résolution de 1 décimale (ex: 10.1). Le GATT format types spec a beaucoup de types pour les nombres décimaux (float32 etc).

Pourquoi le GATT n'utilise-t-il pas un type de données conçu pour contenir des nombres décimaux? Ma conjecture est de limiter la taille des données envoyées sur BLE. Est-ce exact? Je suis en train d'écrire du code NodeJs pour prouver rapidement un peu de technologie. Avec mon hypothèse, voici comment je suppose que l'on "emballe" une décimale avec un chiffre de précision dans un entier signé de 8 bits. J'utilise l'accélération ici (peut être +/- si l'aide signed int):

'use strict'; 

const oneG = -9.806649999788; 

let int8Buf = new Buffer.alloc(8); //to hold signed 8-bit integer 

int8Buf.writeInt8(oneG * 10, 0); 
console.log(int8Buf.readInt8(0)/10); 

L'exécution de cette sorties -9.8 comme je m'y attendais.

Questions:

1. Est-GATT utiliser cette technique "emballage" pour économiser de l'espace sur l'air?
2. Est-ce que je fais cela correctement?
3. Est-ce que NodeJS dispose d'une bibliothèque qui gère ce conditionnement et ce déballage de données? On dirait un scénario très commun. J'ai cherché NPM mais je ne suis pas sûr de ce que ce concept est appelé.

Answer 1

Les entiers mis à l'échelle comme ceux-ci sont utilisés pour simplifier l'implémentation sur les petits périphériques intégrés.

Pour des raisons de coût et de consommation d'énergie, les microcontrôleurs utilisés n'ont souvent pas de FPU (c'est-à-dire un support matériel pour les calculs en virgule flottante). Sur ceux qui n'ont pas de FPU, il est possible d'utiliser des bibliothèques à virgule flottante, mais elles sont lentes (et consomment donc de la puissance), et occupent de l'espace de code. Même sur les microcontrôleurs dotés d'une FPU, son utilisation augmente la consommation d'énergie et l'utilisation de quatre octets pour un nombre à virgule flottante augmentera également l'utilisation de la RAM (autre ressource rare) par rapport à un octet pour la version entière. Pour ces raisons, il est la norme dans le monde embarqué d'utiliser des entiers mis à l'échelle lorsque des quantités fractionnaires sont nécessaires.

Dans le cas d'une caractéristique du GATT, il est également souhaitable d'utiliser des types de données plus petits car vous souhaitez généralement que la valeur de votre caractéristique ne dépasse pas 20 octets. En effet, la ATT MTU est généralement définie sur 23 octets (et ATT sur 3 octets), car il s'agit du plus long paquet ATT pouvant être inclus dans un seul paquet Layer (si l'extension Data Length de Bluetooth 4.2 n'est pas mis en œuvre).