AN451
IMPLEMENTAZIONE SOFTWARE WIRELESS M-BUS
Introduzione
Questa nota applicativa descrive l'implementazione di Silicon Labs di Wireless M-Bus utilizzando un MCU Silicon Labs C8051 e EZRadioPRO®. Wireless M-bus è uno standard europeo per le applicazioni di lettura dei contatori che utilizzano la banda di frequenza 868 MHz.
Impila livelli
Wireless M-Bus utilizza il modello IEC a 3 strati, che è un sottoinsieme del modello OSI a 7 strati (vedere la Figura 1).
Lo strato fisico (PHY) è definito nella EN 13757-4. Il livello fisico definisce la modalità di codifica e trasmissione dei bit, le caratteristiche del modem RF (velocità del chip, preambolo e parola di sincronizzazione) e i parametri RF (modulazione, frequenza centrale e deviazione di frequenza).
Il livello PHY viene implementato utilizzando una combinazione di hardware e firmware. L'EZRadioPRO esegue tutte le funzioni RF e modem. L'EZRadioPRO viene utilizzato in modalità FIFO con il gestore di pacchetti. Il modulo MbusPhy.c fornisce interfaccia SPI, codifica/decodifica, lettura/scrittura a blocchi e gestione dei pacchetti e gestisce gli stati del ricetrasmettitore.
Il livello di collegamento dati M-Bus è implementato nel modulo MbusLink.c. L'interfaccia di programmazione dell'applicazione M-Bus è costituita da funzioni pubbliche che possono essere chiamate dal livello dell'applicazione nel thread principale. Il modulo MbusLink implementa anche il Data Link Layer. Il livello di collegamento dati formatterà e copierà i dati dal buffer TX dell'applicazione al buffer TX di MbusPhy, aggiungendo le intestazioni e i CRC richiesti.
Il livello Applicazione stesso non fa parte del firmware M-bus. Il livello dell'applicazione definisce come formattare un'ampia varietà di dati per la trasmissione. La maggior parte dei contatori deve trasmettere solo uno o due tipi di dati. L'aggiunta di una grande quantità di codice per accogliere qualsiasi tipo di dati al contatore aggiungerebbe codice e costo non necessari al contatore. Potrebbe essere fattibile implementare una libreria o un'intestazione file con un elenco esaustivo di tipi di dati. Tuttavia, la maggior parte dei clienti di misurazione sa esattamente che tipo di dati devono trasmettere e può fare riferimento allo standard per i dettagli di formattazione. Un lettore o sniffer universale potrebbe implementare un set completo di tipi di dati dell'applicazione sulla GUI del PC. Per questi motivi, il livello dell'applicazione viene implementato utilizzando example applicazioni per un contatore e un lettore.
Standard richiesti
- Norma EN 13757-4
Norma EN 13757-4
Sistema di comunicazione per contatori e telelettura dei contatori
Parte 4: Lettura del contatore wireless
Lettura del radiometro per il funzionamento nella banda SRD da 868 MHz a 870 MHz - Norma EN 13757-3
Sistema di comunicazione per contatori e telelettura dei contatori
Parte 3: livello di applicazione dedicato - Norma IEC 60870-2-1:1992
Apparecchiature e sistemi di telecontrollo
Parte 5: Protocolli di trasmissione
Sezione 1: Procedura di trasmissione del collegamento - Norma IEC 60870-1-1:1990
Apparecchiature e sistemi di telecontrollo
Parte 5: Protocolli di trasmissione
Sezione 1: Formati di frame di trasmissione
Definizioni
- Autobus M—M-Bus è uno standard cablato per la lettura dei contatori in Europa.
- M-Bus wireless—M-Bus wireless per applicazioni di lettura dei contatori in Europa.
- FISICO—Physical Layer definisce come i bit ei byte di dati vengono codificati e trasmessi.
- API—Interfaccia del programmatore di applicazioni.
- COLLEGAMENTO-Data Link Layer definisce come vengono trasmessi blocchi e frame.
- CRC—Controllo di ridondanza ciclico.
- FSK—Trasmissione di frequenza.
- Patata fritta-La più piccola unità di dati trasmessi. Un bit di dati è codificato come più chip.
- Modulo-Fonte del codice AC .c file.
Descrizione funzionale di M-Bus PHY
Sequenza di preambolo
La sequenza di preambolo specificata dalla specifica M-bus è un numero intero che alterna zero e uno. Uno è definito come la frequenza più alta e uno zero è definito come la frequenza più bassa.
nx (01)
Le opzioni di preambolo per Si443x sono un numero intero di nibble composti da uno e zero alternati.
nx (1010)
Un preambolo con uno in più non sarebbe un problema, ma, quindi, la parola di sincronizzazione e il carico utile sarebbero disallineati di un bit.
La soluzione è invertire l'intero pacchetto impostando il bit di motore nel registro Modulation Control 2 (0x71). Questo invertirà il preambolo, la parola di sincronizzazione e i dati TX/RX. Di conseguenza, i dati dovrebbero essere invertiti durante la scrittura dei dati TX o la lettura dei dati RX. Inoltre, la parola di sincronizzazione viene invertita prima di scrivere nei registri della parola di sincronizzazione di Si443x.
Sincronizzazione Parola
La parola di sincronizzazione richiesta da EN-13757-4 è di 18 chip per la modalità S e la modalità R o 10 chip per il modello T. La parola di sincronizzazione per Si443x è da 1 a 4 byte. Tuttavia, poiché la parola di sincronizzazione è sempre preceduta dal preambolo, gli ultimi sei bit del preambolo possono essere considerati parte della parola di sincronizzazione; quindi, la prima parola di sincronizzazione è completata da tre ripetizioni di uno zero seguite da uno. La parola di sincronizzazione viene completata prima della scrittura nei registri Si443x.
Tabella 1. Parola di sincronizzazione per la modalità S e la modalità R
| Norma EN 13757-4 | 00 | 01110110 | 10010110 | binario |
| 00 | 76 | 96 | hex | |
| tampone con (01) x 3 | 01010100 | 01110110 | 10010110 | binario |
| 54 | 76 | 96 | hex | |
| complemento | 10101011 | 10001001 | 01101001 | binario |
| AB | 89 | 69 | hex |
Tabella 2. Parola di sincronizzazione per il misuratore di modalità T su Altro
| SINCRONIZZAZIONE | SINCRONIZZAZIONE | SINCRONIZZAZIONE |
| PAROLA | PAROLA | PAROLA |
| 3 | 2 | 1 |
Lunghezza del preambolo di trasmissione
Il preambolo minimo è specificato per quattro diverse modalità operative. È accettabile avere un preambolo più lungo di quanto specificato. Sottraendo sei chip per il preambolo si ottiene il numero minimo di chip per il preambolo Si443x. L'implementazione aggiunge due nibble extra di preambolo in tutte le modalità di preambolo breve per migliorare il rilevamento e l'interoperabilità del preambolo. Il preambolo sul Modo S con un preambolo lungo è molto lungo; quindi, viene utilizzato il preambolo minimo. La lunghezza del preambolo in nibble viene scritta nel registro Lunghezza preambolo (0x34). Il registro della lunghezza del preambolo determina il preambolo solo al momento della trasmissione. Le specifiche minime e le impostazioni della lunghezza del preambolo sono riassunte nella Tabella 3.
Tabella 3. Lunghezza del preambolo di trasmissione
| EN-13757-4 minimo |
Si443x Preambolo Impostazione |
Sincronizzazione Parola |
Totale | extra | |||
| nx (01) | patatine fritte | stuzzichini | patatine fritte | patatine fritte | patatine fritte | patatine fritte | |
| Mode S breve preambolo | 15 | 30 | 8 | 32 | 6 | 38 | 8 |
| Preambolo lungo della modalità S | 279 | 558 | 138 | 552 | 6 | 558 | 0 |
| Modalità T (metro-altro) | 19 | 38 | 10 | 40 | 6 | 46 | 8 |
| Modalità R | 39 | 78 | 20 | 80 | 6 | 86 | 8 |
Il preambolo minimo per la ricezione è determinato dal registro Preamble Detection Control (0x35). Alla ricezione, il numero di bit nella parola di sincronizzazione deve essere sottratto dal preambolo minimo specificato per determinare il preambolo utilizzabile. Il tempo di assestamento minimo del ricevitore è 16 chip se AFC è abilitato o 8 chip se AFC è disabilitato. Il tempo di assestamento del ricevitore viene anche sottratto dal preambolo utilizzabile per determinare l'impostazione minima per il registro di controllo del rilevamento del preambolo.
La probabilità di un falso preambolo dipende dall'impostazione del registro Preamble Detection Control. Una breve impostazione di 8 chip può causare il rilevamento di un falso preambolo ogni pochi secondi. L'impostazione consigliata di 20 chip rende il rilevamento di falsi preamboli un evento improbabile. Le lunghezze dei preamboli per la modalità R e la modalità SL sono sufficientemente lunghe per l'utilizzo dell'impostazione consigliata.
C'è pochissimo vantaggio nel far rilevare al preambolo più di 20 chip.
L'AFC è disabilitato per il modello S con un breve preambolo e il modello T. Ciò riduce il tempo di assestamento del ricevitore e consente un'impostazione di rilevamento del preambolo più lunga. Con AFC disabilitato, la modalità T può utilizzare l'impostazione consigliata di 20 chip. Per la Model S con un breve preambolo viene utilizzata un'impostazione di 4 bocconcini o 20 trucioli. Ciò rende la probabilità di rilevamento di un falso preambolo leggermente più alta per questo modello.
Tabella 4. Rilevamento preambolo
| EN-13757-4 minimo |
Sincronizzazione Parola |
utilizzabile preambolo |
Regolazione RX | Rilevare minimo |
Si443x Preambolo Impostazione rilevamento |
|||
| nx (01) | patatine fritte | patatine fritte | patatine fritte | patatine fritte | patatine fritte | stuzzichini | patatine fritte | |
| Mode S breve preambolo | 15 | 30 | 6 | 24 | 8* | 16 | 4 | 16 |
| Preambolo lungo della Model S | 279 | 558 | 6 | 552 | 16 | 536 | 5 | 20 |
| Modello T (metro-altro) | 19 | 38 | 6 | 32 | 8* | 24 | 5 | 20 |
| Modalità R | 39 | 78 | 6 | 72 | 16 | 56 | 5 | 20 |
| *Nota: AFC disabilitato | ||||||||
Il ricevitore è configurato per interagire con un trasmettitore utilizzando il preambolo minimo specificato. Ciò garantisce che il ricevitore interagirà con qualsiasi trasmettitore conforme a M-bus.
La specifica Wireless M-Bus richiede un preambolo molto lungo per la modalità S1 di almeno 558 chip. Ci vorranno circa 17 ms solo per trasmettere il preambolo. Il Si443x non richiede un preambolo così lungo e non beneficia del lungo preambolo. Sebbene il preambolo lungo sia indicato come opzionale per la modalità S2, non c'è motivo di utilizzare un preambolo lungo con il Si443x. Se si desidera una comunicazione unidirezionale, la modalità T1 fornirà un preambolo più breve, una maggiore velocità di trasmissione dei dati e una maggiore durata della batteria. Se è richiesta una comunicazione bidirezionale utilizzando la modalità S2, si consiglia un breve preambolo.
Notare che la soglia di rilevamento per la Model S con un preambolo lungo è più lunga del numero di nibble di preambolo trasmessi per la Model S con un preambolo breve. Ciò significa che il ricevitore Modo S con preambolo lungo non rileverà un preambolo da un trasmettitore Modo S con preambolo breve. Ciò è necessario se il ricevitore della modalità S con preambolo lungo deve trarre beneficio dal preambolo lungo.
Si noti che il ricevitore in modalità S con preambolo breve rileverà il preambolo e riceverà i pacchetti da entrambe le modalità S con preambolo breve.
trasmettitore e un trasmettitore Mode S con preambolo lungo; quindi, in generale, il lettore del contatore dovrebbe utilizzare la configurazione del ricevitore Modo S con preambolo breve.
Codifica/Decodifica
La specifica Wireless M-bus richiede due diversi metodi di codifica. La codifica Manchester viene utilizzata per la modalità S e la modalità R. La codifica Manchester viene utilizzata anche per il collegamento da altro a contatore nel modello T. Il collegamento da contatore a altro modello T utilizza 3 codifiche su 6.
1. Codifica/decodifica Manchester
La codifica Manchester è storicamente comune nei sistemi RF per fornire un robusto recupero e tracciamento dell'orologio utilizzando un modem semplice ed economico. Tuttavia, una moderna radio ad alte prestazioni come la Si443x non necessita della codifica Manchester. La codifica Manchester è supportata principalmente per la compatibilità con gli standard esistenti, ma la velocità dei dati per il Si443x viene effettivamente raddoppiata quando non si utilizza la codifica Manchester.
Il Si443x supporta la codifica e la decodifica Manchester dell'intero pacchetto nell'hardware. Sfortunatamente, la parola di sincronizzazione non è codificata Manchester. Una sequenza Manchester non valida è stata scelta intenzionalmente per la parola di sincronizzazione. Ciò rende la codifica Manchester incompatibile con la maggior parte delle radio esistenti, incluso il Si443x. Di conseguenza, la codifica e la decodifica Manchester devono essere eseguite dall'MCU. Ogni byte sui dati non codificati è costituito da otto bit di dati. Usando la codifica Manchester, ogni bit di dati è codificato in un simbolo a due chip. Poiché i dati codificati devono essere scritti nella FIFO radio otto chip alla volta, un pezzetto di dati viene codificato e scritto nella FIFO alla volta.
Tabella 5. Codifica Manchester
| dati | Ox12 | 0x34 | byte | ||
| Ox1 | 0x2 | 0x3 | 0x4 | stuzzichini | |
| 1 | 10 | 11 | 100 | binario | |
| chip | 10101001 | 10100110 | 10100101 | 10011010 | binario |
| FIFO | bueA9 | bueA6 | bueA5 | bue9A | hex |
Ogni byte da trasmettere viene passato un byte alla volta alla funzione di codifica byte. La funzione encode byte chiamerà la funzione encode nibble due volte, prima per il nibble più significativo e poi per il nibble meno significativo.
La codifica Manchester nel software non è difficile. Partendo dal bit più significativo, uno viene codificato come sequenza di chip "01". Uno zero è codificato come una sequenza di chip "10". Questo può essere facilmente realizzato utilizzando un ciclo e spostando due bit per ciascun simbolo. Tuttavia, è più veloce utilizzare una semplice tabella di ricerca a 16 voci per ogni bocconcino. La funzione Encode Manchester nibble codifica un nibble di dati, quindi lo scrive nel FIFO. I chip vengono invertiti prima di scrivere alla FIFO per tenere conto dei requisiti del preambolo invertito.
Durante la ricezione, ogni byte nella FIFO è costituito da otto chip ed è decodificato in un bocconcino di dati. La funzione di blocco di lettura legge un byte alla volta dalla FIFO e chiama la funzione di decodifica byte. I chip vengono invertiti dopo la lettura dalla FIFO per tenere conto dei requisiti del preambolo invertito. Ogni byte dei chip codificati Manchester viene decodificato in un bocconcino di dati. Il nibble decodificato viene scritto nel buffer RX utilizzando la funzione write nibble RX buffer.
Notare che sia la codifica che la decodifica vengono eseguite al volo un nibble di dati alla volta. La codifica in un buffer richiederebbe un buffer aggiuntivo due volte la dimensione dei dati non codificati. La codifica e la decodifica sono molto più veloci della massima velocità di trasmissione dati supportata (100 k chip al secondo). Poiché Si443x supporta letture e scritture a più byte su FIFO, l'utilizzo di solo letture e scritture a byte singolo comporta un piccolo sovraccarico. L'overhead è di circa 10 µs per 100 chip codificati. Il vantaggio è un risparmio di RAM di 512 byte.
2. Decodifica codifica tre su sei
Il metodo di codifica Tre su sei specificato in EN-13757-4 è implementato anche nel firmware dell'MCU. Questa codifica viene utilizzata per la modalità T ad alta velocità (100 k chip al secondo) da un contatore all'altro. Il modello T offre il tempo di trasmissione più breve e la durata della batteria più lunga per un misuratore wireless.
Ogni byte di dati da trasmettere è diviso in due nibble. Il bocconcino più significativo viene codificato e trasmesso per primo. Di nuovo, questo viene implementato utilizzando una funzione di codifica byte che chiama la funzione di codifica nibble due volte.
Ogni bocconcino di dati è codificato in un simbolo a sei chip. La sequenza dei simboli a sei chip deve essere scritta nella FIFO a 8 chip.
Durante la codifica, due byte di dati vengono codificati come quattro nibble. Ogni bocconcino è un simbolo di 6 fiches. Quattro simboli a 6 chip sono aggregati come tre byte.
Tabella 6. Codifica tre su sei
| dati | 0x12 | 0x34 | byte | ||||
| Ox1 | 0x2 | 0x3 | 0x4 | stuzzichini | |||
| chip | 15 | 16 | 13 | 34 | ottale | ||
| 1101 | 1110 | 1011 | 11100 | binario | |||
| FIFO | 110100 | 11100010 | 11011100 | binario | |||
| 0x34 | BueE2 | OxDC | hex | ||||
Nel software, la codifica tre su sei viene implementata utilizzando tre funzioni annidate. La funzione encode byte chiamerà la funzione encode nibble due volte. La funzione di codifica nibble utilizza una tabella di ricerca per il simbolo a sei chip e scrive il simbolo nelle funzioni Shift Three su Six. Questa funzione implementa un registro a scorrimento a 16 chip nel software. Il simbolo viene scritto nel byte meno significativo del registro a scorrimento. Il registro viene spostato a sinistra due volte. Questo viene ripetuto tre volte. Quando un byte completo è presente nel byte superiore del registro a scorrimento, viene invertito e scritto nel FIFO.
Poiché ogni byte di dati è codificato come un byte e mezzo codificato, è importante cancellare inizialmente il registro a scorrimento in modo che il primo byte codificato sia corretto. Se la lunghezza del pacchetto è un numero dispari, dopo aver codificato tutti i byte, rimarrà ancora un nibble nel registro a scorrimento. Questo viene gestito con il postambolo come spiegato nella sezione successiva.
La decodifica dei tre su sei codificati è la procedura inversa. Durante la decodifica, tre byte codificati vengono decodificati in due byte di dati. Il registro a scorrimento software viene nuovamente utilizzato per aggregare i byte di dati decodificati. Per la decodifica viene utilizzata una tabella di ricerca inversa a 64 voci. Questo utilizza meno cicli ma più memoria di codice. La ricerca del simbolo corrispondente in una tabella di ricerca a 16 voci richiede molto più tempo.
Postambolo
La specifica Wireless M-bus ha requisiti specifici per il postambolo o il rimorchio. Per tutte le modalità, il minimo è di due chip e il massimo è di otto chip. Poiché l'unità atomica minima per la FIFO è un byte, per la modalità S e la modalità R viene utilizzato un trailer a 8 chip. Il postambole della modalità T è di otto chip se la lunghezza del pacchetto è pari o di quattro chip se la lunghezza del pacchetto è dispari. Il postambolo a quattro chip per una lunghezza dispari del pacchetto soddisfa i requisiti di avere almeno due chip alternati.
Tabella 7. Lunghezza Postambolo
| Lunghezza Postambolo (chips) | |||||
| minimo | massimo | Implementazione | sequenza di chip | ||
| Modalità S | 2 | 8 | 8 | 1010101 | |
| Modalità T | 2 | 8 | 4 | (strano) | 101 |
| 8 | (anche) | 1010101 | |||
| Modalità R | 2 | 8 | 8 | 1010101 | |
Gestore di pacchetti
Il gestore di pacchetti sul Si443x può essere utilizzato in modalità a larghezza di pacchetto variabile o in modalità a larghezza di pacchetto fissa. La modalità a larghezza di pacchetto variabile richiede un byte di lunghezza del pacchetto dopo la parola di sincronizzazione e byte di intestazione facoltativi. Alla ricezione, la Radio utilizzerà il byte di lunghezza per determinare la fine di un pacchetto valido. In trasmissione, la radio inserirà il campo della lunghezza dopo i byte di intestazione.
Il campo L per il protocollo wireless M-bus non può essere utilizzato per il campo lunghezza Si443x. Primo, il campo L non è la lunghezza effettiva del pacchetto. È il numero di byte del payload del livello di collegamento esclusi i byte CRC o la codifica. In secondo luogo, il campo L stesso è codificato utilizzando la codifica Manchester o la codifica Tre su sei per il misuratore di modalità T ad altro.
L'implementazione utilizza il gestore di pacchetti in modalità a larghezza di pacchetto fissa sia per la trasmissione che per la ricezione. Al momento della trasmissione, il livello PHY leggerà il campo L nel buffer di trasmissione e calcolerà il numero di byte codificati, incluso il postambolo. Il numero totale di byte codificati da trasmettere viene scritto nel registro Packet Length (0x3E).
Alla ricezione, i primi due byte codificati vengono decodificati e il campo L viene scritto nel buffer di ricezione. Il campo L viene utilizzato per calcolare il numero di byte codificati da ricevere. Il numero di byte codificati da ricevere viene quindi scritto nel registro Packet Length (0x3E). Il postambolo viene scartato.
L'MCU deve decodificare il campo L, calcolare il numero di byte codificati e scrivere il valore nel registro Packet Length prima che sia stata ricevuta la lunghezza del pacchetto più breve possibile. Il campo L più breve consentito per il livello PHY è 9, fornendo 12 byte non codificati. Ciò fornisce 18 byte codificati per il modello T. I primi due byte sono già stati decodificati. Pertanto, il registro della lunghezza del pacchetto deve essere aggiornato in tempi di 16 byte a 100 kbps o 1.28 millisecondi. Questo non è un problema per un 8051 che funziona a 20 MIPS.
Il numero di byte da ricevere non include il postambolo, ad eccezione del postambolo a quattro chip utilizzato per i pacchetti Modo T con una lunghezza dispari del pacchetto. Pertanto, il destinatario non richiede un postambolo, ad eccezione dei pacchetti di lunghezza dispari del modello T. Questo postambolo è necessario solo per fornire un numero intero di byte codificati. Il contenuto del postambolo viene ignorato; quindi, se il postambolo non viene trasmesso, verranno ricevuti e ignorati quattro chip di rumore. Poiché il numero totale di byte codificati è limitato a 255 (0xFF), l'implementazione limita il campo L massimo per le diverse modalità.
Tabella 8. Limiti delle dimensioni del pacchetto
| codificato | decodificato | Autobus M | ||||
| byte | byte | L-campo | ||||
| dicembre | hex | dicembre | hex | dicembre | hex | |
| Modalità S | 255 | FF | 127 | 7 gradi | 110 | 6E |
| Modalità T (metro-altro) | 255 | FF | 169 | A9 | 148 | 94 |
| Modalità R | 255 | FF | 127 | 7 gradi | 110 | 6E |
Questi limiti sono normalmente ben al di sopra del caso di utilizzo tipico per un misuratore wireless. La lunghezza del pacchetto deve essere ridotta per ottenere la migliore durata possibile della batteria.
Inoltre, l'utente può specificare il campo L massimo che deve essere ricevuto (USER_RX_MAX_L_FIELD). Ciò determina la dimensione richiesta per il buffer di ricezione (USER_RX_BUFFER_SIZE).
Il supporto di un campo L massimo di 255 richiede un buffer di ricezione di 290 byte e un massimo di 581 byte codificati Manchester. Il gestore del pacchetto dovrebbe essere disabilitato e il registro della lunghezza del pacchetto non potrebbe essere utilizzato in quel caso. Questo è fattibile, ma è più conveniente usare il gestore di pacchetti, se possibile.
Utilizzo FIFO
Il Si4431 fornisce un FIFO a 64 byte per la trasmissione e la ricezione. Poiché il numero di byte codificati è 255, un intero pacchetto codificato potrebbe non rientrare nel buffer di 64 byte.
Trasmissione
Alla trasmissione viene calcolato il numero totale di byte codificati. Se il numero totale di byte codificati, incluso il postambolo, è inferiore a 64 byte, l'intero pacchetto viene scritto nella FIFO e viene abilitato solo l'interrupt del pacchetto inviato. La maggior parte dei pacchetti brevi verrà inviata in un trasferimento FIFO.
Se il numero di byte codificati è maggiore di 64, saranno necessari più trasferimenti FIFO per inviare il pacchetto. I primi 64 byte vengono scritti nella FIFO. Gli interrupt Packet Sent e TX FIFO Quasi vuoto sono abilitati. La soglia FIFO TX Quasi vuoto è fissata a 16 byte (25%). Ad ogni evento IRQ viene letto il registro di stato 2. Il bit Packet Sent viene controllato per primo e, se il pacchetto non è stato completamente inviato, i successivi 48 byte di dati codificati vengono scritti nella FIFO. Questo continua fino a quando tutti i byte codificati sono stati scritti e si verifica l'interrupt di Packet Sent.
1. Accoglienza
In ricezione, inizialmente, è abilitato solo l'interrupt Sync Word. Dopo aver ricevuto la parola di sincronizzazione, l'interruzione della parola di sincronizzazione è disabilitata e l'interruzione FIFO Quasi piena è abilitata. La soglia FIFO quasi piena è inizialmente impostata su 2 byte. Il primo interrupt FIFO Quasi pieno viene utilizzato per sapere quando sono stati ricevuti i due byte di lunghezza. Una volta ricevuta la lunghezza, la lunghezza viene decodificata e viene calcolato il numero di byte codificati. La soglia FIFO RX quasi piena viene quindi impostata a 48 byte. Il FIFO RX è quasi pieno e gli interrupt Valid Packet sono abilitati. Al successivo evento IRQ viene letto il registro di stato 1. Innanzitutto, viene controllato il bit Pacchetto valido, quindi viene controllato il bit FIFO Quasi pieno. Se è impostato solo il bit FIFO RX Quasi pieno, i successivi 48 byte vengono letti dalla FIFO. Se è impostato il bit del pacchetto valido, il resto del pacchetto viene letto dalla FIFO. L'MCU tiene traccia di quanti byte sono stati letti e interrompe la lettura dopo l'ultimo byte.
Livello di collegamento dati
Il modulo del livello di collegamento dati implementa un livello di collegamento conforme a 13757-4:2005. Il livello di collegamento dati (LINK) fornisce un'interfaccia tra il livello fisico (PHY) e il livello di applicazione (AL).
Il livello di collegamento dati svolge le seguenti funzioni:
- Fornisce funzioni che trasferiscono dati tra PHY e AL
- Genera CRC per i messaggi in uscita
- Rileva errori CRC nei messaggi in arrivo
- Fornisce l'indirizzamento fisico
- Riconosce i trasferimenti per le modalità di comunicazione bidirezionale
- Bit di dati dei frame
- Rileva errori di inquadratura nei messaggi in arrivo
Collega formato frame layer
Il formato frame Wireless M-Bus utilizzato in EN 13757-4:2005 è derivato dal formato frame FT3 (Frame Type 3) da IEC60870-5-2. Il frame è costituito da uno o più blocchi di dati. Ogni blocco include un campo CRC a 16 bit. Il primo blocco è un blocco a lunghezza fissa di 12 byte che include il campo L, il campo C, il campo M e il campo A.
- L-campo
Il campo L è la lunghezza del payload dei dati del livello di collegamento. Questo non include il campo L stesso o alcuno dei byte CRC. Include il campo L, il campo C, il campo M e il campo A. Questi fanno parte del payload PHY.
Poiché il numero di byte codificati è limitato a 255 byte, il valore massimo supportato per il campo M è 110 byte per i dati codificati Manchester e 148 byte per i dati codificati in modalità T tre su sei.
Il livello Link è responsabile del calcolo del campo L in trasmissione. Il livello di collegamento utilizzerà il campo L alla ricezione.
Nota che il campo L non indica la lunghezza del payload PHY o il numero di byte codificati. Al momento della trasmissione, il PHY calcolerà la lunghezza del payload PHY e il numero di byte codificati. Alla ricezione, il PHY decodificherà il campo L e calcolerà il numero di byte da decodificare. - Campo C
Il campo C è il campo di controllo del frame. Questo campo identifica il tipo di frame e viene utilizzato per le primitive del servizio di scambio dati di collegamento. Il campo C indica il tipo di frame: INVIA, CONFERMA, RICHIESTA o RISPONDI. Nel caso di frame SEND e REQUEST, il campo C indica se è previsto un CONFIRM o RESPOND.
Quando si utilizza la funzione Link TX di base, è possibile utilizzare qualsiasi valore di C. Quando si utilizzano le Primitive del servizio di collegamento, il campo C viene popolato automaticamente secondo la norma EN 13757-4:2005. - Campo M
Il campo M è il codice del produttore. I produttori possono richiedere un codice di tre lettere dai seguenti web indirizzo: http://www.dlms.com/flag/INDEX.HTM Ciascun carattere del codice a tre lettere è codificato come cinque bit. Il codice a 5 bit può essere ottenuto prendendo il codice ASCII e sottraendo 0x40 ("A"). I tre codici a 5 bit sono concatenati per creare 15 bit. Il bit più significativo è zero. - A-Campo
Il campo dell'indirizzo è un indirizzo univoco a 6 byte per ogni dispositivo. L'indirizzo univoco deve essere assegnato dal produttore. È responsabilità di ciascun produttore garantire che ogni dispositivo abbia un indirizzo univoco a 6 byte. L'indirizzo per i frame di invio e richiesta è l'indirizzo personale del contatore o di un altro dispositivo. I frame di dati di conferma e risposta vengono inviati utilizzando l'indirizzo del dispositivo di origine. - CI-campo
Il campo CI è l'intestazione dell'applicazione e specifica il tipo di dati nel payload dei dati dell'applicazione. Sebbene la EN13757-4:2005 specifichi un numero limitato di valori, le Primitive del servizio di collegamento consentiranno l'utilizzo di qualsiasi valore. - CRC
Il CRC è specificato nella EN13757-4:2005.
Il polinomio CRC è:
X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
Notare che il CRC M-Bus viene calcolato su ogni blocco di 16 byte. Il risultato è che ogni 16 byte di dati richiedono 18 byte per essere trasmessi,
Informazioni aggiuntive
Per ulteriori informazioni sull'implementazione del livello di collegamento, vedere "AN452: Guida per programmatori stack M-Bus wireless".
Gestione dell'alimentazione
La Figura 2 mostra la sequenza temporale della gestione dell'alimentazione per un contatore example utilizzando la modalità T1.
L'MCU dovrebbe essere in modalità Sleep quando possibile per risparmiare energia. In questo example, l'MCU è inattivo quando l'RTC è in funzione, durante l'attesa dell'avvio del cristallo radio e durante la trasmissione dalla FIFO. L'MCU si riattiverà dal segnale EZRadioPRO IRQ collegato a una riattivazione Port Match.
Quando si trasmettono messaggi più lunghi di un blocco, l'MCU deve svegliarsi per riempire la FIFO (basata sull'interruzione FIFO quasi vuota) e poi tornare a dormire.
L'MCU dovrebbe essere in modalità Idle in esecuzione dall'oscillatore a bassa potenza o dall'oscillatore in modalità burst durante la lettura dall'ADC. L'ADC richiede un orologio SAR.
Quando non è in uso, EZRadioPRO dovrebbe essere in modalità Spegnimento con il pin SDN guidato in alto. Ciò richiede una connessione cablata all'MCU. I registri di EZ Radio Pro non vengono conservati in modalità di spegnimento; quindi, EZRadioPro viene inizializzato ad ogni intervallo RTC. L'inizializzazione della radio richiede meno di 100 µs e conserva 400 nA. Ciò si traduce in un risparmio energetico di 10 µJ, basato su un intervallo di 10 secondi.
Il cristallo EZRadioPRO impiega circa 16 ms per un POR. Questo è abbastanza lungo per calcolare il CRC per circa otto blocchi. L'MCU tornerà a dormire se completa tutti i CRC prima che il cristallo si sia stabilizzato. Se è richiesta la crittografia, anch'essa può essere avviata durante l'attesa dell'oscillatore a cristallo.
L'MCU dovrebbe funzionare a 20 MHz utilizzando l'oscillatore a bassa potenza per la maggior parte delle attività. Le attività che richiedono un timeout preciso devono utilizzare l'oscillatore di precisione e la modalità inattiva invece della modalità di sospensione. L'RTC fornisce una risoluzione sufficiente per la maggior parte delle attività. La timeline di gestione dell'alimentazione per il misuratore T2 exampl'applicazione è mostrata in Figura 3.
L'implementazione del ricetrasmettitore dovrebbe essere ottimizzata per il caso normale quando lo strumento si riattiva e non è presente alcun lettore. I timeout ACK minimo/massimo sono sufficientemente lunghi da consentire l'utilizzo dell'RTC C8051F930 e mettere l'MCU in modalità di sospensione.
Le opzioni di compilazione sono fornite per i lettori alimentati da rete o USB che non necessitano di utilizzare la modalità di sospensione. La modalità inattiva verrà utilizzata al posto della sospensione in modo che USB e UART possano interrompere l'MCU.
Semplicità Studio
Accesso con un clic a MCU e strumenti wireless, documentazione, software, librerie di codici sorgente e altro. Disponibile per Windows,
Mac e Linux!
 |
 |
 |
 |
| Portafoglio IoT www.silabs.com/IoT |
software/hardware www.silabs.com/semplicità |
Qualità www.silabs.com/qualità |
Supporto e comunità community.silabs.com |
Disclaimer
Silicon Labs intende fornire ai clienti la documentazione più recente, accurata e approfondita di tutte le periferiche e i moduli disponibili per gli implementatori di sistemi e software che utilizzano o intendono utilizzare i prodotti Silicon Labs. I dati di caratterizzazione, i moduli e le periferiche disponibili, le dimensioni della memoria e gli indirizzi di memoria si riferiscono a ciascun dispositivo specifico e i parametri "tipici" forniti possono variare e variano in diverse applicazioni. Esempio di applicazioneampi descritti qui sono solo a scopo illustrativo. Silicon Labs si riserva il diritto di apportare modifiche senza ulteriore avviso e limitazione alle informazioni, alle specifiche e alle descrizioni del prodotto qui contenute e non fornisce garanzie in merito all'accuratezza o alla completezza delle informazioni incluse. Silicon Labs non avrà alcuna responsabilità per le conseguenze dell'uso delle informazioni qui fornite. Questo documento non implica o esprime licenze di copyright concesse ai sensi del presente documento per progettare o fabbricare alcun circuito integrato. I prodotti non sono progettati o autorizzati per essere utilizzati all'interno di alcun sistema di supporto vitale senza lo specifico consenso scritto di Silicon Labs. Un "Sistema di supporto vitale" è qualsiasi prodotto o sistema destinato a supportare o sostenere la vita e/o la salute, che, in caso di guasto, può ragionevolmente comportare lesioni personali significative o morte. I prodotti Silicon Labs non sono progettati o autorizzati per applicazioni militari. I prodotti Silicon Labs non devono in nessun caso essere utilizzati in armi di distruzione di massa incluse (ma non limitate a) armi nucleari, biologiche o chimiche o missili in grado di fornire tali armi.
Informazioni sul marchio
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® e il logo Silicon Labs®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, logo Energy Micro e relative combinazioni, "i microcontrollori più ecologici al mondo", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, il logo Telegesis®, USBXpress® e altri sono marchi o marchi registrati di Silicon Labs. ARM, CORTEX, Cortex-M3 e thumbs sono marchi o marchi registrati di ARM Holdings. Keil è un marchio registrato di ARM Limited. Tutti gli altri prodotti o marchi qui menzionati sono marchi dei rispettivi proprietari.
Silicon Laboratories Inc.
400 Ovest Cesar Chavez
Austin, Texas 78701
U.S.A.
http://www.silabs.com
Documenti / Risorse
 |
SILICON LABS Implementazione software Wireless M-BUS AN451 [pdf] Guida utente SILICON LABS, C8051, MCU e, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Implementazione, AN451 |
