AN451
WDROŻENIE OPROGRAMOWANIA BEZPRZEWODOWEGO M-BUS

Wstęp

Niniejsza nota aplikacyjna opisuje implementację Wireless M-Bus firmy Silicon Labs przy użyciu mikrokontrolera Silicon Labs C8051 i EZRadioPRO®. Wireless M-bus to europejski standard dotyczący aplikacji odczytu liczników wykorzystujących pasmo częstotliwości 868 MHz.

Ułóż warstwy

Wireless M-Bus wykorzystuje 3-warstwowy model IEC, który jest podzbiorem 7-warstwowego modelu OSI (patrz rysunek 1).

Warstwa fizyczna (PHY) jest zdefiniowana w normie EN 13757-4. Warstwa fizyczna definiuje sposób kodowania i transmisji bitów, charakterystykę modemu RF (szybkość chipa, preambuła i słowo synchronizacyjne) oraz parametry RF (modulacja, częstotliwość środkowa i odchylenie częstotliwości).
Warstwa PHY jest implementowana przy użyciu kombinacji sprzętu i oprogramowania sprzętowego. EZRadioPRO realizuje wszystkie funkcje RF i modemu. EZRadioPRO jest używane w trybie FIFO z obsługą pakietów. Moduł MbusPhy.c zapewnia interfejs SPI, kodowanie/dekodowanie, blokowy odczyt/zapis oraz obsługę pakietów i zarządza stanami transceivera.
Warstwa łącza M-Bus Data jest zaimplementowana w module MbusLink.c. Interfejs programowania aplikacji M-Bus składa się z funkcji publicznych, które można wywołać z warstwy aplikacji w wątku głównym. Moduł MbusLink implementuje również warstwę łącza danych. Warstwa łącza danych sformatuje i skopiuje dane z bufora TX aplikacji do bufora TX MbusPhy, dodając wymagane nagłówki i CRC.
Sama warstwa aplikacji nie jest częścią oprogramowania M-bus. Warstwa aplikacji definiuje sposób formatowania szerokiej gamy danych do transmisji. Większość liczników przesyła tylko jeden lub dwa typy danych. Dodanie dużej ilości kodu w celu umieszczenia w liczniku dowolnego rodzaju danych spowodowałoby dodanie niepotrzebnego kodu i zwiększenie kosztów licznika. Możliwe może być zaimplementowanie biblioteki lub nagłówka file z wyczerpującą listą typów danych. Jednak większość klientów zajmujących się pomiarami wie dokładnie, jakiego rodzaju dane muszą przesyłać i może odwołać się do standardu w celu uzyskania szczegółów formatowania. Uniwersalny czytnik lub sniffer może zaimplementować pełny zestaw typów danych aplikacji w graficznym interfejsie użytkownika komputera. Z tych powodów warstwa aplikacji jest implementowana przy użyciu npample aplikacje dla licznika i czytnika.

Wymagane standardy

1. PN-EN 13757-4
   PN-EN 13757-4
   System komunikacji liczników i zdalnego odczytu liczników
   Część 4: Bezprzewodowy odczyt licznika
   Odczyt radiometru dla pracy w paśmie SRD od 868 MHz do 870 MHz
2. PN-EN 13757-3
   System komunikacji liczników i zdalnego odczytu liczników
   Część 3: Dedykowana warstwa aplikacji
3. IEC 60870-2-1:1992
   Sprzęt i systemy telekontroli
   Część 5: Protokoły transmisji
   Sekcja 1: Procedura transmisji łącza
4. IEC 60870-1-1:1990
   Sprzęt i systemy telekontroli
   Część 5: Protokoły transmisji
   Sekcja 1: Formaty ramek transmisyjnych

Definicje

• M-Bus—M-Bus to przewodowy standard odczytu liczników w Europie.
• Bezprzewodowa magistrala M-Bus—Bezprzewodowa magistrala M-Bus do zastosowań związanych z odczytem liczników w Europie.
• FIZYKA— Warstwa fizyczna określa sposób kodowania i przesyłania bitów i bajtów danych.
• API—Interfejs programisty aplikacji.
• POŁĄCZYĆ-Warstwa łącza danych definiuje sposób przesyłania bloków i ramek.
• CRC—Cykliczna kontrola nadmiarowości.
• FSK—Kluczowanie z przesunięciem częstotliwości.
• Żeton-Najmniejsza jednostka przesyłanych danych. Jeden bit danych jest kodowany jako wiele chipów.
• Moduł-Źródło kodu AC .c file.

Opis funkcjonalny M-Bus PHY

Sekwencja preambuły

