SILICON LABS Implémentation du logiciel M-BUS sans fil Guide de l'utilisateur AN451

Cette note d'application décrit l'implémentation Silicon Labs du Wireless M-Bus à l'aide d'un MCU Silicon Labs C8051 et EZRadioPRO®. Le M-bus sans fil est une norme européenne pour les applications de lecture de compteurs utilisant la bande de fréquence 868 MHz.

Empiler les calques

Le M-Bus sans fil utilise le modèle IEC à 3 couches, qui est un sous-ensemble du modèle OSI à 7 couches (voir Figure 1).

La couche Physique (PHY) est définie dans l'EN 13757-4. La couche physique définit la manière dont les bits sont codés et transmis, les caractéristiques du modem RF (débit de puce, préambule et mot de synchronisation) et les paramètres RF (modulation, fréquence centrale et écart de fréquence).
La couche PHY est implémentée à l'aide d'une combinaison de matériel et de micrologiciel. L'EZRadioPRO exécute toutes les fonctions RF et modem. L'EZRadioPRO est utilisé en mode FIFO avec le gestionnaire de paquets. Le module MbusPhy.c fournit l'interface SPI, l'encodage/décodage, la lecture/écriture de blocs et la gestion des paquets et gère les états de l'émetteur-récepteur.
La couche de liaison de données M-Bus est implémentée dans le module MbusLink.c. L'interface de programmation d'applications M-Bus se compose de fonctions publiques qui peuvent être appelées à partir de la couche d'application dans le thread principal. Le module MbusLink implémente également la couche de liaison de données. La couche de liaison de données formatera et copiera les données du tampon TX de l'application vers le tampon TX MbusPhy, en ajoutant les en-têtes et les CRC requis.
La couche Application elle-même ne fait pas partie du firmware M-bus. La couche application définit comment une grande variété de données doit être formatée pour la transmission. La plupart des compteurs n'ont besoin de transmettre qu'un ou deux types de données. L'ajout d'une grande quantité de code pour accueillir tout type de données dans le compteur ajouterait du code et des coûts inutiles au compteur. Il pourrait être possible d'implémenter une bibliothèque ou un en-tête file avec une liste exhaustive des types de données. Cependant, la plupart des clients des compteurs savent exactement quel type de données ils doivent transmettre et peuvent se référer à la norme pour les détails de formatage. Un lecteur ou un renifleur universel peut implémenter un ensemble complet de types de données d'application sur l'interface graphique du PC. Pour ces raisons, la couche application est implémentée en utilisant example applications pour un compteur et un lecteur.

Normes requises

EN 13757-4
EN 13757-4
Système de communication des compteurs et télérelève des compteurs
Partie 4 : Relevé de compteur sans fil
Lecture du radiomètre pour un fonctionnement dans la bande SRD 868 MHz à 870 MHz
EN 13757-3
Système de communication des compteurs et télérelève des compteurs
Partie 3 : Couche applicative dédiée

CEI 60870-2-1:1992
Equipements et systèmes de télécontrôle
Partie 5 : Protocoles de transmission
Section 1 : Procédure de transmission du lien
CEI 60870-1-1:1990
Equipements et systèmes de télécontrôle
Partie 5 : Protocoles de transmission
Section 1 : Formats des trames de transmission

Définitions

M-Bus—M-Bus est une norme filaire pour le relevé de compteurs en Europe.
M-Bus sans fil—M-Bus sans fil pour les applications de relevé de compteurs en Europe.

PHY—La couche physique définit comment les bits et les octets de données sont codés et transmis.
API—Interface du programmeur d'applications.

RELIER-La couche de liaison de données définit la façon dont les blocs et les trames sont transmis.
CRC—Contrôle de redondance cyclique.

FSK—Modulation par déplacement de fréquence.
Ébrécher-Plus petite unité de données transmises. Un bit de données est codé comme plusieurs puces.

Module-source de code CA .c file.

Description fonctionnelle M-Bus PHY

Séquence de préambule

