Ablakok.  Vírusok.  Jegyzetfüzetek.  Internet.  hivatal.  Segédprogramok.  Drivers

Kezdjük a minimummal:
tartalmazza 18f2455 -- könyvtár a használt MK-hoz
--
enable_digital_io() -- minden bemenetet digitális módba kapcsolni
--
álnév gomb van pin_B7 -- mivel van egy gomb csatlakoztatva, deklaráld
pin_B7_direction = bemenet -- a gomb nálunk működik a bejáratnál
--
-- egy sor - és mindent megtalálunk, ami az USB CDC-vel való munkához szükséges
tartalmazza az usb_serial -- usb könyvtárat
--
usb_serial_init() -- --inicializálja az USB CDC-t
örök hurok-- főhurok, folyamatosan fut
usb_serial_flush() -- usb frissítés. Ez az eljárás minden szükségeset megtesz
-- a számítógéppel való kapcsolat fenntartására irányuló műveletek
vég hurok

Összeállítás adott kódot Az eredményül kapott HEX fájlt bootloader segítségével az MK-ba írva és az eszközt elindítva megfigyelhetjük, hogyan definiálódik egy új eszköz a rendszerben: Virtuális com-port.

Most, hogy az eszköz már működik, tanítsuk meg kommunikálni.

A fogadott bájt olvasásához van egy funkció usb_serial_read( byte ) :boolean. Ha van fogadott bájt, azt a megadott változóban tárolja és visszaadja igaz, ellenkező esetben visszatér hamis.

Van egy eljárás egy bájt küldésére usb_serial_data. Változónak van álcázva, tehát egy bájt küldéséhez elég hozzárendelni a küldendő bájt értékét.

A main ciklus előtt deklaráljunk egy bájt méretű változót, a főhurokban ellenőrizzük a vett bájtok meglétét, és ha van, küldjük vissza.

tartalmazza a 18f2455
--
enable_digital_io()
--
álnév gomb van pin_B7
pin_B7_direction = bemenet
--
--
tartalmazza az usb_serial
--
usb_serial_init()
var byte ch -- deklarál egy változót
örök hurok-- főhurok
usb_serial_flush()
ha(usb_serial_read(ch)) akkor-- ha egy bájt érkezik, az a ch-be lesz írva
usb_serial_data=ch -- küldje vissza a fogadott bájtot
vége ha
vég hurok

Lefordítjuk, nyomva tartjuk a gombot, torzítjuk a tápfeszültséget, elindítjuk a bootloadert, megváltoztatjuk a firmware-t, elindítjuk.
A készülék ismét észlelésre került a rendszerben, most szoftverre van szükségünk a készülék működésének teszteléséhez.

Miközben nincs sajátunk, egy kész terminált használunk: én a RealTerm programot használtam.
Megnyitjuk a portot a kívánt számmal és elküldjük az adatokat.


És visszakapjuk, amit küldtünk. Szóval minden úgy működik ahogy kell.

Puha

Tehát a mikrokontrollerünk képes bájtokat fogadni és azonnal visszaküldeni. Most írjuk meg a saját szoftverünket, hogy kommunikáljunk vele (én a Delphi-t fogom használni).

Mi alkotunk új projekt, a szükséges komponenseket a következő formában szórjuk ki:
SpinEdit1 – a portszám megadása
Button1 - kapcsolat létrehozása
2. gomb – a kapcsolat megszakításához
SpinEdit2 – egy bájt decimális formátumú bevitele
Button3 - egy bájt küldése
Memo1 - a fogadott információk megjelenítéséhez.

Mint fentebb említettük, a com-porttal ugyanúgy kell dolgozni, mint egy normál porttal. szöveges fájl: A CreateFile, WriteFile és ReadFile funkciók használata.

Hogy ne menjünk bele a részletekbe, vegyünk egy kész könyvtárat a com porttal való munkához: ComPort.

Minden gombra felakasztjuk a szükséges feladatot, és megkapjuk a végső kódot:

egység Egység1;

felület

használ
Windows, Üzenetek, SysUtils, Változatok, Osztályok, Grafika , Vezérlők, Űrlapok,
Dialógusok, StdCtrls, Spin, ComPort;

típus
TForm1 = osztály(TForm)
SpinEdit1: TSpinEdit;
Button1: TButton;
2. gomb: TButton;
SpinEdit2: TSpinEdit;
3. gomb: TButton;
Memo1:TMemo;
procedúra OnRead(Sender: TObject; ReadBytes: Byte tömb );
eljárás Button1Click(Sender: TObject);
eljárás Button2Click(Sender: TObject);
eljárás FormDestroy(Küldő: TObject);
eljárás Button3Click(Sender: TObject);
magán
(Privát nyilatkozatok)
Port: TComPort;
nyilvános
(Nyilvános nyilatkozatok)
vége;

var
Form1: TForm1;
szám: egész szám;
végrehajtás

Eljárás TForm1.Button1Click(Sender: TObject);
kezdődik
Port:= TComPort.Create(SpinEdit1.Value, br115200); // kapcsolat létrehozása
Port.OnRead:= OnRead; //folyamat létrehozása a fogadott adatok olvasásához
Button2.Enabled:= true ; //aktiválja a kapcsolat záró gombot
vége;

Eljárás TForm1.Button2Click(Sender: TObject);
kezdődik
Port Free; //zárja a kapcsolatot
Button2.Enabled:= false ; //letiltja a gombot
vége;

Eljárás TForm1.Button3Click(Sender: TObject);
kezdődik
ha Button2.Enabled, akkor Port.Write();
vége;

Eljárás TForm1.FormDestroy(Küldő: TObject);
kezdődik
ha Button2.Engedélyezve akkor
Port Free;
vége;

Eljárás TForm1.OnRead(Küldő: TObject; ReadBytes: bájtok tömbje );
var
i:integer;
kezdődik
for i:= Low(ReadBytes) to High(ReadBytes) do //átmennek a fogadott bájtok tömbjén
kezdődik
Memo1.Text:= Memo1.Text + "." +InttoHex(ReadBytes[i],2); //adja hozzá a HEX értékét az ablakhoz
inc(szám); //számolja meg a fogadott bájtok számát
vége;
ha a szám > 10, akkor indítsa el
Memo1.Lines.Add("" ); //átviteli vonal
szám:=0;
vége;
vége;

Elkezdjük, kapcsolatot létesítünk, bájtokat küldünk:

Így a legegyszerűbb terminálunk készen áll a legegyszerűbb USB-eszközzel való együttműködésre.

Mint látható, az olvasás és az írás dinamikus bájttömbök.

A kapott információk feldolgozásával lehetőség nyílik az aktuális feladatnak megfelelő csereprotokoll elkészítésére.

tartalmazza a 18f2455
--
enable_digital_io()
--
álnév gomb van pin_B7
pin_B7_direction = bemenet
--
--
tartalmazza az usb_serial
--
usb_serial_init()
var byte ch
var byteén -- deklarálja a második változót
örök hurok-- főhurok
usb_serial_flush()
ha(usb_serial_read(ch)) akkor-- ha a bájt megérkezett, hajtsa végre a szükséges műveleteket
ügy ch of -- iterálja a bájtszámot
0 : usb_serial_data = 0xff
1 : usb_serial_data = Gomb -- küldés gomb állapota
MÁSKÉPP Blokk-- ha más érkezik
számára 16 segítségévelén hurok-- küldjön 10 bájtnyi adatot
usb_serial_data = ch +i -- ch - ch+15
vég hurok
végblokk
végügy
vége ha
vég hurok

További jellemzők

Ha itt abbahagyja, kap egy rendes cikket Részletes leírás egy példa a könyvtár használatára, amelyből elég sok van a weben. Ezért adok hozzá egy kicsit részletesebb információkat.

Egyszerűsítse az adatok küldését

Az információ egy bájtonkénti küldése nem mindig kényelmes. A könyvtár nagyon hasznos lehet nyomtatás. Eljárásokat tartalmaz minden lehetséges hosszúságú adat küldésére minden lehetséges formátumban: byte, hex, dec, bin, boolean, ami leegyszerűsítheti az adatok kimenetét a programban.
> nyomtatást is tartalmaz
...
vardword adat
print_dword_hex (usb_serial_data , data )