Sekwencja preambuły określona w specyfikacji M-bus jest liczbą całkowitą zawierającą na przemian zera i jedyneki. Jedynka jest definiowana jako wyższa częstotliwość, a zero jako niższa częstotliwość.
nx (01)
Opcje Preambuły dla Si443x to całkowita liczba półbajtów składających się z naprzemiennych jedynek i zer.
nx (1010)
Preambuła z dodatkową preambułą wiodącą nie stanowiłaby problemu, ale wtedy słowo synchronizacyjne i ładunek byłyby przesunięte o jeden bit.
Rozwiązaniem jest odwrócenie całego pakietu poprzez ustawienie bitu silnika w rejestrze kontroli modulacji 2 (0x71). Spowoduje to odwrócenie preambuły, słowa synchronizacyjnego i danych TX/RX. W konsekwencji dane powinny zostać odwrócone podczas zapisywania danych TX lub odczytywania danych RX. Ponadto słowo synchronizacyjne jest odwracane przed zapisem do rejestrów słowa synchronizacyjnego Si443x.

Słowo synchronizacji

Słowo synchronizacyjne wymagane przez normę EN-13757-4 to 18 chipów dla trybu S i trybu R lub 10 chipów dla Modelu T. Słowo synchronizacyjne dla Si443x ma od 1 do 4 bajtów. Jednakże, ponieważ słowo synchronizacyjne jest zawsze poprzedzone preambułą, ostatnie sześć bitów preambuły można uznać za część słowa synchronizującego; tak więc pierwsze słowo synchronizacyjne jest uzupełniane trzema powtórzeniami zera, po którym następuje jedynka. Słowo synchronizacyjne jest uzupełniane przed zapisem do rejestrów Si443x.
Tabela 1. Słowo synchronizacyjne dla modu S i modu R

Tabela 2. Słowo synchronizacyjne dla licznika trybu T z innym

Długość preambuły transmisji

Minimalna preambuła jest określona dla czterech różnych trybów pracy. Dopuszczalne jest, aby preambuła była dłuższa niż określono. Odjęcie sześciu żetonów dla preambuły daje minimalną liczbę żetonów dla preambuły Si443x. Implementacja dodaje dwa dodatkowe półkule preambuły we wszystkich trybach krótkich preambuł, aby poprawić wykrywanie preambuły i interoperacyjność. Preambuła w trybie S z długą preambułą jest bardzo długa; dlatego używana jest minimalna preambuła. Długość preambuły w półbajtach jest zapisywana w rejestrze Długość preambuły (0x34). Rejestr długości preambuły określa preambułę tylko podczas transmisji. Minimalną specyfikację i ustawienia długości preambuły podsumowano w Tabeli 3.
Tabela 3. Długość nagłówka transmisji

Minimalna preambuła do odbioru jest określona przez rejestr kontroli wykrywania preambuły (0x35). Po odbiorze liczbę bitów słowa synchronizującego należy odjąć od określonej minimalnej preambuły, aby określić użyteczną preambułę. Minimalny czas ustalania odbiornika wynosi 16 chipów, jeśli AFC jest włączone lub 8 chipów, jeśli AFC jest wyłączone. Czas ustalania odbiornika jest również odejmowany od użytecznej preambuły w celu określenia minimalnego ustawienia rejestru sterującego wykrywaniem preambuły.

Prawdopodobieństwo fałszywej preambuły zależy od ustawienia rejestru kontroli wykrywania preambuły. Krótkie ustawienie 8 żetonów może skutkować wykrywaniem co kilka sekund fałszywej preambuły. Zalecane ustawienie 20 żetonów sprawia, że ​​wykrycie fałszywej preambuły jest zdarzeniem mało prawdopodobnym. Długości nagłówków dla Modu R i Modu SL są wystarczająco długie, aby można było zastosować zalecane ustawienie.
Wykrywanie przez preambułę więcej niż 20 żetonów przynosi bardzo niewielką korzyść.
Funkcja AFC jest wyłączona dla Modelu S z krótką preambułą i Modelu T. Skraca to czas ustalania się odbiornika i umożliwia ustawienie wykrywania dłuższej preambuły. Przy wyłączonej funkcji AFC tryb T może używać zalecanego ustawienia 20 żetonów. W Modelu S z krótką preambułą zastosowano ustawienie 4 przekąsek lub 20 żetonów. To sprawia, że ​​prawdopodobieństwo wykrycia fałszywej preambuły jest nieco wyższe w tym modelu.
Tabela 4. Wykrywanie preambuły

