AN451
WIRELESS M-BUS SOFTWARE IMPLEMENTATION
Panimula
Inilalarawan ng application note na ito ang pagpapatupad ng Silicon Labs ng Wireless M-Bus gamit ang Silicon Labs C8051 MCU at EZRadioPRO®. Ang Wireless M-bus ay isang European Standard para sa mga application sa pagbabasa ng metro gamit ang frequency band na 868 MHz.
Stack Layers
Ang Wireless M-Bus ay gumagamit ng 3-layer na modelo ng IEC, na isang subset ng 7-layer na modelo ng OSI (tingnan ang Larawan 1).
Ang Physical (PHY) layer ay tinukoy sa EN 13757-4. Tinutukoy ng pisikal na layer kung paano na-encode at ipinapadala ang mga bit, ang mga katangian ng RF modem (chip rate, preamble, at synchronization na salita), at mga parameter ng RF (modulation, center frequency, at frequency deviation).
Ang PHY layer ay ipinatupad gamit ang kumbinasyon ng hardware at firmware. Ang EZRadioPRO ay gumaganap ng lahat ng RF at modem function. Ang EZRadioPRO ay ginagamit sa FIFO mode kasama ang packet handler. Ang MbusPhy.c module ay nagbibigay ng SPI interface, encoding/decoding, block read/write, at packet handling at pinamamahalaan ang mga transceiver states.
Ang layer ng link ng M-Bus Data ay ipinatupad sa MbusLink.c module. Ang interface ng M-Bus Application Programming ay binubuo ng mga pampublikong function na maaaring tawagin mula sa layer ng application sa pangunahing thread. Ang MbusLink module ay nagpapatupad din ng Data Link Layer. Ipo-format at kokopyahin ng layer ng Data link ang data mula sa application na TX buffer patungo sa MbusPhy TX buffer, idaragdag ang mga kinakailangang header at CRC.
Ang Application layer mismo ay hindi bahagi ng M-bus firmware. Tinutukoy ng layer ng application kung paano ipo-format ang malawak na uri ng data para sa paghahatid. Karamihan sa mga metro ay kailangan lamang na magpadala ng isa o dalawang uri ng data. Ang pagdaragdag ng malaking halaga ng code upang ma-accommodate ang anumang uri ng data sa metro ay magdaragdag ng hindi kinakailangang code at gastos sa metro. Maaaring maisagawa ang isang library o isang header file na may kumpletong listahan ng mga uri ng data. Gayunpaman, alam ng karamihan sa mga customer sa pagsukat kung anong uri ng data ang kailangan nilang ipadala at maaaring sumangguni sa pamantayan para sa mga detalye ng pag-format. Ang isang unibersal na reader o sniffer ay maaaring magpatupad ng kumpletong hanay ng mga uri ng data ng application sa PC GUI. Para sa mga kadahilanang ito, ang application layer ay ipinatupad gamit ang example mga aplikasyon para sa isang metro at reader.
Mga Kinakailangang Pamantayan
- EN 13757-4
EN 13757-4
Sistema ng komunikasyon para sa mga metro at malayuang pagbabasa ng mga metro
Bahagi 4: Pagbasa ng wireless meter
Pagbabasa ng radiometer para sa operasyon sa 868 MHz hanggang 870 MHz SRD band - EN 13757-3
Sistema ng komunikasyon para sa mga metro at malayuang pagbabasa ng mga metro
Bahagi 3: Nakatuon na layer ng application - IEC 60870-2-1:1992
Mga kagamitan at sistema ng telecontrol
Bahagi 5: Mga protocol ng paghahatid
Seksyon 1: Pamamaraan sa paghahatid ng link - IEC 60870-1-1:1990
Mga kagamitan at sistema ng telecontrol
Bahagi 5: Mga protocol ng paghahatid
Seksyon 1: Mga format ng frame ng paghahatid
Mga Kahulugan
- M-Bus—Ang M-Bus ay isang wired standard para sa pagbabasa ng metro sa Europe.
- Wireless M-Bus—Wireless M-Bus para sa meter reading application sa Europe.
- PHY—Tinatukoy ng Pisikal na Layer kung paano na-encode at ipinapadala ang mga bits at byte ng data.
- API—Interface ng Application Programmer.
- LINK—Tinutukoy ng Data Link Layer kung paano ipinapadala ang mga block at frame.
- CRC—Cyclic Redundancy Check.
- FSK—Frequency Shift Keying.
- Chip—Pinakamaliit na yunit ng ipinadalang data. Ang isang bit ng data ay naka-encode bilang maramihang chips.
- Module—Pinagmulan ng AC code .c file.
M-Bus PHY Functional Description
Preamble Sequence
Ang Preamble sequence na tinukoy ng M-bus specification ay isang integer number na nagpapalit ng mga zero at one. Ang isa ay tinukoy bilang ang mas mataas na dalas, at ang isang zero ay tinukoy bilang ang mas mababang dalas.
nx (01)
Ang mga opsyon sa Preamble para sa Si443x ay isang integer na bilang ng mga nibbles na binubuo ng mga papalit-palit at mga zero.
nx (1010)
Ang isang preamble na may dagdag na nangunguna ay hindi magiging isang problema, ngunit, kung gayon, ang pag-synchronize ng salita at kargamento ay magiging mali ng kaunti.
Ang solusyon ay ang baligtarin ang buong packet sa pamamagitan ng pagtatakda ng engine bit sa Modulation Control 2 register (0x71). Ibabaligtad nito ang preamble, sync word, at TX/RX data. Bilang kinahinatnan, dapat na baligtarin ang data kapag isinusulat ang data ng TX o binabasa ang data ng RX. Gayundin, ang salitang pag-synchronize ay binabaligtad bago sumulat sa mga rehistro ng Si443x Synchronization Word.
Salita ng Pag-synchronize
Ang salitang pag-synchronize na kinakailangan ng EN-13757-4 ay alinman sa 18 chips para sa Mode S at Mode R o 10 chips para sa Model T. Ang salitang pag-synchronize para sa Si443x ay 1 hanggang 4 bytes. Gayunpaman, dahil ang salitang pag-synchronize ay palaging nauuna sa paunang salita, ang huling anim na piraso ng paunang salita ay maaaring ituring na bahagi ng salitang pag-synchronize; kaya, ang unang salitang pag-synchronize ay may palaman ng tatlong pag-uulit ng isang zero na sinusundan ng isang isa. Ang salita ng pag-synchronize ay kinukumpleto bago sumulat sa mga rehistro ng Si443x.
Talahanayan 1. Synchronization Word para sa Mode S at Mode R
| EN 13757-4 | 00 | 01110110 | 10010110 | binary |
| 00 | 76 | 96 | hex | |
| pad na may (01) x 3 | 01010100 | 01110110 | 10010110 | binary |
| 54 | 76 | 96 | hex | |
| pandagdag | 10101011 | 10001001 | 01101001 | binary |
| AB | 89 | 69 | hex |
Talahanayan 2. Synchronization Word para sa Mode T Meter sa Iba
| SYNCH | SYNCH | SYNCH |
| SALITA | SALITA | SALITA |
| 3 | 2 | 1 |
Ipadala ang Preamble Length
Ang minimum na preamble ay tinukoy para sa apat na magkakaibang mga operating mode. Katanggap-tanggap na magkaroon ng preamble na mas mahaba kaysa sa tinukoy. Ang pagbabawas ng anim na chips para sa preamble ay nagbibigay ng pinakamababang bilang ng mga chips para sa Si443x preamble. Ang pagpapatupad ay nagdaragdag ng dalawang karagdagang nibbles ng preamble sa lahat ng maikling preamble mode upang mapabuti ang preamble detection at interoperability. Ang preamble sa Mode S na may mahabang preamble ay napakahaba; kaya, ang minimum na preamble ay ginagamit. Ang haba ng paunang salita sa mga nibble ay isinusulat sa rehistro ng Preamble Length (0x34). Ang rehistro ng preamble length ay tumutukoy sa preamble sa transmission lamang. Ang pinakamababang detalye at mga setting ng haba ng preamble ay ibinubuod sa Talahanayan 3.
Talahanayan 3. Ipadala ang Haba ng Preamble
| EN-13757-4 pinakamababa |
Si443x Preamble Pag-set ing |
I-sync salita |
Kabuuan | dagdag | |||
| nx (01) | chips | nibbles | chips | chips | chips | chips | |
| Mode S maikling preamble | 15 | 30 | 8 | 32 | 6 | 38 | 8 |
| Mode S mahabang preamble | 279 | 558 | 138 | 552 | 6 | 558 | 0 |
| Mode T (meter-other) | 19 | 38 | 10 | 40 | 6 | 46 | 8 |
| Mode R | 39 | 78 | 20 | 80 | 6 | 86 | 8 |
Ang pinakamababang preamble para sa pagtanggap ay tinutukoy ng Preamble Detection Control register (0x35). Sa pagtanggap, ang bilang ng mga bit sa sync na salita ay dapat ibawas mula sa tinukoy na minimum na preamble upang matukoy ang magagamit na preamble. Ang minimum na oras ng pag-aayos ng receiver ay 16-chips kung ang AFC ay pinagana o 8-chips kung ang AFC ay hindi pinagana. Ang oras ng pag-aayos ng receiver ay ibinabawas din sa magagamit na preamble upang matukoy ang pinakamababang setting para sa rehistro ng Preamble Detection Control.
Ang posibilidad ng isang maling preamble ay depende sa setting ng Preamble Detection Control register. Ang isang maikling setting ng 8-chips ay maaaring magresulta sa isang maling preamble na natukoy bawat ilang segundo. Ang inirerekumendang setting ng 20chips ay ginagawang hindi malamang na kaganapan ang pagtuklas ng maling preamble. Ang mga haba ng preamble para sa Mode R at Mode SL ay sapat na mahaba para magamit ang inirerekomendang setting.
Napakakaunting pakinabang sa paggawa ng preamble na makakita ng mas mahaba kaysa sa 20 chips.
Ang AFC ay hindi pinagana para sa Model S na may maikling preamble at Model T. Binabawasan nito ang oras ng pag-aayos ng receiver at pinahihintulutan ang mas mahabang setting ng pagtuklas ng preamble. Kapag hindi pinagana ang AFC, magagamit ng Mode T ang inirerekomendang setting na 20 chips. Ang isang setting ng 4 nibbles o 20 chips ay ginagamit para sa Model S na may maikling preamble. Ginagawa nitong bahagyang mas mataas ang posibilidad ng isang false preamble detection para sa modelong ito.
Talahanayan 4. Preamble Detection
| EN-13757-4 pinakamababa |
I-sync salita |
magagamit pambungad |
Pag-aayos ng RX | Detect min |
Si443x Preamble Pagtatakda ng Detection |
|||
| nx (01) | chips | chips | chips | chips | chips | nibbles | chips | |
| Mode S maikling preamble | 15 | 30 | 6 | 24 | 8* | 16 | 4 | 16 |
| Model S mahabang preamble | 279 | 558 | 6 | 552 | 16 | 536 | 5 | 20 |
| Model T (meter-other) | 19 | 38 | 6 | 32 | 8* | 24 | 5 | 20 |
| Mode R | 39 | 78 | 6 | 72 | 16 | 56 | 5 | 20 |
| *Tandaan: Na-disable ang AFC | ||||||||
Ang receiver ay naka-configure upang makipag-interoperate sa isang transmitter gamit ang minimum na tinukoy na preamble. Tinitiyak nito na ang receiver ay makikipag-ugnayan sa alinmang M-bus-compliant transmitter.
Ang pagtutukoy ng Wireless M-Bus ay nangangailangan ng napakahabang preamble para sa Mode S1 na hindi bababa sa 558 chips. Aabutin ito ng humigit-kumulang 17 ms para lang maihatid ang preamble. Ang Si443x ay hindi nangangailangan ng gayong mahabang paunang salita at hindi nakikinabang sa mahabang paunang salita. Habang ang mahabang paunang salita ay binanggit bilang opsyonal para sa Mode S2, walang dahilan para gumamit ng mahabang paunang salita sa Si443x. Kung nais ng one-way na komunikasyon, ang Mode T1 ay magbibigay ng mas maikling preamble, mas mataas na rate ng data, at mas mahabang buhay ng baterya. Kung kailangan ng two-way na komunikasyon gamit ang Mode S2, inirerekumenda ang isang maikling preamble.
Pansinin na ang threshold ng pagtuklas para sa Model S na may mahabang preamble ay mas mahaba kaysa sa bilang ng mga preamble nibble na ipinadala para sa Model S na may maikling preamble. Nangangahulugan ito na ang mahabang preamble Mode S receiver ay hindi makaka-detect ng preamble mula sa isang short preamble Mode S transmitter. Ito ay kinakailangan kung ang mahabang preamble Mode S receiver ay makakatanggap ng anumang benepisyo mula sa mahabang preamble.
Tandaan na ang short preamble Mode S receiver ay makaka-detect ng preamble at makakatanggap ng mga packet mula sa parehong short preamble Mode S
transmitter at isang long-preamble Mode S transmitter; kaya, sa pangkalahatan, dapat gamitin ng meter reader ang maikling preamble Mode S receiver configuration.
Encoding/Decoding
Ang pagtutukoy ng Wireless M-bus ay nangangailangan ng dalawang magkaibang paraan ng pag-encode. Ginagamit ang Manchester encoding para sa Mode S at Mode R. Ginagamit din ang Manchester encoding para sa other-to-meter link sa Model T. Gumagamit ang Model T meter-to-other link ng 3 sa 6 na pag-encode.
1. Manchester Encoded/Decoding
Ang pag-encode ng Manchester ay pangkaraniwan sa kasaysayan sa mga RF system upang magbigay ng matatag na pagbawi at pagsubaybay sa orasan gamit ang isang simple at murang modem. Gayunpaman, ang modernong high-performance na radyo tulad ng Si443x ay hindi nangangailangan ng Manchester encoding. Pangunahing sinusuportahan ang pag-encode ng Manchester para sa pagiging tugma sa mga kasalukuyang pamantayan, ngunit ang rate ng data para sa Si443x ay epektibong nadodoble kapag hindi gumagamit ng Manchester encoding.
Sinusuportahan ng Si443x ang Manchester encoding at decoding ng buong packet sa hardware. Sa kasamaang palad, ang salitang pag-synchronize ay hindi naka-encode sa Manchester. Isang di-wastong sequence ng Manchester ang sadyang pinili para sa salitang pag-synchronize. Ginagawa nitong hindi tugma ang pag-encode ng Manchester sa karamihan ng mga kasalukuyang radyo, kabilang ang Si443x. Bilang kinahinatnan, ang Manchester encoding at decoding ay dapat isagawa ng MCU. Ang bawat byte sa hindi naka-encode na data ay binubuo ng walong data bits. Gamit ang Manchester encoding, ang bawat bit ng data ay naka-encode sa isang two-chip na simbolo. Dahil ang naka-encode na data ay dapat na nakasulat sa radio FIFO ng walong chips sa isang pagkakataon, isang nibble ng data ay naka-encode at nakasulat sa FIFO sa isang pagkakataon.
Talahanayan 5. Manchester Encoding
| datos | Ox12 | 0x34 | byte | ||
| Ox1 | 0x2 | 0x3 | 0x4 | nibbles | |
| 1 | 10 | 11 | 100 | binary | |
| chip | 10101001 | 10100110 | 10100101 | 10011010 | binary |
| FIFO | OxA9 | OxA6 | OxA5 | Ox9A | hex |
Ang bawat byte na ipapadala ay ipapasa nang paisa-isa sa encode byte function. Tatawagin ng encode byte function ang encode nibble function nang dalawang beses, una para sa pinaka makabuluhang nibble at pagkatapos ay para sa hindi gaanong makabuluhang nibble.
Ang pag-encode ng Manchester sa software ay hindi mahirap. Simula sa pinaka makabuluhang bit, ang isa ay naka-encode bilang "01" chip sequence. Ang isang zero ay naka-encode bilang isang "10" chip sequence. Madali itong magawa gamit ang isang loop at paglilipat ng dalawang-bit para sa bawat simbolo. Gayunpaman, mas mabilis na gumamit lamang ng simpleng 16 entry look-up table para sa bawat kagat. Ang pag-encode ng Manchester nibble function ay nag-encode ng isang nibble ng data pagkatapos ay isinusulat ito sa FIFO. Ang mga chips ay binabaligtad bago sumulat sa FIFO upang i-account ang mga inverted preamble na kinakailangan.
Kapag tumatanggap, ang bawat byte sa FIFO ay binubuo ng walong chips at nade-decode sa isang nibble ng data. Ang read block function ay nagbabasa ng isang byte sa isang pagkakataon mula sa FIFO at tinatawag ang decode byte function. Ang mga chips ay binabaligtad pagkatapos basahin mula sa FIFO upang isaalang-alang ang mga inverted preamble na kinakailangan. Ang bawat byte ng Manchester na naka-encode na mga chip ay na-decode sa isang maliit na kagat ng data. Ang na-decode na nibble ay isinusulat sa RX buffer gamit ang write nibble RX buffer function.
Pansinin na ang parehong naka-encode at nagde-decode ay ginagawa ng isang data nibble sa isang pagkakataon sa mabilisang. Ang pag-encode sa isang buffer ay mangangailangan ng karagdagang buffer na dalawang beses ang laki ng hindi naka-encode na data. Ang pag-encode at pag-decode ay mas mabilis kaysa sa pinakamabilis na sinusuportahang rate ng data (100 k chips bawat segundo). Dahil ang Si443x ay sumusuporta sa maramihang-byte na pagbabasa at pagsusulat sa FIFO, mayroong maliit na overhead sa paggamit lamang ng single-byte na pagbabasa at pagsusulat. Ang overhead ay humigit-kumulang 10 µs para sa 100 naka-encode na chip. Ang benepisyo ay isang pagtitipid ng RAM na 512 bytes.
2. Tatlo sa Anim na Encoding Decoding
Ang Three-out-of-Six na paraan ng pag-encode na tinukoy sa EN-13757-4 ay ipinapatupad din sa firmware sa MCU. Ginagamit ang encoding na ito para sa high-speed (100 k chips per second) na Mode T mula sa metro patungo sa iba pa. Ang Model T ay nagbibigay ng pinakamaikling oras ng paghahatid at ang pinakamahabang buhay ng baterya para sa isang wireless meter.
Ang bawat byte ng data na ipapadala ay nahahati sa dalawang nibbles. Ang pinaka makabuluhang nibble ay na-encode at ipinadala muna. Muli, ito ay ipinatupad gamit ang isang encode byte function na tumatawag sa encode nibble function nang dalawang beses.
Ang bawat nibble ng data ay naka-encode sa isang anim na chip na simbolo. Ang pagkakasunud-sunod ng mga simbolo ng anim na chip ay dapat na nakasulat sa 8chip FIFO.
Sa panahon ng pag-encode, dalawang byte ng data ang naka-encode bilang apat na nibbles. Ang bawat kagat ay isang 6-chip na simbolo. Apat na 6chip na simbolo ang pinagsama-sama bilang tatlong byte.
Talahanayan 6. Tatlo sa Anim na Encoding
| datos | 0x12 | 0x34 | byte | ||||
| Ox1 | 0x2 | 0x3 | 0x4 | nibbles | |||
| chip | 15 | 16 | 13 | 34 | octal | ||
| 1101 | 1110 | 1011 | 11100 | binary | |||
| FIFO | 110100 | 11100010 | 11011100 | binary | |||
| 0x34 | OxE2 | OxDC | hex | ||||
Sa software, ang three-out-of-six na pag-encode ay ipinapatupad gamit ang tatlong nested function. Ang encode byte function ay tatawag sa encode nibble function nang dalawang beses. Ang encode nibble function ay gumagamit ng look-up table para sa anim na chip na simbolo at isinusulat ang simbolo sa Shift Three out of Six function. Ang function na ito ay nagpapatupad ng 16-chip shift register sa software. Ang simbolo ay isinulat sa hindi bababa sa makabuluhang byte ng shift register. Ang rehistro ay inilipat pakaliwa nang dalawang beses. Inulit ito ng tatlong beses. Kapag ang isang kumpletong byte ay nasa itaas na byte ng shift register, ito ay binabaligtad at isinusulat sa FIFO.
Dahil ang bawat byte ng data ay naka-encode bilang isa at kalahating naka-encode na byte, mahalagang i-clear ang shift register sa simula upang ang unang naka-encode na byte ay tama. Kung ang haba ng packet ay isang kakaibang numero, pagkatapos ma-encode ang lahat ng byte, magkakaroon pa rin ng isang kagat na natitira sa shift register. Ito ay hinahawakan gamit ang postamble gaya ng ipinaliwanag sa susunod na seksyon.
Ang pag-decode ng tatlo sa anim na naka-encode ay ang reverse procedure. Kapag nagde-decode, tatlong naka-encode na byte ang nade-decode sa dalawang data byte. Ang software shift register ay muling ginagamit upang pagsama-samahin ang mga byte ng na-decode na data. Ang isang 64-entry na inverse look-up table ay ginagamit para sa pag-decode. Gumagamit ito ng mas kaunting mga cycle ngunit mas maraming code memory. Ang paghahanap sa isang 16-entry na look-up table para sa kaukulang simbolo ay mas matagal.
Postamble
Ang detalye ng Wireless M-bus ay may mga partikular na kinakailangan para sa postamble o trailer. Para sa lahat ng mga mode, ang minimum ay dalawang chips, at ang maximum ay walong chips. Dahil ang minimum na atomic unit para sa FIFO ay isang byte, isang 8-chip trailer ang ginagamit para sa Mode S at Mode R. Ang Mode T postamble ay walong chips kung ang haba ng packet ay even o apat na chips kung kakaiba ang haba ng packet. Ang four-chip postamble para sa isang kakaibang haba ng packet ay nakakatugon sa mga kinakailangan ng pagkakaroon ng hindi bababa sa dalawang alternating chips.
Talahanayan 7. Haba ng Postamble
| Haba ng postamble (chips) | |||||
| min | max | Pagpapatupad | pagkakasunud-sunod ng chip | ||
| Mode S | 2 | 8 | 8 | 1010101 | |
| Mode T | 2 | 8 | 4 | (kakaiba) | 101 |
| 8 | (kahit) | 1010101 | |||
| Mode R | 2 | 8 | 8 | 1010101 | |
Packet Handler
Ang packet handler sa Si443x ay maaaring gamitin sa isang variable na packet width mode o isang fixed packet width mode. Ang variable na packet width mode ay nangangailangan ng packet length byte pagkatapos ng synchronization word at opsyonal na header byte. Sa pagtanggap, gagamitin ng Radyo ang haba ng byte upang matukoy ang dulo ng isang wastong packet. Sa paghahatid, ipapasok ng radyo ang haba ng field pagkatapos ng mga byte ng header.
Ang L field para sa wireless M-bus protocol ay hindi magagamit para sa Si443x length field. Una, ang L field ay hindi ang aktwal na haba ng packet. Ito ay ang bilang ng mga link layer payload byte na hindi kasama ang mga CRC byte o encoding. Pangalawa, ang L -field mismo ay naka-encode gamit ang alinman sa Manchester encoding o Three out of Six encoding para sa Mode T meter sa iba.
Ginagamit ng pagpapatupad ang packet handler sa fixed packet width mode para sa parehong transmission at reception. Sa paghahatid, babasahin ng layer ng PHY ang L field sa buffer ng pagpapadala at kakalkulahin ang bilang ng mga naka-encode na byte, kasama ang postamble. Ang kabuuang bilang ng mga naka-encode na byte na ipapadala ay nakasulat sa Packet Length register (0x3E).
Sa pagtanggap, ang unang dalawang naka-encode na byte ay na-decode, at ang L-field ay isinusulat sa receive buffer. Ang L-field ay ginagamit upang kalkulahin ang bilang ng mga naka-encode na byte na matatanggap. Ang bilang ng mga naka-encode na byte na matatanggap ay isusulat sa Packet Length register (0x3E). Ang postamble ay itinapon.
Dapat i-decode ng MCU ang L-field, kalkulahin ang bilang ng mga naka-encode na byte, at isulat ang halaga sa rehistro ng Packet Length bago matanggap ang pinakamaikling posibleng haba ng packet. Ang pinakamaikling pinahihintulutang L-field para sa layer ng PHY ay 9, na nagbibigay ng 12 hindi naka-encode na byte. Nagbibigay ito ng 18 na naka-encode na byte para sa Model T. Na-decode na ang unang dalawang byte. Kaya, ang rehistro ng Haba ng packet ay dapat na ma-update sa 16-byte na beses sa 100 kbps o 1.28 millisecond. Ito ay walang problema para sa isang 8051 na tumatakbo sa 20 MIPS.
Ang bilang ng mga byte na matatanggap ay hindi kasama ang postamble, maliban sa apat na chip na postamble na ginagamit para sa Mode T packet na may kakaibang haba ng packet. Kaya, ang receiver ay hindi nangangailangan ng isang postamble, maliban sa Model T odd length packets. Ang postamble na ito ay kailangan lamang upang magbigay ng integer na bilang ng mga naka-encode na byte. Ang nilalaman ng postamble ay hindi pinapansin; kaya, kung ang postamble ay hindi ipinadala, apat na chips ng ingay ang matatanggap at hindi papansinin. Dahil ang kabuuang bilang ng mga naka-encode na byte ay limitado sa 255 (0xFF), nililimitahan ng pagpapatupad ang maximum na L-field para sa iba't ibang mga mode.
Talahanayan 8. Mga Limitasyon sa Laki ng Packet
| naka-encode | na-decode | M-Bus | ||||
| byte | byte | L-Field | ||||
| dec | hex | dec | hex | dec | hex | |
| Mode S | 255 | FF | 127 | 7 F | 110 | 6E |
| Mode T (meter-other) | 255 | FF | 169 | A9 | 148 | 94 |
| Mode R | 255 | FF | 127 | 7 F | 110 | 6E |
Ang mga limitasyong ito ay karaniwang mas mataas sa karaniwang kaso ng paggamit para sa isang wireless meter. Ang haba ng packet ay dapat panatilihing maliit upang makuha ang pinakamahusay na posibleng buhay ng baterya.
Bilang karagdagan, maaaring tukuyin ng user ang maximum na L-field na dapat matanggap (USER_RX_MAX_L_FIELD). Tinutukoy nito ang kinakailangang laki para sa receive buffer (USER_RX_BUFFER_SIZE).
Ang pagsuporta sa maximum na L-field na 255 ay mangangailangan ng receive buffer na 290 bytes at maximum na 581 Manchester encoded byte. Ang packet handler ay kailangang i-disable at ang Packet Length register ay hindi magagamit sa kasong iyon. Ito ay magagawa, ngunit mas maginhawang gamitin ang packet handler, kung maaari.
Paggamit ng FIFO
Ang Si4431 ay nagbibigay ng 64 byte FIFO para sa pagpapadala at pagtanggap. Dahil ang bilang ng mga naka-encode na byte ay 255, ang isang buong naka-encode na packet ay maaaring hindi magkasya sa loob ng 64-byte na buffer.
Paghawa
Sa paghahatid, ang kabuuang bilang ng mga naka-encode na byte ay kinakalkula. Kung ang kabuuang bilang ng mga naka-encode na byte, kasama ang postamble, ay mas mababa sa 64 byte, ang buong packet ay isusulat sa FIFO at tanging ang packet na ipinadala ng interrupt ang pinagana. Karamihan sa mga maikling packet ay ipapadala sa isang FIFO transfer.
Kung ang bilang ng mga naka-encode na byte ay higit sa 64, kakailanganin ng maraming FIFO transfer upang maipadala ang packet. Ang unang 64 byte ay isinulat sa FIFO. Ang Packet Sent at TX FIFO Almost Empty interrupts ay pinagana. Ang TX FIFO Almost Empty threshold ay nakatakda sa 16 bytes (25%). Sa bawat kaganapan sa IRQ, binabasa ang rehistro ng status 2. Ang Packet Sent bit ay sinusuri muna, at, kung ang packet ay hindi pa ganap na naipadala, ang susunod na 48 bytes ng naka-encode na data ay isusulat sa FIFO. Nagpapatuloy ito hanggang sa naisulat ang lahat ng naka-encode na byte at naganap ang Packet Sent na interrupt.
1. Pagtanggap
Sa pagtanggap, sa simula, tanging ang Sync Word interrupt ang pinagana. Pagkatapos matanggap ang sync word, ang sync word interrupt ay hindi pinagana at ang FIFO Almost Full interrupt ay pinagana. Ang halos buong threshold ng FIFO ay unang nakatakda sa 2 bytes. Ang unang FIFO Almost Full interrupt ay ginagamit upang malaman kung kailan natanggap ang dalawang haba na byte. Kapag natanggap na ang haba, nade-decode ang haba at kinakalkula ang bilang ng mga naka-encode na byte. Ang RX FIFO almost Full threshold ay nakatakda sa 48 bytes. Ang RX FIFO ay halos puno at ang mga Valid Packet interrupts ay pinagana. Sa susunod na kaganapan sa IRQ, ang status 1 na rehistro ay nabasa. Una, susuriin ang Valid Packet bit, at pagkatapos ay susuriin ang FIFO Almost Full bit. Kung ang RX FIFO Almost Full bit lang ang nakatakda, ang susunod na 48 bytes ay babasahin mula sa FIFO. Kung ang wastong packet bit ay nakatakda, ang natitira sa packet ay babasahin mula sa FIFO. Sinusubaybayan ng MCU kung gaano karaming mga byte ang nabasa at huminto sa pagbabasa pagkatapos ng huling byte.
Layer ng Data Link
Ang module ng data link layer ay nagpapatupad ng 13757-4:2005 compliant link layer. Ang data link layer (LINK) ay nagbibigay ng interface sa pagitan ng physical layer (PHY) at application layer (AL).
Ginagawa ng Data Link Layer ang mga sumusunod na function:
- Nagbibigay ng mga function na naglilipat ng data sa pagitan ng PHY at AL
- Bumubuo ng mga CRC para sa mga papalabas na mensahe
- Nakikita ang mga error sa CRC sa mga papasok na mensahe
- Nagbibigay ng pisikal na pagtugon
- Kinikilala ang mga paglilipat para sa bidirectional na mga mode ng komunikasyon
- Nag-frame ng mga bits ng data
- Nakikita ang mga error sa pag-frame sa mga papasok na mensahe
Format ng Frame ng Layer ng Link
Ang format ng Wireless M-Bus frame na ginamit sa EN 13757-4:2005 ay hinango mula sa FT3 (Frame Type 3) na format ng frame mula sa IEC60870-5-2. Ang frame ay binubuo ng isa o higit pang mga bloke ng data. Ang bawat bloke ay may kasamang 16-bit na field ng CRC. Ang unang bock ay isang fixed-length na block na 12 bytes na kinabibilangan ng L-field, C-field, M-field, at A-Field.
- L-Field
Ang L-field ay ang haba ng data payload ng Link layer. Hindi kasama dito ang L-field mismo o alinman sa mga CRC byte. Kasama dito ang L-field, C-field, M-field, at A-Field. Ito ay bahagi ng PHY payload.
Dahil ang bilang ng mga naka-encode na byte ay limitado sa 255 byte, ang maximum na sinusuportahang halaga para sa M-field ay 110 byte para sa Manchester na naka-encode na data at 148 byte para sa Mode T Three-Out-of-Six na naka-encode na data.
Ang Link layer ay responsable para sa pagkalkula ng L-field sa paghahatid. Gagamitin ng link-layer ang L-field sa reception.
Tandaan na hindi ipinapahiwatig ng L-field ang haba ng payload ng PHY o ang bilang ng mga naka-encode na byte. Sa paghahatid, kakalkulahin ng PHY ang haba ng payload ng PHY at ang bilang ng mga naka-encode na byte. Sa pagtanggap, ide-decode ng PHY ang L-field at kakalkulahin ang bilang ng mga byte na ide-decode. - C-Field
Ang C-field ay ang frame control field. Tinutukoy ng field na ito ang uri ng frame at ginagamit para sa mga primitive ng serbisyo ng pagpapalitan ng data ng link. Ang C-field ay nagpapahiwatig ng uri ng frame – IPADALA, KUMPIRMA, HILING, o TUGUNAN. Sa kaso ng SEND at REQUEST frame, ang C-field ay nagpapahiwatig kung ang isang CONFIRM o RESPOND ay inaasahan.
Kapag ginagamit ang pangunahing function ng Link TX, maaaring gamitin ang anumang halaga ng C. Kapag ginagamit ang Link Service Primitives, ang C field ay awtomatikong napo-populate ayon sa EN 13757-4:2005. - M-Field
Ang M-field ay ang code ng tagagawa. Ang mga tagagawa ay maaaring humiling ng isang tatlong-titik na code mula sa mga sumusunod web address: http://www.dlms.com/flag/INDEX.HTM Ang bawat karakter ng tatlong-titik na code ay naka-encode bilang limang bits. Maaaring makuha ang 5-bit code sa pamamagitan ng pagkuha ng ASCII code at pagbabawas ng 0x40 (“A”). Ang tatlong 5-bit na code ay pinagsama-sama upang makagawa ng 15-bits. Ang pinaka makabuluhang bit ay zero. - A-Field
Ang address field ay isang natatanging 6-byte na address para sa bawat device. Ang natatanging address ay dapat italaga ng tagagawa. Responsibilidad ng bawat tagagawa na tiyakin na ang bawat device ay may natatanging 6-byte na address. Ang address para sa Send and Request frames ay ang self-address ng metro o iba pang device. Ang mga frame ng data ng pagkumpirma at pagtugon ay ipinapadala gamit ang address ng pinagmulang device. - CI-Field
Ang CI-field ay ang application header at tinutukoy ang uri ng data sa payload ng data ng application. Habang ang EN13757-4:2005 ay tumutukoy ng limitadong bilang ng mga halaga, ang Link Service Primitives ay magpapahintulot sa anumang halaga na magamit. - CRC
Ang CRC ay tinukoy sa EN13757-4:2005.
Ang CRC Polynomial ay:
X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
Tandaan na ang M-Bus CRC ay kinakalkula sa bawat 16-byte na bloke. Ang resulta ay ang bawat 16 bytes ng data ay nangangailangan ng 18 bytes na maipadala,
Karagdagang Impormasyon
Para sa karagdagang impormasyon tungkol sa Pagpapatupad ng Link Layer, tingnan ang "AN452: Wireless M-Bus Stack Programmers Guide".
Pamamahala ng Kapangyarihan
Ipinapakita ng Figure 2 ang timeline ng pamamahala ng kuryente para sa isang metro halampgamit ang Mode T1.
Ang MCU ay dapat nasa Sleep mode hangga't maaari upang makatipid ng enerhiya. Sa ex na itoample, ang MCU ay natutulog kapag ang RTC ay tumatakbo, kapag naghihintay sa radio crystal start-up, at kapag nagpapadala mula sa FIFO. Magigising ang MCU mula sa EZRadioPRO IRQ signal na konektado sa isang Port Match wake-up.
Kapag nagpapadala ng mga mensahe na mas mahaba kaysa sa isang bloke, ang MCU ay dapat gumising upang punan ang FIFO (batay sa FIFO na halos walang laman na interrupt) at pagkatapos ay bumalik sa pagtulog.
Ang MCU ay dapat nasa Idle mode na tumatakbo mula sa low power oscillator o burst-mode oscillator kapag nagbabasa mula sa ADC. Ang ADC ay nangangailangan ng SAR na orasan.
Kapag hindi ginagamit, ang EZRadioPRO ay dapat nasa Shutdown mode na mataas ang SDN pin. Nangangailangan ito ng hardwired na koneksyon sa MCU. Ang mga rehistro ng EZ Radio Pro ay hindi pinapanatili sa shutdown mode; kaya, ang EZRadioPro ay sinisimulan sa bawat pagitan ng RTC. Ang pagsisimula ng Radyo ay tumatagal ng mas mababa sa 100 µs at nagtitipid ng 400 nA. Nagreresulta ito sa 10 µJ na pagtitipid ng enerhiya, batay sa 10 segundong pagitan.
Ang EZRadioPRO crystal ay tumatagal ng humigit-kumulang 16 ms para sa isang POR. Sapat na ang haba nito para kalkulahin ang CRC para sa humigit-kumulang walong bloke. Matutulog na muli ang MCU kung makukumpleto nito ang lahat ng CRC bago pa maging matatag ang kristal. Kung kinakailangan ang pag-encrypt, maaari din itong simulan habang naghihintay sa crystal oscillator.
Dapat tumakbo ang MCU sa 20 MHz gamit ang low-power oscillator para sa karamihan ng mga gawain. Ang mga gawaing nangangailangan ng tumpak na timeout ay dapat gumamit ng precision oscillator at idle mode sa halip na sleep mode. Ang RTC ay nagbibigay ng sapat na resolusyon para sa karamihan ng mga gawain. Ang timeline ng pamamahala ng kuryente para sa T2 meter halampAng application ay ipinapakita sa Figure 3.
Ang pagpapatupad ng transceiver ay dapat na ma-optimize para sa normal na kaso kapag ang metro ay nagising at walang reader. Ang minimum/maximum na mga timeout ng ACK ay sapat na mahaba upang posibleng gamitin ang C8051F930 RTC at ilagay ang MCU sa sleep mode.
Ang mga opsyon sa pagbuo ay ibinibigay para sa mga mains o USB-powered reader na hindi kailangang gumamit ng sleep mode. Gagamitin ang idle mode sa halip na sleep para maantala ng USB at UART ang MCU.
Simplicity Studio
Isang-click na access sa MCU at mga wireless na tool, dokumentasyon, software, source code library at higit pa. Magagamit para sa Windows,
Mac at Linux!
 |
 |
 |
 |