La séquence de préambule spécifiée par la spécification M-bus est un nombre entier alternant des zéros et des uns. Un un est défini comme la fréquence la plus élevée et un zéro est défini comme la fréquence la plus basse.
nx (01)
Les options de préambule pour le Si443x sont un nombre entier de quartets consistant en une alternance de uns et de zéros.
nx (1010)
Un préambule avec un préambule supplémentaire ne serait pas un problème, mais, alors, le mot de synchronisation et la charge utile seraient désalignés d'un bit.
La solution consiste à inverser l'intégralité du paquet en définissant le bit de moteur dans le registre de contrôle de modulation 2 (0x71). Cela inversera le préambule, le mot de synchronisation et les données TX/RX. Par conséquent, les données doivent être inversées lors de l'écriture des données TX ou de la lecture des données RX. De plus, le mot de synchronisation est inversé avant d'être écrit dans les registres du mot de synchronisation Si443x.

Mot de synchronisation

Le mot de synchronisation requis par EN-13757-4 est soit de 18 puces pour le Mode S et le Mode R, soit de 10 puces pour le Modèle T. Le mot de synchronisation pour le Si443x est de 1 à 4 octets. Cependant, comme le mot de synchronisation est toujours précédé du préambule, les six derniers bits du préambule peuvent être considérés comme faisant partie du mot de synchronisation ; ainsi, le premier mot de synchronisation est complété par trois répétitions d'un zéro suivi d'un un. Le mot de synchronisation est complété avant d'écrire dans les registres Si443x.
Tableau 1. Mot de synchronisation pour le mode S et le mode R

EN 13757-4	00	01110110	10010110	binaire
EN 13757-4	00	76	96	hex
tampon avec (01) x 3	01010100	01110110	10010110	binaire
tampon avec (01) x 3	54	76	96	hex
complément	10101011	10001001	01101001	binaire
complément	AB	89	69	hex

Tableau 2. Mot de synchronisation pour le compteur de mode T à l'autre

SYNCHRONISATION	SYNCHRONISATION	SYNCHRONISATION
MOT	MOT	MOT
3	2	1

Transmettre la longueur du préambule

Le préambule minimum est spécifié pour quatre modes de fonctionnement différents. Il est acceptable d'avoir un préambule plus long que spécifié. La soustraction de six puces pour le préambule donne le nombre minimum de puces pour le préambule du Si443x. L'implémentation ajoute deux quartets supplémentaires de préambule dans tous les modes de préambule court pour améliorer la détection et l'interopérabilité du préambule. Le préambule du Mode S avec un long préambule est très long ; ainsi, le préambule minimum est utilisé. La longueur de préambule en quartets est écrite dans le registre de longueur de préambule (0x34). Le registre de longueur de préambule détermine le préambule lors de la transmission uniquement. Les spécifications minimales et les paramètres de longueur de préambule sont résumés dans le tableau 3.
Tableau 3. Transmettre la longueur du préambule

	FR-13757-4 minimum		Si443x Préambule Réglage		Synchroniser Mot	Total	supplémentaire
	nx (01)	puces	grignote	puces	puces	puces	puces
Préambule court du mode S	15	30	8	32	6	38	8
Mode S long préambule	279	558	138	552	6	558	0
Mode T (compteur-autre)	19	38	10	40	6	46	8
ModeR	39	78	20	80	6	86	8

Le préambule minimum pour la réception est déterminé par le registre de contrôle de détection de préambule (0x35). A la réception, le nombre de bits dans le mot de synchronisation doit être soustrait du préambule minimum spécifié pour déterminer le préambule utilisable. Le temps d'établissement minimum du récepteur est de 16 puces si AFC est activé ou de 8 puces si AFC est désactivé. Le temps d'établissement du récepteur est également soustrait du préambule utilisable pour déterminer le réglage minimum pour le registre de contrôle de détection de préambule.

La probabilité d'un faux préambule dépend du réglage du registre de contrôle de détection de préambule. Un réglage court de 8 puces peut entraîner la détection d'un faux préambule toutes les quelques secondes. Le réglage recommandé de 20 puces fait de la détection de faux préambule un événement improbable. Les longueurs de préambule pour le Mode R et le Mode SL sont suffisamment longues pour que le réglage recommandé soit utilisé.
Il y a très peu d'avantages à faire en sorte que le préambule détecte plus de 20 puces.
L'AFC est désactivé pour le modèle S avec un préambule court et le modèle T. Cela réduit le temps d'établissement du récepteur et permet un réglage de détection de préambule plus long. Avec l'AFC désactivé, le Mode T peut utiliser le réglage recommandé de 20 puces. Un réglage de 4 nibbles ou 20 chips est utilisé pour la Model S avec un préambule court. Cela rend la probabilité d'une détection de faux préambule légèrement plus élevée pour ce modèle.
Tableau 4. Détection de préambule

	FR-13757-4 minimum		Synchroniser Mot	utilisable préambule	Règlement RX	Détecter min	Si443x Préambule Paramètre de détection
	nx (01)	puces	puces	puces	puces	puces	grignote	puces