Odbiornik jest skonfigurowany do współpracy z nadajnikiem przy użyciu minimalnej określonej preambuły. Dzięki temu odbiornik będzie współpracował z dowolnym nadajnikiem zgodnym ze standardem M-bus.
Specyfikacja Wireless M-Bus wymaga bardzo długiej preambuły dla trybu S1, składającej się z co najmniej 558 chipów. Samo przesłanie preambuły zajmie około 17 ms. Si443x nie wymaga tak długiej preambuły i nie korzysta z długiej preambuły. Chociaż długa preambuła jest opcjonalna dla trybu S2, nie ma powodu używać długiej preambuły w Si443x. Jeśli pożądana jest komunikacja jednokierunkowa, tryb T1 zapewni krótszą nagłówek, większą szybkość transmisji danych i dłuższą żywotność baterii. Jeżeli wymagana jest komunikacja dwukierunkowa przy użyciu trybu S2, zalecana jest krótka wstępna informacja.
Należy zauważyć, że próg detekcji dla Modelu S z długą preambułą jest dłuższy niż liczba półbajtów preambuły transmitowanych dla Modelu S z krótką preambułą. Oznacza to, że odbiornik Modu S z długą preambułą nie wykryje preambuły z nadajnika Modu S z krótką preambułą. Jest to konieczne, jeśli odbiornik Modu S z długą preambułą ma odnieść jakąkolwiek korzyść z długiej preambuły.
Należy zauważyć, że odbiornik Modu S z krótką preambułą wykryje preambułę i odbierze pakiety zarówno z krótkiej preambuły Trybu S
nadajnik i nadajnik Modu S z długą preambułą; ogólnie rzecz biorąc, czytnik liczników powinien używać konfiguracji odbiornika Mode S z krótką preambułą.

Kodowanie/dekodowanie

Specyfikacja bezprzewodowej magistrali M-bus wymaga dwóch różnych metod kodowania. Kodowanie Manchester jest używane w trybie S i trybie R. Kodowanie Manchester jest również używane w łączu inny-metr w Modelu T. W łączu licznik-inny Model T wykorzystywane są 3 z 6 kodowań.
1. Kodowanie/dekodowanie Manchesteru
Kodowanie Manchester jest powszechnie stosowane w systemach RF w celu zapewnienia niezawodnego odtwarzania zegara i śledzenia przy użyciu prostego i niedrogiego modemu. Jednakże nowoczesne radio o wysokiej wydajności, takie jak Si443x, nie wymaga kodowania Manchester. Kodowanie Manchester jest obsługiwane przede wszystkim ze względu na zgodność z istniejącymi standardami, ale szybkość transmisji danych w Si443x jest skutecznie podwojona, gdy nie jest używane kodowanie Manchester.
Si443x obsługuje kodowanie i dekodowanie Manchesteru całego pakietu sprzętowo. Niestety, słowo synchronizacyjne nie jest zakodowane w Manchesterze. Dla słowa synchronizującego celowo wybrano nieprawidłową sekwencję Manchesteru. To sprawia, że ​​kodowanie Manchester jest niekompatybilne z większością istniejących radiotelefonów, w tym z Si443x. W rezultacie kodowanie i dekodowanie Manchesteru musi być wykonywane przez MCU. Każdy bajt niezakodowanych danych składa się z ośmiu bitów danych. Przy użyciu kodowania Manchester każdy bit danych jest kodowany w symbolu dwuchipowym. Ponieważ zakodowane dane muszą być zapisywane w radiowym FIFO po osiem chipów na raz, pojedyncza porcja danych jest kodowana i zapisywana w FIFO na raz.
Tabela 5. Kodowanie Manchester