| Portfolio ng IoT www.silabs.com/IoT |
SW/HW www.silabs.com/simplicity |
Kalidad www.silabs.com/quality |
Suporta at Komunidad community.silabs.com |
Disclaimer
Nilalayon ng Silicon Labs na magbigay sa mga customer ng pinakabago, tumpak, at malalim na dokumentasyon ng lahat ng peripheral at module na available para sa mga nagpapatupad ng system at software na gumagamit o nagbabalak na gamitin ang mga produkto ng Silicon Labs. Ang data ng characterization, magagamit na mga module at peripheral, mga laki ng memorya at mga address ng memorya ay tumutukoy sa bawat partikular na device, at ang "Karaniwang" mga parameter na ibinigay ay maaaring mag-iba sa iba't ibang mga application. Aplikasyon halampAng mga inilarawan dito ay para sa mga layuning panglarawan lamang. Inilalaan ng Silicon Labs ang karapatang gumawa ng mga pagbabago nang walang karagdagang abiso at limitasyon sa impormasyon ng produkto, mga detalye, at mga paglalarawan dito, at hindi nagbibigay ng mga garantiya tungkol sa katumpakan o pagkakumpleto ng kasamang impormasyon. Ang Silicon Labs ay walang pananagutan para sa mga kahihinatnan ng paggamit ng impormasyong ibinigay dito. Ang dokumentong ito ay hindi nagpapahiwatig o nagpapahayag ng mga lisensya sa copyright na ipinagkaloob sa ilalim nito upang magdisenyo o gumawa ng anumang integrated circuit. Ang mga produkto ay hindi idinisenyo o pinahintulutan na gamitin sa loob ng anumang Life Support System nang walang partikular na nakasulat na pahintulot ng Silicon Labs. Ang “Life Support System” ay anumang produkto o sistema na nilalayon upang suportahan o mapanatili ang buhay at/o kalusugan, na, kung ito ay mabigo, maaaring makatuwirang asahan na magreresulta sa malaking personal na pinsala o kamatayan. Ang mga produkto ng Silicon Labs ay hindi idinisenyo o pinahintulutan para sa mga aplikasyong militar. Ang mga produkto ng Silicon Labs ay hindi dapat gamitin sa anumang pagkakataon sa mga sandata ng malawakang pagsira kabilang ang (ngunit hindi limitado sa) mga sandatang nuklear, biyolohikal, o kemikal, o mga missile na may kakayahang maghatid ng mga naturang armas.
Impormasyon sa Trademark
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs®, at ang Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, Energy Micro logo at mga kumbinasyon nito, "pinaka-enerhiya na microcontroller sa mundo", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, Telegesis Logo®, USBXpress®, at iba pa ay mga trademark o rehistradong trademark ng Silicon Labs. Ang ARM, CORTEX, Cortex-M3, at thumbs ay mga trademark o rehistradong trademark ng ARM Holdings. Ang Keil ay isang rehistradong trademark ng ARM Limited. Ang lahat ng iba pang produkto o pangalan ng tatak na binanggit dito ay mga trademark ng kani-kanilang mga may hawak.
Silicon Laboratories Inc.
400 Kanlurang Cesar Chavez
Austin, TX 78701
USA
http://www.silabs.com
Mga Dokumento / Mga Mapagkukunan
 |
SILICON LABS Wireless M-BUS Software Implementation AN451 [pdf] Gabay sa Gumagamit SILICON LABS, C8051, MCU, at, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Pagpapatupad, AN451 |