Az összes parancs neve megtalálható a könyvtárfájlban.

Várakozás a számítógéphez való csatlakozásra

Ha a mikrokontroller fő ciklusának elindítása előtt először létre kell hozni egy kapcsolatot a számítógéppel, akkor hozzáadhatja a sorokat előtte
míg(usb_cdc_line_status() == 0x00) hurok
vég hurok

Kösse össze a port számát az eszközzel

Ha mindent a régiben hagy, a rendszer minden új kapcsolathoz kiosztja az első szabad portszámot. És ez azt jelenti, hogy szemmel kell tartania.
Ennek elkerülése érdekében egyedi sorozatszámot kell rendelnie az eszközhöz, mielőtt csatlakoztatná az USB-könyvtárat:
A szám bármilyen hosszúságú lehet, és különböző karaktereket tartalmazhat.
const byte USB_STRING3=
{
24 , -- tömb hossza
0x03 , --bDescriptorType
"0" , 0x00 ,
"1" , 0x00 ,
"2" , 0x00 ,
"3" , 0x00 ,
"4" , 0x00 ,
"5" , 0x00 ,
"6" , 0x00 ,
"7" , 0x00 ,
"8" , 0x00 ,
"9" , 0x00 ,
"X" 0x00
}

Módosítsa az eszköz nevét a sajátjára

Megváltoztathatja a rendszerben látható eszköz nevét az illesztőprogramok telepítése előtt, ha deklarál egy tömböt a névvel, mint a sorozatszám, ezt az USB-könyvtár csatlakoztatása előtt kell megtenni.
const byte USB_STRING2=
{
28 , --
0x03 , --bDescriptorType
"D", 0x00 ,
"e", 0x00 ,
"m", 0x00 ,
"o", 0x00 ,
" " , 0x00 ,
"B", 0x00 ,
"o", 0x00 ,
"a", 0x00 ,
"r", 0x00 ,
"d", 0x00 ,
" " , 0x00 ,
"=" , 0x00 ,
")" 0x00
}

De sajnos az illesztőprogramok telepítése után a készülék az .inf fájlban megadottra változtatja a nevét, így ott is változtatjuk a nevet


DESCRIPTION="Demo CDC"

Megszervezzük a készülék automatikus csatlakoztatását

Sajnos nincs közvetlen végrehajtási mód ez a feladat nem, mert kitalálni kell.

Mindenekelőtt egyedi gyártót és termékértéket kell hozzárendelnie az eszközéhez, hogy könnyen azonosíthassa azt több száz egyéb szabványos CDC firmware között.
A VID-et és a PID-et pénzért adják ki, úgyhogy menjünk a kínaiak útján: vegyünk magunknak csendben nyilvánvalóan szabad értékeket.

Firmware:
Az USB-könyvtár csatlakoztatása előtt két változót kell deklarálni a firmware-ben

const szó USB_SERIAL_PRODUCT_ID = 0xFF10
const szó USB_SERIAL_VENDOR_ID = 0xFF10

Az FF10 helyett tetszőleges két szót (2 bájt) beszúrhat. A végeredményt a mellékelt archívum tartalmazza.

Illesztőprogramok:
Mivel az illesztőprogramokat nem a mi VID és PID kombinációnkhoz tervezték, értékeinket kézzel fogjuk hozzáadni az .inf fájlhoz:


%DESCRIPTION%=Illesztőprogram telepítése, USB\VID_FF10&PID_FF10


%DESCRIPTION%=Illesztőprogram telepítése, USB\VID_FF10&PID_FF10

Puha:
Az eszköz csatlakozási/leválasztási eseményeinek észleléséhez csatlakoztatjuk a ComponentUSB könyvtárat. Nem tartom szükségesnek minden sor magyarázatát: minden változás a mellékelt projektben látható.

Eredmény

A képernyőképen nehezen látszik, de a küldés gomb csak akkor aktív, ha van csatlakoztatott eszköz, és 50 ms-onként küld egy kérést a program a gomb állapotának lekérésére (ami azonban hibás, mert a gombnyomást feldolgozni kell az MK-n).

Mint látható, az MK és a PC közötti adatcsere megszervezése USB-n keresztül nem a legnehezebb feladat. Az így létrejövő kapcsolat nem csak végső célokra használható, hanem egy program hibakeresésére is alkalmas. Hiszen a számítások eredményeit, a regiszterek és a változók aktuális állapotát számítógépre küldeni sokkal világosabb, mint morze-kódban villogni egy LED-párt.

És végül azt tanácsolom, hogy nézzen utána forrás hangulatlámpák. Jó párat találhatsz ott. jó lehetőség a kapott adatok feldolgozása egy kényelmes csereprotokoll megszervezéséhez.

Jó könyv, sok mindent elmagyaráz. Hasznos azok számára, akik szeretnék megérteni, hogyan történik az adatok átvitele az USB buszon keresztül.

