AN451
ការអនុវត្តកម្មវិធី M-BUS ឥតខ្សែ
សេចក្តីផ្តើម
កំណត់ចំណាំកម្មវិធីនេះពិពណ៌នាអំពីការអនុវត្ត Silicon Labs នៃ Wireless M-Bus ដោយប្រើ Silicon Labs C8051 MCU និង EZRadioPRO®។ Wireless M-bus គឺជាស្តង់ដារអ៊ឺរ៉ុបសម្រាប់កម្មវិធីអានម៉ែត្រដោយប្រើប្រេកង់ 868 MHz ។
ស្រទាប់ជង់
Wireless M-Bus ប្រើគំរូ IEC 3-layer ដែលជាសំណុំរងនៃម៉ូដែល OSI 7-layer (សូមមើលរូបភាពទី 1)។
ស្រទាប់រូបវិទ្យា (PHY) ត្រូវបានកំណត់នៅក្នុង EN 13757-4 ។ ស្រទាប់រាងកាយកំណត់ពីរបៀបដែលប៊ីតត្រូវបានអ៊ិនកូដ និងបញ្ជូន លក្ខណៈម៉ូដឹម RF (អត្រាបន្ទះឈីប បុព្វបទ និងពាក្យធ្វើសមកាលកម្ម) និងប៉ារ៉ាម៉ែត្រ RF (ម៉ូឌុល ប្រេកង់កណ្តាល និងគម្លាតប្រេកង់)។
ស្រទាប់ PHY ត្រូវបានអនុវត្តដោយប្រើការរួមបញ្ចូលគ្នានៃផ្នែករឹង និងកម្មវិធីបង្កប់។ EZRadioPRO អនុវត្តមុខងារ RF និងម៉ូដឹមទាំងអស់។ EZRadioPRO ត្រូវបានប្រើក្នុងរបៀប FIFO ជាមួយនឹងឧបករណ៍ដោះស្រាយកញ្ចប់ព័ត៌មាន។ ម៉ូឌុល MbusPhy.c ផ្តល់នូវចំណុចប្រទាក់ SPI ការអ៊ិនកូដ/ឌិកូដ ទប់ស្កាត់ការអាន/សរសេរ និងការចាត់ចែងកញ្ចប់ព័ត៌មាន និងគ្រប់គ្រងស្ថានភាពឧបករណ៍បញ្ជូន។
ស្រទាប់តំណទិន្នន័យ M-Bus ត្រូវបានអនុវត្តនៅក្នុងម៉ូឌុល MbusLink.c ។ ចំណុចប្រទាក់កម្មវិធីកម្មវិធី M-Bus មានមុខងារសាធារណៈដែលអាចត្រូវបានហៅចេញពីស្រទាប់កម្មវិធីនៅក្នុងខ្សែស្រឡាយមេ។ ម៉ូឌុល MbusLink ក៏អនុវត្តស្រទាប់តំណទិន្នន័យផងដែរ។ ស្រទាប់តំណទិន្នន័យនឹងធ្វើទ្រង់ទ្រាយ និងចម្លងទិន្នន័យពីកម្មវិធី TX buffer ទៅ MbusPhy TX buffer ដោយបន្ថែមបឋមកថា និង CRCs ដែលត្រូវការ។
ស្រទាប់កម្មវិធីខ្លួនវាមិនមែនជាផ្នែកនៃកម្មវិធីបង្កប់ M-bus ទេ។ ស្រទាប់កម្មវិធីកំណត់ពីរបៀបដែលទិន្នន័យជាច្រើនត្រូវបានធ្វើទ្រង់ទ្រាយសម្រាប់ការបញ្ជូន។ ម៉ែត្រភាគច្រើនត្រូវការបញ្ជូនទិន្នន័យមួយ ឬពីរប្រភេទប៉ុណ្ណោះ។ ការបន្ថែមលេខកូដមួយចំនួនធំដើម្បីផ្ទុកទិន្នន័យប្រភេទណាមួយទៅក្នុងម៉ែត្រនឹងបន្ថែមលេខកូដដែលមិនចាំបាច់ និងថ្លៃដើមដល់ម៉ែត្រ។ វាអាចមានលទ្ធភាពអនុវត្តបណ្ណាល័យ ឬបឋមកថា file ជាមួយនឹងបញ្ជីពេញលេញនៃប្រភេទទិន្នន័យ។ ទោះជាយ៉ាងណាក៏ដោយ អតិថិជនក្នុងការវាស់ស្ទង់ភាគច្រើនដឹងច្បាស់អំពីប្រភេទទិន្នន័យដែលពួកគេត្រូវការដើម្បីបញ្ជូន និងអាចយោងទៅលើស្តង់ដារសម្រាប់ព័ត៌មានលម្អិតនៃទម្រង់។ អ្នកអានជាសកល ឬ sniffer អាចអនុវត្តសំណុំពេញលេញនៃប្រភេទទិន្នន័យកម្មវិធីនៅលើ PC GUI ។ សម្រាប់ហេតុផលទាំងនេះ ស្រទាប់កម្មវិធីត្រូវបានអនុវត្តដោយប្រើ example កម្មវិធីសម្រាប់ម៉ែត្រនិងអ្នកអាន។
តម្រូវការស្តង់ដារ
- EN 13757-4
EN 13757-4
ប្រព័ន្ធទំនាក់ទំនងសម្រាប់ម៉ែត្រ និងការអានម៉ែត្រពីចម្ងាយ
ផ្នែកទី 4: ការអានម៉ែត្រឥតខ្សែ
ការអានវិទ្យុទាក់ទងសម្រាប់ប្រតិបត្តិការនៅក្នុងក្រុមតន្រ្តី SRD 868 MHz ទៅ 870 MHz - EN 13757-3
ប្រព័ន្ធទំនាក់ទំនងសម្រាប់ម៉ែត្រ និងការអានម៉ែត្រពីចម្ងាយ
ផ្នែកទី 3៖ ស្រទាប់កម្មវិធីពិសេស - IEC 60870-2-1:1992
ឧបករណ៍ និងប្រព័ន្ធទូរគមនាគមន៍
ផ្នែកទី 5៖ ពិធីការបញ្ជូន
ផ្នែកទី 1: ដំណើរការបញ្ជូនតំណ - IEC 60870-1-1:1990
ឧបករណ៍ និងប្រព័ន្ធទូរគមនាគមន៍
ផ្នែកទី 5៖ ពិធីការបញ្ជូន
ផ្នែកទី 1៖ ទម្រង់នៃការបញ្ជូន
និយមន័យ
- ឡានក្រុង M-M-Bus គឺជាស្តង់ដារខ្សែសម្រាប់ការអានម៉ែត្រនៅអឺរ៉ុប។
- ឥតខ្សែ M-Bus-Wireless M-Bus សម្រាប់កម្មវិធីអានម៉ែត្រនៅអឺរ៉ុប។
- ភី-Physical Layer កំណត់ពីរបៀបដែលទិន្នន័យប៊ីត និងបៃត្រូវបានអ៊ិនកូដ និងបញ្ជូន។
- API—ចំណុចប្រទាក់អ្នកសរសេរកម្មវិធីកម្មវិធី។
- តំណភ្ជាប់—Data Link Layer កំណត់ពីរបៀបដែលប្លុក និងស៊ុមត្រូវបានបញ្ជូន។
- CRC—ពិនិត្យភាពមិនស៊ីសង្វាក់គ្នានៃវដ្ត។
- FSK—ការចុចគ្រាប់ចុចប្តូរប្រេកង់។
- បន្ទះសៀគ្វី—ឯកតាតូចបំផុតនៃទិន្នន័យបញ្ជូន។ ប៊ីតទិន្នន័យមួយត្រូវបានអ៊ិនកូដជាបន្ទះសៀគ្វីច្រើន។
- ម៉ូឌុល —ប្រភពកូដ AC .c file.
ការពិពណ៌នាមុខងារ M-Bus PHY
បុព្វបទ
លំដាប់ Preamble ដែលបានបញ្ជាក់ដោយការបញ្ជាក់ M-bus គឺជាចំនួនគត់ជំនួសលេខសូន្យ និងលេខមួយ។ មួយត្រូវបានកំណត់ថាជាប្រេកង់ខ្ពស់ជាង ហើយសូន្យត្រូវបានកំណត់ថាជាប្រេកង់ទាប។
nx (01)
ជម្រើស Preamble សម្រាប់ Si443x គឺជាចំនួនគត់នៃ nibbles ដែលមានលេខជំនួស និងសូន្យ។
nx (1010)
បុព្វកថាដែលមានការនាំមុខបន្ថែមនឹងមិនមានបញ្ហាទេ ប៉ុន្តែបន្ទាប់មក ពាក្យធ្វើសមកាលកម្ម និងបន្ទុកនឹងត្រូវខុសមួយបន្តិច។
ដំណោះស្រាយគឺត្រូវបង្វែរកញ្ចប់ព័ត៌មានទាំងមូលដោយកំណត់ម៉ាស៊ីនប៊ីតនៅក្នុងការចុះឈ្មោះ Modulation Control 2 (0x71)។ វានឹងបញ្ច្រាសពាក្យបុព្វបទ ធ្វើសមកាលកម្មពាក្យ និងទិន្នន័យ TX/RX ។ ជាលទ្ធផល ទិន្នន័យគួរតែត្រូវបានដាក់បញ្ច្រាសនៅពេលសរសេរទិន្នន័យ TX ឬអានទិន្នន័យ RX ។ ដូចគ្នានេះផងដែរ ពាក្យធ្វើសមកាលកម្មត្រូវបានដាក់បញ្ច្រាសមុនពេលសរសេរទៅកាន់ Si443x Synchronization Word registers។
ពាក្យធ្វើសមកាលកម្ម
ពាក្យធ្វើសមកាលកម្មដែលតម្រូវដោយ EN-13757-4 គឺទាំង 18 បន្ទះសៀគ្វីសម្រាប់ Mode S និង Mode R ឬ 10 chips សម្រាប់ Model T ។ ពាក្យធ្វើសមកាលកម្មសម្រាប់ Si443x គឺ 1 ទៅ 4 បៃ។ ទោះយ៉ាងណាក៏ដោយ ដោយសារពាក្យធ្វើសមកាលកម្មតែងតែនាំមុខដោយបុព្វកថា ប្រាំមួយប៊ីតចុងក្រោយនៃបុព្វបទអាចចាត់ទុកថាជាផ្នែកមួយនៃពាក្យធ្វើសមកាលកម្ម។ ដូច្នេះ ពាក្យធ្វើសមកាលកម្មដំបូងត្រូវបានដាក់ដោយពាក្យដដែលៗចំនួនបីនៃសូន្យតាមពីក្រោយដោយមួយ។ ពាក្យធ្វើសមកាលកម្មត្រូវបានបំពេញបន្ថែមមុនពេលសរសេរទៅចុះឈ្មោះ Si443x ។
តារាងទី 1. ការធ្វើសមកាលកម្ម Word សម្រាប់ Mode S និង Mode R
| EN 13757-4 | 00 | 01110110 | 10010110 | គោលពីរ |
| 00 | 76 | 96 | ឆកោន | |
| បន្ទះជាមួយ (01) x 3 | 01010100 | 01110110 | 10010110 | គោលពីរ |
| 54 | 76 | 96 | ឆកោន | |
| បំពេញបន្ថែម | 10101011 | 10001001 | 01101001 | គោលពីរ |
| AB | 89 | 69 | ឆកោន |
តារាង 2. ការធ្វើសមកាលកម្មពាក្យសម្រាប់របៀប T ម៉ែត្រទៅផ្សេងទៀត។
| ធ្វើសមកាលកម្ម | ធ្វើសមកាលកម្ម | ធ្វើសមកាលកម្ម |
| ពាក្យ | ពាក្យ | ពាក្យ |
| 3 | 2 | 1 |
បញ្ជូនប្រវែងបុព្វបទ
បុព្វកថាអប្បបរមាត្រូវបានបញ្ជាក់សម្រាប់របៀបប្រតិបត្តិការបួនផ្សេងគ្នា។ វាអាចទទួលយកបានដែលមានបុព្វកថាវែងជាងការបញ្ជាក់។ ការដកបន្ទះឈីបចំនួនប្រាំមួយសម្រាប់បុព្វកថាផ្តល់ឱ្យចំនួនអប្បបរមានៃបន្ទះឈីបសម្រាប់បុព្វកថា Si443x ។ ការអនុវត្តបន្ថែម nibbles បន្ថែមចំនួនពីរនៃ preamble នៅក្នុងទម្រង់ preamble ខ្លីទាំងអស់ ដើម្បីបង្កើនការរកឃើញ preamble និងអន្តរប្រតិបត្តិការ។ បុព្វកថាអំពី របៀប S ជាមួយនឹងបុព្វកថាវែងគឺវែងណាស់; ដូច្នេះ បុព្វកថាអប្បបរមាត្រូវបានប្រើ។ ប្រវែងបុព្វកថានៅក្នុង nibbles ត្រូវបានសរសេរទៅបញ្ជីឈ្មោះ Preamble Length (0x34) ។ ការចុះឈ្មោះប្រវែងបុព្វកថាកំណត់បុព្វបទនៅពេលបញ្ជូនតែប៉ុណ្ណោះ។ ការបញ្ជាក់អប្បបរមា និងការកំណត់ប្រវែងបុព្វបទត្រូវបានសង្ខេបនៅក្នុងតារាងទី 3 ។
តារាងទី 3. ប្រវែងបញ្ជូនបុព្វបទ
| EN-13757-4 អប្បបរមា |
Si443x បុព្វបទ កំណត់ |
ធ្វើសមកាលកម្ម ពាក្យ |
សរុប | បន្ថែម | |||
| nx (01) | បន្ទះសៀគ្វី | nibbles | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | |
| របៀប S បុព្វកថាខ្លី | 15 | 30 | 8 | 32 | 6 | 38 | 8 |
| របៀប S បុព្វកថាវែង | 279 | 558 | 138 | 552 | 6 | 558 | 0 |
| របៀប T (ម៉ែត្រផ្សេងទៀត) | 19 | 38 | 10 | 40 | 6 | 46 | 8 |
| របៀប R | 39 | 78 | 20 | 80 | 6 | 86 | 8 |
បុព្វកថាអប្បបរមាសម្រាប់ការទទួលត្រូវបានកំណត់ដោយការចុះឈ្មោះ Preamble Detection Control (0x35) ។ នៅពេលទទួលភ្ញៀវ ចំនួនប៊ីតនៅក្នុងពាក្យដែលធ្វើសមកាលកម្មត្រូវតែដកចេញពីបុព្វបទអប្បបរមាដែលបានបញ្ជាក់ដើម្បីកំណត់បុព្វបទដែលអាចប្រើប្រាស់បាន។ ពេលវេលាទូទាត់អប្បបរមារបស់អ្នកទទួលគឺ 16-chips ប្រសិនបើ AFC ត្រូវបានបើក ឬ 8-chips ប្រសិនបើ AFC ត្រូវបានបិទ។ ពេលវេលាទូទាត់របស់អ្នកទទួលក៏ត្រូវបានដកចេញពីបុព្វបទដែលអាចប្រើប្រាស់បានផងដែរ ដើម្បីកំណត់ការកំណត់អប្បបរមាសម្រាប់ការចុះឈ្មោះ Preamble Detection Control។
ប្រូបាប៊ីលីតេនៃបុព្វកថាមិនពិតអាស្រ័យទៅលើការកំណត់នៃបញ្ជីឈ្មោះ Preamble Detection Control។ ការកំណត់ខ្លីនៃ 8-chips អាចបណ្តាលឱ្យមានបុព្វបទមិនពិតដែលត្រូវបានរកឃើញរៀងរាល់ពីរបីវិនាទីម្តង។ ការកំណត់ដែលបានណែនាំនៃ 20chips ធ្វើឱ្យការរកឃើញបុព្វបទមិនពិតជាព្រឹត្តិការណ៍ដែលមិនទំនង។ ប្រវែងបុព្វបទសម្រាប់ Mode R និង Mode SL គឺវែងគ្រប់គ្រាន់សម្រាប់ការកំណត់ដែលបានណែនាំឱ្យប្រើ។
មានអត្ថប្រយោជន៍តិចតួចណាស់ក្នុងការធ្វើឱ្យបុព្វបទរកឃើញយូរជាង 20 បន្ទះសៀគ្វី។
AFC ត្រូវបានបិទសម្រាប់ Model S ដែលមានបុព្វបទខ្លី និង Model T។ វាកាត់បន្ថយពេលវេលាទូទាត់របស់អ្នកទទួល និងអនុញ្ញាតឱ្យកំណត់ការរកឃើញបុព្វបទយូរជាងនេះ។ ជាមួយនឹង AFC ត្រូវបានបិទ របៀប T អាចប្រើការកំណត់ដែលបានណែនាំនៃ 20 បន្ទះសៀគ្វី។ ការកំណត់នៃ 4 nibbles ឬ 20 chips ត្រូវបានប្រើសម្រាប់ Model S ជាមួយនឹងបុព្វបទខ្លីមួយ។ នេះធ្វើឱ្យប្រូបាប៊ីលីតេនៃការរកឃើញបុព្វបទមិនពិតខ្ពស់ជាងបន្តិចសម្រាប់គំរូនេះ។
តារាងទី 4. ការរកឃើញជាមុន
| EN-13757-4 អប្បបរមា |
ធ្វើសមកាលកម្ម ពាក្យ |
អាចប្រើបាន បុព្វកថា |
ការតាំងទីលំនៅ RX | រកឃើញ នាទី |
Si443x បុព្វបទ ការកំណត់ការរកឃើញ |
|||
| nx (01) | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | បន្ទះសៀគ្វី | nibbles | បន្ទះសៀគ្វី | |
| របៀប S បុព្វកថាខ្លី | 15 | 30 | 6 | 24 | 8* | 16 | 4 | 16 |
| គំរូ S បុព្វកថាវែង | 279 | 558 | 6 | 552 | 16 | 536 | 5 | 20 |
| ម៉ូដែល T (ម៉ែត្រផ្សេងទៀត) | 19 | 38 | 6 | 32 | 8* | 24 | 5 | 20 |
| របៀប R | 39 | 78 | 6 | 72 | 16 | 56 | 5 | 20 |
| *ចំណាំ៖ AFC ត្រូវបានបិទ | ||||||||
អ្នកទទួលត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីធ្វើអន្តរកម្មជាមួយឧបករណ៍បញ្ជូនដោយប្រើបុព្វបទដែលបានបញ្ជាក់អប្បបរមា។ នេះធានាថាអ្នកទទួលនឹងធ្វើអន្តរកម្មជាមួយឧបករណ៍បញ្ជូនដែលអនុលោមតាម M-bus ។
ការបញ្ជាក់របស់ Wireless M-Bus ទាមទារបុព្វបទដ៏វែងឆ្ងាយសម្រាប់ Mode S1 យ៉ាងហោចណាស់ 558 បន្ទះឈីប។ វានឹងចំណាយពេលប្រហែល 17 ms ដើម្បីបញ្ជូនបុព្វបទ។ Si443x មិនតម្រូវឱ្យមានបុព្វកថាវែងបែបនេះទេ ហើយមិនទទួលបានអត្ថប្រយោជន៍ពីបុព្វកថាវែងនោះទេ។ ខណៈពេលដែលបុព្វកថាវែងត្រូវបានកត់សំគាល់ថាជាជម្រើសសម្រាប់ Mode S2 វាគ្មានហេតុផលដើម្បីប្រើបុព្វបទវែងជាមួយ Si443x នោះទេ។ ប្រសិនបើការប្រាស្រ័យទាក់ទងមួយផ្លូវគឺចង់បាន របៀប T1 នឹងផ្តល់នូវបុព្វបទខ្លីជាង អត្រាទិន្នន័យខ្ពស់ និងអាយុកាលថ្មយូរជាង។ ប្រសិនបើការទំនាក់ទំនងពីរផ្លូវដោយប្រើរបៀប S2 ត្រូវបានទាមទារ ការណែនាំខ្លីៗត្រូវបានណែនាំ។
សូមកត់សម្គាល់ថាកម្រិតនៃការរកឃើញសម្រាប់ម៉ូដែល S ដែលមានបុព្វកថាវែងគឺវែងជាងចំនួននៃបុព្វបទដែលបានបញ្ជូនសម្រាប់ម៉ូដែល S ជាមួយនឹងបុព្វកថាខ្លី។ នេះមានន័យថាអ្នកទទួល Mode S preamble វែងនឹងមិនរកឃើញ preamble ពី preamble Mode S transmitter ខ្លីទេ។ នេះគឺចាំបាច់ប្រសិនបើអ្នកទទួល Mode S បុព្វបទវែង ដើម្បីទទួលបានអត្ថប្រយោជន៍ណាមួយពីបុព្វកថាវែង។
ចំណាំថាអ្នកទទួលទម្រង់មុនខ្លី S នឹងរកឃើញបុព្វកថា និងទទួលកញ្ចប់ព័ត៌មានពីទាំងពីរទម្រង់មុនខ្លី
ឧបករណ៍បញ្ជូននិងឧបករណ៍បញ្ជូន Mode S នាំមុខវែង; ដូច្នេះ ជាទូទៅ អ្នកអានម៉ែត្រគួរតែប្រើការកំណត់រចនាសម្ព័ន្ធអ្នកទទួលមុខងារ Preamble Mode S ខ្លី។
ការអ៊ិនកូដ/ឌិកូដ
ការបញ្ជាក់របស់ Wireless M-bus ទាមទារវិធីសាស្ត្របំប្លែងកូដពីរផ្សេងគ្នា។ ការអ៊ិនកូដ Manchester ត្រូវបានប្រើសម្រាប់ Mode S និង Mode R។ ការអ៊ិនកូដ Manchester ក៏ប្រើសម្រាប់តំណភ្ជាប់ផ្សេងទៀតទៅម៉ែត្រក្នុង Model T។ តំណភ្ជាប់ម៉ែត្រ Model T ប្រើការអ៊ិនកូដ 3 ក្នុងចំណោម 6 ។
២.៤.១. Manchester អ៊ិនកូដ/ឌិកូដ
ការអ៊ិនកូដ Manchester គឺជារឿងធម្មតាជាប្រវត្តិសាស្ត្រនៅក្នុងប្រព័ន្ធ RF ដើម្បីផ្តល់នូវការងើបឡើងវិញ និងតាមដាននាឡិកាដ៏រឹងមាំដោយប្រើម៉ូដឹមសាមញ្ញ និងមានតំលៃថោក។ ទោះជាយ៉ាងណាក៏ដោយ វិទ្យុដែលមានប្រសិទ្ធភាពខ្ពស់ទំនើបដូចជា Si443x មិនត្រូវការការអ៊ិនកូដ Manchester ទេ។ ការអ៊ិនកូដ Manchester ត្រូវបានគាំទ្រជាចម្បងសម្រាប់ភាពឆបគ្នាជាមួយនឹងស្តង់ដារដែលមានស្រាប់ ប៉ុន្តែអត្រាទិន្នន័យសម្រាប់ Si443x ត្រូវបានកើនឡើងទ្វេដងយ៉ាងមានប្រសិទ្ធភាពនៅពេលមិនប្រើការអ៊ិនកូដ Manchester។
Si443x គាំទ្រការអ៊ិនកូដ Manchester និងការឌិកូដនៃកញ្ចប់ព័ត៌មានទាំងមូលនៅក្នុងផ្នែករឹង។ ជាអកុសល ពាក្យធ្វើសមកាលកម្មមិនត្រូវបានអ៊ិនកូដ Manchester ទេ។ លំដាប់ Manchester មិនត្រឹមត្រូវត្រូវបានជ្រើសរើសដោយចេតនាសម្រាប់ពាក្យធ្វើសមកាលកម្ម។ នេះធ្វើឱ្យការអ៊ិនកូដ Manchester មិនឆបគ្នាជាមួយវិទ្យុដែលមានស្រាប់ភាគច្រើន រួមទាំង Si443x ផងដែរ។ ជាលទ្ធផល ការអ៊ិនកូដ និងឌិកូដ Manchester ត្រូវតែធ្វើឡើងដោយ MCU ។ បៃនីមួយៗនៅលើទិន្នន័យដែលមិនបានអ៊ិនកូដមានប្រាំបីប៊ីតទិន្នន័យ។ ដោយប្រើការអ៊ិនកូដ Manchester ប៊ីតទិន្នន័យនីមួយៗត្រូវបានអ៊ិនកូដទៅជានិមិត្តសញ្ញាបន្ទះឈីបពីរ។ ដោយសារទិន្នន័យដែលបានអ៊ិនកូដត្រូវតែសរសេរទៅវិទ្យុ FIFO ប្រាំបីបន្ទះក្នុងពេលតែមួយ ទិន្នន័យមួយត្រូវបានអ៊ិនកូដ និងសរសេរទៅ FIFO ក្នុងពេលតែមួយ។
តារាងទី 5. ការអ៊ិនកូដ Manchester
| ទិន្នន័យ | អុក ១៦៥ | 0x34 | បៃ | ||
| អុក ១៦៥ | 0x2 | 0x3 | 0x4 | nibbles | |
| 1 | 10 | 11 | 100 | គោលពីរ | |
| បន្ទះសៀគ្វី | 10101001 | 10100110 | 10100101 | 10011010 | គោលពីរ |
| FIFO | OxA9 | OxA6 | OxA5 | អុក ០៧០ អេ | ឆកោន |
បៃនីមួយៗដែលត្រូវបញ្ជូនគឺត្រូវបញ្ជូនមួយបៃក្នុងពេលតែមួយទៅមុខងារអ៊ិនកូដបៃ។ មុខងារ encode byte នឹងហៅមុខងារ encode nibble ពីរដង ទីមួយសម្រាប់ nibble ដ៏សំខាន់បំផុត និងបន្ទាប់មកសម្រាប់ nibble តិចបំផុត។
ការអ៊ិនកូដ Manchester នៅក្នុងកម្មវិធីមិនពិបាកទេ។ ចាប់ផ្តើមពីប៊ីតដ៏សំខាន់បំផុត មួយត្រូវបានអ៊ិនកូដជាលំដាប់បន្ទះឈីប "01" ។ លេខសូន្យត្រូវបានអ៊ិនកូដជាលំដាប់បន្ទះឈីប "10" ។ នេះអាចសម្រេចបានយ៉ាងងាយស្រួលដោយប្រើរង្វិលជុំ និងការផ្លាស់ប្តូរពីរប៊ីតសម្រាប់និមិត្តសញ្ញានីមួយៗ។ ទោះយ៉ាងណាក៏ដោយ វាលឿនជាងក្នុងការគ្រាន់តែប្រើតារាងរកមើលធាតុ 16 សាមញ្ញសម្រាប់ nibble នីមួយៗ។ មុខងារ encode Manchester nibble បំប្លែងទិន្នន័យមួយ រួចសរសេរវាទៅ FIFO ។ បន្ទះសៀគ្វីត្រូវបានដាក់បញ្ច្រាសមុនពេលសរសេរទៅ FIFO ដើម្បីកំណត់តម្រូវការបុព្វបទដែលដាក់បញ្ច្រាស។
នៅពេលទទួល បៃនីមួយៗនៅក្នុង FIFO មានបន្ទះឈីបចំនួនប្រាំបី ហើយត្រូវបានឌិកូដទៅជាទិន្នន័យតែមួយ។ មុខងារប្លុកអានអានមួយបៃក្នុងពេលតែមួយពី FIFO ហើយហៅមុខងារឌិកូដបៃ។ បន្ទះសៀគ្វីត្រូវបានដាក់បញ្ច្រាសបន្ទាប់ពីអានពី FIFO ដើម្បីកំណត់តម្រូវការបុព្វបទដែលដាក់បញ្ច្រាស។ បៃនីមួយៗនៃបន្ទះឈីបដែលបានអ៊ិនកូដ Manchester ត្រូវបានឌិកូដទៅជាទិន្នន័យ។ nibble ដែលបានឌិកូដត្រូវបានសរសេរទៅសតិបណ្ដោះអាសន្ន RX ដោយប្រើមុខងារ write nibble RX buffer។
សូមកត់សម្គាល់ថាទាំងការបំប្លែងកូដ និងការឌិកូដត្រូវបានធ្វើការចាប់យកទិន្នន័យមួយក្នុងពេលតែមួយ។ ការអ៊ិនកូដទៅសតិបណ្ដោះអាសន្ននឹងតម្រូវឱ្យមានសតិបណ្ដោះអាសន្នបន្ថែម 100 ដងនៃទំហំទិន្នន័យដែលមិនបានអ៊ិនកូដ។ ការអ៊ិនកូដ និងការឌិកូដគឺលឿនជាងអត្រាទិន្នន័យដែលគាំទ្រលឿនបំផុត (443 k chips ក្នុងមួយវិនាទី)។ ដោយសារ Si10x គាំទ្រការអាន និងសរសេរច្រើនបៃទៅ FIFO វាមានចំណុចសំខាន់តូចមួយក្នុងការប្រើការអាន និងសរសេរតែមួយបៃប៉ុណ្ណោះ។ តម្លៃលើសគឺប្រហែល 100 µs សម្រាប់ 512 បន្ទះសៀគ្វីដែលបានអ៊ិនកូដ។ អត្ថប្រយោជន៍គឺការសន្សំ RAM ចំនួន XNUMX បៃ។
២.៤.២. បីចេញពីប្រាំមួយ អ៊ិនកូដឌិកូដ
វិធីសាស្ត្របំប្លែងកូដបីចេញពីប្រាំមួយ ដែលបានបញ្ជាក់នៅក្នុង EN-13757-4 ក៏ត្រូវបានអនុវត្តនៅក្នុងកម្មវិធីបង្កប់នៅលើ MCU ផងដែរ។ ការបំប្លែងកូដនេះត្រូវបានប្រើសម្រាប់ល្បឿនលឿន (100 k chips ក្នុងមួយវិនាទី) Mode T ពីម៉ែត្រទៅផ្សេង។ ម៉ូដែល T ផ្តល់នូវរយៈពេលបញ្ជូនខ្លីបំផុត និងអាយុកាលថ្មវែងបំផុតសម្រាប់ម៉ែត្រឥតខ្សែ។
បៃនីមួយៗនៃទិន្នន័យដែលត្រូវបញ្ជូនត្រូវបែងចែកជាពីរ nibbles ។ nibble ដ៏សំខាន់បំផុតគឺត្រូវបានអ៊ិនកូដ និងបញ្ជូនមុន។ ជាថ្មីម្តងទៀត វាត្រូវបានអនុវត្តដោយប្រើមុខងារ encode byte ដែលហៅមុខងារ encode nibble ពីរដង។
ទិន្នន័យនីមួយៗត្រូវបានអ៊ិនកូដទៅជានិមិត្តសញ្ញាប្រាំមួយឈីប។ លំដាប់នៃនិមិត្តសញ្ញាប្រាំមួយឈីបត្រូវតែសរសេរទៅ 8chip FIFO ។
កំឡុងពេលអ៊ិនកូដ ទិន្នន័យពីរបៃត្រូវបានអ៊ិនកូដជាបួន nibbles ។ នីបនីមួយៗគឺជានិមិត្តសញ្ញា 6 បន្ទះ។ និមិត្តសញ្ញា 6chip ចំនួនបួនត្រូវបានបញ្ចូលគ្នាជាបីបៃ។
តារាងទី 6. ការអ៊ិនកូដបីក្នុងចំណោមប្រាំមួយ។
| ទិន្នន័យ | 0x12 | 0x34 | បៃ | ||||
| អុក ១៦៥ | 0x2 | 0x3 | 0x4 | nibbles | |||
| បន្ទះសៀគ្វី | 15 | 16 | 13 | 34 | ប្រាំបី | ||
| 1101 | 1110 | 1011 | 11100 | គោលពីរ | |||
| FIFO | 110100 | 11100010 | 11011100 | គោលពីរ | |||
| 0x34 | OxE2 | អុកឌីស៊ី | ឆកោន | ||||
នៅក្នុងសូហ្វវែរ ការអ៊ិនកូដ 16 ចេញពីប្រាំមួយត្រូវបានអនុវត្តដោយប្រើមុខងារដាក់បី។ មុខងារ encode byte នឹងហៅមុខងារ encode nibble ពីរដង។ មុខងារ encode nibble ប្រើតារាងរកមើលសម្រាប់និមិត្តសញ្ញាប្រាំមួយឈីប ហើយសរសេរនិមិត្តសញ្ញាទៅ Shift Three out of Six functions។ មុខងារនេះអនុវត្តការចុះឈ្មោះផ្លាស់ប្តូរបន្ទះឈីប XNUMX នៅក្នុងកម្មវិធី។ និមិត្តសញ្ញាត្រូវបានសរសេរទៅបៃដ៏សំខាន់តិចបំផុតនៃការចុះឈ្មោះប្តូរ។ ការចុះឈ្មោះត្រូវបានប្តូរទៅខាងឆ្វេងពីរដង។ នេះត្រូវបានធ្វើម្តងទៀតបីដង។ នៅពេលដែលបៃពេញលេញមានវត្តមាននៅក្នុងបៃខាងលើនៃការចុះឈ្មោះការផ្លាស់ប្តូរ វាត្រូវបានដាក់បញ្ច្រាស និងសរសេរទៅ FIFO ។
ដោយសារបៃនៃទិន្នន័យនីមួយៗត្រូវបានអ៊ិនកូដជាបៃដែលបានអ៊ិនកូដមួយនិងកន្លះ នោះវាមានសារៈសំខាន់ណាស់ក្នុងការសម្អាតការផ្លាស់ប្តូរការចុះឈ្មោះជាមុនសិន ដើម្បីឱ្យបៃដែលបានអ៊ិនកូដដំបូងត្រឹមត្រូវ។ ប្រសិនបើប្រវែងកញ្ចប់ព័ត៌មានជាលេខសេស បន្ទាប់ពីអ៊ិនកូដបៃទាំងអស់ វានឹងនៅតែមានលេខមួយដែលនៅសល់ក្នុងការចុះឈ្មោះការផ្លាស់ប្តូរ។ នេះត្រូវបានដោះស្រាយជាមួយនឹង postamble ដូចដែលបានពន្យល់នៅក្នុងផ្នែកបន្ទាប់។
ការឌិកូដបីក្នុងចំណោមប្រាំមួយដែលបានអ៊ិនកូដគឺជានីតិវិធីបញ្ច្រាស។ នៅពេលឌិកូដ បៃដែលបានអ៊ិនកូដបីត្រូវបានឌិកូដទៅជាបៃទិន្នន័យពីរ។ ការចុះឈ្មោះការផ្លាស់ប្តូរកម្មវិធីត្រូវបានប្រើម្តងទៀតដើម្បីប្រមូលផ្តុំបៃនៃទិន្នន័យដែលបានឌិកូដ។ តារាងរកមើលបញ្ច្រាស 64 ត្រូវបានប្រើសម្រាប់ការឌិកូដ។ វាប្រើវដ្តតិចជាង ប៉ុន្តែអង្គចងចាំកូដកាន់តែច្រើន។ ការស្វែងរកតារាងរកមើលធាតុ 16 សម្រាប់និមិត្តសញ្ញាដែលត្រូវគ្នាត្រូវចំណាយពេលយូរជាង។
ប្រៃសណីយ៍
លក្ខណៈបច្ចេកទេសនៃរថយន្តក្រុងឥតខ្សែ M-bus មានតម្រូវការជាក់លាក់សម្រាប់ postamble ឬ trailer ។ សម្រាប់គ្រប់ម៉ូដទាំងអស់ អប្បបរមាគឺពីរបន្ទះ ហើយអតិបរមាគឺប្រាំបីបន្ទះ។ ដោយសារឯកតាអាតូមតិចបំផុតសម្រាប់ FIFO គឺមួយបៃ ឈុតខ្លីៗ 8-chip ត្រូវបានប្រើសម្រាប់ Mode S និង Mode R ។ Mode T postamble គឺប្រាំបីបន្ទះសៀគ្វី ប្រសិនបើប្រវែងកញ្ចប់គឺសូម្បីតែ ឬបួនបន្ទះ ប្រសិនបើប្រវែងកញ្ចប់គឺសេស។ បន្ទះសៀគ្វីបួនបន្ទះសម្រាប់ប្រវែងកញ្ចប់សេស បំពេញតាមតម្រូវការនៃការមានបន្ទះសៀគ្វីឆ្លាស់គ្នាយ៉ាងហោចណាស់ពីរ។
តារាង 7. ប្រវែង Postamble
| ប្រវែង Postamble (បន្ទះសៀគ្វី) | |||||
| នាទី | អតិបរមា | ការអនុវត្ត | លំដាប់បន្ទះឈីប | ||
| របៀប S | 2 | 8 | 8 | 1010101 | |
| របៀប T | 2 | 8 | 4 | (សេស) | 101 |
| 8 | (គូ) | 1010101 | |||
| របៀប R | 2 | 8 | 8 | 1010101 | |
កម្មវិធីគ្រប់គ្រងកញ្ចប់
ឧបករណ៍ដោះស្រាយកញ្ចប់ព័ត៌មាននៅលើ Si443x អាចត្រូវបានប្រើនៅក្នុងរបៀបទទឹងកញ្ចប់អថេរ ឬរបៀបទទឹងកញ្ចប់ព័ត៌មានថេរ។ របៀបទទឹងកញ្ចប់អថេរតម្រូវឱ្យមានបៃប្រវែងកញ្ចប់បន្ទាប់ពីពាក្យធ្វើសមកាលកម្ម និងបៃបឋមកថាស្រេចចិត្ត។ នៅពេលទទួល វិទ្យុនឹងប្រើបៃប្រវែងដើម្បីកំណត់ចុងបញ្ចប់នៃកញ្ចប់ព័ត៌មានត្រឹមត្រូវ។ នៅពេលបញ្ជូន វិទ្យុនឹងបញ្ចូលវាលប្រវែងបន្ទាប់ពីបៃបឋមកថា។
វាល L សម្រាប់ពិធីការ M-bus ឥតខ្សែមិនអាចប្រើសម្រាប់វាលប្រវែង Si443x បានទេ។ ទីមួយ វាល L មិនមែនជាប្រវែងកញ្ចប់ព័ត៌មានពិតប្រាកដទេ។ វាគឺជាចំនួននៃបៃនៃការផ្ទុកស្រទាប់តំណដែលមិនរាប់បញ្ចូលបៃបៃ CRC ឬការអ៊ិនកូដ។ ទីពីរ L -field ខ្លួនវាត្រូវបានអ៊ិនកូដដោយប្រើការអ៊ិនកូដ Manchester ឬការអ៊ិនកូដបីចេញពីប្រាំមួយសម្រាប់ Mode T ម៉ែត្រទៅផ្សេងទៀត។
ការអនុវត្តប្រើឧបករណ៍ដោះស្រាយកញ្ចប់ព័ត៌មានក្នុងទម្រង់ទទឹងកញ្ចប់ព័ត៌មានថេរសម្រាប់ទាំងការបញ្ជូន និងការទទួល។ នៅពេលបញ្ជូន ស្រទាប់ PHY នឹងអានវាល L នៅក្នុងសតិបណ្ដោះអាសន្នបញ្ជូន និងគណនាចំនួនបៃដែលបានអ៊ិនកូដ រួមទាំងប្រៃសណីយ៍។ ចំនួនសរុបនៃបៃដែលបានអ៊ិនកូដដែលត្រូវបញ្ជូនគឺត្រូវបានសរសេរទៅចុះឈ្មោះប្រវែងកញ្ចប់ (0x3E)។
នៅពេលទទួល បៃដែលបានអ៊ិនកូដពីរដំបូងត្រូវបានឌិកូដ ហើយវាល L ត្រូវបានសរសេរទៅសតិបណ្ដោះអាសន្នទទួល។ វាល L ត្រូវបានប្រើដើម្បីគណនាចំនួនបៃដែលបានអ៊ិនកូដដែលត្រូវទទួល។ បន្ទាប់មកចំនួននៃបៃដែលបានអ៊ិនកូដដែលត្រូវទទួលត្រូវបានសរសេរទៅចុះឈ្មោះប្រវែងកញ្ចប់ (0x3E)។ ប្រៃសណីយ៍ត្រូវបានបោះចោល។
MCU ត្រូវតែឌិកូដវាល L គណនាចំនួនបៃដែលបានអ៊ិនកូដ ហើយសរសេរតម្លៃទៅបញ្ជីប្រវែងកញ្ចប់មុនពេលទទួលបានប្រវែងកញ្ចប់ខ្លីបំផុត។ វាល L ខ្លីបំផុតដែលអាចអនុញ្ញាតបានសម្រាប់ស្រទាប់ PHY គឺ 9 ដោយផ្តល់ឱ្យ 12 បៃដែលមិនបានអ៊ិនកូដ។ វាផ្តល់ឱ្យ 18 បៃដែលបានអ៊ិនកូដសម្រាប់គំរូ T ។ ពីរបៃដំបូងត្រូវបានឌិកូដរួចហើយ។ ដូច្នេះ ការចុះឈ្មោះប្រវែងកញ្ចប់ព័ត៌មានត្រូវតែធ្វើបច្ចុប្បន្នភាពជា 16-byte ដងក្នុងល្បឿន 100 kbps ឬ 1.28 មិល្លីវិនាទី។ នេះមិនមែនជាបញ្ហាទេសម្រាប់ 8051 ដែលដំណើរការនៅ 20 MIPS ។
ចំនួនបៃដែលត្រូវទទួលមិនរាប់បញ្ចូលទាំងប្រៃសណីយ៍ទេ លើកលែងតែប្រៃសណីយ៍បន្ទះឈីបបួនដែលប្រើសម្រាប់កញ្ចប់ព័ត៌មាន Mode T ដែលមានប្រវែងកញ្ចប់សេស។ ដូច្នេះ អ្នកទទួលមិនទាមទារសំបុត្រទេ លើកលែងតែកញ្ចប់ប្រវែងសេស Model T Postamble នេះគឺត្រូវការតែដើម្បីផ្តល់ចំនួនគត់នៃបៃដែលបានអ៊ិនកូដប៉ុណ្ណោះ។ ខ្លឹមសារនៃប្រៃសណីយ៍មិនត្រូវបានអើពើ; ដូច្នេះ ប្រសិនបើការប្រៃសណីយ៍មិនត្រូវបានបញ្ជូនទេ សំឡេងរំខានចំនួនបួននឹងត្រូវបានទទួល និងមិនអើពើ។ ដោយសារចំនួនសរុបនៃបៃដែលបានអ៊ិនកូដត្រូវបានកំណត់ត្រឹម 255 (0xFF) ការអនុវត្តកំណត់វាល L អតិបរមាសម្រាប់របៀបផ្សេងៗគ្នា។
តារាង 8. ដែនកំណត់ទំហំកញ្ចប់
| បានអ៊ិនកូដ | ឌិកូដ | M-Bus | ||||
| បៃ | បៃ | L-វាល | ||||
| ធ្នូ | ឆកោន | ធ្នូ | ឆកោន | ធ្នូ | ឆកោន | |
| របៀប S | 255 | FF | 127 | 7 អេហ្វ | 110 | 6E |
| របៀប T (ម៉ែត្រផ្សេងទៀត) | 255 | FF | 169 | A9 | 148 | 94 |
| របៀប R | 255 | FF | 127 | 7 អេហ្វ | 110 | 6E |
ដែនកំណត់ទាំងនេះជាធម្មតាលើសពីករណីប្រើប្រាស់ធម្មតាសម្រាប់ម៉ែត្រឥតខ្សែ។ ប្រវែងកញ្ចប់ព័ត៌មានគួររក្សាទុកឱ្យតូច ដើម្បីទទួលបានអាយុកាលថ្មល្អបំផុត។
លើសពីនេះ អ្នកប្រើប្រាស់អាចបញ្ជាក់វាលអតិបរិមា L ដែលគួរតែត្រូវបានទទួល (USER_RX_MAX_L_FIELD)។ វាកំណត់ទំហំដែលត្រូវការសម្រាប់សតិបណ្ដោះអាសន្នទទួល (USER_RX_BUFFER_SIZE)។
ការគាំទ្រវាល L-អតិបរិមានៃ 255 នឹងតម្រូវឱ្យមានសតិបណ្ដោះអាសន្នទទួល 290 បៃ និងអតិបរមា 581 បៃដែលបានអ៊ិនកូដ Manchester ។ ឧបករណ៍ដោះស្រាយកញ្ចប់ព័ត៌មាននឹងត្រូវបិទ ហើយការចុះឈ្មោះប្រវែងកញ្ចប់មិនអាចប្រើនៅក្នុងករណីនោះ។ នេះអាចទៅរួច ប៉ុន្តែវាកាន់តែងាយស្រួលប្រើឧបករណ៍ដោះស្រាយកញ្ចប់ ប្រសិនបើអាចធ្វើទៅបាន។
ការប្រើប្រាស់ FIFO
Si4431 ផ្តល់ 64 បៃ FIFO សម្រាប់បញ្ជូន និងទទួល។ ដោយសារចំនួននៃបៃដែលបានអ៊ិនកូដគឺ 255 នោះកញ្ចប់ដែលបានអ៊ិនកូដទាំងមូលប្រហែលជាមិនសមនៅក្នុងសតិបណ្ដោះអាសន្ន 64 បៃទេ។
ការឆ្លង
នៅលើការបញ្ជូន ចំនួនសរុបនៃបៃដែលបានអ៊ិនកូដត្រូវបានគណនា។ ប្រសិនបើចំនួនសរុបនៃបៃដែលបានអ៊ិនកូដ រួមទាំងសំបុត្រប្រៃសណីយ៍មានតិចជាង 64 បៃ នោះកញ្ចប់ព័ត៌មានទាំងមូលត្រូវបានសរសេរទៅ FIFO ហើយមានតែកញ្ចប់ព័ត៌មានដែលបានផ្ញើការរំខានប៉ុណ្ណោះដែលត្រូវបានបើក។ កញ្ចប់ខ្លីៗភាគច្រើននឹងត្រូវបានផ្ញើនៅក្នុងការផ្ទេរ FIFO មួយ។
ប្រសិនបើចំនួនបៃដែលបានអ៊ិនកូដធំជាង 64 ការផ្ទេរ FIFO ច្រើននឹងត្រូវបានទាមទារដើម្បីផ្ញើកញ្ចប់ព័ត៌មាន។ 64 បៃដំបូងត្រូវបានសរសេរទៅ FIFO ។ កញ្ចប់ដែលបានផ្ញើ និង TX FIFO ការរំខានស្ទើរតែទទេត្រូវបានបើកដំណើរការ។ TX FIFO ស្ទើរតែទទេត្រូវបានកំណត់ទៅ 16 បៃ (25%) ។ នៅពេលព្រឹត្តិការណ៍ IRQ នីមួយៗ ការចុះឈ្មោះស្ថានភាព 2 ត្រូវបានអាន។ កញ្ចប់ដែលបានផ្ញើត្រូវបានពិនិត្យជាមុន ហើយប្រសិនបើកញ្ចប់ព័ត៌មានមិនត្រូវបានផ្ញើទាំងស្រុងទេ ទិន្នន័យដែលបានអ៊ិនកូដចំនួន 48 បៃបន្ទាប់ត្រូវបានសរសេរទៅ FIFO ។ វាបន្តរហូតដល់បៃដែលបានអ៊ិនកូដទាំងអស់ត្រូវបានសរសេរ ហើយការរំខានកញ្ចប់ដែលបានផ្ញើកើតឡើង។
២០.៤. ទទួលភ្ញៀវ
នៅលើការទទួលដំបូង មានតែការរំខាន Sync Word ប៉ុណ្ណោះដែលត្រូវបានបើក។ បន្ទាប់ពីទទួលបានពាក្យធ្វើសមកាលកម្ម ការរំខានពាក្យសមកាលកម្មត្រូវបានបិទ ហើយការរំខាន FIFO ស្ទើរតែពេញលេញត្រូវបានបើក។ FIFO ស្ទើរតែពេញកម្រិតដំបូងត្រូវបានកំណត់ទៅ 2 បៃ។ ការរំខាន FIFO ស្ទើរតែពេញលេញត្រូវបានប្រើដើម្បីដឹងថាតើពេលណាបានទទួលបានបៃប្រវែងពីរ។ នៅពេលដែលប្រវែងត្រូវបានទទួល ប្រវែងត្រូវបានឌិកូដ ហើយចំនួនបៃដែលបានអ៊ិនកូដត្រូវបានគណនា។ បន្ទាប់មក RX FIFO ស្ទើរតែពេញកម្រិតត្រូវបានកំណត់ទៅ 48 បៃ។ RX FIFO ស្ទើរតែពេញ ហើយការរំខានកញ្ចប់ព័ត៌មានត្រឹមត្រូវត្រូវបានបើក។ នៅពេលព្រឹត្តិការណ៍ IRQ បន្ទាប់ ការចុះឈ្មោះស្ថានភាព 1 ត្រូវបានអាន។ ដំបូង ប៊ីតកញ្ចប់ព័ត៌មានត្រឹមត្រូវត្រូវបានពិនិត្យ ហើយបន្ទាប់មក FIFO ស្ទើរតែពេញប៊ីតត្រូវបានធីក។ ប្រសិនបើមានតែ RX FIFO ស្ទើរតែពេញលេញត្រូវបានកំណត់ 48 បៃបន្ទាប់ត្រូវបានអានពី FIFO ។ ប្រសិនបើកញ្ចប់ព័ត៌មានត្រឹមត្រូវត្រូវបានកំណត់ កញ្ចប់ព័ត៌មានដែលនៅសល់ត្រូវបានអានពី FIFO ។ MCU តាមដានចំនួនបៃដែលត្រូវបានអាន ហើយឈប់អានបន្ទាប់ពីបៃចុងក្រោយ។
ស្រទាប់តំណទិន្នន័យ
ម៉ូឌុលស្រទាប់តំណទិន្នន័យអនុវត្តស្រទាប់តំណអនុលោមតាម 13757-4: 2005 ។ ស្រទាប់តំណទិន្នន័យ (LINK) ផ្តល់នូវចំណុចប្រទាក់រវាងស្រទាប់រូបវន្ត (PHY) និងស្រទាប់កម្មវិធី (AL)។
Data Link Layer អនុវត្តមុខងារដូចខាងក្រោមៈ
- ផ្តល់មុខងារដែលផ្ទេរទិន្នន័យរវាង PHY និង AL
- បង្កើត CRCs សម្រាប់សារចេញ
- រកឃើញកំហុស CRC នៅក្នុងសារចូល
- ផ្តល់អាសយដ្ឋានជាក់ស្តែង
- ទទួលស្គាល់ការផ្ទេរសម្រាប់របៀបទំនាក់ទំនងទ្វេទិស
- ស៊ុមទិន្នន័យប៊ីត
- រកឃើញកំហុសក្នុងស៊ុមក្នុងសារចូល
ភ្ជាប់ទម្រង់ស៊ុមស្រទាប់
ទម្រង់ស៊ុម Wireless M-Bus ដែលប្រើក្នុង EN 13757-4:2005 គឺបានមកពីទម្រង់ស៊ុម FT3 (Frame Type 3) ពី IEC60870-5-2។ ស៊ុមមានប្លុកទិន្នន័យមួយ ឬច្រើន។ ប្លុកនីមួយៗរួមបញ្ចូលវាល CRC 16 ប៊ីត។ ប្លុកទីមួយគឺជាប្លុកប្រវែងថេរនៃ 12 បៃ ដែលរួមមាន L-field, C-field, M-field និង A-Field។
- L-វាល
វាល L គឺជាប្រវែងនៃបន្ទុកទិន្នន័យស្រទាប់តំណ។ នេះមិនរាប់បញ្ចូលវាល L-field ខ្លួនវាផ្ទាល់ ឬ CRC បៃណាមួយឡើយ។ វារួមបញ្ចូល L-field, C-field, M-field និង A-Field ។ ទាំងនេះគឺជាផ្នែកនៃ PHY payload ។
ដោយសារតែចំនួនបៃដែលបានអ៊ិនកូដត្រូវបានកំណត់ត្រឹម 255 បៃ តម្លៃដែលគាំទ្រអតិបរមាសម្រាប់ M-field គឺ 110 បៃសម្រាប់ទិន្នន័យដែលបានអ៊ិនកូដ Manchester និង 148 បៃសម្រាប់ទិន្នន័យដែលបានអ៊ិនកូដ Mode T Three-Out-of-Six ។
ស្រទាប់តំណភ្ជាប់គឺទទួលខុសត្រូវក្នុងការគណនា L-field នៅលើការបញ្ជូន។ ស្រទាប់តំណនឹងប្រើវាល L នៅលើការទទួល។
ចំណាំ វាល L មិនបង្ហាញពីប្រវែងផ្ទុក PHY ឬចំនួនបៃដែលបានអ៊ិនកូដទេ។ នៅពេលបញ្ជូន PHY នឹងគណនាប្រវែងបន្ទុក PHY និងចំនួនបៃដែលបានអ៊ិនកូដ។ នៅពេលទទួល PHY នឹងឌិកូដ L-field ហើយគណនាចំនួនបៃដែលត្រូវឌិកូដ។ - គ-វាល
វាល C គឺជាវាលត្រួតពិនិត្យស៊ុម។ វាលនេះកំណត់ប្រភេទស៊ុម និងត្រូវបានប្រើប្រាស់សម្រាប់ការភ្ជាប់សេវាផ្លាស់ប្តូរទិន្នន័យបឋម។ វាល C បង្ហាញប្រភេទស៊ុម – ផ្ញើ បញ្ជាក់ ស្នើសុំ ឬឆ្លើយតប។ ក្នុងករណី SEND និង REQUEST frames វាល C បង្ហាញថាតើការបញ្ជាក់ ឬការឆ្លើយតបត្រូវបានរំពឹងទុក។
នៅពេលប្រើមុខងារ Link TX មូលដ្ឋាន តម្លៃណាមួយនៃ C អាចត្រូវបានប្រើ។ នៅពេលប្រើ Link Service Primitives វាល C ត្រូវបានបញ្ចូលដោយស្វ័យប្រវត្តិយោងទៅតាម EN 13757-4:2005 ។ - M-Field
វាល M គឺជាលេខកូដរបស់អ្នកផលិត។ ក្រុមហ៊ុនផលិតអាចស្នើសុំលេខកូដបីអក្សរពីខាងក្រោម web អាសយដ្ឋាន៖ http://www.dlms.com/flag/INDEX.HTM តួអក្សរនីមួយៗនៃកូដបីអក្សរត្រូវបានអ៊ិនកូដជាប្រាំប៊ីត។ លេខកូដ 5 ប៊ីតអាចទទួលបានដោយយកលេខកូដ ASCII ហើយដក 0x40 ("A")។ លេខកូដ 5 ប៊ីតចំនួនបីត្រូវបានភ្ជាប់គ្នាដើម្បីបង្កើត 15 ប៊ីត។ ប៊ីតដ៏សំខាន់បំផុតគឺសូន្យ។ - A-វាល
វាលអាសយដ្ឋានគឺជាអាសយដ្ឋាន 6 បៃតែមួយគត់សម្រាប់ឧបករណ៍នីមួយៗ។ អាសយដ្ឋានតែមួយគត់គួរតែត្រូវបានកំណត់ដោយក្រុមហ៊ុនផលិត។ វាជាទំនួលខុសត្រូវរបស់អ្នកផលិតនីមួយៗដើម្បីធានាថាឧបករណ៍នីមួយៗមានអាសយដ្ឋាន 6 បៃតែមួយគត់។ អាសយដ្ឋានសម្រាប់ស៊ុមផ្ញើ និងស្នើសុំគឺជាអាសយដ្ឋានដោយខ្លួនឯងរបស់ម៉ែត្រ ឬឧបករណ៍ផ្សេងទៀត។ ស៊ុមទិន្នន័យបញ្ជាក់ និងឆ្លើយតបត្រូវបានផ្ញើដោយប្រើអាសយដ្ឋាននៃឧបករណ៍ដើម។ - CI-Field
CI-field គឺជាបឋមកថាកម្មវិធី និងជាក់លាក់អំពីប្រភេទទិន្នន័យនៅក្នុងបន្ទុកទិន្នន័យកម្មវិធី។ ខណៈពេលដែល EN13757-4:2005 បញ្ជាក់ចំនួនកំណត់នៃតម្លៃ សេវាកម្ម Link Primitives នឹងអនុញ្ញាតឱ្យប្រើតម្លៃណាមួយ។ - កាកបាទក្រហមកម្ពុជា
CRC ត្រូវបានបញ្ជាក់នៅក្នុង EN13757-4: 2005 ។
ពហុធា CRC គឺ៖
X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
ចំណាំថា M-Bus CRC ត្រូវបានគណនាលើប្លុក 16 បៃនីមួយៗ។ លទ្ធផលគឺថារាល់ 16 បៃនៃទិន្នន័យតម្រូវឱ្យ 18 បៃត្រូវបានបញ្ជូន។
ព័ត៌មានបន្ថែម
សម្រាប់ព័ត៌មានបន្ថែមអំពីការអនុវត្តស្រទាប់តំណ សូមមើល “AN452: Wireless M-Bus Stack Programmers Guide”។
ការគ្រប់គ្រងថាមពល
រូបភាពទី 2 បង្ហាញពីពេលវេលាគ្រប់គ្រងថាមពលសម្រាប់ម៉ែត្រឧampដោយប្រើរបៀប T1 ។
MCU គួរតែស្ថិតនៅក្នុងទម្រង់ Sleep នៅពេលណាដែលអាចធ្វើទៅបាន ដើម្បីសន្សំថាមពល។ នៅក្នុងនេះ អតីតampដូច្នេះ MCU កំពុងដេកនៅពេលដែល RTC កំពុងដំណើរការ នៅពេលរង់ចាំការចាប់ផ្ដើមគ្រីស្តាល់វិទ្យុ និងនៅពេលបញ្ជូនពី FIFO ។ MCU នឹងភ្ញាក់ពីសញ្ញា EZRadioPRO IRQ ដែលភ្ជាប់ទៅ Port Match wake-up។
នៅពេលបញ្ជូនសារយូរជាងមួយប្លុក MCU ត្រូវតែក្រោកឡើងដើម្បីបំពេញ FIFO (ផ្អែកលើ FIFO ស្ទើរតែគ្មានការរំខាន) ហើយបន្ទាប់មកត្រឡប់ទៅគេងវិញ។
MCU គួរតែស្ថិតនៅក្នុងរបៀបទំនេរដែលដំណើរការពីលំយោលថាមពលទាប ឬលំយោលរបៀបផ្ទុះនៅពេលអានពី ADC ។ ADC ទាមទារនាឡិកា SAR ។
នៅពេលមិនប្រើ EZRadioPRO គួរតែស្ថិតនៅក្នុងរបៀបបិទជាមួយនឹងម្ជុល SDN ដែលជំរុញឱ្យខ្ពស់។ នេះតម្រូវឱ្យមានការតភ្ជាប់ខ្សែរឹងទៅ MCU ។ ការចុះឈ្មោះ EZ Radio Pro មិនត្រូវបានរក្សាទុកក្នុងរបៀបបិទទេ។ ដូច្នេះ EZRadioPro ត្រូវបានចាប់ផ្តើមនៅលើចន្លោះ RTC នីមួយៗ។ ការចាប់ផ្តើមវិទ្យុត្រូវការតិចជាង 100 µs និងរក្សាទុក 400 nA ។ នេះបណ្តាលឱ្យមានការសន្សំថាមពល 10 µJ ដោយផ្អែកលើចន្លោះពេល 10 វិនាទី។
គ្រីស្តាល់ EZRadioPRO ចំណាយពេលប្រហែល 16 ms សម្រាប់ POR ។ នេះគឺវែងល្មមដើម្បីគណនា CRC ប្រហែលប្រាំបីប្លុក។ MCU នឹងត្រលប់ទៅដំណេកវិញ ប្រសិនបើវាបញ្ចប់ CRCs ទាំងអស់ មុនពេលគ្រីស្តាល់មានស្ថេរភាព។ ប្រសិនបើការអ៊ិនគ្រីបត្រូវបានទាមទារ វាក៏អាចត្រូវបានចាប់ផ្តើមផងដែរ ខណៈពេលដែលកំពុងរង់ចាំគ្រីស្តាល់ oscillator ។
MCU គួរតែដំណើរការនៅ 20 MHz ដោយប្រើលំយោលថាមពលទាបសម្រាប់កិច្ចការភាគច្រើន។ កិច្ចការដែលទាមទារការអស់ពេលច្បាស់លាស់ត្រូវតែប្រើលំយោលជាក់លាក់ និងរបៀបទំនេរជំនួសឱ្យរបៀបគេង។ RTC ផ្តល់នូវដំណោះស្រាយគ្រប់គ្រាន់សម្រាប់កិច្ចការភាគច្រើន។ ពេលវេលាគ្រប់គ្រងថាមពលសម្រាប់ T2 ម៉ែត្រ ឧample កម្មវិធីត្រូវបានបង្ហាញក្នុងរូបភាពទី 3 ។
ការអនុវត្តឧបករណ៍បញ្ជូនគួរតែត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់ករណីធម្មតានៅពេលដែលម៉ែត្រភ្ញាក់ឡើងហើយមិនមានអ្នកអានមានវត្តមាន។ ការអស់ពេល ACK អប្បបរមា/អតិបរិមាគឺវែងគ្រប់គ្រាន់ ដើម្បីឱ្យវាអាចប្រើ C8051F930 RTC ហើយដាក់ MCU ទៅក្នុងរបៀបគេង។
ជម្រើសបង្កើតត្រូវបានផ្តល់ជូនសម្រាប់អ្នកអានដែលប្រើថាមពលមេ ឬ USB ដែលមិនចាំបាច់ប្រើមុខងារគេង។ របៀបទំនេរនឹងត្រូវបានប្រើជំនួសឱ្យការគេង ដូច្នេះ USB និង UART អាចរំខាន MCU ។
ស្ទូឌីយោភាពសាមញ្ញ
ការចូលដំណើរការដោយចុចមួយដងទៅកាន់ MCU និងឧបករណ៍ឥតខ្សែ ឯកសារ សូហ្វវែរ បណ្ណាល័យកូដប្រភព និងច្រើនទៀត។ មានសម្រាប់ Windows,
Mac និង Linux!
 |
 |
 |
 |
