ភារកិច្ចសម្រាប់អ្នកអភិវឌ្ឍន៍ ឬរបៀបដែលយើងបញ្ចេញម៉ាស៊ីនស្កេនដោយដៃដោយគ្មានអ្នកលក់

សួស្តីអ្នករាល់គ្នា។

យើង Viktor Antipov និង Ilya Aleshin ថ្ងៃនេះនឹងនិយាយអំពីបទពិសោធន៍របស់យើងក្នុងការធ្វើការជាមួយឧបករណ៍ USB តាមរយៈ Python PyUSB និងបន្តិចបន្តួចអំពីវិស្វកម្មបញ្ច្រាស។

សម័យបុរេប្រវត្តិសាស្ត្រ

នៅឆ្នាំ 2019 ក្រឹត្យរបស់រដ្ឋាភិបាលនៃសហព័ន្ធរុស្ស៊ីលេខ 224 "ស្តីពីការអនុម័តលើច្បាប់សម្រាប់ការដាក់ស្លាកផលិតផលថ្នាំជក់ជាមួយនឹងមធ្យោបាយកំណត់អត្តសញ្ញាណនិងលក្ខណៈពិសេសនៃការអនុវត្តប្រព័ន្ធព័ត៌មានរដ្ឋសម្រាប់ការត្រួតពិនិត្យចរាចរទំនិញដែលមានការដាក់ស្លាកជាកាតព្វកិច្ចជាមួយនឹងមធ្យោបាយកំណត់អត្តសញ្ញាណ។ ទាក់ទងនឹងផលិតផលថ្នាំជក់” ចូលជាធរមាន។
ឯកសារពន្យល់ថាចាប់ពីថ្ងៃទី 1 ខែកក្កដា ឆ្នាំ 2019 ក្រុមហ៊ុនផលិតត្រូវបានតម្រូវឱ្យដាក់ស្លាកថ្នាំជក់នីមួយៗ។ ហើយអ្នកចែកចាយផ្ទាល់ត្រូវតែទទួលបានផលិតផលទាំងនេះជាមួយនឹងការអនុវត្តឯកសារផ្ទេរជាសកល (UDD)។ នៅក្នុងវេន ហាងនានាត្រូវចុះបញ្ជីការលក់ផលិតផលដែលមានស្លាកសញ្ញាតាមរយៈបញ្ជីសាច់ប្រាក់។

គួរបញ្ជាក់ផងដែរថា ចាប់ពីថ្ងៃទី 1 ខែកក្កដា ឆ្នាំ 2020 ការចរាចរផលិតផលថ្នាំជក់ដែលគ្មានស្លាកសញ្ញាត្រូវបានហាមឃាត់។ នេះមានន័យថាកញ្ចប់បារីទាំងអស់ត្រូវតែត្រូវបានសម្គាល់ដោយលេខកូដ Datamatrix ពិសេស។ លើសពីនេះទៅទៀត - ចំណុចសំខាន់មួយ - វាបានប្រែក្លាយថា Datamatrix នឹងមិនមានលក្ខណៈធម្មតាទេប៉ុន្តែបញ្ច្រាស។ នោះ​គឺ​មិនមែន​កូដ​ខ្មៅ​លើ​ស​ទេ ប៉ុន្តែ​ផ្ទុយ​មក​វិញ​។

យើងបានសាកល្បងម៉ាស៊ីនស្កែនរបស់យើង ហើយវាបានប្រែក្លាយថាពួកគេភាគច្រើនត្រូវតែត្រូវបាន reflashed/rerained បើមិនដូច្នេះទេ ពួកវាមិនអាចដំណើរការធម្មតាជាមួយ barcode នេះបានទេ។ វេននៃព្រឹត្តិការណ៍នេះបានធានាឱ្យយើងឈឺក្បាលយ៉ាងខ្លាំងព្រោះក្រុមហ៊ុនរបស់យើងមានហាងជាច្រើនដែលនៅរាយប៉ាយនៅលើទឹកដីដ៏ធំ។ ការចុះឈ្មោះសាច់ប្រាក់រាប់សិបពាន់ - និងពេលវេលាតិចតួចណាស់។