Bevezetés 1
Kinek szól ez a könyv: 2
Mit találsz a 2. könyvben
Szoftverkövetelmények 3
Hardverkövetelmények 4
A 4-es kódról
A 4. fejezetek rövid leírása
6. jelölés
Köszönöm 7
I. RÉSZ. BEVEZETÉS AZ USB-BE 9
1. fejezet Mi az az USB 11
1.1. Az USB 11 története
1.2. Az USB összehasonlítása más interfészekkel 14
1.3. USB alapfogalmak 16
1.3.1. Általános busz architektúra 16
1.3.2. Fizikai és logikai busz architektúra 16
1.3.3. Az USB 18 összetevői
1.3.4. USB-eszköz tulajdonságai 18
1.3.5. Hub tulajdonságai 19
1.3.6. Gazdatulajdonságok 20
1.4. Példák USB-eszközökre 20
1.4.1. Egér és billentyűzet., 21
1.4.2. Monitorok 21
1.4.3. USB-COM és USB-LPT 22 adapterek
1.4.4. Szkennerek 23
1.4.5. Modemek 23
1.4.6. Hangszórók 24
1.4.7. Flash meghajtók 25
1.4.8. Hubok 28
1.4.9. Mérési technológia 28
1.4.10. Egzotikus kütyük 29
1.5. internetkapcsolat USB 30-on keresztül
1.5.1. USB-Ethernet konverter 31
1.5.2. Közvetlen csatlakozás a 31-es USB-porton keresztül
1.6. Adatátvitel 31
1.6.1. Kommunikációs alapelvek 32
1.6.2. Megszakítási mechanizmus 32
1.6.3. Gazda adapter interfészek 32
1.6.4. Közvetlen memóriaelérési képesség 34
1.6.5. Kommunikációs módok 34
1.7. USB-eszközök telepítése és konfigurálása 35
1.7.1. BIOS beállítások USB 38-hoz
1.7.2. Hibaelhárítás 41
1.8. USB-korlátok 45
1.9. Ha számítógépet vásárol 46
1.9.1. A HS és az USB 2.0 nem ugyanaz! 46
1.9.2. Alaplap 47
1.9.3. 48-as épület
1.9.4. USB „régebbi” számítógéptípusokhoz 48
1.10. Online források ehhez a fejezethez 49
2. fejezet Hardver USB 51
2.1. Kábelek és csatlakozók 51
2.1.1. Kábeltípusok 52
2.1.2. Kábel hossza 53
2.1.3. Csatlakozók 53
2.2. Fizikai interfész 55
2.2.1. Adatkódolás 57
2.2.2. A készülék azonosítása 58
2.3. Táplálkozás 59
2.3.1. Az USB-eszközök energiatípusai 59
2.3.2. Energiagazdálkodás 60
2.3.3. Belépés az üzemmódba alacsony energia fogyasztás 61
2.4. Online források ehhez a fejezethez 61
RÉSZ II. USB BELSŐ SZERVEZET 63
3. fejezet A gumiabroncs belső felépítése 65
3.1. A kommunikáció logikai szintjei 65
3.1.1. Kliensszoftver szint 66
3.1.2. USB-rendszer-illesztőprogram-szint 67
3.1.3. Interfész Host Controller 68. szint
3.1.4. Perifériabusz 68-as szint
3.1.5. USB logikai eszközszint 69
3.1.6. Az USB-eszköz működési szintje 69
3.2. Réteges adatátvitel 69
3.3. Az adatátvitel típusai 71
3.4. Szinkronizálás izokron átvitellel 73
3.5. Személyzet 77
3.6. Végpontok 78
3.7. 79. csatornák
3.8. Csomagok 81
3.8.1. Az IN, OUT, SETUP és PING 83 token csomagok formátuma
3.8.2. SOF 83 csomagformátum
3.8.3. Adatcsomag formátum 84
3.8.4. Nyugtázó csomag formátum< 84
3.8.5. SPLIT * 84 csomag formátum
3.9. Ellenőrző összeg 85
3.9.1. CRC számítási algoritmus 86
3.9.2. A CRC 87 szoftveres számítása
3.10. Tranzakciók 90
3.10.1. Tranzakciótípusok 91
3.10.2. Tranzakció megerősítése és folyamatvezérlés 92
3.10.3. Tranzakciós protokollok 93
4. fejezet A készülék belső felépítése 96
4.1. Kérések USB-eszközökhöz 96
4.1.1. 96. konfigurációs csomag
4.1.2. Normál eszközlekérdezések 99
4.1.3. Eszközleírók 105
5. fejezet A gazdagép és a hubok belső felépítése 123
5.1. Hubok 123
5.1.1. A gazdagép vezérlő interakciója a hubbal 126
5.1.2. Hub leíró 127
5.1.3. A hub 129-et kér
5.1.4. CLEAR_HUB_FEATURE 130 kérése
5.1.5. Kérje a CLEAR PORT_FEATURE 130-at
5.1.6. Kérjen GET_BUS_STA TE 131-et
5.1.7. GET_HUB_DESCRfPTOR 131 kérése
5.1.8. GET_HUB_STATUS kérése 131
5.1.9. GET_PORT_STA TUS 132 kérése
5.1.10. SET_HUB_DESCRIPTOR 134 kérése
5.1.11. A SET_HUB_FEATURE 134. kérése
5.1.12. PORT FUNKCIÓ BEÁLLÍTÁSA kérés. 134
5.2. Együttműködés eszközökkel különböző sebességeket 135
6. fejezet USB számítógép nélkül 137
6.1. OTG csatlakozók 138
6.2. Az OTG-eszközök típusai 138
6.3. OTG-eszközleíró 139
6.4. Online források ehhez a fejezethez 140
RÉSZ III. PROGRAMOZÁSI GYAKORLAT 141
7. fejezet USB támogatás Windows 143 rendszeren
7.1. WDM 144 modell
7.2. Interakció az USB-illesztőprogrammal 146
8. fejezet Rejtett eszközök * 149
8.1. HID eszköz tulajdonságai 149
8.2. Kommunikáció HID-eszközzel 151
8.3. HID-eszköz telepítése 152
8.4. HID eszközazonosító 152
8.4.1. A rendszerindító eszközök azonosítása 153
8.4.2. HID eszköz konfigurációs leíró 153
8.4.3. HID-leíró 154
8.4.4. Jelentésleíró 156
8.5. Jelentésleíró szerkezete 156
8.5.1. A jelentéselemek felépítése 156
8.5.2. Jelentéstételtípusok 157
8.5.3. Leíró példák 165
8.6. Kérések a HID eszközhöz 168
8.6.1. GET_REPORT kérés. 169
8.6.2. SET_REPORT kérés 169
8.6.3. GETJDLE kérés. 170
8.6.4. SETJDLE 170 kérése
8.6.5. GET_PROTOCOL 171 kérése
8.6.6. SET_PROTOCOL 171 kérése
8.7. Eszközök 171
8.8. Interakció a HID illesztőprogrammal 172
9. fejezet Bevezetés a WDM 181-be
9.1. Illesztőprogram-rétegek 183
9.2. Szimbolikus eszköznevek 184
9.3. A WDM illesztőprogram alapvető eljárásai 189
9.3.1. Eljárás DriverEntry 190
9.3.2. AddDevice eljárás 192
9.3.3. Letöltési eljárás 194
9.3.4. A járművezető kezelési eljárásai 196
9.3.5. IOCTL 203 kérések kiszolgálása
9.4. Az illesztőprogram betöltése és az illesztőprogram hívása 209
9.4.1. A járművezető működési eljárása 209
9.4.2. Járművezetői regisztráció 210
9.4.3. Munkafolyamatokra hivatkozva 217
9.4.4. A vezető tárolása bent futtatható fájl 218
9.5. Illesztőprogram-létrehozó eszközök 220
9.5.1. NuMega Driver Studio 220
9.5.2. Jungo WinDriver 220
9.5.3. Jungo Kernel Driver 220
10. fejezet USB PnP specifikáció 221
10.1. Általános információ a Plug and Play rendszerről 221
10.1.1. Plug and Play feladatok és funkciók 221
10.1.2. PnP-eljárás indítása 222
10.1.3. PnP szoftverösszetevők 224
10.2. Plug and Play USB 225-höz
10.2.1. USB-eszközök konfigurálása 226
10.2.2. 226-os USB-eszköz
10.2.3. PnP USB-eszközazonosítók 228
10.3. Az USB-eszközök listájának lekérése 229
10.4. INF fájl 234
10.4.1. INF fájlszerkezet 234
10.4.2. szakasz 235-ös verzió
10.4.3. Gyártó 237. sz
10.4.4. Destination Dirs 239. szakasz
10.4.5. 241-es modell leírása
10.4.6. Az xxx.AddReg és az xxx.DelReg szakasz. 242
10.4.7. Section xxx.LogConfig 244
10.4.8. Section xxx.CopyFiles 244
10.4.9. szakasz Strings 245
10.4.10. A szakasz linkjei 246
10.4.11. INF-fájlok létrehozása és tesztelése 247
10.4.12. Eszközök telepítése INF-fájl használatával 248
10.5. Registry ágak az USB 249-hez
11. fejezet BIOS-szolgáltatások 251
11.1. BIOS szolgáltatás 1AH 251
11.1.1. B101H funkció - a PCI BIOS 252 jelenlétének észlelése
11.1.2. Funkció В102Н - PCI-eszköz keresése azonosítók alapján
készülék és gyártó 253
11.1.3. B103H funkció - PCI-eszköz keresése a 254-es osztálykód alapján
11.1.4. Funkció B108H – konfigurációs regiszter olvasása (byte) 255
11.1.5. ВУ9Н funkció - konfigurációs regiszter (Word) olvasása 256
11.1.6. B10AN funkció - konfigurációs regiszter (DWord) olvasása 256
11.1.7. В10ВН funkció - konfigurációs regiszter írása (byte) 257
11.1.8. B10CH funkció - konfigurációs regiszter írása (Word) 257
11.1.9. B10DH funkció – Konfigurációs regiszter írása (DWord) 258
11.2. 259. használati példa
RÉSZ IV. USB-ESZKÖZÖK LÉTREHOZÁSA 283
12. fejezet USB-perifériák 285
12.1. Chips Atmel 286
12.1.1. Mikrokontrollerek MSC-51 architektúrával 286
12.1.2. Hub vezérlők 289
12.1.3. Mikroprocesszor hubok AVR 289 maggal
12.1.4. Egyéb Atmel 290 IC
12.2. Chignal 291 chip
12.2.1. C8051F320 és C8051F321 mikroprocesszorok 291
12.2.2. Egyéb Cygnal 293 IC-k
12.3. FTDI 296 chipek
12.3.1. FT232AM és FT232BM 297 chipek
12.3.2. FT245AM és FT245BM 298 chipek
12.3.3. Chip FT2232BM 299
12.3.4. Chip FT8U100AX 300
12.3.5. Hibakereső készletek és modulok 301
12.3.6. Sofőrök 302
12.3.7. További segédprogramok 303
12.3.8. Egyéb modulok 304
12.4. Intel 304 chipek
12.5. Chip Microchip 308
12.6. Motorola 308 IC-k
12.7. Philips 309 chipek
12.7.1. Mikrochip USB 310
12.7.2. Hub 311
12.7.3. Egyéb Philips 313 chipek
12.8. Mikroáramkörök Texas Instruments 314
12.9. Chips Trans Dimenzió 317
12.10. Áramvédelmi IC-k 318
12.11. Online források ehhez a fejezethez 319
13. fejezet Atmel AT89C5131 HID Device 322
13.1. A АТ89С5131 322 szerkezeti diagramja
13.2. Az USB-regiszterek AT89C5131 324
13.2.1. Regisztrálja az USBCON 324-et
13.2.2. Regisztrálja az USBADDR 326-ot
13.2.3. Regisztrálja az USBINT 327-et
13.2.4. Regisztrálja az USBIEN 328-at
13.2.5. UEPNUM regiszter. 329
13.2.6. Regisztrálja az UEPCONX 330-at
13.2.7. UEPSTAX nyilvántartás. 331
13.2.8. UEPRST nyilvántartás. 334
13.2.9. UEPINT nyilvántartás. 335
13.2.10. Regisztrálja az UEPIEN 336-ot
13.2.11. Regisztrálja az UEPDATX 337-et
13.2.12. Regisztrálja az UBYCTLX 337-et
13.2.13. Regisztrálja az UFNUML 338-at
13.2.14. Regisztrálja az UFNUMH-t. 338
13.3. AT89S5131 338 áramkör
13.4. Programozási eszközök 339
13.4.1. 341. fordító
13.4.2. Programozó 342
13.5. Program a 349-es mikroprocesszorhoz
13.5.1. A program első verziója a АТ89С5131 349-hez
13.5.2. Karakterlánc-leírók hozzáadása 369
13.5.3. Végpontok hozzáadása 374
13.5.4. HID eszköz létrehozása 377
13.5.5. Kommunikáció HID eszközzel 381
13.6. Jelentések olvasása Windows 388 rendszerben
13.7. További funkciók Windows XP 396
13.8. Több jelentéssel rendelkező eszköz 397
14. fejezet ATMEL AT89C5131 USB-eszköz létrehozása 402
14.1. Nem HID eszköz 402
14.2. Illesztőprogram létrehozása a Sofőr Stúdió 405
14.2.1. Néhány szó a Driver Studio 407 könyvtárról
14.2.2. Egyéb Driver Studio 411 osztályok
14.2.3. Illesztőprogram-sablon létrehozása a Driver Studio 412 segítségével
14.2.4. A 422-es illesztőprogram-sablon finomítása
14.2.5. Eszközosztály-alapmódszerek 423
14.2.6. Adatolvasás megvalósítása 426
14.2.7. Illesztőprogram telepítése 428
14.2.8. Adatolvasó 429
14.2.9. Adatok olvasása más típusú végpontokból 438
14.2.10. Tisztítsa meg az USB-illesztőprogramot 439
15. fejezet FTDI 457 chipek használata
15.1. Funkcionális diagram FT232BM 457
15.2. Áramkör FT232BM 460
15.3. Funkciók D2XX 460
15.4. Áttérés COM-ról USB 465-re
15.4.1. 465 Átalakító áramkör leírása
15.4.2. Az adatátviteli sebesség beállítása 467
V. RÉSZ KÉZIKÖNYV 469
16. fejezet ablakok jellemzői 471
16.1. CreateFile és CloseHandle függvények: objektum megnyitása és bezárása.471
16.1.1. További információ 472
16.1.2. Visszatérési érték 472
16.1.3. Hívja a 472-es példát
16.2. Fájl olvasási funkció: Adatok olvasása 473
16.2.1. További információ 474
16.2.2. Visszatérési érték 474
16.2.3. Hívja a 474-es példát
16.3. WriteFile funkció: Adatátvitel 475
16.3.1. További információ 476
16.3.2. Visszatérési érték 476
16.3.3. Hívja a 476-os példát
16.4. ReadFileEx funkció. APC Read Data 477
16.4.1. Visszatérési érték 479
16.4.2. További információ 479
16.4.3. Hívja a 479-es példát
16.5. WriteFileEx funkció: APC Data Transfer 480
16.5.1. Visszatérési érték 481
16.5.2. Hívja a 481-es példát
16.6. WaitForSingleObject funkció jelre vár
objektum állapota 482
16.6.1. Visszatérési érték 482
16.7. WaitForMultipleObjects funkció: jelre vár
objektum állapotok 483
16.7.1. Visszatérési érték 484
16.8. GetOverlappedResult függvény eredménye aszinkron művelet 484
16.8.1. Visszatérési érték 485
16.9. DeviceIoControl funkció: Direct Driver Control 485
16.9.1. Visszatérési érték 487
16.10. QueryDosDevice funkció: Eszköznév lekérése
DOS névvel 487
16.10.1. Visszatérési érték 488
16.10.2. Hívja a 488-as példát
16.11: Dos-eszköz funkciójának meghatározása: DOS-eszköznév-műveletek 489
16.11.1. Visszatérési érték 490
16.11.2. Hívja a 490-es példát
17. fejezet HID API-funkciók 492
17.1. HidD_Hello Funkció: Library Check 492
17.2. HidD_GetHidGuid funkció: Szerezze be a GUID 492-t
17.3. HidD_GetPreparsedData függvény: Eszközleíró létrehozása 493
17.4. HidD_FreePreparsedData funkció: Eszközkezelő 493 felszabadítása
17.5. HidD_GetFeature funkció: FEATURE jelentés lekérése 494
17.6. HidD_SetFeature funkció: FEATURE jelentés küldése 494
17.7. HidD_GetNumInputBuffers függvény: a pufferek számának lekérése 495
17.8. HidD_SetNumInputBuffers funkció: a pufferek számának beállítása 495
17.9. HidD_GetAttribntes funkció: Eszközattribútumok lekérése 495
17.10. Funkció HidD_GetMamifactnrerStnng. szerezze be a gyártó 496-os karakterláncát
17.11. HidD_GetProductString függvény. szerezze be a 497-es termékcsaládot
17.12. Funkció HidD_ Get Serial MumberString. kap egy húrt
497-es sorozatszám
17.13. HidD_GetIndexedString függvény. kap egy sort a 498-as indexnél
17.14. HidDjGetlnputReport függvény. INPUT jelentés fogadása 498
17.15. HidD_SetOutputReport függvény. OUTPUT jelentés küldése 499
17.16. HidP_GetCaps funkció: Eszköztulajdonságok lekérése 499
17.17. HidP_MaxDataListLength függvény: 500-as jelentésméretek lekérése
18. fejezet UCH 502 Host Controller
18.1. 502 Host Controller Control Registers
18.1.1. USB parancsregiszter (USBCMD) ..504
18.1.2. USB állapotregiszter (USBSTS) 506
18.1.3. Megszakításvezérlő regiszter (USBINTR) 506
18.1.4. Keretszám-regiszter (FRNUM) 507
18.1.5. Keret alapcímregiszter (FLBASEADD) 508
18.1.6. Keretmódosító-regiszter (SOFMOD) 508 kezdete
18.1.7. Portállapot- és vezérlési nyilvántartás (PORTSC) 509
18.2. UCH 510 gazdavezérlő adatstruktúrái
18.2.1. 510. keretlista
18.2.2. Átviteli leíró i 511
18.2.3. Sorfejléc 514
18.3. UCH 516 Leírólista feldolgozása
19. fejezet Eszközök 518
19.1. Microsoft Visual Studio Tools 518
19.1.1. 518-tól függ
19.1.2. Hibakeresés 518
19.1.3. GuidGen 518
19.2. Microsoft DDK 520 eszközök
19.2.1. Device Tree 520
19.2.2. DevCon.-521
19.2.3. Chklnf és Genlnf. 526
19.3. CompuWare Corporation 527 Eszközök
19.3.1. Monitor 527
19.3.2. Symlink 527
19.3.3. EzDriverInstaller 527
19.3.4. WdmSniff 527
19.4. Syslntemals 528 eszközök
19.4.1. WinObj 528
19.5. USB Forum 531 eszközök
19.5.1. HID Descriptor Tool 531
19.6. HDD szoftvereszközök 533
19.7. Sourceforge 533 eszközök
APPS 535
1. függelék További szolgáltatások 537
2. melléklet Nyelvi azonosítók táblázata (LangID) 539
3. melléklet Szállítókódok táblázata (Szállítóazonosító, Készülékazonosító) 543
4. melléklet CD Leírás 546
Irodalom 548
Index 549