| ផលប័ត្រ IoT www.silabs.com/IoT |
SW/HW www.silabs.com/simplicity |
គុណភាព www.silabs.com/quality |
ការគាំទ្រ និងសហគមន៍ community.silabs.com |
ការបដិសេធ
Silicon Labs មានបំណងផ្តល់ជូនអតិថិជននូវឯកសារចុងក្រោយបំផុត ត្រឹមត្រូវ និងស៊ីជម្រៅនៃគ្រឿងកុំព្យូទ័រ និងម៉ូឌុលទាំងអស់ដែលមានសម្រាប់អ្នកអនុវត្តប្រព័ន្ធ និងកម្មវិធីដែលប្រើប្រាស់ ឬមានបំណងប្រើប្រាស់ផលិតផល Silicon Labs ។ ទិន្នន័យលក្ខណៈ ម៉ូឌុល និងគ្រឿងកុំព្យូទ័រដែលអាចប្រើបាន ទំហំអង្គចងចាំ និងអាសយដ្ឋានអង្គចងចាំ សំដៅលើឧបករណ៍ជាក់លាក់នីមួយៗ ហើយប៉ារ៉ាម៉ែត្រ "ធម្មតា" ដែលបានផ្តល់អាច និងធ្វើខុសគ្នានៅក្នុងកម្មវិធីផ្សេងៗ។ កម្មវិធី ឧamples ដែលបានពិពណ៌នានៅទីនេះគឺសម្រាប់គោលបំណងបង្ហាញតែប៉ុណ្ណោះ។ Silicon Labs រក្សាសិទ្ធិដើម្បីធ្វើការផ្លាស់ប្តូរដោយគ្មានការជូនដំណឹងបន្ថែម និងការកំណត់ចំពោះព័ត៌មានផលិតផល លក្ខណៈបច្ចេកទេស និងការពិពណ៌នានៅទីនេះ និងមិនផ្តល់ការធានាចំពោះភាពត្រឹមត្រូវ ឬពេញលេញនៃព័ត៌មានដែលបានរួមបញ្ចូលនោះទេ។ Silicon Labs នឹងមិនទទួលខុសត្រូវចំពោះផលវិបាកនៃការប្រើប្រាស់ព័ត៌មានដែលបានផ្តល់ឱ្យនៅទីនេះទេ។ ឯកសារនេះមិនបង្កប់ន័យ ឬបង្ហាញពីអាជ្ញាប័ណ្ណរក្សាសិទ្ធិដែលត្រូវបានផ្តល់ឱ្យក្រោមនេះ ដើម្បីរចនា ឬប្រឌិតសៀគ្វីរួមបញ្ចូលគ្នាណាមួយឡើយ។ ផលិតផលមិនត្រូវបានរចនា ឬអនុញ្ញាតឱ្យប្រើប្រាស់ក្នុងប្រព័ន្ធទ្រទ្រង់ជីវិតណាមួយឡើយ ដោយគ្មានការយល់ព្រមជាលាយលក្ខណ៍អក្សរជាក់លាក់ពី Silicon Labs។ “ប្រព័ន្ធទ្រទ្រង់ជីវិត” គឺជាផលិតផល ឬប្រព័ន្ធណាមួយដែលមានបំណងគាំទ្រ ឬទ្រទ្រង់ជីវិត និង/ឬសុខភាព ដែលប្រសិនបើវាបរាជ័យ វាអាចត្រូវបានគេរំពឹងថានឹងបណ្តាលឱ្យមានរបួស ឬស្លាប់យ៉ាងធ្ងន់ធ្ងរ។ ផលិតផល Silicon Labs មិនត្រូវបានរចនាឡើង ឬអនុញ្ញាតសម្រាប់កម្មវិធីយោធាទេ។ ផលិតផល Silicon Labs មិនត្រូវស្ថិតក្រោមកាលៈទេសៈណាក៏ដោយ ដែលត្រូវបានប្រើប្រាស់ក្នុងអាវុធប្រល័យលោក រួមទាំង (ប៉ុន្តែមិនកំណត់ចំពោះ) អាវុធនុយក្លេអ៊ែរ អាវុធជីវសាស្ត្រ ឬគីមី ឬមីស៊ីលដែលមានសមត្ថភាពបញ្ជូនអាវុធបែបនេះឡើយ។
ព័ត៌មានពាណិជ្ជសញ្ញា
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs®, និងស្លាកសញ្ញា Silicon Labs®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, និមិត្តសញ្ញា Energy Micro និងបន្សំរបស់វា, “ឧបករណ៍បញ្ជាមីក្រូដែលងាយស្រួលប្រើបំផុតរបស់ពិភពលោក”, Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, Telegesis Logo®, USBXpress® និងផ្សេងទៀតគឺជាពាណិជ្ជសញ្ញា ឬពាណិជ្ជសញ្ញាដែលបានចុះបញ្ជីរបស់ Silicon Labs។ ARM, CORTEX, Cortex-M3 និងមេដៃគឺជាពាណិជ្ជសញ្ញា ឬពាណិជ្ជសញ្ញាដែលបានចុះបញ្ជីរបស់ ARM Holdings ។ Keil គឺជាពាណិជ្ជសញ្ញាចុះបញ្ជីរបស់ ARM Limited ។ ផលិតផល ឬម៉ាកយីហោផ្សេងទៀតទាំងអស់ដែលបានលើកឡើងនៅទីនេះ គឺជាពាណិជ្ជសញ្ញារបស់អ្នកកាន់រៀងៗខ្លួន។
Silicon Laboratories Inc.
400 West Cesar Chavez
Austin, TX 78701
សហរដ្ឋអាមេរិក
http://www.silabs.com
ឯកសារ/ធនធាន
 |
ការអនុវត្តកម្មវិធី SILICON LABS ឥតខ្សែ M-BUS AN451 [pdf] ការណែនាំអ្នកប្រើប្រាស់ SILICON LABS, C8051, MCU, និង, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, កម្មវិធី, ការអនុវត្ត, AN451 |