Préambule court du mode S	15	30	6	24	8*	16	4	16
Préambule long de la Model S	279	558	6	552	16	536	5	20
Modèle T (compteur-autre)	19	38	6	32	8*	24	5	20
ModeR	39	78	6	72	16	56	5	20
*Note: AFC désactivé

Le récepteur est configuré pour interagir avec un émetteur en utilisant le préambule minimum spécifié. Cela garantit que le récepteur interopérera avec tout émetteur compatible M-bus.
La spécification Wireless M-Bus nécessite un préambule très long pour le Mode S1 d'au moins 558 puces. Cela prendra environ 17 ms juste pour transmettre le préambule. Le Si443x ne nécessite pas un préambule aussi long et ne bénéficie pas du préambule long. Alors que le long préambule est indiqué comme facultatif pour le mode S2, il n'y a aucune raison d'utiliser un long préambule avec le Si443x. Si une communication unidirectionnelle est souhaitée, le mode T1 fournira un préambule plus court, un débit de données plus élevé et une durée de vie de la batterie plus longue. Si une communication bidirectionnelle utilisant le mode S2 est requise, un court préambule est recommandé.
Notez que le seuil de détection pour la Model S avec un préambule long est plus long que le nombre de quartets de préambule transmis pour la Model S avec un préambule court. Cela signifie que le récepteur Mode S à préambule long ne détectera pas de préambule provenant d'un émetteur Mode S à préambule court. Ceci est nécessaire si le récepteur Mode S à long préambule doit tirer un quelconque profit du long préambule.
Notez que le récepteur Mode S à préambule court détectera le préambule et recevra des paquets à la fois d'un Mode S à préambule court
émetteur et un émetteur Mode S à long préambule ; ainsi, en général, le releveur doit utiliser la configuration du récepteur Mode S à préambule court.

Encodage/Décodage

La spécification Wireless M-bus requiert deux méthodes de codage différentes. Le codage Manchester est utilisé pour le mode S et le mode R. Le codage Manchester est également utilisé pour la liaison autre-compteur dans le modèle T. La liaison compteur-à-autre modèle T utilise 3 codages sur 6.
1. Encodage/décodage Manchester
L'encodage Manchester est historiquement courant dans les systèmes RF pour fournir une récupération et un suivi d'horloge robustes à l'aide d'un modem simple et peu coûteux. Cependant, une radio haute performance moderne comme la Si443x n'a pas besoin d'encodage Manchester. L'encodage Manchester est pris en charge principalement pour la compatibilité avec les normes existantes, mais le débit de données pour le Si443x est effectivement doublé lorsqu'il n'utilise pas l'encodage Manchester.
Le Si443x prend en charge l'encodage et le décodage Manchester de l'intégralité du paquet dans le matériel. Malheureusement, le mot de synchronisation n'est pas codé en Manchester. Une séquence Manchester invalide a été choisie intentionnellement pour le mot de synchronisation. Cela rend l'encodage Manchester incompatible avec la plupart des radios existantes, y compris le Si443x. En conséquence, le codage et le décodage Manchester doivent être effectués par le MCU. Chaque octet de données non codées se compose de huit bits de données. En utilisant le codage Manchester, chaque bit de données est codé en un symbole à deux puces. Étant donné que les données codées doivent être écrites dans la FIFO radio huit puces à la fois, un quartet de données est codé et écrit dans la FIFO à la fois.
Tableau 5. Codage Manchester

données	Ox12		0x34		octets
	Ox1	0x2	0x3	0x4	grignote
	1	10	11	100	binaire
ébrécher	10101001	10100110	10100101	10011010	binaire
FIFO	BœufA9	BœufA6	BœufA5	Bœuf9A	hex