Każdy bajt do przesłania jest przekazywany po jednym bajcie do funkcji encode byte. Funkcja encode byte wywoła funkcję encode półbajt dwukrotnie, najpierw dla najbardziej znaczącej półbajtu, a następnie dla najmniej znaczącej półbajtu.
Kodowanie Manchesteru w oprogramowaniu nie jest trudne. Zaczynając od najbardziej znaczącego bitu, jeden jest kodowany jako sekwencja chipów „01”. Zero jest kodowane jako sekwencja chipów „10”. Można to łatwo osiągnąć za pomocą pętli i przesuwania o dwa bity dla każdego symbolu. Jednak szybciej jest po prostu użyć prostej tabeli przeglądowej z 16 wpisami dla każdego półbajta. Funkcja encode Manchester nibble koduje fragment danych, a następnie zapisuje go do FIFO. Żetony są odwracane przed zapisem do FIFO w celu uwzględnienia wymagań odwróconej preambuły.
Podczas odbioru każdy bajt w FIFO składa się z ośmiu chipów i jest dekodowany w jeden fragment danych. Funkcja bloku odczytu odczytuje po jednym bajcie z FIFO i wywołuje funkcję dekodowania bajtu. Chipy są odwracane po odczycie z FIFO w celu uwzględnienia wymagań odwróconej preambuły. Każdy bajt chipów zakodowanych w Manchesterze jest dekodowany na skrawek danych. Zdekodowany półbajt jest zapisywany do bufora RX przy użyciu funkcji bufora RX zapisu półbajtu.
Należy zauważyć, że zarówno kodowanie, jak i dekodowanie są wykonywane w locie, po jednym skubaniu danych. Kodowanie do bufora wymagałoby dodatkowego bufora dwukrotnie większego niż niezakodowane dane. Kodowanie i dekodowanie jest znacznie szybsze niż najszybsza obsługiwana szybkość transmisji danych (100 tys. chipów na sekundę). Ponieważ Si443x obsługuje wielobajtowy odczyt i zapis w FIFO, korzystanie wyłącznie z jednobajtowych odczytów i zapisów wiąże się z niewielkim narzutem. Narzut wynosi około 10 µs dla 100 zakodowanych chipów. Zaletą jest oszczędność pamięci RAM wynosząca 512 bajtów.
2. Trzy z sześciu dekodowań kodujących
Metoda kodowania „trzy z sześciu” określona w normie EN-13757-4 jest również zaimplementowana w oprogramowaniu sprzętowym mikrokontrolera. To kodowanie jest używane w trybie T o dużej szybkości (100 tys. chipów na sekundę) z licznika na drugi. Model T zapewnia najkrótszy czas transmisji i najdłuższą żywotność baterii dla licznika bezprzewodowego.
Każdy bajt danych do przesłania jest podzielony na dwa półbajty. Najbardziej znaczący półbajt jest kodowany i przesyłany jako pierwszy. Ponownie jest to realizowane za pomocą funkcji encode byte, która dwukrotnie wywołuje funkcję encode nibble.
Każdy kawałek danych jest zakodowany w symbolu składającym się z sześciu żetonów. Sekwencja symboli sześciożetonowych musi zostać zapisana w 8-chipowym FIFO.
Podczas kodowania dwa bajty danych są kodowane jako cztery półbajty. Każde ugryzienie to symbol 6 żetonów. Cztery symbole 6chip są agregowane jako trzy bajty.
Tabela 6. Trzy z sześciu kodowań

W oprogramowaniu kodowanie trzy z sześciu jest realizowane przy użyciu trzech zagnieżdżonych funkcji. Funkcja encode byte dwukrotnie wywoła funkcję encode nibble. Funkcja encode nibble wykorzystuje tabelę przeglądową symbolu sześcioelementowego i zapisuje symbol do funkcji Shift Three z Six. Ta funkcja implementuje w oprogramowaniu 16-chipowy rejestr przesuwny. Symbol jest zapisywany w najmniej znaczącym bajcie rejestru przesuwnego. Rejestr jest dwukrotnie przesunięty w lewo. Powtarza się to trzy razy. Kiedy w górnym bajcie rejestru przesuwnego znajduje się cały bajt, jest on odwracany i zapisywany w FIFO.
Ponieważ każdy bajt danych jest kodowany jako półtora bajtu zakodowanego, ważne jest, aby początkowo wyczyścić rejestr przesuwny, aby pierwszy zakodowany bajt był poprawny. Jeśli długość pakietu jest liczbą nieparzystą, po zakodowaniu wszystkich bajtów w rejestrze przesuwnym pozostanie jeszcze jeden półbajt. Jest to obsługiwane za pomocą postambuły, jak wyjaśniono w następnej sekcji.
Dekodowanie trzech z sześciu zakodowanych jest procedurą odwrotną. Podczas dekodowania trzy zakodowane bajty są dekodowane na dwa bajty danych. Programowy rejestr przesuwny jest ponownie używany do agregowania bajtów zdekodowanych danych. Do dekodowania używana jest odwrotna tablica przeglądowa zawierająca 64 wpisy. Zużywa to mniej cykli, ale więcej pamięci kodu. Przeszukiwanie tabeli zawierającej 16 wpisów w celu znalezienia odpowiedniego symbolu zajmuje znacznie więcej czasu.
Poczta
Specyfikacja bezprzewodowej magistrali M-bus ma specyficzne wymagania dotyczące poczty lub zwiastuna. We wszystkich trybach minimalna liczba to dwa żetony, a maksymalna to osiem żetonów. Ponieważ minimalną jednostką atomową dla FIFO jest jeden bajt, w trybie S i trybie R używana jest 8-chipowa nakładka. Postambuła trybu T składa się z ośmiu żetonów, jeśli długość pakietu jest parzysta, lub czterech żetonów, jeśli długość pakietu jest nieparzysta. Postambuła składająca się z czterech chipów dla pakietu o nieparzystej długości spełnia wymagania posiadania co najmniej dwóch naprzemiennych chipów.
Tabela 7. Długość postambułu