Programozás ezen keresztül USB csatlakozó

A fixture programozása a beállításhoz parabolaantennák Az USB-n keresztüli SF-50 csak abban különbözik az RS-232-n keresztüli programozástól, ahogyan az adatokat a műszerről a számítógépre és a számítógépről a másikra továbbítják. USB-n keresztüli programozáskor egy hordozható USB kulcs(cserélhető eszköz). Ez akkor hasznos, ha például a számítógépe vagy gyakrabban egy laptop (netbook) nem rendelkezik RS-232 soros porttal a házán.
A készülék programozásához USB használatával a tároláshoz szüksége lesz:
- USB-meghajtó (flash drive) formázva fájlrendszer FAT-32;
- AliEditor szerkesztő program, amely az OPENBOX SF-50 szoftverrész Database_editor_new mappájában található.

A programozás megkezdése előtt át kell vinni az adatbázist a készülékről a számítógépre. Ehhez kapcsolja be az eszközt, csatlakozzon USB csatlakozó cserélhető eszköz. Futtassa a MENU - Rendszer - Mentés USB-re,

Lépjen ki a menüből a MENU gomb megnyomásával, amíg az aktuális csatorna meg nem jelenik, vagy a főmenü képére, ha még nincs csatorna, és távolítsa el a flash meghajtót. Helyezze be a flash meghajtót a számítógépbe.
Futtassa az Editor.exe programot a Database_editor_new mappából, és nyissa meg a benne lévő flash meghajtón lévő képet.

