Tere kõigile.
Meie, Viktor Antipov ja Ilja Aleshin, räägime täna oma kogemustest Python PyUSB kaudu USB-seadmetega töötamisel ja veidi pöördprojekteerimisest.
eelajalugu
2019. aastal võeti vastu Vene Föderatsiooni valitsuse määrus nr 224 „Tubakatoodete identifitseerimisvahenditega märgistamise eeskirjade ja identifitseerimisvahenditega kohustusliku märgistamisele kuuluvate kaupade ringluse jälgimise riikliku infosüsteemi rakendamise tunnuste kohta tubakatoodete osas” jõustus.
Dokumendis selgitatakse, et alates 1. juulist 2019 on tootjad kohustatud märgistama iga tubakapakendi. Ja otseturustajad peavad need tooted vastu võtma universaalse ülekandedokumendi (UDD) täitmisega. Kauplustel omakorda tuleb registreerida märgistatud toodete müük kassa kaudu.
Samuti on alates 1. juulist 2020 keelatud märgistamata tubakatoodete ringlus. See tähendab, et kõik sigaretipakid peavad olema märgistatud spetsiaalse Datamatrixi vöötkoodiga. Pealegi - oluline punkt - selgus, et Datamatrix ei ole tavaline, vaid pöördvõrdeline. See tähendab, et mitte must kood valgel, vaid vastupidi.
Testisime oma skännereid ja selgus, et enamus neist vajavad uuesti värskust/õpetamist, muidu nad lihtsalt ei suuda selle vöötkoodiga normaalselt töötada. Asjade selline pööre tagas meile tugeva peavalu, sest meie ettevõttel on palju kauplusi, mis on laiali laiali laiali. Mitukümmend tuhat kassaaparaati – ja väga vähe aega.
Mida tuli teha? On kaks võimalust. Esiteks: kohapealsed insenerid värskendavad ja reguleerivad skannereid käsitsi. Teiseks: töötame eemalt ja eelistatavalt katame ühe iteratsiooniga korraga palju skannereid.
Esimene variant meile ilmselgelt ei sobinud: me peaksime kulutama raha külalisinseneride peale ja sel juhul oleks protsessi keeruline kontrollida ja koordineerida. Kuid kõige tähtsam on see, et inimesed töötaksid, see tähendab, et me saaksime potentsiaalselt palju vigu ja suure tõenäosusega ei peaks kinni tähtajast.
Teine variant sobib kõigile, kui mitte ühe asja jaoks. Mõnel müüjal polnud kaugvilkumise tööriistu, mida vajasime kõigi vajalike operatsioonisüsteemide jaoks. Ja kuna tähtajad hakkasid otsa saama, siis pidin oma peaga mõtlema.
Järgmisena räägime teile, kuidas arendasime Debian 9.x OS-i jaoks mõeldud käsiskannerite tööriistu (kõik meie kassaaparaadid on Debianis).
Lahendage mõistatus: kuidas skannerit vilkuda
Victor Antipov teatab.
Müüja pakutav ametlik utiliit töötab Windowsis ja ainult IE-ga. Utiliit võib vilkuda ja skannerit konfigureerida.
Kuna meie sihtsüsteem on Debian, installisime Debiani usb-redirector-serveri ja Windowsi usb-redirector-kliendi. USB-redirector utiliitide abil edastasime skanneri Linuxi masinast Windowsi masinasse.
Windowsi müüja utiliit nägi skannerit ja isegi vilgutas seda normaalselt. Seega tegime esimese järelduse: OS-ist ei sõltu midagi, asi on vilkuvas protokollis.
OKEI. Käivitasime Windowsi masinas vilkumise ja Linuxi masinas eemaldasime prügila.
Toppisime prügimäe WireSharki ja... muutusime kurvaks (jätan mõned prügimäe üksikasjad välja, need ei paku mingit huvi).
Mida prügimägi meile näitas:
Aadressid 0000-0030 on Wiresharki järgi otsustades USB-teenuse teave.
Meid huvitas osa 0040-0070.
Ühest edastuskaadrist polnud midagi selget peale MOCFT-märkide. Need märgid osutusid püsivara faili tähemärkideks, aga ka ülejäänud tähemärgid kuni kaadri lõpuni (püsivarafail on esile tõstetud):
Mida sümbolid fd 3e 02 01 fe tähendasid, polnud mul isiklikult, nagu ka Iljal, õrna aimugi.
Vaatasin järgmist raami (teenuseteave on siit eemaldatud, püsivara fail on esile tõstetud):
Mis selgus? Et esimesed kaks baiti on mingi konstant. Kõik järgnevad plokid kinnitasid seda, kuid enne edastusploki lõppu:
See kaader oli ka jahmatav, kuna konstant oli muutunud (esile tõstetud) ja kummalisel kombel oli osa failist. Faili ülekantud baitide suurus näitas, et edastati 1024 baiti. Ma jälle ei teadnud, mida ülejäänud baidid tähendavad.
Kõigepealt vaatasin vana BBS-i hüüdnimena üle standardsed edastusprotokollid. Ükski protokoll ei edastanud 1024 baiti. Hakkasin riistvara õppima ja leidsin 1K Xmodem protokolli. See võimaldas edastada 1024, kuid mööndusega: alguses ainult 128 ja ainult siis, kui vigu ei esinenud, suurendas protokoll edastatavate baitide arvu. Mul oli kohe ülekanne 1024 baiti. Otsustasin uurida edastusprotokolle ja täpsemalt X-modemi.
Modemit oli kaks varianti.
Esiteks CRC8 toega XMODEM paketivorming (algne XMODEM):
Teiseks XMODEM-paketivorming koos CRC16 toega (XmodemCRC):
See näeb välja sarnane, välja arvatud SOH, pakendi number ja CRC ning pakendi pikkus.
Vaatasin teise edastusploki algust (ja nägin jälle püsivara faili, kuid juba taandatud 1024 baiti):
Nägin tuttavat päist fd 3e 02, kuid järgmised kaks baiti olid juba muutunud: see oli 01 fe ja sai 02 fd. Siis märkasin, et teine plokk kannab nüüd numbrit 02 ja sain seega aru: minu ees oli ülekandeploki numeratsioon. Esimene 1024 käik on 01, teine on 02, kolmas on 03 ja nii edasi (aga muidugi kuusnurkselt). Aga mida tähendab üleminek fe-lt fd-le? Silmad nägid vähenemist 1 võrra, aju tuletas meelde, et programmeerijad loevad 0-st, mitte 1-st. Aga miks siis esimene plokk on 1, mitte 0? Ma pole ikka veel sellele küsimusele vastust leidnud. Aga ma sain aru, kuidas teist plokki loetakse. Teine plokk pole midagi muud kui FF – (miinus) esimese ploki number. Seega määrati teine plokk = 02 (FF-02) = 02 FD. Prügimäe hilisem lugemine kinnitas minu oletust.
Siis hakkas ülekandest ilmnema järgmine pilt:
Edastamise algus
fd 3e 02 – Start
01 FE – ülekandeloendur
Edastamine (34 plokki, 1024 baiti üle kantud)
fd 3e 1024 baiti andmeid (jagatud 30-baidilisteks plokkideks).
Edastamise lõpp
fd 25
Ülejäänud andmed tuleb joondada 1024 baidiga.
Kuidas näeb välja ploki ülekande otsaraam:
fd 25 – signaali edastamine ploki lõpuni. Järgmine 2f 52 – ülejäänud fail kuni 1024 baiti suurune. 2f 52 on protokolli järgi otsustades 16-bitine CRC kontrollsumma.
Vanade aegade huvides tegin C-s programmi, mis tõmbas failist 1024 baiti ja arvutas 16-bitise CRC. Programmi käivitamine näitas, et see pole 16-bitine CRC. Jälle stuupor – umbes kolm päeva. Kogu selle aja püüdsin aru saada, mis see võiks olla, kui mitte kontrollsumma. Ingliskeelseid saite uurides avastasin, et X-modem kasutab oma kontrollsumma arvutamist – CRC-CCITT (XModem). Ma ei leidnud selle arvutuse C-rakendusi, kuid leidsin saidi, mis arvutas selle kontrollsumma võrgus. Pärast minu faili 1024 baiti veebilehele ülekandmist näitas sait mulle kontrollsummat, mis vastas täielikult faili kontrollsummale.
Hurraa! Viimane mõistatus sai lahendatud, nüüd oli vaja teha oma püsivara. Järgmiseks andsin oma teadmised edasi (ja need jäid vaid pähe) Iljale, kes on tuttav võimsa tööriistakomplektiga Python.
Programmi loomine
Ilja Aleshin teatab.
Olles saanud asjakohased juhised, olin väga "õnnelik".
Kust alustada? See on õige, algusest peale. USB-pesast tühjendamisest.
Käivitage USB-pcap
Valige port, millega seade on ühendatud, ja fail, kuhu me prügi salvestame.
Ühendame skanneri masinaga, kuhu on installitud Windowsi jaoks mõeldud EZConfigScanning tarkvara.
Sellest leiame üksuse seadmele käskude saatmiseks. Aga kuidas on lood meeskondadega? Kust ma neid saan?
Kui programm käivitub, küsitakse seadmeid automaatselt (seda näeme veidi hiljem). Ja seal olid ametlikest varustusdokumentidest väljaõppe vöötkoodid. DEFALT. See on meie meeskond.
Vajalikud andmed on laekunud. Avage wiresharki kaudu dump.pcap.
Blokeeri EZConfigScanningi käivitamisel. Kohad, millele peate tähelepanu pöörama, on märgitud punasega.
Seda kõike esimest korda nähes läks mul süda pahaks. Pole selge, kust edasi kaevata.
Väike ajurünnak ja-ja-ja... Ahaa! Prügilas välja - Kas inJa in это välja.
Uurisin googeldades, mis on URB_INTERRUPT. Sain teada, et see on andmeedastusviis. Ja selliseid meetodeid on 4: juhtimine, katkestamine, isokroonne, hulgi. Nende kohta saate lugeda eraldi.
Ja USB-seadme liidese lõpp-punkti aadressid saab hankida kas käsu "lsusb –v" või pyusb abil.
Nüüd peame leidma kõik selle VID-iga seadmed. Saate otsida konkreetselt VID:PID järgi.
See näeb välja selline:
Niisiis, meil on vajalik teave: P_INFO käsud. või DEFALT, aadressid, kuhu kirjutada käske endpoint=03 ja kust saada vastus endpoint=86. Jääb üle vaid käsud hex-vormingusse teisendada.
Kuna oleme seadme juba leidnud, ühendame selle kernelist lahti...
...ja kirjutage lõpp-punkti aadressiga 0x03,
... ja seejärel lugege vastust lõpp-punktist aadressiga 0x86.
Struktureeritud vastus:
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: 0x6986Neid andmeid näeme failis dump.pcap.
Suurepärane! Teisenda süsteemi vöötkoodid kuueteistkümnendikku. See on kõik, treeningu funktsionaalsus on valmis.
Aga püsivara? Tundub, et kõik on sama, kuid seal on nüanss.
Pärast vilkumise protsessi täielikku prügimägemist saime laias laastus aru, millega tegu. Siin on artikkel XMODEMi kohta, mis aitas väga hästi mõista, kuidas see suhtlus toimub, kuigi üldiselt: Soovitan seda lugeda.
Prügipilti vaadates näete, et kaadri suurus on 1024 ja URB-andmete suurus on 64.
Seega – 1024/64 – saame plokis 16 rida, loeme püsivara faili 1 märgi kaupa ja moodustame ploki. 1 rea täiendamine plokis erimärkidega fd3e02 + ploki number.
Järgmisele 14 reale lisatakse fd25 +, kasutades XMODEM.calc_crc() arvutame välja kogu ploki kontrollsumma (kulus palju aega, et aru saada, et “FF – 1” on CSUM) ja viimast, 16. rida täiendatakse koos fd3e-ga.
Näib, et see on kõik, lugege püsivara faili, lööge plokkidele, ühendage skanner kernelist lahti ja saatke see seadmesse. Kuid see pole nii lihtne. Skanner tuleb lülitada püsivara režiimi,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Kust see meeskond pärit on?? Prügimäelt.
Kuid me ei saa 64 piirangu tõttu skannerisse saata tervet plokki:
Noh, NEWAPP-i vilkumisrežiimis olev skanner ei aktsepteeri hex-i. Seetõttu peate iga rea bytes_array tõlkima
[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]Ja seejärel saatke need andmed skannerisse.
Saame vastuse:
[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]Kui vaatate artiklit XMODEMi kohta, selgub: andmed on vastu võetud.
Kui kõik plokid on üle kantud, viime ülekande lõpule END_TRANSFER = 'xfdx01x04'.
Noh, kuna need plokid ei kanna tavainimeste jaoks mingit teavet, installime püsivara vaikimisi peidetud režiimis. Ja igaks juhuks korraldame tqdm-i kaudu edenemisriba.
Tegelikult on see pisiasjade küsimus. Jääb üle vaid mähkida lahendus masstiplikatsiooniks selgelt määratletud ajal skriptidesse, et mitte aeglustada kassades töötamist, ja lisada logimine.
Summaarne
Olles kulutanud palju aega ja vaeva ning juukseid pähe, saime välja töötada vajalikud lahendused ning pidasime ka tähtajast kinni. Samal ajal on skannerid nüüd tsentraalselt uuendatud ja ümberõpetatud, meie kontrollime selgelt kogu protsessi. Ettevõte hoidis kokku aega ja raha ning saime hindamatu kogemuse seda tüüpi pöördprojekteerimisseadmete vallas.
Allikas: www.habr.com