Obsługa pakietów

Procedura obsługi pakietów w Si443x może być używana w trybie zmiennej szerokości pakietu lub w trybie stałej szerokości pakietu. Tryb zmiennej szerokości pakietu wymaga bajtu długości pakietu po słowie synchronizacyjnym i opcjonalnych bajtach nagłówka. Po odbiorze radio użyje bajtu długości do określenia końca ważnego pakietu. Podczas transmisji radio wstawi pole długości po bajtach nagłówka.
Pole L dla protokołu bezprzewodowej M-bus nie może być użyte dla pola długości Si443x. Po pierwsze, pole L nie jest rzeczywistą długością pakietu. Jest to liczba bajtów ładunku warstwy łącza, nie obejmująca bajtów CRC ani kodowania. Po drugie, samo pole L jest kodowane przy użyciu kodowania Manchester lub kodowania Three z Six dla licznika trybu T na inny.
Implementacja wykorzystuje procedurę obsługi pakietów w trybie stałej szerokości pakietu zarówno do transmisji, jak i odbioru. Podczas transmisji warstwa PHY odczyta pole L w buforze transmisji i obliczy liczbę zakodowanych bajtów, łącznie z postambułą. Całkowita liczba zakodowanych bajtów do przesłania jest zapisywana w rejestrze długości pakietu (0x3E).
Po odbiorze pierwsze dwa zakodowane bajty są dekodowane, a pole L jest zapisywane w buforze odbiorczym. Pole L służy do obliczenia liczby zakodowanych bajtów do odebrania. Liczba zakodowanych bajtów do odebrania jest następnie zapisywana w rejestrze długości pakietu (0x3E). Postambuła zostaje odrzucona.
MCU musi zdekodować pole L, obliczyć liczbę zakodowanych bajtów i zapisać wartość w rejestrze długości pakietu, zanim otrzyma najkrótszą możliwą długość pakietu. Najkrótsze dopuszczalne pole L dla warstwy PHY wynosi 9, co daje 12 niezakodowanych bajtów. Daje to 18 zakodowanych bajtów dla Modelu T. Pierwsze dwa bajty zostały już zdekodowane. Zatem rejestr długości pakietu musi być aktualizowany co 16 bajtów przy 100 kbps lub 1.28 milisekundy. Nie stanowi to problemu dla 8051 pracującego z szybkością 20 MIPS.
Liczba bajtów do odebrania nie obejmuje postambuły, z wyjątkiem czterochipowej postambuły używanej dla pakietów Modu T o nieparzystej długości pakietu. Zatem odbiorca nie wymaga postambuły, z wyjątkiem pakietów o nieparzystej długości Modelu T. Ta postambuła jest potrzebna tylko do podania całkowitej liczby zakodowanych bajtów. Treść postambuły jest ignorowana; tak więc, jeśli postambuła nie zostanie przesłana, odebrane i zignorowane zostaną cztery chipy szumu. Ponieważ całkowita liczba zakodowanych bajtów jest ograniczona do 255 (0xFF), implementacja ogranicza maksymalne pole L dla różnych trybów.
Tabela 8. Limity wielkości pakietów

Limity te są zwykle znacznie wyższe od typowego przypadku użycia licznika bezprzewodowego. Długość pakietu powinna być mała, aby uzyskać najlepszą możliwą żywotność baterii.
Dodatkowo użytkownik może określić maksymalne pole L, które powinno zostać odebrane (USER_RX_MAX_L_FIELD). Określa to wymagany rozmiar bufora odbiorczego (USER_RX_BUFFER_SIZE).
Obsługa maksymalnego pola L wynoszącego 255 wymagałaby bufora odbiorczego o wielkości 290 bajtów i maksymalnie 581 bajtów zakodowanych w formacie Manchester. W takim przypadku moduł obsługi pakietów musiałby zostać wyłączony, a rejestr długości pakietu nie mógłby być w tym przypadku używany. Jest to wykonalne, ale jeśli to możliwe, wygodniej jest używać modułu obsługi pakietów.

Użycie FIFO

Si4431 zapewnia 64-bajtowe FIFO do transmisji i odbioru. Ponieważ liczba zakodowanych bajtów wynosi 255, cały zakodowany pakiet może nie zmieścić się w 64-bajtowym buforze.
Przenoszenie
Podczas transmisji obliczana jest całkowita liczba zakodowanych bajtów. Jeśli całkowita liczba zakodowanych bajtów, łącznie z postambułą, jest mniejsza niż 64 bajty, cały pakiet jest zapisywany w FIFO i włączone jest tylko przerwanie wysłanego pakietu. Większość krótkich pakietów zostanie wysłana w jednym przelewie FIFO.
Jeśli liczba zakodowanych bajtów jest większa niż 64, do wysłania pakietu wymagane będzie wielokrotne transfery FIFO. Pierwsze 64 bajty są zapisywane w FIFO. Włączone są przerwania „Pakiet wysłany” i „TX FIFO prawie pusty”. Próg TX FIFO prawie pusty jest ustawiony na 16 bajtów (25%). Po każdym zdarzeniu IRQ odczytywany jest rejestr stanu 2. Najpierw sprawdzany jest bit Packet Sent, a jeśli pakiet nie został w całości wysłany, kolejnych 48 bajtów zakodowanych danych jest zapisywanych do FIFO. Trwa to do momentu zapisania wszystkich zakodowanych bajtów i wystąpienia przerwania Packet Sent.
1. Recepcja
Początkowo podczas odbioru włączone jest tylko przerwanie Sync Word. Po odebraniu słowa synchronizującego przerwanie słowa synchronizacyjnego jest wyłączane i włączane jest przerwanie FIFO Prawie pełne. Próg prawie pełnego FIFO jest początkowo ustawiony na 2 bajty. Pierwsze przerwanie FIFO prawie pełne służy do sprawdzenia, kiedy odebrane zostały dwa bajty długości. Po odebraniu długości długość jest dekodowana i obliczana jest liczba zakodowanych bajtów. Próg RX FIFO prawie pełny jest następnie ustawiany na 48 bajtów. RX FIFO jest prawie pełne i włączone są przerwania Valid Packet. Po następnym zdarzeniu IRQ odczytywany jest rejestr stanu 1. Najpierw sprawdzany jest bit Valid Packet, a następnie bit FIFO Prawie pełny. Jeżeli ustawiony jest tylko bit RX FIFO Prawie pełny, z FIFO odczytywanych jest kolejnych 48 bajtów. Jeżeli ustawiony jest bit ważnego pakietu, pozostała część pakietu jest odczytywana z FIFO. MCU śledzi, ile bajtów zostało odczytanych i przestaje czytać po ostatnim bajcie.

Warstwa łącza danych

Moduł warstwy łącza danych implementuje warstwę łącza zgodną z normą 13757-4:2005. Warstwa łącza danych (LINK) zapewnia interfejs pomiędzy warstwą fizyczną (PHY) a warstwą aplikacji (AL).
Warstwa łącza danych spełnia następujące funkcje:

• Zapewnia funkcje przesyłające dane pomiędzy PHY i AL
• Generuje CRC dla wiadomości wychodzących
• Wykrywa błędy CRC w wiadomościach przychodzących
• Zapewnia adresowanie fizyczne
• Potwierdza transfery dla trybów komunikacji dwukierunkowej
• Ramki bitów danych
• Wykrywa błędy w ramkach w przychodzących wiadomościach

Format ramki warstwy łącza

Format ramki Wireless M-Bus używany w normie EN 13757-4:2005 wywodzi się z formatu ramki FT3 (typ ramki 3) z normy IEC60870-5-2. Ramka składa się z jednego lub większej liczby bloków danych. Każdy blok zawiera 16-bitowe pole CRC. Pierwszy bock to blok o stałej długości składający się z 12 bajtów, który zawiera pole L, pole C, pole M i pole A.

1. Pole L
   Pole L to długość ładunku danych warstwy łącza. Nie obejmuje to samego pola L ani żadnego z bajtów CRC. Obejmuje pole L, pole C, pole M i pole A. Są one częścią ładunku PHY.
   Ponieważ liczba zakodowanych bajtów jest ograniczona do 255 bajtów, maksymalna obsługiwana wartość pola M wynosi 110 bajtów dla danych zakodowanych metodą Manchester i 148 bajtów dla danych zakodowanych w trybie T trzy z sześciu.
   Warstwa łącza jest odpowiedzialna za obliczanie pola L podczas transmisji. Warstwa łącza będzie używać pola L podczas odbioru.
   Należy zauważyć, że pole L nie wskazuje długości ładunku PHY ani liczby zakodowanych bajtów. Podczas transmisji PHY obliczy długość ładunku PHY i liczbę zakodowanych bajtów. Po odbiorze PHY zdekoduje pole L i obliczy liczbę bajtów do zdekodowania.