តើត្រូវធ្វើអ្វី? មានជម្រើសពីរ។ ទីមួយ៖ វិស្វករនៅនឹងកន្លែង ធ្វើការកែសំរួលម៉ាស៊ីនស្កេនដោយដៃ។ ទីពីរ៖ យើងធ្វើការពីចម្ងាយ ហើយល្អជាង គ្របដណ្ដប់លើម៉ាស៊ីនស្កែនជាច្រើនក្នុងពេលតែមួយ ក្នុងពេលតែមួយ។

ជម្រើសទី XNUMX ច្បាស់ណាស់គឺមិនសមរម្យសម្រាប់យើងទេ: យើងនឹងត្រូវចំណាយប្រាក់លើវិស្វករមកទស្សនាហើយក្នុងករណីនេះវានឹងពិបាកក្នុងការគ្រប់គ្រងនិងសម្របសម្រួលដំណើរការ។ ប៉ុន្តែអ្វីដែលសំខាន់បំផុតនោះគឺថាមនុស្សនឹងធ្វើការ ពោលគឺយើងអាចទទួលបានកំហុសច្រើន ហើយភាគច្រើនទំនងជាមិនបំពេញតាមកាលកំណត់នោះទេ។

ជម្រើសទីពីរគឺល្អសម្រាប់មនុស្សគ្រប់គ្នា ប្រសិនបើមិនមែនសម្រាប់រឿងមួយ។ អ្នកលក់ខ្លះមិនមានឧបករណ៍បញ្ចេញពន្លឺពីចម្ងាយដែលយើងត្រូវការសម្រាប់ប្រព័ន្ធប្រតិបត្តិការដែលត្រូវការទាំងអស់។ ហើយ​តាំង​ពី​ពេល​កំណត់​បាន​អស់​ហើយ ខ្ញុំ​ត្រូវ​គិត​ដោយ​ក្បាល​ខ្លួន​ឯង។

បន្ទាប់មក យើងនឹងប្រាប់អ្នកពីរបៀបដែលយើងបានបង្កើតឧបករណ៍សម្រាប់ម៉ាស៊ីនស្កេនដៃសម្រាប់ Debian 9.x OS (រាល់ការចុះឈ្មោះសាច់ប្រាក់របស់យើងគឺនៅលើ Debian)។

ដោះស្រាយពាក្យស្លោក៖ របៀបបញ្ចេញម៉ាស៊ីនស្កេន

Victor Antipov រាយការណ៍។

ឧបករណ៍ប្រើប្រាស់ផ្លូវការដែលផ្តល់ដោយអ្នកលក់ដំណើរការក្រោម Windows ហើយមានតែជាមួយ IE ប៉ុណ្ណោះ។ ឧបករណ៍ប្រើប្រាស់អាចបញ្ចេញពន្លឺ និងកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនស្កេន។

ដោយសារប្រព័ន្ធគោលដៅរបស់យើងគឺ Debian យើងបានដំឡើងម៉ាស៊ីនមេ usb-redirector នៅលើ Debian និងម៉ាស៊ីនភ្ញៀវ usb-redirector នៅលើ Windows ។ ដោយប្រើឧបករណ៍ប្រើប្រាស់ usb-redirector យើងបានបញ្ជូនម៉ាស៊ីនស្កេនពីម៉ាស៊ីនលីនុចទៅម៉ាស៊ីនវីនដូ។

ឧបករណ៍ប្រើប្រាស់ពីអ្នកលក់វីនដូបានឃើញម៉ាស៊ីនស្កេន ហើយថែមទាំងបញ្ចេញវាជាធម្មតា។ ដូច្នេះហើយ យើងធ្វើការសន្និដ្ឋានដំបូង៖ គ្មានអ្វីអាស្រ័យលើ OS ទេ វាជាបញ្ហានៃពិធីការពន្លឺ។

យល់ព្រម។ យើងបានដំណើរការពន្លឺនៅលើម៉ាស៊ីន Windows ហើយបានលុបការចោលនៅលើម៉ាស៊ីនលីនុច។

យើងបានចាក់សំរាមចូលទៅក្នុង WireShark ហើយ ... មានការសោកសៅ (ខ្ញុំនឹងលុបចោលព័ត៌មានលម្អិតមួយចំនួននៃកន្លែងចាក់សំរាម ពួកគេមិនមានការចាប់អារម្មណ៍ទេ)។

អ្វី​ដែល​គំនរ​សំរាម​បាន​បង្ហាញ​យើង៖