Amikor a rendszer kéri, hogy válasszon adatbázist, válassza a Felhasználói adatbázis lehetőséget.

Nyomja meg az OK gombot. Válassza az Összes szolgáltatás lehetőséget, megnyílik az adatbázisban lévő összes beolvasott és mentett TV-, rádió- és szolgáltatási csatorna listája.

Szerkessze a csatornákat tetszés szerint, például hagyjon csak nyitott csatornákat.
Nyomja meg a számítógép billentyűzetén Shift gomb, nyomja meg a lefelé mutató nyilat, és jelölje ki a törölni kívánt csatornákat. A kijelölés törléséhez nyomja meg a Delete gombot.

A műholdbeállítások szerkesztéséhez válassza az Összes szolgáltatás – Műholdinformáció – EUTELSAT W4, W7 menüpontot, majd nyomja meg az ENTER gombot.

Ha szükséges, módosítsa az Antenna 1 értékeit.
Transponder törléséhez válasszon ki egy szükségtelent, és nyomja meg a Törlés gombot a számítógép billentyűzetén, és erősítse meg a kiválasztott műveletet.

Transponder hozzáadásához álljon a műhold nevére, és nyomja meg a gombot jobb gomb egérrel, és válassza az Információ hozzáadása lehetőséget (vagy válassza ki a műholdat, és nyomja meg a Beszúrás gombot a billentyűzeten).

Adja meg az új transzponder adatait, például a lyngsat.com webhelyről.

Nyomja meg az OK gombot, és ellenőrizze, hogy a transzponder regisztrálva van-e.

Műhold hozzáadásához lépjen a Műhold információ sorba, nyomja meg a Beszúrás gombot a billentyűzeten, és adja meg az új műhold paramétereit.

zárja be a szerkesztő programot, távolítsa el a meghajtót.
Helyezze be a meghajtót az OPENBOX SF-50 eszközbe, hajtsa végre a MENU - System - Frissítés USB-ről parancsot egymás után, válassza ki a "SAT&TP List" módot.

Válassza a Start lehetőséget. Erősítse meg szándékait.

Az eszköz frissíti az adatbázist, és újraindul. Az újraindítás után a beállításokban új módon kell beállítani az orosz menü nyelvét. Állítsa vissza a készüléket a gyári beállításokra.
Lépjen ki a beállítások menüből a MENU gomb kétszeri megnyomásával. Nyomja meg az OK gombot az aktuális csatornán, és győződjön meg arról, hogy a csatornalista szerkesztve van.

Győződjön meg arról is, hogy a transzponderek és műholdak listáját szerkesztették.
A programozás befejeződött.

Az USB-busz (Universal Serial Bus - Universal Serial Bus) 1996. január 15-én jelent meg a szabvány első verziójának az Intel, a DEC, az IBM, a NEC, a Northen Telecom és a Compaq jóváhagyásával.

A fejlesztők elé állított szabvány fő célja, hogy a felhasználók Plug&Play módban dolgozhassanak perifériákkal. Ez azt jelenti, hogy a készüléket működő számítógéphez csatlakoztatni kell, automatikus felismerés közvetlenül a csatlakozás, majd a megfelelő illesztőprogramok telepítése után. Ezenkívül kívánatos, hogy a kis teljesítményű eszközöket magáról a buszról táplálják. A busz sebességének elegendőnek kell lennie a perifériák túlnyomó többségéhez. Az USB-vezérlőnek csak egy megszakítást szabad megszakítania, függetlenül a buszhoz csatlakoztatott eszközök számától, vagyis az IBM PC-kompatibilis számítógépek belső buszainak erőforráshiányának megoldásához.

Szinte minden feladatot az USB szabványban oldottak meg, és 1997 tavaszán kezdtek megjelenni a számítógépek csatlakozókkal USB csatlakozások eszközöket. Mostanra az USB-t olyan aktívan bevezették a számítógép-perifériák gyártói, hogy például az Apple Computers iMAC számítógépében csak USB van külső buszként.

Az USB 1.0 jellemzői a következők:

1. nagy sebességű adatcsere (teljes sebességű) - 12 Mb azt/Val vel;

2. maximális kábelhossz magas árfolyam esetén - 5 méter;

3. alacsony adatcsere sebesség (alacsony sebesség) - 1,5 Mb azt/Val vel;

4. maximális kábelhossz alacsony árfolyam esetén - 3 méter;

5. a csatlakoztatott eszközök maximális száma 127;

6. különböző árfolyamú eszközök lehetséges egyidejű csatlakoztatása;

8. készülékenkénti maximális áramfelvétel - 500 mA.

Ezért tanácsos szinte minden perifériás eszközt csatlakoztatni az USB 1.0-hoz, kivéve a digitális videokamerákat és a nagy sebességű merevlemezek. Ez az interfész különösen hasznos a gyakran csatlakoztatott/lekapcsolt eszközök, például digitális fényképezőgépek csatlakoztatásához.
A mindössze két adatsebesség használatának lehetősége korlátozza a busz alkalmazhatóságát, de jelentősen csökkenti az interfészvonalak számát és egyszerűsíti a hardveres megvalósítást.
A közvetlenül USB-ről történő tápellátás csak alacsony fogyasztású eszközök, például billentyűzetek, egerek, joystickok stb.

Az USB-jelek továbbítása 4 vezetékes kábelen keresztül történik, amely vázlatosan az alábbi ábrán látható:

2.6.1 ábra – USB jelvezetékek

