AN451
IMPLEMENTACIÓN DE SOFTWARE M-BUS INALÁMBRICO
Introdución
Esta nota da aplicación describe a implementación de Silicon Labs de Wireless M-Bus mediante un MCU Silicon Labs C8051 e EZRadioPRO®. Wireless M-bus é un estándar europeo para aplicacións de lectura de contadores que utilizan a banda de frecuencia de 868 MHz.
Apilar capas
Wireless M-Bus usa o modelo IEC de 3 capas, que é un subconxunto do modelo OSI de 7 capas (consulta a Figura 1).
A capa física (PHY) está definida na EN 13757-4. A capa física define como se codifican e transmiten os bits, as características do módem de RF (taxa de chip, preámbulo e palabra de sincronización) e os parámetros de RF (modulación, frecuencia central e desviación de frecuencia).
A capa PHY implétase mediante unha combinación de hardware e firmware. O EZRadioPRO realiza todas as funcións de RF e módem. O EZRadioPRO úsase en modo FIFO co manejador de paquetes. O módulo MbusPhy.c ofrece interface SPI, codificación/descodificación, lectura/escritura de bloques e manexo de paquetes e xestiona os estados do transceptor.
A capa de enlace de datos M-Bus está implementada no módulo MbusLink.c. A interface de programación de aplicacións M-Bus consta de funcións públicas que se poden chamar desde a capa de aplicación do fío principal. O módulo MbusLink tamén implementa a capa de enlace de datos. A capa de enlace de datos formateará e copiará os datos do búfer TX da aplicación ao búfer TX de MbusPhy, engadindo as cabeceiras e os CRC necesarios.
A capa de aplicación en si non forma parte do firmware M-bus. A capa de aplicación define como formatear unha gran variedade de datos para a súa transmisión. A maioría dos medidores só precisan transmitir un ou dous tipos de datos. Engadir unha gran cantidade de código para acomodar calquera tipo de datos ao contador engadiría código innecesario e custo ao contador. Podería ser factible implementar unha biblioteca ou unha cabeceira file cunha lista exhaustiva de tipos de datos. Non obstante, a maioría dos clientes de medición saben exactamente que tipo de datos necesitan transmitir e poden consultar o estándar para os detalles do formato. Un lector ou detector universal pode implementar un conxunto completo de tipos de datos de aplicacións na GUI do PC. Por estes motivos, a capa de aplicación implétase mediante example aplicacións para un contador e lector.
Normas esixidas
- EN 13757-4
EN 13757-4
Sistema de comunicación para contadores e lectura remota de contadores
Parte 4: Lectura de contadores sen fíos
Lectura do radiómetro para operación na banda SRD de 868 MHz a 870 MHz - EN 13757-3
Sistema de comunicación para contadores e lectura remota de contadores
Parte 3: capa de aplicación dedicada - IEC 60870-2-1:1992
Equipos e sistemas de telecontrol
Parte 5: Protocolos de transmisión
Sección 1: Procedemento de transmisión da ligazón - IEC 60870-1-1:1990
Equipos e sistemas de telecontrol
Parte 5: Protocolos de transmisión
Sección 1: Formatos de trama de transmisión
Definicións
- M-Bus—M-Bus é un estándar cableado para a lectura de contadores en Europa.
- M-Bus sen fíos—M-Bus sen fíos para aplicacións de lectura de contadores en Europa.
- PHY—A capa física define como se codifican e transmiten os bits e os bytes de datos.
- API—Interfaz do programador de aplicacións.
- ENLACE—A capa de enlace de datos define como se transmiten os bloques e as tramas.
- CRC—Comprobación de redundancia cíclica.
- FSK—Tecla de cambio de frecuencia.
- chip—Unidade máis pequena de datos transmitidos. Un bit de datos está codificado como varios chips.
- Módulo—Fonte do código AC .c file.
Descrición funcional de M-Bus PHY
Secuencia de preámbulos
A secuencia de preámbulos especificada pola especificación M-bus é un número enteiro que alterna ceros e uns. Un defínese como a frecuencia máis alta e un cero defínese como a frecuencia máis baixa.
nx (01)
As opcións de preámbulo para o Si443x son un número enteiro de bocados que consiste en uns e ceros alternados.
nx (1010)
Un preámbulo cun inicial adicional non sería un problema, pero, entón, a palabra de sincronización e a carga útil estarían desalineadas nun bit.
A solución é inverter todo o paquete configurando o bit do motor no rexistro Modulation Control 2 (0x71). Isto inverte o preámbulo, a palabra de sincronización e os datos TX/RX. Como consecuencia, os datos deberían invertirse ao escribir os datos TX ou ler os datos RX. Ademais, a palabra de sincronización invírtese antes de escribir nos rexistros de palabras de sincronización Si443x.
Palabra de sincronización
A palabra de sincronización requirida pola EN-13757-4 é de 18 chips para o Modo S e o Modo R ou de 10 chips para o Modelo T. A palabra de sincronización para o Si443x é de 1 a 4 bytes. Porén, dado que a palabra de sincronización sempre vai precedida polo preámbulo, os últimos seis bits do preámbulo pódense considerar parte da palabra de sincronización; así, a primeira palabra de sincronización enchégase con tres repeticións dun cero seguidas dun un. A palabra de sincronización complétase antes de escribir nos rexistros Si443x.
Táboa 1. Palabra de sincronización para o modo S e o modo R
| EN 13757-4 | 00 | 01110110 | 10010110 | binario |
| 00 | 76 | 96 | feitizo | |
| almofada con (01) x 3 | 01010100 | 01110110 | 10010110 | binario |
| 54 | 76 | 96 | feitizo | |
| complemento | 10101011 | 10001001 | 01101001 | binario |
| AB | 89 | 69 | feitizo |
Táboa 2. Palabra de sincronización para o modo T contador con outro
| SINCRONIZACIÓN | SINCRONIZACIÓN | SINCRONIZACIÓN |
| PALABRA | PALABRA | PALABRA |
| 3 | 2 | 1 |
Lonxitude do preámbulo de transmisión
O preámbulo mínimo especifícase para catro modos de funcionamento diferentes. É aceptable ter un preámbulo máis longo do especificado. Restando seis fichas para o preámbulo dáse o número mínimo de fichas para o preámbulo Si443x. A implementación engade dous bocados adicionais de preámbulo en todos os modos de preámbulo curto para mellorar a detección e a interoperabilidade de preámbulos. O preámbulo do modo S cun preámbulo longo é moi longo; polo tanto, utilízase o preámbulo mínimo. A lonxitude do preámbulo en mordiscos escríbese no rexistro de lonxitude do preámbulo (0x34). O rexistro de lonxitude do preámbulo determina o preámbulo só tras a transmisión. A especificación mínima e a configuración da lonxitude do preámbulo resúmense na Táboa 3.
Táboa 3. Lonxitude do preámbulo de transmisión
| EN-13757-4 mínimo |
Si443x Preámbulo Establecemento |
Sincronizar Palabra |
Total | extra | |||
| nx (01) | fichas | mordiscos | fichas | fichas | fichas | fichas | |
| Preámbulo curto do modo S | 15 | 30 | 8 | 32 | 6 | 38 | 8 |
| Preámbulo longo do modo S | 279 | 558 | 138 | 552 | 6 | 558 | 0 |
| Modo T (medidor-outro) | 19 | 38 | 10 | 40 | 6 | 46 | 8 |
| Modo R | 39 | 78 | 20 | 80 | 6 | 86 | 8 |
O preámbulo mínimo para a recepción está determinado polo rexistro de control de detección de preámbulos (0x35). Tras a recepción, o número de bits da palabra de sincronización debe restarse do preámbulo mínimo especificado para determinar o preámbulo utilizable. O tempo mínimo de asentamento do receptor é de 16 chips se AFC está activado ou de 8 chips se AFC está desactivado. O tempo de asentamento do receptor tamén se resta do preámbulo utilizable para determinar a configuración mínima para o rexistro de control de detección de preámbulos.
A probabilidade dun preámbulo falso depende da configuración do rexistro de control de detección de preámbulos. Unha configuración curta de 8 chips pode provocar que se detecte un preámbulo falso cada poucos segundos. A configuración recomendada de 20 chips fai que a detección de preámbulos falsos sexa un evento improbable. As lonxitudes do preámbulo para o Modo R e o Modo SL son suficientemente longas para que se utilice a configuración recomendada.
Hai moi pouco beneficio en facer que o preámbulo detecte máis de 20 fichas.
O AFC está desactivado no modelo S cun preámbulo curto e no modelo T. Isto reduce o tempo de asentamento do receptor e permite unha configuración de detección de preámbulo máis longa. Co AFC desactivado, o modo T pode usar a configuración recomendada de 20 fichas. Para o Model S úsase unha configuración de 4 bocados ou 20 fichas cun preámbulo curto. Isto fai que a probabilidade de detectar un preámbulo falso sexa lixeiramente maior para este modelo.
Táboa 4. Detección de preámbulos
| EN-13757-4 mínimo |
Sincronizar Palabra |
utilizable preámbulo |
Resolución de RX | Detectar min |
Si443x Preámbulo Configuración de detección |
|||
| nx (01) | fichas | fichas | fichas | fichas | fichas | mordiscos | fichas | |
| Preámbulo curto do modo S | 15 | 30 | 6 | 24 | 8* | 16 | 4 | 16 |
| Preámbulo longo do modelo S | 279 | 558 | 6 | 552 | 16 | 536 | 5 | 20 |
| Modelo T (medidor-outro) | 19 | 38 | 6 | 32 | 8* | 24 | 5 | 20 |
| Modo R | 39 | 78 | 6 | 72 | 16 | 56 | 5 | 20 |
| *Nota: AFC desactivado | ||||||||
O receptor está configurado para interoperar cun transmisor usando o preámbulo mínimo especificado. Isto garante que o receptor interoperará con calquera transmisor compatible con M-bus.
A especificación Wireless M-Bus require un preámbulo moi longo para o Modo S1 de polo menos 558 chips. Isto levará uns 17 ms só transmitir o preámbulo. O Si443x non require un preámbulo tan longo e non se beneficia do preámbulo longo. Aínda que o preámbulo longo se sinala como opcional para o Modo S2, non hai razón para usar un preámbulo longo co Si443x. Se se desexa unha comunicación unidireccional, o Modo T1 proporcionará un preámbulo máis curto, unha maior taxa de datos e unha maior duración da batería. Se se precisa unha comunicación bidireccional mediante o modo S2, recoméndase un breve preámbulo.
Teña en conta que o limiar de detección para o Model S cun preámbulo longo é maior que o número de mordiscos de preámbulo transmitidos para o Model S cun preámbulo curto. Isto significa que o receptor Modo S de preámbulo longo non detectará un preámbulo dun transmisor Modo S de preámbulo curto. Isto é necesario se o receptor Modo S de preámbulo longo recibe algún beneficio do preámbulo longo.
Teña en conta que o receptor Modo S de preámbulo curto detectará o preámbulo e recibirá paquetes tanto do Modo S de preámbulo curto.
transmisor e un transmisor Modo S de preámbulo longo; polo que, en xeral, o lector de contadores debería utilizar a configuración do receptor Modo S de preámbulo curto.
Codificación/Decodificación
A especificación Wireless M-bus require dous métodos de codificación diferentes. A codificación de Manchester utilízase para o Modo S e o Modo R. A codificación de Manchester tamén se usa para a ligazón doutro a metro no Modelo T. A ligazón de metro a outro do Modelo T usa 3 de cada 6 codificacións.
1. Manchester Codificado/Decodificación
A codificación de Manchester é habitual históricamente nos sistemas de RF para proporcionar unha recuperación e un seguimento do reloxo robustos mediante un módem sinxelo e económico. Non obstante, unha radio moderna de alto rendemento como o Si443x non precisa de codificación Manchester. A codificación de Manchester é compatible principalmente para a compatibilidade cos estándares existentes, pero a taxa de datos para o Si443x duplícase de feito cando non se utiliza a codificación de Manchester.
O Si443x admite a codificación e descodificación de Manchester de todo o paquete no hardware. Desafortunadamente, a palabra de sincronización non está codificada Manchester. Escolleuse intencionadamente unha secuencia Manchester non válida para a palabra de sincronización. Isto fai que a codificación de Manchester sexa incompatible coa maioría das radios existentes, incluído o Si443x. Como consecuencia, a codificación e descodificación de Manchester debe ser realizada polo MCU. Cada byte de datos non codificados consta de oito bits de datos. Usando a codificación Manchester, cada bit de datos codificase nun símbolo de dous chips. Dado que os datos codificados deben escribirse no FIFO de radio oito chips á vez, un bocado de datos codificase e escríbese no FIFO á vez.
Táboa 5. Codificación Manchester
| datos | Boi12 | 0x34 | bytes | ||
| Boi1 | 0x2 | 0x3 | 0x4 | mordiscos | |
| 1 | 10 | 11 | 100 | binario | |
| chip | 10101001 | 10100110 | 10100101 | 10011010 | binario |
| FIFO | OxA9 | OxA6 | OxA5 | Ox9A | feitizo |
Cada byte que se vai transmitir pásase un byte á vez á función de codificación de bytes. A función de codificación de bytes chamará á función de codificación de mordisco dúas veces, primeiro para o mordisco máis significativo e despois para o mordisco menos significativo.
A codificación de Manchester no software non é difícil. A partir do bit máis significativo, un é codificado como unha secuencia de chip "01". Un cero codificase como unha secuencia de chips "10". Isto pódese conseguir facilmente usando un bucle e cambiando dous bits para cada símbolo. Non obstante, é máis rápido usar só unha simple táboa de consulta de 16 entradas para cada bocado. A función codificar Manchester nibble codifica un mordisco de datos e despois escríbeo no FIFO. As fichas invírtense antes de escribir no FIFO para ter en conta os requisitos do preámbulo invertido.
Ao recibir, cada byte no FIFO consta de oito chips e decodícase nun bocado de datos. A función de bloque de lectura le un byte á vez desde o FIFO e chama á función de decodificación de bytes. As fichas invírtense despois da lectura do FIFO para ter en conta os requisitos do preámbulo invertido. Cada byte de chips codificados en Manchester é decodificado nun bocado de datos. O nibble decodificado escríbese no búfer RX usando a función de búfer RX do nibble de escritura.
Teña en conta que tanto a codificación como a decodificación realízanse un mordisco de datos á vez. A codificación nun búfer requiriría un búfer adicional o dobre do tamaño dos datos non codificados. A codificación e descodificación son moito máis rápidas que a velocidade de datos máis rápida admitida (100 k chips por segundo). Dado que o Si443x admite lecturas e escrituras de varios bytes no FIFO, hai unha pequena sobrecarga ao usar só lecturas e escrituras dun só byte. A sobrecarga é duns 10 µs para 100 chips codificados. O beneficio é un aforro de RAM de 512 bytes.
2. Tres de cada seis codificación decodificación
O método de codificación de tres de seis especificado en EN-13757-4 tamén se implementa no firmware da MCU. Esta codificación úsase para o modo T de alta velocidade (100 k chips por segundo) de contador a outro. O modelo T proporciona o tempo de transmisión máis curto e a maior duración da batería para un medidor sen fíos.
Cada byte de datos a transmitir divídese en dous nibbles. O mordisco máis significativo é codificado e transmitido primeiro. De novo, isto implícase mediante unha función de codificación de bytes que chama dúas veces á función de codificación de mordisco.
Cada bocado de datos está codificado nun símbolo de seis chips. A secuencia de símbolos de seis chips debe escribirse no FIFO de 8 chips.
Durante a codificación, dous bytes de datos codifican como catro mordiscos. Cada bocado é un símbolo de 6 fichas. Catro símbolos de 6 chips son agregados como tres bytes.
Táboa 6. Tres de seis codificacións
| datos | 0x12 | 0x34 | bytes | ||||
| Boi1 | 0x2 | 0x3 | 0x4 | mordiscos | |||
| chip | 15 | 16 | 13 | 34 | octal | ||
| 1101 | 1110 | 1011 | 11100 | binario | |||
| FIFO | 110100 | 11100010 | 11011100 | binario | |||
| 0x34 | OxE2 | OxDC | feitizo | ||||
No software, a codificación de tres de seis implícase mediante tres funcións aniñadas. A función de codificación de bytes chamará dúas veces á función de codificación. A función codificar nibble usa unha táboa de busca para o símbolo de seis chips e escribe o símbolo nas funcións Shift Three de Six. Esta función implementa un rexistro de desprazamento de 16 chips no software. O símbolo escríbese no byte menos significativo do rexistro de desprazamento. O rexistro desprázase dúas veces cara á esquerda. Isto repítese tres veces. Cando un byte completo está presente no byte superior do rexistro de desprazamento, invírtese e escríbese no FIFO.
Dado que cada byte de datos está codificado como byte e medio codificado, é importante borrar o rexistro de desprazamento inicialmente para que o primeiro byte codificado sexa correcto. Se a lonxitude do paquete é un número impar, despois de codificar todos os bytes, aínda quedará un mordisco no rexistro de desprazamento. Isto é xestionado co postámbolo como se explica na seguinte sección.
Decodificar o tres de cada seis codificados é o procedemento inverso. Durante a decodificación, tres bytes codificados descodícanse en dous bytes de datos. O rexistro de desprazamento do software utilízase de novo para agregar bytes de datos descodificados. Para a decodificación úsase unha táboa de busca inversa de 64 entradas. Isto usa menos ciclos pero máis memoria de código. Buscar o símbolo correspondente nunha táboa de consulta de 16 entradas leva moito máis tempo.
Postámbulo
A especificación Wireless M-bus ten requisitos específicos para o correo postal ou o tráiler. Para todos os modos, o mínimo é de dúas fichas e o máximo de oito. Dado que a unidade atómica mínima para o FIFO é un byte, utilízase un tráiler de 8 chips para o Modo S e o Modo R. O postámbolo do Modo T é de oito chips se a lonxitude do paquete é par ou de catro chips se a lonxitude do paquete é impar. O postámbolo de catro chips para unha lonxitude de paquete impar cumpre os requisitos de ter polo menos dúas fichas alternas.
Táboa 7. Lonxitude do postámbulo
| Lonxitude do postámbulo (fichas) | |||||
| min | máx | Implementación | secuencia de chip | ||
| Modo S | 2 | 8 | 8 | 1010101 | |
| Modo T | 2 | 8 | 4 | (estraño) | 101 |
| 8 | (mesmo) | 1010101 | |||
| Modo R | 2 | 8 | 8 | 1010101 | |
Manexador de paquetes
O manejador de paquetes do Si443x pódese usar nun modo de ancho de paquete variable ou nun modo de ancho de paquete fixo. O modo de ancho de paquete variable require un byte de lonxitude de paquete despois da palabra de sincronización e os bytes de cabeceira opcionais. Tras a recepción, a radio utilizará o byte de lonxitude para determinar o final dun paquete válido. Na transmisión, a radio inserirá o campo de lonxitude despois dos bytes de cabeceira.
O campo L para o protocolo M-bus sen fíos non se pode usar para o campo de lonxitude Si443x. En primeiro lugar, o campo L non é a lonxitude real do paquete. É o número de bytes de carga útil da capa de ligazón sen incluír os bytes ou a codificación CRC. En segundo lugar, o propio campo L codificase mediante a codificación Manchester ou a codificación Tres de seis para o contador de Modo T para outro.
A implementación usa o manejador de paquetes en modo de ancho de paquete fixo para a transmisión e recepción. Tras a transmisión, a capa PHY lerá o campo L no búfer de transmisión e calculará o número de bytes codificados, incluído o postámbolo. O número total de bytes codificados que se van transmitir escríbese no rexistro de lonxitude de paquete (0x3E).
Tras a recepción, os dous primeiros bytes codificados son decodificados e o campo L escríbese no búfer de recepción. O campo L úsase para calcular o número de bytes codificados que se recibirán. O número de bytes codificados que se recibirán escríbese despois no rexistro de lonxitude de paquete (0x3E). Descártase o correo postal.
O MCU debe decodificar o campo L, calcular o número de bytes codificados e escribir o valor no rexistro de lonxitude de paquete antes de recibir a lonxitude de paquete máis curta posible. O campo L máis curto permitido para a capa PHY é 9, o que dá 12 bytes non codificados. Isto dá 18 bytes codificados para o Modelo T. Os dous primeiros bytes xa foron decodificados. Así, o rexistro de lonxitude do paquete debe actualizarse en veces de 16 bytes a 100 kbps ou 1.28 milisegundos. Non é problema para un 8051 que funciona a 20 MIPS.
O número de bytes que se recibirán non inclúe o postámbolo, excepto o posámbolo de catro chips usado para os paquetes do Modo T cunha lonxitude de paquete impar. Así, o receptor non require un correo postal, excepto para os paquetes de lonxitude impar do Modelo T. Este postámbolo só é necesario para dar un número enteiro de bytes codificados. O contido do postámbolo é ignorado; polo que, se non se transmite o postámbolo, recibiranse catro chips de ruído e ignoraranse. Dado que o número total de bytes codificados está limitado a 255 (0xFF), a implementación limita o campo L máximo para os diferentes modos.
Táboa 8. Límites de tamaño do paquete
| codificado | decodificado | M-Bus | ||||
| bytes | bytes | Campo L | ||||
| dec | feitizo | dec | feitizo | dec | feitizo | |
| Modo S | 255 | FF | 127 | 7 F | 110 | 6E |
| Modo T (medidor-outro) | 255 | FF | 169 | A9 | 148 | 94 |
| Modo R | 255 | FF | 127 | 7 F | 110 | 6E |
Estes límites son normalmente moi superiores ao caso de uso típico dun medidor sen fíos. A lonxitude do paquete debe manterse pequena para obter a mellor duración posible da batería.
Ademais, o usuario pode especificar o campo L máximo que se debe recibir (USER_RX_MAX_L_FIELD). Isto determina o tamaño necesario para o búfer de recepción (USER_RX_BUFFER_SIZE).
Soportar un campo L máximo de 255 requiriría un búfer de recepción de 290 bytes e un máximo de 581 bytes codificados Manchester. O manejador de paquetes debería estar desactivado e o rexistro de lonxitude do paquete non podería usarse nese caso. Isto é factible, pero é máis conveniente usar o manejador de paquetes, se é posible.
Uso de FIFO
O Si4431 proporciona un FIFO de 64 bytes para transmitir e recibir. Dado que o número de bytes codificados é de 255, é posible que un paquete codificado completo non caia no búfer de 64 bytes.
Transmisión
Na transmisión, calcúlase o número total de bytes codificados. Se o número total de bytes codificados, incluído o postámbolo, é inferior a 64 bytes, o paquete completo escríbese no FIFO e só se activa a interrupción do paquete enviado. A maioría dos paquetes curtos enviaranse nunha soa transferencia FIFO.
Se o número de bytes codificados é superior a 64, serán necesarias varias transferencias FIFO para enviar o paquete. Os primeiros 64 bytes escríbense no FIFO. As interrupcións Paquete enviado e TX FIFO case baleiras están habilitadas. O limiar TX FIFO case baleiro establécese en 16 bytes (25%). En cada evento IRQ, lese o rexistro de estado 2. O bit Paquete enviado compróbase primeiro e, se o paquete non se enviou completamente, os seguintes 48 bytes de datos codificados escríbense no FIFO. Isto continúa ata que se escriben todos os bytes codificados e se produce a interrupción do paquete enviado.
1. Recepción
Na recepción, inicialmente, só está activada a interrupción de Sync Word. Despois de recibir a palabra de sincronización, a interrupción da palabra de sincronización está desactivada e a interrupción FIFO case completa está habilitada. O limiar FIFO case completo está inicialmente establecido en 2 bytes. A primeira interrupción FIFO Almost Full úsase para saber cando se recibiron os dous bytes de lonxitude. Unha vez recibida a lonxitude, decodícase a lonxitude e calcúlase o número de bytes codificados. O limiar case completo de RX FIFO establécese entón en 48 bytes. O RX FIFO está case cheo e as interrupcións de paquetes válidos están habilitadas. No seguinte evento IRQ, lese o rexistro de estado 1. En primeiro lugar, compróbase o bit Paquete válido e despois o bit FIFO Case cheo. Se só se establece o bit RX FIFO Almost Full, os seguintes 48 bytes lense do FIFO. Se se establece o bit de paquete válido, o resto do paquete lese desde o FIFO. O MCU fai un seguimento de cantos bytes se liron e deixa de ler despois do último byte.
Capa de enlace de datos
O módulo de capa de enlace de datos implementa unha capa de enlace compatible con 13757-4:2005. A capa de enlace de datos (LINK) proporciona unha interface entre a capa física (PHY) e a capa de aplicación (AL).
A capa de enlace de datos realiza as seguintes funcións:
- Ofrece funcións que transfiren datos entre PHY e AL
- Xera CRC para as mensaxes de saída
- Detecta erros CRC nas mensaxes entrantes
- Proporciona o enderezo físico
- Recoñece as transferencias para modos de comunicación bidireccional
- Bits de datos de marcos
- Detecta erros de enmarcado nas mensaxes entrantes
Formato de marco de capa de ligazón
O formato de cadro Wireless M-Bus usado na EN 13757-4:2005 deriva do formato de cadro FT3 (Frame Type 3) de IEC60870-5-2. O marco está composto por un ou máis bloques de datos. Cada bloque inclúe un campo CRC de 16 bits. O primeiro bloque é un bloque de lonxitude fixa de 12 bytes que inclúe o campo L, o campo C, o campo M e o campo A.
- Campo L
O campo L é a lonxitude da carga útil de datos da capa de ligazón. Isto non inclúe o propio campo L nin ningún dos bytes CRC. Inclúe o campo L, campo C, campo M e campo A. Estes forman parte da carga útil PHY.
Dado que o número de bytes codificados está limitado a 255 bytes, o valor máximo admitido para o campo M é de 110 bytes para os datos codificados de Manchester e de 148 bytes para os datos codificados de tres de seis en Modo T.
A capa de enlace é a responsable de calcular o campo L na transmisión. A capa de ligazón usará o campo L na recepción.
Teña en conta que o campo L non indica a lonxitude da carga útil PHY nin o número de bytes codificados. Tras a transmisión, o PHY calculará a lonxitude da carga útil PHY e o número de bytes codificados. Tras a recepción, o PHY decodificará o campo L e calculará o número de bytes para decodificar. - Campo C
O campo C é o campo de control de cadros. Este campo identifica o tipo de trama e úsase para as primitivas do servizo de intercambio de datos de enlace. O campo C indica o tipo de trama: ENVIAR, CONFIRMAR, SOLICITAR ou RESPONDER. No caso das tramas SEND e REQUEST, o campo C indica se se espera unha CONFIRM ou RESPOND.
Cando se utiliza a función básica Link TX, pódese utilizar calquera valor de C. Cando se utiliza Link Service Primitives, o campo C enchégase automaticamente segundo a EN 13757-4:2005. - Campo M
O campo M é o código do fabricante. Os fabricantes poden solicitar un código de tres letras entre os seguintes web enderezo: http://www.dlms.com/flag/INDEX.HTM Cada carácter do código de tres letras está codificado como cinco bits. O código de 5 bits pódese obter tomando o código ASCII e restando 0x40 ("A"). Os tres códigos de 5 bits están concatenados para facer 15 bits. O bit máis significativo é cero. - Campo A
O campo de enderezo é un enderezo único de 6 bytes para cada dispositivo. O enderezo único debe ser asignado polo fabricante. É responsabilidade de cada fabricante asegurarse de que cada dispositivo teña un enderezo único de 6 bytes. O enderezo dos marcos de envío e solicitude é o enderezo propio do contador ou doutro dispositivo. Os marcos de datos de confirmación e resposta envíanse utilizando o enderezo do dispositivo de orixe. - Campo CI
O campo CI é a cabeceira da aplicación e especifica o tipo de datos na carga útil de datos da aplicación. Aínda que a EN13757-4:2005 especifica un número limitado de valores, o Link Service Primitives permitirá que se utilice calquera valor. - CRC
O CRC está especificado na EN13757-4:2005.
O polinomio CRC é:
X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
Teña en conta que o M-Bus CRC calcúlase sobre cada bloque de 16 bytes. O resultado é que cada 16 bytes de datos requiren que se transmitan 18 bytes.
Información adicional
Para obter información adicional sobre a implementación da capa de enlace, consulte "AN452: Guía de programadores de pila M-Bus sen fíos".
Xestión de enerxía
A figura 2 mostra a liña de tempo de xestión de enerxía para un medidor, por exemploample usando o modo T1.
O MCU debe estar en modo de suspensión sempre que sexa posible para aforrar enerxía. Neste example, o MCU está durmindo cando o RTC está en funcionamento, ao agardar ao inicio do cristal de radio e ao transmitir desde o FIFO. O MCU espertarase a partir do sinal EZRadioPRO IRQ conectado a un espertador Port Match.
Ao transmitir mensaxes de máis dun bloque, o MCU debe espertar para encher o FIFO (baseado na interrupción case baleira FIFO) e despois volver a durmir.
O MCU debe estar en modo inactivo funcionando desde o oscilador de baixa potencia ou o oscilador en modo de ráfaga ao ler desde o ADC. O ADC require un reloxo SAR.
Cando non estea en uso, o EZRadioPRO debería estar en modo de apagado co pin SDN alto. Isto require unha conexión por cable ao MCU. Os rexistros de EZ Radio Pro non se conservan no modo de apagado; polo tanto, o EZRadioPro iníciase en cada intervalo RTC. A inicialización da radio leva menos de 100 µs e conserva 400 nA. Isto resulta nun aforro de enerxía de 10 µJ, baseado nun intervalo de 10 segundos.
O cristal EZRadioPRO leva uns 16 ms para un POR. Isto é o suficientemente longo para calcular o CRC duns oito bloques. O MCU volverá a durmir se completa todos os CRC antes de que o cristal se estabilice. Se é necesario o cifrado, tamén se pode iniciar mentres se espera no oscilador de cristal.
O MCU debería funcionar a 20 MHz usando o oscilador de baixa potencia para a maioría das tarefas. As tarefas que requiren un tempo de espera preciso deben utilizar o oscilador de precisión e o modo inactivo en lugar do modo de suspensión. O RTC ofrece resolución suficiente para a maioría das tarefas. O cronograma de xestión de enerxía para o contador T2 exampA aplicación móstrase na Figura 3.
A implementación do transceptor debe optimizarse para o caso normal cando o medidor esperta e non hai lector presente. Os tempos de espera mínimo/máximo de ACK son suficientemente longos para que sexa posible utilizar o C8051F930 RTC e poñer o MCU en modo de suspensión.
Ofrécense opcións de compilación para lectores de alimentación ou USB que non precisan usar o modo de suspensión. Usarase o modo inactivo en lugar do modo de suspensión para que o USB e o UART poidan interromper o MCU.
Simplicity Studio
Acceso cun só clic a MCU e ferramentas sen fíos, documentación, software, bibliotecas de código fonte e moito máis. Dispoñible para Windows,
Mac e Linux!
 |
 |
 |
 |