អាសយដ្ឋាន 0000-0030 វិនិច្ឆ័យដោយ Wireshark គឺជាព័ត៌មានសេវាកម្ម USB ។

យើងចាប់អារម្មណ៍ផ្នែក 0040-0070។

គ្មានអ្វីច្បាស់លាស់ពីស៊ុមបញ្ជូនមួយ លើកលែងតែតួអក្សរ MOCFT ។ តួអក្សរទាំងនេះប្រែទៅជាតួអក្សរពីឯកសារកម្មវិធីបង្កប់ក៏ដូចជាតួអក្សរដែលនៅសល់រហូតដល់ចុងបញ្ចប់នៃស៊ុម (ឯកសារកម្មវិធីបង្កប់ត្រូវបានបន្លិច):

អ្វីដែលនិមិត្តសញ្ញា fd 3e 02 01 fe មានន័យ ខ្ញុំផ្ទាល់ដូចជា Ilya មិនដឹងទេ។

ខ្ញុំបានក្រឡេកមើលស៊ុមខាងក្រោម (ព័ត៌មានសេវាកម្មត្រូវបានដកចេញនៅទីនេះ ឯកសារកម្មវិធីបង្កប់ត្រូវបានបន្លិច)៖

តើអ្វីបានក្លាយទៅជាច្បាស់? ថាពីរបៃដំបូងគឺជាប្រភេទនៃថេរមួយចំនួន។ រាល់ប្លុកជាបន្តបន្ទាប់បានបញ្ជាក់ពីរឿងនេះ ប៉ុន្តែមុនពេលចុងបញ្ចប់នៃប្លុកបញ្ជូន៖

ស៊ុមនេះក៏គួរឱ្យអស់សំណើចផងដែរ ចាប់តាំងពីថេរបានផ្លាស់ប្តូរ (បន្លិច) ហើយចម្លែកគ្រប់គ្រាន់ មានផ្នែកនៃឯកសារ។ ទំហំនៃបៃដែលបានផ្ទេរនៃឯកសារបានបង្ហាញថា 1024 បៃត្រូវបានផ្ទេរ។ ខ្ញុំ​មិន​ដឹង​ថា​បៃ​ដែល​នៅ​សល់​មានន័យ​ដូច​ម្តេច​ទៀត​ទេ។

ជាដំបូងក្នុងនាមជាសម្មតិនាម BBS ចាស់ ខ្ញុំបានពិនិត្យមើលពិធីការបញ្ជូនស្តង់ដារ។ គ្មានពិធីការបញ្ជូន 1024 បៃទេ។ ខ្ញុំចាប់ផ្តើមសិក្សាផ្នែករឹង ហើយបានឆ្លងកាត់ពិធីការ 1K Xmodem ។ វាអនុញ្ញាតឱ្យបញ្ជូន 1024 ប៉ុន្តែជាមួយនឹងការព្រមានមួយ: ដំបូងមានតែ 128 ហើយប្រសិនបើមិនមានកំហុសទេពិធីការបានបង្កើនចំនួនបៃបញ្ជូន។ ភ្លាមៗខ្ញុំមានការផ្ទេរ 1024 បៃ។ ខ្ញុំបានសម្រេចចិត្តសិក្សាពិធីការបញ្ជូន និងជាពិសេស ម៉ូដឹម X។

មានបំរែបំរួលពីរនៃម៉ូដឹម។

ទីមួយ ទម្រង់កញ្ចប់ XMODEM ជាមួយនឹងការគាំទ្រ CRC8 (XMODEM ដើម)៖

ទីពីរ ទ្រង់ទ្រាយកញ្ចប់ព័ត៌មាន XMODEM ជាមួយនឹងការគាំទ្រ CRC16 (XmodemCRC)៖

វាមើលទៅស្រដៀងគ្នា លើកលែងតែ SOH លេខកញ្ចប់ និង CRC និងប្រវែងកញ្ចប់។

ខ្ញុំបានមើលនៅដើមប្លុកបញ្ជូនទីពីរ (ហើយម្តងទៀតបានឃើញឯកសារកម្មវិធីបង្កប់ ប៉ុន្តែបានចូលបន្ទាត់រួចហើយដោយ 1024 បៃ)៖