Itt a GND egy általános vezetékes áramkör a perifériás eszközök táplálására, a Vbus - +5 V pedig a tápáramkörökhöz is. A D+ busz adatátvitelre szolgál a buszon, a D-busz pedig az adatok fogadására.
A teljes buszsebességet (teljes sebességet) támogató kábel sodrott érpárból készül, árnyékolással védett, és minimális sebességű (alacsony sebességű) üzemmódban is használható. A csak minimális sebességgel működő kábel (például egér csatlakoztatásához) bármilyen és árnyékolatlan lehet.
A perifériák csatlakoztatására használt csatlakozók sorba vannak osztva: az "A" sorozatú csatlakozók (anya és anya) csak forráshoz, például számítógéphez való csatlakoztatásra szolgálnak, a "B" sorozatú csatlakozók (anya és anya) csak perifériához való csatlakoztatásra szolgálnak. eszköz.

Az USB-csatlakozók pin-számozása a 2.6.1. táblázatban látható.

2.6.1. táblázat – Az USB-érintkezők célja és jelölése

1999-ben ugyanaz a számítógépes cégek konzorciuma, amely az USB-busz szabvány első verziójának kifejlesztését kezdeményezte, elkezdte aktívan fejleszteni az USB 2.0-s verzióját, amely egy további nagy sebességű (Hi-speed) módot is tartalmaz. A busz sávszélessége 40-szeresére, 480 Mbps-ra nőtt, ami lehetővé tette a videó adatok USB-n keresztüli átvitelét.
Az összes korábban kiadott periféria és nagy sebességű kábel kompatibilitása teljes mértékben megmarad. A 2.0 szabvány vezérlője már integrálva van a programozható eszközök rendszerlogikájába (pl. alaplap személyi számítógép).

2008-ban az Intel, a Microsoft, a Hewlett-Packard, a Texas Instruments, a NEC és az NXP Semiconductors létrehozta az USB 3.0 specifikációt. Az USB 3.0 specifikációjában a frissített szabvány csatlakozói és kábelei mind fizikailag, mind funkcionálisan kompatibilisek az USB 2.0-val, de a négy kommunikációs vonalon kívül még négy került be. Azonban új kapcsolatok érkeztek USB csatlakozók A 3.0 a régiektől külön, egy másik érintkezősorban található. Az USB 3.0 specifikációja 5 Gbps-ra emeli a maximális adatátviteli sebességet – ez egy nagyságrenddel nagyobb, mint az USB 2.0 által biztosított 480 Mbps. Emellett a maximális áramerősség 500 mA-ről 900 mA-re nőtt készülékenként, ami lehetővé teszi egyes olyan eszközök táplálását, amelyek korábban külön tápellátást igényeltek.

Tegyük fel, hogy kifejlesztett egy USB-eszközt, amellyel számítógéppel szeretne dolgozni. Ezt legalább két módon lehet elérni:

1. egy teljes értékű meghajtó fejlesztése operációs rendszer;

2. speciális osztályú USB interfész használata - HID (Human Interface Device) eszközöknek nevezett eszközök.

Az első módszer univerzális: megfelelő ismeretekkel az illesztőprogramok írása terén, beprogramozhatja, hogy bármilyen eszközzel működjön, bármilyen sebességgel, amelyet az USB támogat. De ez meglehetősen nehéz feladat.

A második út a következő. Létezik egy modern operációs rendszerek által támogatott interfész a számítógép-ember interakciós eszközökhöz vagy a HID-eszközökhöz, mint például:

1. billentyűzetek, egerek, joystickok;

2. különféle érzékelőkés az olvasók;

3. játékkormányzás és pedálok;

4. gombok, kapcsolók, szabályozók.

Bármely ilyen eszközt, ha teljesíti a HID eszközökre vonatkozó követelményeket, a rendszer automatikusan felismeri, és nem igényel speciális illesztőprogramokat. Ezenkívül ezek programozása általában sokkal egyszerűbb, mint egy egyedi eszközillesztő megírása. Sajnos a módszernek van egy jelentős hátránya: a HID eszközzel történő információcsere sebessége nagyon korlátozott, és maximum 64 kB/s.

Alapvetően a HID technológia alapján bármilyen eszközzel meg lehet szervezni az interakciót, még akkor is, ha az nem a szoros értelemben vett interfész eszköz az ember és a számítógép között. Ez kiküszöböli az egyedi eszközillesztő időigényes fejlesztését, és időt takarít meg egy új USB-eszköz fejlesztése során. A gazdagép oldalon az eszközzel való cserét az operációs rendszer disztribúciójában található szabványos HID illesztőprogram fogja kezelni. Csak az eszköz oldaláról kell végrehajtani minimális követelményeket USB HID protokoll.

Érdemes megjegyezni, hogy sok USB-eszköz, amely első pillantásra nem tartozik az emberi interakciós eszközök definíciójába, még mindig logikusabb HID-eszközként való megvalósítása. Ez a jelenség gyakran előfordul a gyártóberendezések területén, ahol a közelmúltban az USB technológia tömeges bevezetését tapasztalták. Vegyünk például egy laboratóriumi tápegységet, amely képes beállítani a számítógép kimeneti jeleinek paramétereit USB-interfész segítségével. Kétségtelen, hogy maga az energiaforrás nem az emberrel való interakció eszköze. Azonban in ez az eset Az USB-kapcsolaton keresztül megvalósított funkciók megduplázzák a készülékre telepített billentyűzetet, kezelőszerveket és kijelzőket. És ezek a vezérlők csak a HID definíciója alá tartoznak. Ennek megfelelően a tápegység ezekkel az USB-funkciókkal a leglogikusabban HID-eszközként van megszervezve.

A vizsgált példában egy kis adatátviteli sebesség is elegendő lesz a normál működéshez, míg más esetekben a készülékek nagyon igényesek lehetnek az árfolyamra. Az alacsony átviteli sebesség a fő korlátja a HID eszköz kialakításának, amely a 12 Mbps teljes sebességhez képest USB sebesség Az 1.0-s busz a HID technológia nagy hátrányának tűnik egy konkrét USB-megvalósítás kiválasztása szempontjából. Sok kommunikációs feladathoz azonban ez a sebesség bőven elegendő, és a HID architektúra, mint speciális eszköz, méltó helyet foglal el az adatcsere megszervezésének módjai között.

Kétféle HID-eszköz létezik: a számítógép kezdeti rendszerindításában részt vevő (bootolható) és nem. A rendszerindító USB-HID eszköz legszembetűnőbb példája a billentyűzet, amely a számítógép indításával kezd működni.

A HID eszköz fejlesztése során a specifikáció által támasztott alábbi követelményeket kell teljesíteni:

1. A teljes sebességű HID eszköz másodpercenként 64000 bájtot vagy 1 ms-onként 64 bájtot tud továbbítani; egy kis sebességű HID eszköz másodpercenként akár 800 bájtot vagy 10 ms-onként 8 bájtot képes átvinni.

2. A HID eszköz kijelölheti lekérdezési gyakoriságát, hogy megállapítsa, van-e friss adata továbbítandó.

3. Az adatcsere a HID eszközzel egy speciális struktúrán keresztül történik, amelyet jelentésnek (Report) neveznek. Minden meghatározott jelentés legfeljebb 65535 bájtnyi adatot tartalmazhat. A jelentésszerkezet nagyon rugalmas felépítésű, amely lehetővé teszi bármilyen adatátviteli formátum leírását. Ahhoz, hogy egy adott jelentésformátum ismertté váljon a gazdagép számára, a mikrokontrollernek tartalmaznia kell egy speciális leírást - egy jelentésleírót.

Az USB-kommunikáció közvetlenül a mikrokontrolleren valósul meg többféle módon:

1. hardveres támogatással rendelkező vezérlő használata, például AT90USB*, az atmegától;

2. az usb interfész szoftveres emulációja bármilyen mikrokontrolleren.

A szoftveres megvalósításhoz jelenleg számos kész megoldás létezik a különböző mikrokontroller-családokhoz. Az AVR mikrokontrollerekhez, mint például az Atmega8, a következő ingyenes C könyvtárak használhatók:

Mindkettő meglehetősen könnyen használható, az USB 1.1 alacsony sebességű eszközök teljes emulációját biztosítják, kivéve a kommunikációs hibakezelést és az elektromos jellemzőket, és szinte minden AVR vezérlőn futnak, legalább 2k flash-el, 128 bájt RAM-mal és 12-20 MHz-cel.