2. Pole C
   Pole C jest polem sterującym ramką. To pole identyfikuje typ ramki i jest używane w elementach podstawowych usługi wymiany danych łącza. Pole C wskazuje typ ramki – WYŚLIJ, POTWIERDŹ, ŻĄDANIE lub ODPOWIEDŹ. W przypadku ramek SEND i REQUEST pole C wskazuje, czy oczekiwane jest CONFIRM czy RESPOND.
   W przypadku korzystania z podstawowej funkcji Link TX można zastosować dowolną wartość C. Podczas korzystania z elementów podstawowych usługi łącza pole C jest wypełniane automatycznie zgodnie z normą EN 13757-4:2005.
3. Pole M
   Pole M to kod producenta. Producenci mogą poprosić o trzyliterowy kod, korzystając z poniższych informacji web adres: http://www.dlms.com/flag/INDEX.HTM Każdy znak trzyliterowego kodu jest kodowany jako pięć bitów. Kod 5-bitowy można otrzymać, wziąwszy kod ASCII i odejmując 0x40 („A”). Trzy 5-bitowe kody są łączone w celu uzyskania 15-bitów. Najbardziej znaczący bit to zero.
4. W polu
   Pole adresu to unikalny 6-bajtowy adres każdego urządzenia. Unikalny adres powinien zostać nadany przez producenta. Obowiązkiem każdego producenta jest zapewnienie, że każde urządzenie ma unikalny 6-bajtowy adres. Adresem ramek Wyślij i Żądaj jest adres własny licznika lub innego urządzenia. Ramki danych potwierdzenia i odpowiedzi są wysyłane przy użyciu adresu urządzenia inicjującego.
5. Pole CI
   Pole CI to nagłówek aplikacji i określa typ danych w ładunku danych aplikacji. Chociaż norma EN13757-4:2005 określa ograniczoną liczbę wartości, elementy podstawowe usługi łącza pozwalają na użycie dowolnej wartości.
6. CRC
   CRC jest określone w EN13757-4:2005.
   Wielomian CRC to:
   X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
   Należy pamiętać, że CRC M-Bus jest obliczane dla każdego 16-bajtowego bloku. W rezultacie każde 16 bajtów danych wymaga przesłania 18 bajtów,

Informacje dodatkowe

Aby uzyskać dodatkowe informacje na temat implementacji warstwy łącza, zobacz „AN452: Przewodnik programisty stosu Wireless M-Bus”.

Zarządzanie energią

Rysunek 2 przedstawia harmonogram zarządzania energią dla licznika, npampplik przy użyciu trybu T1.

Jeśli to możliwe, mikrokontroler powinien znajdować się w trybie uśpienia, aby oszczędzać energię. W tym egzample, MCU śpi, gdy działa RTC, czeka na uruchomienie kryształu radiowego i podczas transmisji z FIFO. MCU obudzi się z sygnału IRQ EZRadioPRO podłączonego do wybudzenia Port Match.
Podczas przesyłania komunikatów dłuższych niż jeden blok, MCU musi się obudzić, aby wypełnić FIFO (w oparciu o prawie puste przerwanie FIFO), a następnie wrócić do stanu uśpienia.
Podczas odczytu z ADC mikrokontroler powinien znajdować się w trybie bezczynności i działać z oscylatora małej mocy lub oscylatora w trybie impulsowym. ADC wymaga zegara SAR.
Kiedy EZRadioPRO nie jest używane, powinno znajdować się w trybie wyłączenia z pinem SDN w stanie wysokim. Wymaga to przewodowego połączenia z MCU. Rejestry EZ Radio Pro nie są zachowywane w trybie wyłączenia; tak więc EZRadioPro jest inicjalizowane w każdym odstępie czasu RTC. Inicjalizacja radia zajmuje mniej niż 100 µs i oszczędza 400 nA. Daje to oszczędność energii wynoszącą 10 µJ w oparciu o 10-sekundowy interwał.
Kryształ EZRadioPRO potrzebuje około 16 ms dla POR. To wystarczająco długo, aby obliczyć CRC dla około ośmiu bloków. MCU wróci do stanu uśpienia, jeśli ukończy wszystkie CRC, zanim kryształ się ustabilizuje. Jeśli wymagane jest szyfrowanie, można je również uruchomić w oczekiwaniu na oscylator kwarcowy.
W przypadku większości zadań mikrokontroler powinien pracować z częstotliwością 20 MHz, korzystając z oscylatora małej mocy. Zadania wymagające dokładnego limitu czasu muszą używać precyzyjnego oscylatora i trybu bezczynności zamiast trybu uśpienia. RTC zapewnia wystarczającą rozdzielczość dla większości zadań. Oś czasu zarządzania energią dla licznika T2 npampAplikacja pokazana jest na rysunku 3.

Implementację transiwera należy zoptymalizować dla normalnego przypadku, gdy licznik się wybudza i nie ma czytnika. Minimalne/maksymalne limity czasu ACK są wystarczająco długie, aby możliwe było użycie C8051F930 RTC i przełączenie MCU w tryb uśpienia.
Opcje kompilacji są dostępne dla czytników zasilanych z sieci lub USB, które nie wymagają korzystania z trybu uśpienia. Zamiast uśpienia używany będzie tryb bezczynności, aby USB i UART mogły zakłócać działanie MCU.

Studio Prostoty
Dostęp jednym kliknięciem do narzędzi MCU i bezprzewodowych, dokumentacji, oprogramowania, bibliotek kodów źródłowych i nie tylko. Dostępne dla systemu Windows,
Mac i Linux!

Portfolio IoT www.silabs.com/IoT	SW/sprzęt www.silabs.com/simplicity	Jakość www.silabs.com/jakość	Wsparcie i społeczność społeczność.silabs.com

Zastrzeżenie
Silicon Labs zamierza dostarczać klientom najnowszą, dokładną i szczegółową dokumentację wszystkich urządzeń peryferyjnych i modułów dostępnych dla implementatorów systemów i oprogramowania, którzy używają lub zamierzają używać produktów Silicon Labs. Dane dotyczące charakterystyki, dostępne moduły i urządzenia peryferyjne, rozmiary pamięci i adresy pamięci odnoszą się do każdego konkretnego urządzenia, a „typowe” parametry mogą się różnić i różnią się w różnych aplikacjach. Aplikacja exampOpisane tutaj pliki służą wyłącznie celom ilustracyjnym. Silicon Labs zastrzega sobie prawo do wprowadzania zmian bez dodatkowego powiadomienia i ograniczania informacji o produkcie, specyfikacji i opisów zawartych w niniejszym dokumencie i nie daje gwarancji co do dokładności lub kompletności zawartych informacji. Silicon Labs nie ponosi odpowiedzialności za skutki wykorzystania informacji zawartych w niniejszym dokumencie. Niniejszy dokument nie implikuje ani nie wyraża licencji praw autorskich przyznanych na mocy niniejszego dokumentu na projektowanie lub wytwarzanie jakichkolwiek układów scalonych. Produkty nie są zaprojektowane ani nie są dopuszczone do stosowania w jakimkolwiek systemie podtrzymywania życia bez wyraźnej pisemnej zgody Silicon Labs. „System podtrzymywania życia” to dowolny produkt lub system przeznaczony do podtrzymywania lub podtrzymywania życia i/lub zdrowia, co do którego, jeśli zawiedzie, można zasadnie oczekiwać, że spowoduje poważne obrażenia ciała lub śmierć. Produkty Silicon Labs nie są projektowane ani autoryzowane do zastosowań wojskowych. Produkty Silicon Labs nie mogą być w żadnym wypadku używane w broni masowego rażenia, w tym (ale nie wyłącznie) w broni nuklearnej, biologicznej lub chemicznej, ani w rakietach zdolnych do przenoszenia takiej broni.
Informacje o znaku towarowym
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® i logo Silicon Labs®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, logo Energy Micro i ich kombinacje, „najbardziej przyjazne energetycznie mikrokontrolery na świecie”, Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, logo Telegesis®, USBXpress® i inne są znakami towarowymi lub zastrzeżonymi znakami towarowymi firmy Silicon Labs. ARM, CORTEX, Cortex-M3 i kciuki są znakami towarowymi lub zastrzeżonymi znakami towarowymi ARM Holdings. Keil jest zastrzeżonym znakiem towarowym firmy ARM Limited. Wszystkie inne produkty lub nazwy marek wymienione w niniejszym dokumencie są znakami towarowymi odpowiednich właścicieli.

Laboratoria Silicon Inc.
400 Zachodni Cesar Chávez
Austin, Teksas 78701
USA
http://www.silabs.com

Dokumenty / Zasoby

Wdrożenie oprogramowania SILICON LABS Wireless M-BUS AN451 [plik PDF] Instrukcja użytkownika SILICON LABS, C8051, MCU i EZRadioPRO, Bezprzewodowa magistrala M-bus, Bezprzewodowa, M-BUS, Oprogramowanie, Implementacja, AN451

Odniesienia

• Instrukcja obsługi