ខ្ញុំបានឃើញបឋមកថា fd 3e 02 ដែលធ្លាប់ស្គាល់ ប៉ុន្តែពីរបៃបន្ទាប់បានផ្លាស់ប្តូររួចហើយ៖ វាគឺ 01 fe ហើយបានក្លាយជា 02 fd ។ បន្ទាប់មកខ្ញុំបានកត់សម្គាល់ឃើញថាប្លុកទីពីរឥឡូវនេះមានលេខ 02 ហើយដូច្នេះយល់: នៅពីមុខខ្ញុំគឺជាលេខនៃប្លុកបញ្ជូន។ ប្រអប់លេខ 1024 ដំបូងគឺ 01, ទីពីរគឺ 02, ទីបីគឺ 03 ហើយដូច្នេះនៅលើ (ប៉ុន្តែនៅក្នុង hex, ជាការពិតណាស់) ។ ប៉ុន្តែតើការផ្លាស់ប្តូរពី fe ទៅ fd មានន័យដូចម្តេច? ភ្នែកមើលឃើញការថយចុះ 1 ខួរក្បាលរំលឹកថាអ្នកសរសេរកម្មវិធីរាប់ពី 0 មិនមែន 1 ។ ប៉ុន្តែហេតុអ្វីបានជាប្លុកទី 1 មិនមែន 0? ខ្ញុំនៅតែមិនបានរកឃើញចម្លើយចំពោះសំណួរនេះទេ។ ប៉ុន្តែខ្ញុំបានយល់ពីរបៀបដែលប្លុកទីពីរត្រូវបានរាប់។ ប្លុកទីពីរគឺគ្មានអ្វីលើសពី FF - (ដក) ចំនួននៃប្លុកទីមួយ។ ដូច្នេះប្លុកទីពីរត្រូវបានកំណត់ថា = 02 (FF-02) = 02 FD ។ ការអានជាបន្តបន្ទាប់នៃការចាក់សំរាមបានបញ្ជាក់ពីការស្មានរបស់ខ្ញុំ។

បន្ទាប់មករូបភាពខាងក្រោមនៃការបញ្ជូនបានចាប់ផ្តើមលេចចេញមក៖

ការចាប់ផ្តើមនៃការបញ្ជូន
fd 3e 02 - ចាប់ផ្តើម
01 FE - បញ្ជរបញ្ជូន
ផ្ទេរ (34 ប្លុក, 1024 បៃផ្ទេរ)
fd 3e 1024 បៃនៃទិន្នន័យ (បែងចែកជាប្លុក 30 បៃ) ។
ចុងបញ្ចប់នៃការបញ្ជូន
fd ២៥

ទិន្នន័យដែលនៅសល់ត្រូវតម្រឹមទៅ 1024 បៃ។

តើស៊ុមបញ្ចប់ការបញ្ជូនប្លុកមើលទៅដូចអ្វី៖

fd 25 - សញ្ញាដើម្បីបញ្ចប់ការបញ្ជូនប្លុក។ បន្ទាប់ 2f 52 - ឯកសារដែលនៅសល់រហូតដល់ 1024 បៃក្នុងទំហំ។ 2f 52 វិនិច្ឆ័យដោយពិធីការ គឺជាមូលប្បទានប័ត្រ CRC 16 ប៊ីត។

សម្រាប់ជាប្រយោជន៍ដល់សម័យបុរាណ ខ្ញុំបានបង្កើតកម្មវិធីមួយក្នុង C ដែលទាញ 1024 បៃពីឯកសារមួយ ហើយគណនា CRC 16 ប៊ីត។ ការបើកដំណើរការកម្មវិធីបានបង្ហាញថានេះមិនមែនជា CRC 16 ប៊ីតទេ។ Stupor ម្តងទៀត - ប្រហែលបីថ្ងៃ។ គ្រប់ពេលវេលានេះ ខ្ញុំកំពុងព្យាយាមយល់ពីអ្វីដែលវាអាចជា ប្រសិនបើមិនមែនជាការឆែកឆេរ។ ពេលកំពុងសិក្សាគេហទំព័រជាភាសាអង់គ្លេស ខ្ញុំបានរកឃើញថា X-modem ប្រើការគណនា checksum របស់វាផ្ទាល់ - CRC-CCITT (XModem) ។ ខ្ញុំមិនបានរកឃើញការអនុវត្ត C ណាមួយនៃការគណនានេះទេ ប៉ុន្តែខ្ញុំបានរកឃើញគេហទំព័រដែលគណនា checksum នេះតាមអ៊ីនធឺណិត។ ដោយបានផ្ទេរ 1024 បៃនៃឯកសាររបស់ខ្ញុំទៅគេហទំព័រ គេហទំព័រនេះបានបង្ហាញខ្ញុំនូវ checksum ដែលផ្គូផ្គងនឹង checksum ទាំងស្រុងពីឯកសារ។

ហ៊ឺយ! សំណួរចុងក្រោយត្រូវបានដោះស្រាយ ឥឡូវនេះខ្ញុំត្រូវការបង្កើតកម្មវិធីបង្កប់ផ្ទាល់ខ្លួនរបស់ខ្ញុំ។ បន្ទាប់មក ខ្ញុំបានបញ្ជូនចំណេះដឹងរបស់ខ្ញុំ (ហើយវានៅសល់តែក្នុងក្បាលរបស់ខ្ញុំ) ទៅកាន់ Ilya ដែលស៊ាំជាមួយឧបករណ៍ដ៏មានអានុភាព Python ។

ការបង្កើតកម្មវិធី

Ilya Aleshin រាយការណ៍។

ដោយ​បាន​ទទួល​ការ​ណែនាំ​ដ៏​សមរម្យ ខ្ញុំ​ពិត​ជា​សប្បាយ​ចិត្ត​ណាស់។

កន្លែងដែលត្រូវចាប់ផ្តើម? ត្រឹមត្រូវហើយ តាំងពីដើមមក។  ពីការយកសំរាមចេញពីរន្ធ USB ។

បើកដំណើរការ USB-pcap https://desowin.org/usbpcap/tour.html

ជ្រើសរើសច្រកដែលឧបករណ៍ត្រូវបានភ្ជាប់ និងឯកសារដែលយើងនឹងរក្សាទុកកន្លែងចាក់សំរាម។

យើងភ្ជាប់ម៉ាស៊ីនស្កេនទៅម៉ាស៊ីនដែលកម្មវិធី EZConfigScanning ដើមសម្រាប់ Windows ត្រូវបានដំឡើង។

នៅក្នុងវាយើងរកឃើញធាតុសម្រាប់ផ្ញើពាក្យបញ្ជាទៅឧបករណ៍។ ប៉ុន្តែចុះយ៉ាងណាចំពោះក្រុម? តើខ្ញុំអាចទទួលបានពួកគេនៅឯណា?
នៅពេលដែលកម្មវិធីចាប់ផ្តើម ឧបករណ៍ត្រូវបានស្ទង់មតិដោយស្វ័យប្រវត្តិ (យើងនឹងឃើញវានៅពេលក្រោយបន្តិច)។ ហើយមានការបណ្តុះបណ្តាល បាកូដពីឯកសារឧបករណ៍ផ្លូវការ។ DEFALT នេះគឺជាក្រុមរបស់យើង។

ទិន្នន័យចាំបាច់ត្រូវបានទទួល។ បើក dump.pcap តាមរយៈ wireshark ។

រារាំងនៅពេលចាប់ផ្តើម EZConfigScanning ។ កន្លែងដែលអ្នកត្រូវយកចិត្តទុកដាក់ត្រូវបានសម្គាល់ជាពណ៌ក្រហម។

ឃើញ​រឿង​ទាំង​នេះ​ជា​លើក​ទី​មួយ​ហើយ​ក៏​ស្រក់​ទឹក​ចិត្ត។ វាមិនច្បាស់ថាត្រូវជីកកន្លែងណាបន្ទាប់ទេ។

យល់សប្តិបន្តិចហើយ... អាហា! នៅក្នុងកន្លែងចាក់សំរាម ចេញ - នេះ inនិង in វា ចេញ.

ខ្ញុំបាន Google ថា URB_INTERRUPT ជាអ្វី។ ខ្ញុំបានរកឃើញថានេះគឺជាវិធីសាស្ត្រផ្ទេរទិន្នន័យ។ ហើយមាន 4 វិធីសាស្រ្តដូចជា: ការគ្រប់គ្រង, រំខាន, isochronous, bulk ។ អ្នកអាចអានអំពីពួកវាដោយឡែកពីគ្នា។

ហើយអាសយដ្ឋានចំណុចបញ្ចប់នៅក្នុងចំណុចប្រទាក់ឧបករណ៍ USB អាចទទួលបានតាមរយៈពាក្យបញ្ជា “lsusb –v” ឬដោយប្រើ pyusb ។

ឥឡូវនេះយើងត្រូវស្វែងរកឧបករណ៍ទាំងអស់ដែលមាន VID នេះ។ អ្នកអាចស្វែងរកជាពិសេសដោយ VID:PID ។

វាមើលទៅដូចនេះ៖

ដូច្នេះ យើងមានព័ត៌មានចាំបាច់៖ ពាក្យបញ្ជា P_INFO ។ ឬ DEFALT អាសយដ្ឋានកន្លែងដែលត្រូវសរសេរពាក្យបញ្ជា endpoint=03 និងកន្លែងដែលត្រូវទទួលបានការឆ្លើយតប endpoint=86។ អ្វីដែលនៅសល់គឺការបំប្លែងពាក្យបញ្ជាទៅជាគោលដប់ប្រាំមួយ។

ដោយសារយើងបានរកឃើញឧបករណ៍រួចហើយ សូមផ្តាច់វាចេញពីខឺណែល...

...ហើយសរសេរទៅចំណុចបញ្ចប់ដោយអាសយដ្ឋាន 0x03,

... ហើយបន្ទាប់មកអានការឆ្លើយតបពីចំណុចបញ្ចប់ដែលមានអាសយដ្ឋាន 0x86 ។

ចម្លើយដែលមានរចនាសម្ព័ន្ធ៖

P_INFOfmt: 1
mode: app
app-present: 1
boot-present: 1
hw-sn: 18072B44CA
hw-rev: 0x20
cbl: 4
app-sw-rev: CP000116BBA
boot-sw-rev: CP000014BAD
flash: 3
app-m_name: Voyager 1450g
boot-m_name: Voyager 1450g
app-p_name: 1450g
boot-p_name: 1450g
boot-time: 16:56:02
boot-date: Oct 16 2014
app-time: 08:49:30
app-date: Mar 25 2019
app-compat: 289
boot-compat: 288
csum: 0x6986

យើងឃើញទិន្នន័យនេះនៅក្នុង dump.pcap ។

អស្ចារ្យ! បំលែងលេខកូដប្រព័ន្ធទៅជាលេខគោលដប់ប្រាំមួយ។ នោះហើយជាវា មុខងារបណ្តុះបណ្តាលគឺរួចរាល់។

ចុះកម្មវិធីបង្កប់វិញ? អ្វីគ្រប់យ៉ាងហាក់ដូចជាដូចគ្នា ប៉ុន្តែមានភាពខុសប្លែកគ្នា។

ដោយ​បាន​យក​ការ​បោះចោល​ទាំងស្រុង​នៃ​ដំណើរ​ការ​បញ្ចេញ​ពន្លឺ យើង​បាន​យល់​អំពី​អ្វី​ដែល​យើង​កំពុង​ដោះស្រាយ។ នេះគឺជាអត្ថបទអំពី XMODEM ដែលមានប្រយោជន៍ខ្លាំងណាស់ក្នុងការយល់ដឹងពីរបៀបដែលទំនាក់ទំនងនេះកើតឡើង ទោះបីជាក្នុងន័យទូទៅក៏ដោយ៖ http://microsin.net/adminstuff/others/xmodem-protocol-overview.html ខ្ញុំសូមណែនាំឱ្យអានវា។

ក្រឡេកមើលកន្លែងចាក់សំរាម អ្នកអាចមើលឃើញថាទំហំស៊ុមគឺ 1024 ហើយទំហំទិន្នន័យ URB គឺ 64 ។

ដូច្នេះ - 1024/64 - យើងទទួលបាន 16 បន្ទាត់ក្នុងប្លុកមួយ អានឯកសារកម្មវិធីបង្កប់ 1 តួអក្សរក្នុងពេលតែមួយ ហើយបង្កើតជាប្លុក។ ការបំពេញ 1 បន្ទាត់ក្នុងប្លុកដែលមានតួអក្សរពិសេស fd3e02 + លេខប្លុក។
14 ជួរបន្ទាប់ត្រូវបានបន្ថែមដោយ fd25 + ដោយប្រើ XMODEM.calc_crc() យើងគណនា checksum នៃប្លុកទាំងមូល (វាចំណាយពេលច្រើនដើម្បីយល់ថា “FF – 1” គឺ CSUM) ហើយចុងក្រោយ បន្ទាត់ទី 16 ត្រូវបានបំពេញបន្ថែម ជាមួយ fd3e ។