Pályázatok írásához támogatással Windows USB A HID eszközöknek szükségük van a WDK-ban található hid* fejlécfájlokra ( Windows illesztőprogram Kit), vagy használhatja a szabadon terjeszthető hidlibrary könyvtárat vagy más hasonlót.

Így általános esetben az USB-programozás meglehetősen bonyolult feladat, amelyhez speciális hardveres támogatású mikrokontroller és operációs rendszer-illesztőprogram írása szükséges. A gyakorlatban azonban az eszközök fejlesztésekor lehetőség nyílik egy sokkal egyszerűbb HID interfész - eszközök - használatára, amelyek támogatása szabványos rendszermeghajtó szintjén valósul meg, a programozás pedig a meglévő függvénykönyvtárak segítségével egyszerűsödik.

Ellenőrző kérdések

  1. Mi a különbség az USB D- és GND vezetékei között? Miért nem lehet egyetlen közös vezetéket használni a tápellátáshoz és a jelhez?
  2. Hány USB sebességmód létezik ma (beleértve a 3.0-s verziót is)?
  3. Mi az a HID eszköz? Miért nem igényelnek írási illesztőprogramokat a modern operációs rendszerekben való működéshez?
  4. Lehetséges-e megvalósítani USB-eszközök olyan mikroprocesszort használ, amely nem rendelkezik beépített interfész támogatással?
  5. Melyek a fő különbségek az USB 3.0 és a korábbi verziók között?

De nem elég csak fizikailag csatlakoztatni a készüléket a számítógéphez, hanem adatcserét is létre kell hozni közöttük. Hogyan válasszunk portot és szervezzünk kapcsolatot? Néhány évvel ezelőtt átlagos megoldás COM portot használt. Különböző szakemberek egyébként még mindig 8, 16, vagy akár 32 COM portot telepítenek ipari számítógépekre (egy egész kategória létezik a soros portokhoz, vezérlőkhöz stb. különböző PCI bővítőkártyákból). Így ha több külső eszközt kell csatlakoztatni RS-232 interfésszel, akkor drága adapterekre és egzotikus bővítőkártyákra lehet szükség, amelyek a régi hagyomány szerint hetekig hajóznak Oroszországba gőzhajókon. Mellesleg, egy közönséges adapter neve "DB9m / DB25f adapter" csak irritációt okozhat a számítógépes áruház vezetőjének.

Mi az a HID eszköz

Mostantól szinte minden eszköz USB-interfészen keresztül csatlakozik a számítógéphez. Ezért sok új PC egyáltalán nem rendelkezik COM-porttal.

USB interfész - tipikus megoldás egy új párosítására külső eszköz számítógéppel, pontosabban egy USB 1.1 protokollon alapuló HID interfész.

Bár sokan úgy gondolják, hogy a HID (Human Interface Device) interfész kizárólag a billentyűzet, az egér és a joystick számára való, számos külső eszközök és számítógép interfészével kapcsolatos megoldásra alkalmas.

Ha a felhasználónak alacsony sebességű adatcserét kell végrehajtania (legfeljebb 64 kbps), és ugyanakkor kívánatos csökkenteni a saját illesztőprogramjaik fárasztó fejlesztésének idejét, akkor a HID meglehetősen megfelelő számukra. A kimenet egy egyszerű és teljesen modern megoldás lesz, amely szabványos USB-szoftver-interfészen alapul, garantált támogatással minden elterjedt szoftverplatformon.

HID eszköz tulajdonságai

A HID-eszköz szoftvertámogatásának megszervezése szempontjából minden nagyon vonzónak tűnik: alatta dolgozni Windows vezérlés készen bevált algoritmusok alapján gyorsan létrehozhat érthető kompakt kódot. Ebben az esetben a fejlesztőnek bőven lesz ideje saját legfelső szintű adatcsere protokolljának megvalósítására, mivel a szükséges absztrakciós szintet már a HID protokoll szervezi (lásd a táblázatot). Ezenkívül a programozó könnyen hibakereshet egy írott csereprotokollt (természetesen, ha van működő HID-eszköz) - magának a protokollnak a viszonylagos merevsége miatt elegendő egyszerűen kidolgozni egy programot az eszköz támogatására. számítógép által. Még mindig lenne! Nagyon sok munkát végzett már a HID eszköz megalkotója.

Adatcsere létrehozása HID eszköz és számítógép között

A HID-eszköz és a számítógép közötti interakció leírására a „gazdagép” kifejezést használjuk. Ebben az esetben az USB protokollon keresztüli kommunikáció általános fizikai architektúrájában lévő vezérlőeszközre utal. Tehát a számítógép minden portja gazdagép. Különféle USB eszközöket csatlakoztathatunk hozzájuk (flash meghajtók, egerek, webkamerák, kamerák stb.), amelyek nem rendelkeznek gazdagéppel. A gazdagép biztosítja a felderítést, a csatlakozást, a leválasztást, az eszközkonfigurációt, valamint a statisztikák gyűjtését és az energiagazdálkodást.

A HID készülék maga állíthatja be azt a lekérdezési gyakoriságot, amely során az esetleges új adatok meglétét észleli. Ez azt jelenti, hogy a programozó még ilyen alacsony szinten is megbízhat a rendszerben, hiszen a HID eszközvezérlő programban előre be kell állítani a lekérdezési gyakoriságot és az egyéb kommunikációs paramétereket. Ebben a HID protokoll eltér az USB 1.1 vagy USB 2.0 általános leírásától, amely nem támaszt szigorú követelményeket a protokoll szervezésére vonatkozóan. Azonban bizonyos, magas szintű biztonságot igénylő feladatoknál meglehetősen nehéz lehet megszabadulni a ciklikus szavazásoktól, amikor szinte ugyanazokat az adatblokkokat továbbítják folyamatosan.

A HID eszközök programozásának jellemzői

A HID eszközöknek speciális leírásai vannak. Amikor a gazdagép megállapítja, hogy az eszköz a HID osztályba tartozik, átadja az irányítást a megfelelő illesztőprogramnak. Feltételezhető, hogy a további adatcsere az ő vezetésével történik.

Windows rendszeren a HidServ rendszerszolgáltatás felelős a HID eszközök eléréséért. További részletek a HID-eszközökhöz intézett kérések funkcióiról és a HID-illesztőprogrammal való munka egyéb jellemzőiről P. V. Agurov „USB interfész” című munkájában találhatók. A használat és a programozás gyakorlata” (St. Petersburg: BHV-Petersburg, 2005).

HID eszközök programozása a "legfelső szinten"

A Pascalon dolgozó "alkalmazott" programozók nehéz életét megkönnyíti a bevált HID modul. PAS, a shell for hid. dll (Rejtett felhasználói könyvtár - a fájl tulajdonságainál megadottak szerint). A fájlhoz fűzött megjegyzések szerint az a Microsoft Corporation hidsdi.h és hidpi.h moduljain alapul. És maga a HID fájl. A PAS a JEDI() csomag része.

HID eszközzel való munkavégzés Delphi környezet win32 esetén a TJvHidDeviceController komponenst használják, amely egy kényelmes globális menedzser a HID eszközök elérésére. És már ennek alapján is beszerezhet egy objektumpéldányt egy adott eszközzel való munkavégzéshez.

A TJvHidDeviceController komponens fő tulajdonságai és eseményei

Tekintsük részletesebben a TJvHidDeviceController összetevőt. Az OnArrival esemény akkor aktiválódik, amikor egy HID eszköz érkezik (csatlakozik) a rendszerhez, az eszközhöz való hozzáférést az esemény kezelője biztosítja a TJvHidDevice osztály egy példányán keresztül. Az OnDeviceChange egyszerű esemény az eszköz állapotváltozására reagál, csak a rendszerben bekövetkezett változásokat jelzi. Az OnDeviceData esemény akkor aktiválódik, amikor adat érkezik az egyik HID-eszközről, és átadja a következőket a kezelőnek: HidDev: TJvHidDevice; - az eszköz, amelyről az adatokat fogadták;