Chaque octet à transmettre est transmis un octet à la fois à la fonction d'encodage d'octet. La fonction encode byte appellera deux fois la fonction encode nibble, d'abord pour le quartet le plus significatif, puis pour le quartet le moins significatif.
L'encodage Manchester dans le logiciel n'est pas difficile. En partant du bit le plus significatif, l'un est codé sous la forme d'une séquence de puces « 01 ». Un zéro est codé comme une séquence de puces « 10 ». Cela peut être facilement accompli en utilisant une boucle et en décalant deux bits pour chaque symbole. Cependant, il est plus rapide d'utiliser simplement une simple table de consultation de 16 entrées pour chaque quartet. La fonction de quartet de Manchester encode encode un quartet de données puis l'écrit dans la FIFO. Les puces sont inversées avant d'écrire dans la FIFO pour tenir compte des exigences de préambule inversé.
Lors de la réception, chaque octet de la FIFO se compose de huit puces et est décodé en un quartet de données. La fonction de lecture de bloc lit un octet à la fois dans la FIFO et appelle la fonction de décodage d'octet. Les puces sont inversées après lecture de la FIFO pour tenir compte des exigences de préambule inversé. Chaque octet des puces codées Manchester est décodé en un quartet de données. Le quartet décodé est écrit dans le tampon RX en utilisant la fonction de tampon RX de quartet d'écriture.
Notez que l'encodage et le décodage sont effectués un quartet de données à la fois à la volée. Le codage dans une mémoire tampon nécessiterait une mémoire tampon supplémentaire deux fois plus grande que les données non codées. L'encodage et le décodage sont beaucoup plus rapides que le débit de données le plus rapide (100 443 puces par seconde). Étant donné que le Si10x prend en charge les lectures et les écritures sur plusieurs octets dans la FIFO, il y a un petit surcoût lié à l'utilisation de lectures et d'écritures sur un seul octet. Le surdébit est d'environ 100 µs pour 512 puces codées. L'avantage est une économie de RAM de XNUMX octets.
2. Décodage d'encodage trois sur six
La méthode de codage trois sur six spécifiée dans la norme EN-13757-4 est également implémentée dans le micrologiciel du MCU. Cet encodage est utilisé pour le mode T haut débit (100 k chips par seconde) d'un compteur à l'autre. Le modèle T offre le temps de transmission le plus court et la plus longue durée de vie de la batterie pour un compteur sans fil.
Chaque octet de données à transmettre est divisé en deux quartets. Le quartet le plus significatif est codé et transmis en premier. Encore une fois, cela est implémenté à l'aide d'une fonction d'octet de codage qui appelle deux fois la fonction de quartet de codage.
Chaque quartet de données est codé dans un symbole à six puces. La séquence de symboles à six puces doit être écrite dans la FIFO à huit puces.
Pendant le codage, deux octets de données sont codés sous forme de quatre quartets. Chaque grignotage est un symbole de 6 jetons. Quatre symboles à 6 puces sont agrégés sur trois octets.
Tableau 6. Codage de trois sur six

données	0x12			0x34			octets
	Ox1	0x2		0x3		0x4	grignote
ébrécher	15	16		13		34	octale
	1101	1110		1011		11100	binaire
FIFO	110100		11100010		11011100		binaire
	0x34		BœufE2		OxDC		hex

Dans le logiciel, l'encodage trois sur six est implémenté à l'aide de trois fonctions imbriquées. La fonction d'encodage d'octet appellera deux fois la fonction d'encodage nibble. La fonction de quartet d'encodage utilise une table de recherche pour le symbole à six puces et écrit le symbole dans les fonctions Shift Three of Six. Cette fonction implémente un registre à décalage de 16 puces dans le logiciel. Le symbole est écrit dans l'octet de poids faible du registre à décalage. Le registre est décalé deux fois vers la gauche. Ceci est répété trois fois. Lorsqu'un octet complet est présent dans l'octet supérieur du registre à décalage, il est inversé et écrit dans la FIFO.
Etant donné que chaque octet de données est codé comme un octet et demi codé, il est important d'effacer initialement le registre à décalage afin que le premier octet codé soit correct. Si la longueur du paquet est un nombre impair, après avoir encodé tous les octets, il restera encore un quartet dans le registre à décalage. Ceci est traité avec le postambule comme expliqué dans la section suivante.
Le décodage des trois sur six encodés est la procédure inverse. Lors du décodage, trois octets codés sont décodés en deux octets de données. Le registre à décalage logiciel est à nouveau utilisé pour agréger des octets de données décodées. Une table de consultation inversée à 64 entrées est utilisée pour le décodage. Cela utilise moins de cycles mais plus de mémoire de code. La recherche du symbole correspondant dans une table de correspondance à 16 entrées prend beaucoup plus de temps.
Postambule
La spécification Wireless M-bus a des exigences spécifiques pour le postambule ou la remorque. Pour tous les modes, le minimum est de deux puces et le maximum est de huit puces. Étant donné que l'unité atomique minimale pour la FIFO est d'un octet, une remorque à 8 puces est utilisée pour le mode S et le mode R. Le postambule du mode T est de huit puces si la longueur du paquet est paire ou de quatre puces si la longueur du paquet est impaire. Le postambule à quatre puces pour une longueur de paquet impaire répond aux exigences d'avoir au moins deux puces en alternance.
Tableau 7. Longueur du postambule

	Longueur du postambule (puces)
	min	max	Mise en œuvre		séquence de puces
Mode S	2	8	8		1010101
Mode T	2	8	4	(impair)	101
			8	(même)	1010101
ModeR	2	8	8		1010101

Gestionnaire de paquets

Le gestionnaire de paquets sur le Si443x peut être utilisé en mode de largeur de paquet variable ou en mode de largeur de paquet fixe. Le mode de largeur de paquet variable nécessite un octet de longueur de paquet après le mot de synchronisation et des octets d'en-tête facultatifs. A la réception, la radio utilisera l'octet de longueur pour déterminer la fin d'un paquet valide. Lors de la transmission, la radio insère le champ de longueur après les octets d'en-tête.
Le champ L pour le protocole sans fil M-bus ne peut pas être utilisé pour le champ de longueur Si443x. Premièrement, le champ L n'est pas la longueur réelle du paquet. Il s'agit du nombre d'octets de charge utile de couche liaison sans compter les octets CRC ou le codage. Deuxièmement, le champ L lui-même est codé à l'aide d'un codage Manchester ou d'un codage trois sur six pour le compteur Mode T vers un autre.
La mise en œuvre utilise le gestionnaire de paquets en mode de largeur de paquet fixe pour la transmission et la réception. Lors de la transmission, la couche PHY lira le champ L dans le tampon de transmission et calculera le nombre d'octets codés, y compris le postambule. Le nombre total d'octets codés à transmettre est écrit dans le registre de longueur de paquet (0x3E).
A la réception, les deux premiers octets codés sont décodés et le champ L est écrit dans le tampon de réception. Le champ L est utilisé pour calculer le nombre d'octets codés à recevoir. Le nombre d'octets codés à recevoir est alors écrit dans le registre de longueur de paquet (0x3E). Le postambule est jeté.
Le MCU doit décoder le champ L, calculer le nombre d'octets codés et écrire la valeur dans le registre de longueur de paquet avant que la longueur de paquet la plus courte possible ne soit reçue. Le champ L le plus court admissible pour la couche PHY est 9, ce qui donne 12 octets non codés. Cela donne 18 octets codés pour le modèle T. Les deux premiers octets ont déjà été décodés. Ainsi, le registre de longueur de paquet doit être mis à jour tous les 16 octets à 100 kbps ou 1.28 milliseconde. Ce n'est pas un problème pour un 8051 fonctionnant à 20 MIPS.
Le nombre d'octets à recevoir n'inclut pas le postambule, à l'exception du postambule à quatre puces utilisé pour les paquets Mode T avec une longueur de paquet impaire. Ainsi, le récepteur n'a pas besoin de postambule, sauf pour les paquets de longueur impaire du modèle T. Ce postambule n'est nécessaire que pour donner un nombre entier d'octets encodés. Le contenu du postambule est ignoré ; ainsi, si le postambule n'est pas transmis, quatre fragments de bruit seront reçus et ignorés. Étant donné que le nombre total d'octets codés est limité à 255 (0xFF), la mise en œuvre limite le champ L maximum pour les différents modes.
Tableau 8. Limites de taille de paquet

	codé		décodé		M-Bus
	octets		octets		L-Champ
	déc	hex	déc	hex	déc	hex
Mode S	255	FF	127	7 F	110	6E
Mode T (compteur-autre)	255	FF	169	A9	148	94
ModeR	255	FF	127	7 F	110	6E

Ces limites sont normalement bien au-dessus du cas d'utilisation typique d'un compteur sans fil. La longueur du paquet doit être réduite pour obtenir la meilleure durée de vie possible de la batterie.
De plus, l'utilisateur peut spécifier le champ L maximum qui doit être reçu (USER_RX_MAX_L_FIELD). Cela détermine la taille requise pour le tampon de réception (USER_RX_BUFFER_SIZE).
La prise en charge d'un champ L maximum de 255 nécessiterait un tampon de réception de 290 octets et un maximum de 581 octets codés Manchester. Le gestionnaire de paquets devrait être désactivé et le registre de longueur de paquet ne pourrait pas être utilisé dans ce cas. C'est faisable, mais il est plus pratique d'utiliser le gestionnaire de paquets, si possible.

Utilisation FIFO

Le Si4431 fournit une FIFO de 64 octets pour la transmission et la réception. Étant donné que le nombre d'octets codés est de 255, un paquet codé entier peut ne pas tenir dans la mémoire tampon de 64 octets.
Transmission
Lors de la transmission, le nombre total d'octets codés est calculé. Si le nombre total d'octets codés, y compris le postambule, est inférieur à 64 octets, le paquet entier est écrit dans la FIFO et seule l'interruption du paquet envoyé est activée. La plupart des paquets courts seront envoyés en un seul transfert FIFO.
Si le nombre d'octets codés est supérieur à 64, plusieurs transferts FIFO seront nécessaires pour envoyer le paquet. Les 64 premiers octets sont écrits dans la FIFO. Les interruptions Paquet envoyé et TX FIFO presque vide sont activées. Le seuil TX FIFO Presque Vide est fixé à 16 octets (25%). A chaque événement IRQ, le registre d'état 2 est lu. Le bit Packet Sent est vérifié en premier et, si le paquet n'a pas été complètement envoyé, les 48 octets suivants de données codées sont écrits dans la FIFO. Cela continue jusqu'à ce que tous les octets codés aient été écrits et que l'interruption Paquet envoyé se produise.
1. Réception
A la réception, dans un premier temps, seule l'interruption Sync Word est activée. Après avoir reçu le mot de synchronisation, l'interruption de mot de synchronisation est désactivée et l'interruption FIFO presque pleine est activée. Le seuil FIFO presque plein est initialement défini sur 2 octets. La première interruption FIFO Presque Pleine est utilisée pour savoir quand les deux octets de longueur ont été reçus. Une fois la longueur reçue, la longueur est décodée et le nombre d'octets encodés est calculé. Le seuil RX FIFO presque plein est alors fixé à 48 octets. La FIFO RX est presque pleine et les interruptions de paquets valides sont activées. Lors de l'événement IRQ suivant, le registre d'état 1 est lu. Tout d'abord, le bit de paquet valide est vérifié, puis le bit FIFO presque plein est vérifié. Si seul le bit RX FIFO Presque Plein est défini, les 48 octets suivants sont lus à partir de la FIFO. Si le bit de paquet valide est défini, le reste du paquet est lu à partir de la FIFO. Le MCU garde une trace du nombre d'octets lus et arrête la lecture après le dernier octet.

Couche de liaison de données

Le module de couche liaison de données implémente une couche liaison conforme à 13757-4:2005. La couche liaison de données (LINK) fournit une interface entre la couche physique (PHY) et la couche application (AL).
La couche de liaison de données remplit les fonctions suivantes :

Fournit des fonctions qui transfèrent des données entre PHY et AL
Génère des CRC pour les messages sortants
Détecte les erreurs CRC dans les messages entrants
Fournit un adressage physique
Reconnaît les transferts pour les modes de communication bidirectionnels
Bits de données de trames
Détecte les erreurs de cadrage dans les messages entrants

Format de cadre de calque de lien

Le format de trame Wireless M-Bus utilisé dans la norme EN 13757-4:2005 est dérivé du format de trame FT3 (Frame Type 3) de la norme IEC60870-5-2. La trame est constituée d'un ou plusieurs blocs de données. Chaque bloc comprend un champ CRC de 16 bits. Le premier bloc est un bloc de longueur fixe de 12 octets qui comprend le champ L, le champ C, le champ M et le champ A.

L-Champ
Le champ L est la longueur de la charge utile des données de la couche Liaison. Cela n'inclut pas le champ L lui-même ni aucun des octets CRC. Il comprend le champ L, le champ C, le champ M et le champ A. Ceux-ci font partie de la charge utile PHY.
Comme le nombre d'octets codés est limité à 255 octets, la valeur maximale prise en charge pour le champ M est de 110 octets pour les données codées Manchester et de 148 octets pour les données codées Mode T Trois sur six.
La couche Liaison est responsable du calcul du champ L lors de la transmission. La couche liaison utilisera le champ L à la réception.
Notez que le champ L n'indique pas la longueur de la charge utile PHY ou le nombre d'octets codés. Lors de la transmission, le PHY calculera la longueur de la charge utile PHY et le nombre d'octets codés. A la réception, le PHY décodera le champ L et calculera le nombre d'octets à décoder.
Champ C
Le champ C est le champ de contrôle de trame. Ce champ identifie le type de trame et est utilisé pour les primitives du service d'échange de données de liaison. Le champ C indique le type de trame – SEND, CONFIRM, REQUEST ou RESPOND. Dans le cas des trames SEND et REQUEST, le champ C indique si un message CONFIRM ou RESPOND est attendu.
Lors de l'utilisation de la fonction de base Link TX, n'importe quelle valeur de C peut être utilisée. Lors de l'utilisation des primitives de service de liaison, le champ C est automatiquement renseigné conformément à la norme EN 13757-4:2005.
M-Champ
Le champ M est le code du fabricant. Les fabricants peuvent demander un code à trois lettres parmi les suivants web adresse: http://www.dlms.com/flag/INDEX.HTM Chaque caractère du code à trois lettres est codé sur cinq bits. Le code à 5 bits peut être obtenu en prenant le code ASCII et en soustrayant 0x40 (« A »). Les trois codes à 5 bits sont concaténés pour former 15 bits. Le bit le plus significatif est zéro.
Un champ
Le champ d'adresse est une adresse unique de 6 octets pour chaque appareil. L'adresse unique doit être attribuée par le fabricant. Il est de la responsabilité de chaque fabricant de s'assurer que chaque appareil possède une adresse unique de 6 octets. L'adresse pour les trames d'envoi et de demande est l'auto-adresse du compteur ou d'un autre appareil. Les trames de données de confirmation et de réponse sont envoyées en utilisant l'adresse de l'appareil d'origine.
CI-Champ
Le champ CI est l'en-tête de l'application et spécifie le type de données dans la charge utile des données de l'application. Alors que la norme EN13757-4:2005 spécifie un nombre limité de valeurs, les primitives de service de liaison permettront d'utiliser n'importe quelle valeur.
CRC
Le CRC est spécifié dans la norme EN13757-4:2005.
Le polynôme CRC est :
X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
Notez que le M-Bus CRC est calculé sur chaque bloc de 16 octets. Le résultat est que tous les 16 octets de données nécessitent 18 octets pour être transmis,

Informations Complémentaires

Pour plus d'informations sur la mise en œuvre de la couche de liaison, consultez « AN452 : Guide des programmeurs de pile M-Bus sans fil ».

Gestion de l'alimentation

La figure 2 montre le calendrier de gestion de l'alimentation pour un compteur example utilisant le Mode T1.

Le MCU doit être en mode veille dans la mesure du possible pour économiser l'énergie. Dans cet example, le MCU est en veille lorsque le RTC est en cours d'exécution, lors de l'attente du démarrage du cristal radio et lors de la transmission depuis le FIFO. Le MCU se réveillera à partir du signal IRQ EZRadioPRO connecté à un réveil Port Match.
Lors de la transmission de messages de plus d'un bloc, le MCU doit se réveiller pour remplir la FIFO (sur la base de l'interruption FIFO presque vide), puis se rendormir.
Le MCU doit être en mode veille à partir de l'oscillateur basse puissance ou de l'oscillateur en mode rafale lors de la lecture à partir de l'ADC. L'ADC nécessite une horloge SAR.
Lorsqu'il n'est pas utilisé, l'EZRadioPRO doit être en mode d'arrêt avec la broche SDN élevée. Cela nécessite une connexion câblée au MCU. Les registres EZ Radio Pro ne sont pas conservés en mode d'arrêt ; ainsi, l'EZRadioPro est initialisé à chaque intervalle RTC. L'initialisation de la radio prend moins de 100 µs et conserve 400 nA. Il en résulte une économie d'énergie de 10 µJ, basée sur un intervalle de 10 secondes.
Le cristal EZRadioPRO prend environ 16 ms pour un POR. C'est assez long pour calculer le CRC pour environ huit blocs. Le MCU se rendort s'il termine tous les CRC avant que le cristal ne se soit stabilisé. Si le cryptage est requis, il peut également être démarré en attendant l'oscillateur à cristal.
Le MCU doit fonctionner à 20 MHz en utilisant l'oscillateur basse consommation pour la plupart des tâches. Les tâches qui nécessitent un délai d'attente précis doivent utiliser l'oscillateur de précision et le mode veille au lieu du mode veille. Le RTC fournit une résolution suffisante pour la plupart des tâches. Le calendrier de gestion de l'alimentation pour le compteur T2 exampl'application est illustrée à la figure 3.

La mise en œuvre de l'émetteur-récepteur doit être optimisée pour le cas normal lorsque le compteur se réveille et qu'aucun lecteur n'est présent. Les délais d'attente ACK minimum/maximum sont suffisamment longs pour qu'il soit possible d'utiliser le C8051F930 RTC et de mettre le MCU en mode veille.
Des options de construction sont fournies pour les lecteurs secteur ou alimentés par USB qui n'ont pas besoin d'utiliser le mode veille. Le mode veille sera utilisé à la place du mode veille afin que l'USB et l'UART puissent interrompre le MCU.

Studio Simplicité
Accès en un clic aux outils MCU et sans fil, à la documentation, aux logiciels, aux bibliothèques de code source et plus encore. Disponible pour Windows,
Mac et Linux !


Portefeuille IoT www.silabs.com/IoT	Logiciel/matériel www.silabs.com/simplicité	Qualité www.silabs.com/qualité	Soutien et communauté communauté.silabs.com

Clause de non-responsabilité
Silicon Labs a pour objectif de fournir aux clients la documentation la plus récente, précise et approfondie de tous les périphériques et modules disponibles pour les implémenteurs de systèmes et de logiciels utilisant ou prévoyant d'utiliser les produits Silicon Labs. Les données de caractérisation, les modules et périphériques disponibles, les tailles de mémoire et les adresses de mémoire se réfèrent à chaque périphérique spécifique, et les paramètres « typiques » fournis peuvent varier et varient effectivement dans différentes applications.ampLes chiers décrits ici le sont à titre indicatif seulement. Silicon Labs se réserve le droit d'apporter des modifications sans préavis ni limitation aux informations sur les produits, aux spécifications et aux descriptions des présentes, et ne donne aucune garantie quant à l'exactitude ou l'exhaustivité des informations incluses. Silicon Labs n'assume aucune responsabilité pour les conséquences de l'utilisation des informations fournies ici. Ce document n'implique ni n'exprime les licences de droit d'auteur accordées en vertu des présentes pour concevoir ou fabriquer des circuits intégrés. Les produits ne sont pas conçus ou autorisés pour être utilisés dans un système de survie sans le consentement écrit spécifique de Silicon Labs. Un « système d'assistance vitale » est tout produit ou système destiné à soutenir ou à maintenir la vie et/ou la santé, qui, s'il échoue, peut raisonnablement entraîner des blessures corporelles importantes ou la mort. Les produits de Silicon Labs ne sont pas conçus ou autorisés pour des applications militaires. Les produits de Silicon Labs ne doivent en aucun cas être utilisés dans des armes de destruction massive, y compris (mais sans s'y limiter) des armes nucléaires, biologiques ou chimiques, ou des missiles capables de transporter de telles armes.
Informations sur la marque déposée
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® et le logo Silicon Labs®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, le logo Energy Micro et leurs combinaisons, « les microcontrôleurs les plus écoénergétiques au monde », Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, le logo Telegesis®, USBXpress® et autres sont des marques ou des marques déposées de Silicon Labs. ARM, CORTEX, Cortex-M3 et les pouces sont des marques ou des marques déposées d'ARM Holdings. Keil est une marque déposée d'ARM Limited. Tous les autres produits ou noms de marque mentionnés ici sont des marques déposées de leurs détenteurs respectifs.

Laboratoires Silicon Inc.
400 Ouest César Chavez
Austin, TX 78701
USA
http://www.silabs.com

Documents / Ressources

SILICON LABS Implémentation du logiciel M-BUS sans fil AN451 [pdf] Guide de l'utilisateur
SILICON LABS, C8051, MCU et, EZRadioPRO, M-bus sans fil, Sans fil, M-BUS, Logiciel, Implémentation, AN451

Références

Manuel d'utilisation

Introduction