| Carteira IoT www.silabs.com/IoT |
SW/HW www.silabs.com/simplicity |
Calidade www.silabs.com/quality |
Apoio e Comunidade community.silabs.com |
Exención de responsabilidade
Silicon Labs pretende ofrecer aos clientes a documentación máis recente, precisa e detallada de todos os periféricos e módulos dispoñibles para os implementadores de sistemas e software que utilicen ou teñan intención de utilizar os produtos de Silicon Labs. Os datos de caracterización, os módulos e periféricos dispoñibles, os tamaños de memoria e os enderezos de memoria refírense a cada dispositivo específico, e os parámetros "típicos" proporcionados poden variar en diferentes aplicacións. Aplicación exampOs aquí descritos son só para fins ilustrativos. Silicon Labs resérvase o dereito de facer cambios sen previo aviso e limitación á información do produto, especificacións e descricións aquí, e non ofrece garantías sobre a precisión ou integridade da información incluída. Silicon Labs non terá ningunha responsabilidade polas consecuencias do uso da información que se ofrece aquí. Este documento non implica nin expresa licenzas de copyright concedidas a continuación para deseñar ou fabricar ningún circuíto integrado. Os produtos non están deseñados nin autorizados para ser usados dentro de ningún sistema de soporte vital sen o consentimento específico por escrito de Silicon Labs. Un "Sistema de soporte vital" é calquera produto ou sistema destinado a manter ou manter a vida e/ou a saúde que, se falla, pode esperarse razoablemente que resulte en danos persoais importantes ou a morte. Os produtos de Silicon Labs non están deseñados nin autorizados para aplicacións militares. Os produtos de Silicon Labs non se utilizarán en ningún caso en armas de destrución masiva, incluídas (pero non limitadas a) armas nucleares, biolóxicas ou químicas, ou mísiles capaces de lanzar tales armas.
Información da marca comercial
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® e Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, Energy Micro logo e combinacións dos mesmos, "os microcontroladores máis amigables coa enerxía do mundo", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, o Telegesis Logo®, USBXpress® e outros son marcas comerciais ou marcas rexistradas de Silicon Labs. ARM, CORTEX, Cortex-M3 e os pulgares son marcas comerciais ou marcas rexistradas de ARM Holdings. Keil é unha marca rexistrada de ARM Limited. Todos os demais produtos ou marcas mencionadas aquí son marcas comerciais dos seus respectivos posuidores.
Silicon Laboratories Inc.
400 Oeste César Chávez
Austin, TX 78701
EUA
http://www.silabs.com
Documentos/Recursos
 |
Implementación de software M-BUS sen fíos SILICON LABS AN451 [pdfGuía do usuario SILICON LABS, C8051, MCU e, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Implementation, AN451 |