វាហាក់ដូចជានោះហើយជាវា អានឯកសារកម្មវិធីបង្កប់ បុកប្លុក ផ្តាច់ម៉ាស៊ីនស្កេនពីខឺណែល ហើយផ្ញើវាទៅឧបករណ៍។ ប៉ុន្តែវាមិនសាមញ្ញនោះទេ។ ម៉ាស៊ីនស្កេនត្រូវប្តូរទៅរបៀបកម្មវិធីបង្កប់
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
តើក្រុមនេះមកពីណា?? ពីកន្លែងចាក់សំរាម។

ប៉ុន្តែយើងមិនអាចផ្ញើប្លុកទាំងមូលទៅម៉ាស៊ីនស្កេនបានទេ ដោយសារដែនកំណត់ 64៖

ជាការប្រសើរណាស់ ម៉ាស៊ីនស្កេននៅក្នុងរបៀបបញ្ចេញពន្លឺ NEWAPP មិនទទួលយក hex ទេ។ ដូច្នេះ អ្នកនឹងត្រូវបកប្រែបន្ទាត់នីមួយៗ bytes_array

[253, 10, 22, 78, 44, 78, 69, 87, 65, 80, 80, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

ហើយបន្ទាប់មកផ្ញើទិន្នន័យនេះទៅម៉ាស៊ីនស្កេន។

យើងទទួលបានចម្លើយ៖

[2, 1, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

ប្រសិនបើអ្នកពិនិត្យមើលអត្ថបទអំពី XMODEM វានឹងកាន់តែច្បាស់៖ ទិន្នន័យត្រូវបានទទួលយក។

បន្ទាប់ពីប្លុកទាំងអស់ត្រូវបានផ្ទេរ យើងបញ្ចប់ការផ្ទេរ END_TRANSFER = 'xfdx01x04' ។

ជាការប្រសើរណាស់ ដោយសារប្លុកទាំងនេះមិនផ្ទុកព័ត៌មានណាមួយសម្រាប់មនុស្សសាមញ្ញ យើងនឹងដំឡើងកម្មវិធីបង្កប់ក្នុងរបៀបលាក់ទុកតាមលំនាំដើម។ ហើយក្នុងករណី យើងនឹងរៀបចំរបារវឌ្ឍនភាពតាមរយៈ tqdm ។

តាមពិតទៅ វាជារឿងតូចតាច។ អ្វីដែលនៅសេសសល់គឺការរុំដំណោះស្រាយនៅក្នុងស្គ្រីបសម្រាប់ការចម្លងទ្រង់ទ្រាយធំតាមពេលវេលាដែលបានកំណត់យ៉ាងច្បាស់ ដើម្បីកុំឱ្យដំណើរការយឺតយ៉ាវក្នុងដំណើរការធ្វើការនៅច្រកចេញ ហើយបន្ថែមការចូល។

លទ្ធផល

ដោយបានចំណាយពេលវេលា និងការខំប្រឹងប្រែងជាច្រើន និងសក់នៅលើក្បាលរបស់យើង យើងអាចអភិវឌ្ឍដំណោះស្រាយដែលយើងត្រូវការ ហើយក៏បានបំពេញតាមកាលកំណត់ផងដែរ។ ក្នុងពេលជាមួយគ្នានេះ ម៉ាស៊ីនស្កែនឥឡូវនេះត្រូវបានជួសជុលឡើងវិញ និងធ្វើការហ្វឹកហាត់ឡើងវិញនៅកណ្តាល យើងគ្រប់គ្រងដំណើរការទាំងមូលយ៉ាងច្បាស់។ ក្រុមហ៊ុនបានសន្សំសំចៃពេលវេលា និងថវិកា ហើយយើងទទួលបានបទពិសោធន៍ដែលមិនអាចកាត់ថ្លៃបាននៅក្នុងឧបករណ៍វិស្វកម្មបញ្ច្រាសនៃប្រភេទនេះ។

ប្រភព: www.habr.com