Az OnDeviceDataError esemény adatátviteli hibáról értesít a HidDev paraméterek átadásával a feldolgozási eljárásnak: TJvHidDevice; - HID eszköz és hiba: DWORD; - hibakód. Az OnDeviceUnplug esemény értesíti, hogy egy eszközt eltávolítottak a rendszerre telepített eszközök listájáról. A Plug and Unplug eseménykezelőinek típusai megegyeznek (a forrásszövegben: TJvHidUnplugEvent = TJvHidPlugEvent). A HID eszköznek megfelelő TJvHidDevice osztály objektuma átadásra kerül a kezelőnek.

A rendszerben elérhető HID eszközök szekvenciális felsorolására az Enumerate metódus hívásával az OnEnumerate eseményt szánjuk, azaz az eseménykezelőben a talált eszközök egymás után objektumként kerülnek továbbításra. Ezt az eseményt az Enumerate metódus kényszeríti ki, amely arra szolgál, hogy a meglévő HID-eszközöket "átadja" a kezelőn, például a gazdagép (számítógép) által kezdeményezett HID-eszközök állapotának auditálásakor.

Az OnRemoval esemény akkor aktiválódik, amikor az eszközt fizikailag eltávolítják a rendszerből, és ugyanazzal a TJvHidUnplugEvent kezelőtípussal rendelkezik, mint az OnDeviceUnplug esetében. A CountByProductName függvény az argumentumban megadott terméknévnek megfelelő eszközök számát, a CountByVendorName pedig az argumentumban megadott szállítónevek számát adja vissza.

A TJvHidDevice osztály főbb tulajdonságai és eseményei

A TJvHidDevice osztály egyetlen HID eszköz virtuális reprezentációja. Ennek az osztálynak az új objektuma beszerezhető, mint már említettük, az OnArrival vagy az OnEnumerate eseményből. A TJvHidDeviceController és a TJvHidDevice osztályok funkcionalitása részben megduplázódik, mivel az első egy közös eszközkészletet tartalmaz a rendszerben elérhető HID-eszközökkel való munkavégzéshez, és egy mechanizmust az egyik elérésére. Egy eszköz egyedileg azonosítható a SerialNumber, ProductName és VendorName tulajdonságai alapján. Az OnData esemény segítségével információt kaphat az adatok érkezéséről egy ilyen objektum használatával. Az adatküldés a WriteFile metóduson keresztül történik (a szoros értelemben vett függvényen keresztül). A WriteFile a WriteFile (kernel32) rendszerfüggvény körüli burkolóanyag.

Az eszköz eltávolításának ellenőrzéséhez saját kezelőt kell hozzárendelnie az OnUnplug eseményhez. Mielőtt elkezdené az adatcserét egy HID eszközzel, meg kell győződnie arról, hogy az ilyen adatcsere lehetséges a HasReadWriteAccess segítségével. Ennek az osztálynak még külön OnDataError eseménye is van az adatcsere hiba előfordulásához.

És most nézzük meg egy "élő" projekt kódrészleteit, amely egy tesztkliens alkalmazást valósít meg az adatcsere megszervezésére egy nem szabványos eszközzel - HID-alapú műanyag chipkártyákkal. A realizmusért folytatott küzdelemben a szerző vállalta a bátorságot, hogy ne dobjon ki "extra" technológiai kódkötéseket a listákból.

A ScanDevices metódus (1. lista) arra szolgál, hogy elindítsa a rendszerben a kívánt HID-eszköz keresésének folyamatát. A kód nagy része, az Enumerate metódus hívása kivételével, opcionális, és rugalmasságot biztosít az alkalmazás számára, így például ugyanahhoz a tesztprogramhoz hozzáadhatja a nem HID felületen történő munkavégzés lehetőségét. Az AddError metódus a program futása közben hibakeresési információkat nyomtat az ablakba.

A 2. lista az OnEnumerate eseménykezelőt mutatja a szükséges külső eszköz megtalálásához. Az egyszerűség kedvéért feltételezzük, hogy a program csak egy olyan típusú eszközzel tud működni, amelyre szüksége van.

Mielőtt a projekt további megvalósítására gondolnánk, beszéljünk egy kicsit az elfogadott felső szintű adatcsere-formátumról, vagyis arról a struktúráról, amely közvetítő szerepet tölt be az adatfogadási és -továbbítási módok és a megoldandó konkrét alkalmazott feladat között. . Az a tény, hogy itt a fejlesztő lehetőséget kap kreatív képességeinek megvalósítására. Illetve a fejlesztők, mert egy új protokoll létrehozásának folyamata nagyon gyakran kétirányú, és az első hegedűn az játszik, akinek nehezebben tudja megvalósítani a cserealgoritmust. Általánosságban elmondható, hogy bármilyen csereprotokollról is legyen szó, mindig jó minden szoftverentitást a lehető legvizuálisabbá és önellátóvá tenni, még néhány általánosan elfogadott hagyomány rovására is. Mert A legjobb döntés- olyan, amely rövid időn belül megvalósul minimális hivatkozással szoftverkörnyezetés nagy a további fejlődési lehetőség. Ezen elvek alapján egy felső szintű csereprotokoll jött létre, ahol a fő fogalom a „parancs”. A 3. lista azt mutatja, hogy a szerző mennyire szereti a karakterlánc-adatokat, amivel többször megmentette a programmodulok hibakeresése során. Milyen csodálatos, hogy van még String típusunk is! Minden protokoll parancs kategóriákra (osztályokra) van felosztva, amelyeken belül van egy parancskód, amely egyedileg jellemzi a célját. Az edParam paraméterrel adatokat küldünk az eszközre, az edAnswerData paraméter pedig az eszközről kapott adatokat tartalmazza. A leírt rekordtagok karakterlánctípusa lehetővé teszi az adatok szabad és vizuális kezelését HEX karakterlánc formátumban. És ami a legkellemesebb, a leírt lemez formátuma ideológiailag valahol középen áll a közvetlen célja és a különféle megjelenítési formái (INI, HEX, XML stb.) között.

A parancsvégrehajtás, azaz az adatok készülékre történő küldése 8 bájt hosszúságú adatcsomagok küldésével valósul meg (4. lista). Ez a hosszúság nem az egyetlen döntés, ezt a választást a felső réteg protokoll követelményei határozzák meg, és minden esetben eltérő lehet. Ezt úgy hívják, ízlés dolga. A furcsa IsUSBMode jelző az ExecuteCommand metódusban (Listing 5 in PC Disk World) emlékeztet arra, hogy az USB helyett esetleg COM portot vagy más interfészt kell használnunk. Az elküldött adatcsoport elején egy tetszőlegesen választott formátumú (például 3E3E3E2B) szinkronizálási szekvencia kerül az eszközre, amely tájékoztatja az eszközt, hogy a bemeneten teljesen legális adatok vannak. Hadd emlékeztesselek erre ebben az esetben beszélgetünk nem annyira a HID-ről, hanem egy speciális felső szintű protokollról, amelyet ideológiailag elválasztottak a hardvertől, és konkrét alkalmazott problémák megoldására tervezték.

Az eszközről kapott adatok GetDataExecutor kezelőjében (8 bájtos csomag) egy speciálisan létrehozott OnNewInputData eseményt használtak az eredetileg feldolgozott adatok további feldolgozásra való átvitelére, jelezve azok régi és új értékeit (6. lista a "World"-on a PC-lemezről"). Így a nyers adatok érkezésének és a további feldolgozás jelzésének eseményei szétválaszthatók, lehetővé téve néhány speciális figyelmeztető algoritmus hozzáadását a korai szakaszban a hibás, ismétlődő vagy szükségtelen bemeneti információkhoz.

Az itt bemutatott példák a HID-eszközzel való munkavégzésre illusztrálják a cikk általános gondolatát - a nem szabványos HID-eszközök Delphi-eszközökkel történő programozásának viszonylagos egyszerűségét.

Ha hibát észlel, jelöljön ki egy szövegrészt, és nyomja meg a Ctrl + Enter billentyűket
OSSZA MEG: