inkluderar 18f2455 -- bibliotek för den använda MK
--
aktivera_digital_io() -- växlar alla ingångar till digitalt läge
--
alias Knapp är pin_B7 -- eftersom vi har en knapp ansluten, låt oss förklara det
pin_B7_direction = ingång -- vår knapp fungerar för inträde
--
-- en rad - och vi har allt du behöver för att arbeta med USB CDC
include usb_serial -- bibliotek för att arbeta med usb
--
usb_serial_init() -- --initiera USB CDC
forever loop-- huvudslinga, exekveras kontinuerligt
usb_serial_flush() -- Usb-uppdatering. Detta förfarande utför allt som behövs
-- åtgärder för att upprätthålla anslutningen till PC
ändslinga
Sammanställning denna kod Genom att skriva den resulterande HEX-filen till MK med hjälp av en bootloader och starta enheten, kommer du att kunna observera hur en ny enhet definieras i systemet: Virtual com-port.
Nu när enheten redan fungerar, låt oss lära den att kommunicera.
För att läsa den mottagna byten finns en funktion usb_serial_read( byte ) :boolean. Om det finns en mottagen byte, lagrar den den i den angivna variabeln och returnerar sann, annars återkommer falsk.
Det finns en procedur för att skicka en byte usb_serial_data. Den är förklädd som en variabel, så för att skicka en byte behöver du bara tilldela den värdet på den byte som skickas.
Låt oss deklarera en bytestor variabel före huvudslingan, i huvudslingan kommer vi att kontrollera om det finns mottagna bytes, och om de finns, skicka tillbaka dem.
inkluderar 18f2455
--
aktivera_digital_io()
--
alias Knapp är pin_B7
pin_B7_direction = ingång
--
--
inkludera usb_serial
--
usb_serial_init()
var byte kap -- deklarera en variabel
forever loop-- huvudslinga
usb_serial_flush()
om(usb_serial_read(ch)) sedan-- om en byte tas emot, kommer den att skrivas till kap
usb_serial_data = kap -- skicka tillbaka den mottagna byten
avsluta om
ändslinga
Vi kompilerar, håller ned knappen, byter strömförsörjning, startar bootloader, ändrar firmware, startar.
Enheten har identifierats i systemet igen, nu behöver vi programvara för att testa enhetens funktion.
Även om vi inte har vår egen, använder vi en färdig terminal: jag använde RealTerm-programmet.
Öppna porten med önskat nummer och skicka data.
Och vi får tillbaka det vi skickade. Det betyder att allt fungerar som det ska.
Vi skapar nytt projekt, vi sprider de nödvändiga komponenterna enligt formuläret:
SpinEdit1 - för att ange portnumret
Knapp1 - för att upprätta en anslutning
Knapp 2 - för att koppla från
SpinEdit2 - för att ange bytes i decimalform
Knapp3 - för att skicka en byte
Memo1 - för att visa mottagen information.
Som nämnts ovan måste du arbeta med com-porten på samma sätt som med en vanlig textfil: Använder funktionerna CreateFile, WriteFile och ReadFile.
Utan att gå in på detaljer, låt oss ta ett färdigt bibliotek för att arbeta med en com-port: ComPort.
Vi bifogar den nödvändiga uppgiften till varje knapp och får den slutliga koden:
enhet Enhet1;gränssnitt
Används
Windows, meddelanden, SysUtils, varianter, klasser, grafik, kontroller, formulär,
Dialoger, StdCtrl, Spin, ComPort;Typ
TForm1 = klass(TForm)
SpinEdit1:TSpinEdit;
Knapp1: TBnapp;
Knapp 2: TB-knapp;
SpinEdit2:TSpinEdit;
Knapp3: TBnapp;
Memo1: TMemo;
procedure OnRead(Avsändare: TObject; ReadBytes: array av Byte );
procedure Button1Click(Avsändare: TObject);
procedure Button2Click(Avsändare: TObject);
procedure FormDestroy(Avsändare: TObject);
procedure Button3Click(Avsändare: TObject);
privat
(Privata deklarationer)
Port: TComPort;
offentlig
(Offentliga deklarationer)
avsluta;var
Form1: TForm1;
num:heltal;
genomförandeProcedur TForm1.Button1Click(Avsändare: TObject);
börja
Port:= TComPort.Create(SpinEdit1.Value, br115200); //skapa en anslutning
Port.OnRead:= OnRead; //skapa en ström för att läsa mottagen data
Button2.Enabled:= true ; //aktivera knappen för att stänga anslutningen
avsluta;Procedur TForm1.Button2Click(Avsändare: TObject);
börja
Port.Free; //stäng anslutningen
Button2.Enabled:= false ; //avaktivera knappen
avsluta;Procedur TForm1.Button3Click(Avsändare: TObject);
börja
om Button2.Enabled då Port.Write();
avsluta;Procedur TForm1.FormDestroy(Avsändare: TObject);
börja
om Button2.Enabled då
Port.Free;
avsluta;Procedur TForm1.OnRead(Sändare: TObject; ReadBytes: array av Byte );
var
i:heltal;
börja
för i:= Low(ReadBytes) till High(ReadBytes) gör //passera genom arrayen av mottagna byte
börja
Memo1.Text:= Memo1.Text + "." +InttoHex(ReadBytes[i],2); //lägg till dess HEX-värde i fönstret
inc(antal); //räkna antalet mottagna byte
avsluta;
om num > 10 så börja
Memo1.Lines.Add("" ); // linda linjen
antal:= 0;
avsluta;
avsluta;
Vi startar, upprättar en anslutning, skickar bytes:
Så vår enklaste terminal är redo att fungera med den enklaste USB-enheten.
Som du kan se sker läsning och skrivning i dynamiska byte-arrayer.
Genom att behandla den mottagna informationen kan du skapa det nödvändiga utbytesprotokollet som är lämpligt för den aktuella uppgiften.
inkluderar 18f2455
--
aktivera_digital_io()
--
alias Knapp är pin_B7
pin_B7_direction = ingång
--
--
inkludera usb_serial
--
usb_serial_init()
var byte kap
var byte i -- deklarera den andra variabeln
forever loop-- huvudslinga
usb_serial_flush()
om(usb_serial_read(ch)) sedan-- Om byten tas emot, utför de nödvändiga åtgärderna
fall ch av -- gå igenom bytenumret
0 : usb_serial_data = 0xff
1 : usb_serial_data = Knapp -- Skicka knappstatus
ANNAT blockera-- om något annat tas emot
för 16 använder i slinga-- skicka 10 byte med data
usb_serial_data = ch +i -- från ch till ch+15
ändslinga
ändblock
slutfall
avsluta om
ändslinga
> inkludera tryck
...
var dword data
print_dword_hex(usb_serial_data, data)
Namnen på alla kommandon finns i biblioteksfilen.
medan(usb_cdc_line_status() == 0x00) slinga
ändslinga
const byte USB_STRING3 =
{
24 , -- arraylängd
0x03, -- bDescriptorType
"0" , 0x00 ,
"1" , 0x00 ,
"2" , 0x00 ,
"3" , 0x00 ,
"4" , 0x00 ,
"5" , 0x00 ,
"6" , 0x00 ,
"7" , 0x00 ,
"8" , 0x00 ,
"9" , 0x00 ,
"X", 0x00
}
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
}
Men tyvärr, efter att ha installerat drivrutinerna kommer enheten att byta namn till det som anges i .inf-filen, så vi ändrar namnet där också
DESCRIPTION="Demo CDC"
Först och främst måste du tilldela ett unikt tillverkare- och produktvärde till din enhet för att enkelt kunna identifiera den bland hundratals andra vanliga CDC-firmwares.
VID och PID delas ut för pengar, så låt oss följa kinesernas väg: ta tyst de uppenbart fria värdena.
Firmware:
I den fasta programvaran måste du deklarera två variabler innan du ansluter USB-biblioteket
konstord USB_SERIAL_PRODUCT_ID = 0xFF10
konstord USB_SERIAL_VENDOR_ID = 0xFF10
Drivrutiner:
Eftersom drivrutinerna inte är designade för vår kombination av VID och PID kommer vi att lägga till våra värden till .inf-filen manuellt:
%DESCRIPTION%=Installera drivrutiner, USB\VID_FF10&PID_FF10
%DESCRIPTION%=Installera drivrutiner, USB\VID_FF10&PID_FF10
Programvara:
Låt oss ansluta ComponentUSB-biblioteket för att fånga enhetens anslutnings-/nedkopplingshändelser. Jag tror inte att det är nödvändigt att förklara varje rad: alla ändringar kan ses i det bifogade projektet.
Som du kan se är det inte den svåraste uppgiften att organisera datautbyte mellan en MK och en PC via USB. Den resulterande anslutningen kan användas inte bara för slutliga ändamål: den är också lämplig för att felsöka programmet. När allt kommer omkring är det mycket tydligare att skicka beräkningsresultat och aktuella tillstånd för register och variabler till en dator än att blinka ett par lysdioder i morsekod.
Och till sist: Jag råder dig att titta närmare källkod stämningslampor. Du kan hitta ganska mycket där bra alternativ bearbetning av mottagna data för att organisera ett bekvämt utbytesprotokoll.
Bra bok, förklarar mycket. Det kommer att vara användbart för dem som vill förstå hur data överförs via USB-bussen.
Inledning 1
Vem är den här boken för: 2
Vad du hittar i bok 2
Programvarukrav 3
Hårdvarukrav 4
Om programkod 4
Kort beskrivning av kapitel 4
Notation 6
Tack 7
DEL I. INTRODUKTION TILL USB 9
Kapitel 1. Vad är USB 11
1.1. Historien om USB 11
1.2. Jämförelse av USB med andra gränssnitt 14
1.3. USB 16-koncept
1.3.1. Allmän bussarkitektur 16
1.3.2. Fysisk och logisk arkitektur för buss 16
1.3.3. Komponenter i USB 18
1.3.4. USB-enhetsegenskaper 18
1.3.5. Hubegenskaper 19
1.3.6. Värdegenskaper 20
1.4. 20 Exempel på USB-enheter
1.4.1. Mus och tangentbord., 21
1.4.2. Monitorer 21
1.4.3. USB-till-COM- och USB-till-LPT-adaptrar 22
1.4.4. Skanner 23
1.4.5. Modem 23
1.4.6. Högtalare 24
1.4.7. Flash-enheter 25
1.4.8. Nav 28
1.4.9. Mätteknik 28
1.4.10. Exotiska enheter 29
1.5. Nätverksanslutning via USB 30
1.5.1. USB-Ethernet-omvandlare 31
1.5.2. Direktanslutning via USB-port 31
1.6. Dataöverföring 31
1.6.1. Principer för dataöverföring 32
1.6.2. Avbrottsmekanism 32
1.6.3. Värdadaptergränssnitt 32
1.6.4. DMA-förmåga 34
1.6.5. Dataöverföringslägen 34
1.7. Installera och konfigurera USB-enheter 35
1.7.1. BIOS-inställningar för USB 38
1.7.2. Felsökning 41
1.8. USB 45-begränsningar
1.9. Om du köper en dator 46
1.9.1. HS och USB 2.0 är inte samma sak! 46
1.9.2. Moderkort 47
1.9.3. Byggnad 48
1.9.4. USB för "gamla" datormodeller 48
1.10. Onlineresurser för detta kapitel 49
Kapitel 2. Hårdvara USB 51
2.1. Kablar och kontakter 51
2.1.1. Kabeltyper 52
2.1.2. Kabellängd 53
2.1.3. Kontaktdon 53
2.2. Fysiskt gränssnitt 55
2.2.1. Datakodning 57
2.2.2. Enhetsidentifiering 58
2.3. Näring 59
2.3.1. USB-strömtyper 59
2.3.2. Energihushållning 60
2.3.3. Går in i läge låg strömförbrukning 61
2.4. Onlineresurser för detta kapitel 61
DEL II. INTERN ORGANISATION USB 63
Kapitel 3. Inre organisation av bussen 65
3.1. Logiska kommunikationsnivåer 65
3.1.1. Klientprogramnivå 66
3.1.2. Systemnivå USB-drivrutiner 67
3.1.3. Interface Host Controller Layer 68
3.1.4. Perifer buss nivå 68
3.1.5. USB logisk enhetsnivå 69
3.1.6. Funktionsnivå för USB-enhet 69
3.2. Överföra data över 69 nivåer
3.3. Typer av dataöverföringar 71
3.4. Synkronisering med isokron överföring 73
3.5. Personal 77
3.6. Slutpunkter 78
3.7. Kanaler 79
3.8. Paket 81
3.8.1. Format för IN-, OUT-, SETUP- och PING-markeringspaket 83
3.8.2. SOF 83 paketformat
3.8.3. Datapaketformat 84
3.8.4. Bekräftelsepaketformat< 84
3.8.5. Paketformat SPLIT * 84
3.9. Kontrollsumma 85
3.9.1. Algoritm för att beräkna CRC 86
3.9.2. Programvaruberäkning av CRC 87
3.10. Transaktioner 90
3.10.1. Transaktionstyper 91
3.10.2. Transaktionsbekräftelse och flödeskontroll 92
3.10.3. Transaktionsprotokoll 93
Kapitel 4. Intern organisation av enheten 96
4.1. Förfrågningar till USB-enheter 96
4.1.1. Konfigurationspaket 96
4.1.2. Standardförfrågningar till enheter 99
4.1.3. Enhetsbeskrivningar 105
Kapitel 5. Intern organisation av värden och hubbar 123
5.1. Nav 123
5.1.1. Interaktion mellan värdstyrenheten och hubben 126
5.1.2. Navbeskrivning 127
5.1.3. Hub begär 129
5.1.4. Begär CLEAR_HUB_FEATURE 130
5.1.5. Begär CLEAR PORT_FEATURE 130
5.1.6. Begär GET_BUS_STA TE 131
5.1.7. Begär GET_HUB_DESCRfPTOR 131
5.1.8. Begär GET_HUB_STATUS 131
5.1.9. Begär GET_PORT_STA TUS 132
5.1.10. Begär SET_HUB_DESCRIPTOR 134
5.1.11. Begär SET_HUB_FEATURE 134
5.1.12. SET PORT FEATURE begäran. 134
5.2. Samarbete enheter från i olika hastigheter 135
Kapitel 6. USB utan PC 137
6.1. OTG 138 kontakter
6.2. Typer av OTG-enheter 138
6.3. OTG-enhetsbeskrivning 139
6.4. Onlineresurser för detta kapitel 140
DEL III. PROGRAMMERINGSÖVNING 141
Kapitel 7. USB-stöd på Windows 143
7.1. Modell WDM 144
7.2. Interaktion med USB-drivrutin 146
Kapitel 8. HID-enheter * 149
8.1. HID-enhetsegenskaper 149
8.2. Hur man kommunicerar med en HID-enhet 151
8.3. Installera en HID-enhet 152
8.4. HID-enhetsidentifiering 152
8.4.1. Startenhetsidentifiering 153
8.4.2. HID-enhetskonfigurationsbeskrivning 153
8.4.3. HID-beskrivning 154
8.4.4. Rapportbeskrivning 156
8.5. Rapportbeskrivningsstruktur 156
8.5.1. Rapportelementens struktur 156
8.5.2. Typer av rapportelement 157
8.5.3. Exempel på deskriptorer 165
8.6. HID-enhetsfrågor 168
8.6.1. GET_REPORT begäran. 169
8.6.2. Begär SET_REPORT 169
8.6.3. GETJDLE begäran. 170
8.6.4. Fråga SETJDLE 170
8.6.5. Begär GET_PROTOCOL 171
8.6.6. Begär SET_PROTOCOL 171
8.7. Verktyg 171
8.8. Interaktion med HID-drivrutinen 172
Kapitel 9. Introduktion till WDM 181
9.1. Drivrutinslager 183
9.2. Symboliska enhetsnamn 184
9.3. Grundläggande procedurer för WDM-drivrutin 189
9.3.1. Procedur DriverEntry 190
9.3.2. Procedur AddDevice 192
9.3.3. Procedur Lossa 194
9.3.4. Driftsprocedurer för drivrutinen 196
9.3.5. Betjänar IOCTL 203-förfrågningar
9.4. Ladda föraren och komma åt förarprocedurer 209
9.4.1. Procedur för att arbeta med föraren 209
9.4.2. Registrering av föraren 210
9.4.3. Med hänvisning till Driftsprocedurer 217
9.4.4. Förvara föraren inuti körbar fil 218
9.5. Verktyg för att skapa drivrutiner 220
9.5.1. NuMega Driver Studio 220
9.5.2. Jungo WinDriver 220
9.5.3. Jungo Kernel Driver 220
Kapitel 10. USB PnP-specifikation 221
10.1. Allmän information om Plug and Play 221
10.1.1. Plug and Play-uppgifter och funktioner 221
10.1.2. Kör PnP-procedur 222
10.1.3. PnP 224 mjukvarukomponenter
10.2. Plug and Play för USB 225
10.2.1. Konfigurera USB 226-enheter
10.2.2. USB-enhetsnummer 226
10.2.3. PnP USB-enhetsidentifierare 228
10.3. Hämta en lista över USB-enheter 229
10.4. INF-fil 234
10.4.1. INF-filstruktur 234
10.4.2. Avsnitt Version 235
10.4.3. Sektionstillverkare 237
10.4.4. Sektion DestinationDirs 239
10.4.5. Modellbeskrivning avsnitt 241
10.4.6. Avsnitt xxx.AddReg och xxx.DelReg. 242
10.4.7. Avsnitt xxx.LogConfig 244
10.4.8. Avsnitt xxx.CopyFiles 244
10.4.9. Sektionssträngar 245
10.4.10. Sektionsanslutningar 246
10.4.11. Skapa och testa INF-filer 247
10.4.12. Installera enheter med en INF-fil 248
10.5. Registergrenar för USB 249
Kapitel 11. BIOS-funktioner 251
11.1. Service BIOS 1AN 251
11.1.1. Funktion B101H - bestämma närvaron av PCI BIOS 252
11.1.2. Funktion В102Н - sök efter PCI-enhet med identifierare
enhet och tillverkare 253
11.1.3. Funktion В103Н - sök efter PCI-enhet med klasskod 254
11.1.4. Funktion B108N - läsning av konfigurationsregister (Byte) 255
11.1.5. Funktion VYu9N - läsning av konfigurationsregistret (Word) 256
11.1.6. Funktion B10AN - läsning av konfigurationsregister (DWord) 256
11.1.7. Funktion В10ВН - skriv konfigurationsregister (Byte) 257
11.1.8. Funktion B10CH - skriva ett konfigurationsregister (Word) 257
11.1.9. Funktion B10DH - Konfigurationsregisterskrivning (DWord) 258
11.2. Exempel på användning 259
DEL IV. SKAPA USB-ENHETER 283
Kapitel 12. USB-kringutrustning 285
12.1. Atmel 286 marker
12.1.1. Mikrokontroller med MSC-51 286-arkitektur
12.1.2. Hub-kontroller 289
12.1.3. Hub mikroprocessorer med AVR 289 kärna
12.1.4. Andra Atmel 290 marker
12.2. Cygnal 291 chips
12.2.1. Mikroprocessorer C8051F320 och C8051F321 291
12.2.2. Andra Cygnal 293-chips
12.3. FTDI 296 chips
12.3.1. Chips FT232AM och FT232BM 297
12.3.2. Chips FT245AM och FT245BM 298
12.3.3. Chip FT2232BM 299
12.3.4. Chip FT8U100AX 300
12.3.5. Felsökningssatser och moduler 301
12.3.6. Drivrutiner 302
12.3.7. Ytterligare verktyg 303
12.3.8. Andra 304-moduler
12.4. Intel 304 chips
12.5. Microchip 308 chips
12.6. Motorola 308 chips
12.7. Philips 309 chips
12.7.1. USB 310 chips
12.7.2. Hubs 311
12.7.3. Andra Philips 313-chips
12.8. Texas Instruments 314 marker
12.9. Trans Dimension 317 chips
12.10. 318 strömskyddschips
12.11. Onlineresurser för detta kapitel 319
Kapitel 13. HID-enhet baserad på Atmel AT89C5131 322
13.1. Blockschema AT89S5131 322
13.2. USB-register AT89С5131 324
13.2.1. USBCON Register 324
13.2.2. USBADDR Register 326
13.2.3. USBINT Register 327
13.2.4. USBIEN 328 register
13.2.5. UEPNUM register. 329
13.2.6. Registrera UEPCONX 330
13.2.7. UEPSTAX register. 331
13.2.8. Registrera UEPRST. 334
13.2.9. UEPINT-registret. 335
13.2.10. Registrera UEPIEN 336
13.2.11. Registrera UEPDATX 337
13.2.12. Registrera UBYCTLX 337
13.2.13. UFNUML Register 338
13.2.14. UFNUMH register. 338
13.3. Krets AT89S5131 338
13.4. Programmeringsverktyg 339
13.4.1. Kompilator 341
13.4.2. Programmerare 342
13.5. Program för mikroprocessor 349
13.5.1. Första versionen av programmet för AT89S5131 349
13.5.2. Lägga till strängbeskrivningar 369
13.5.3. Lägger till slutpunkter 374
13.5.4. Skapa en HID-enhet 377
13.5.5. Kommunikation med HID-enhet 381
13.6. Läser rapporter i Windows 388
13.7. Ytterligare funktioner Windows XP 396
13.8. Enhet med flera rapporter 397
Kapitel 14. Skapa en USB-enhet baserad på ATMEL AT89C5131 402
14.1. Icke-HID-enhet 402
14.2. Skapa en drivrutin med använder drivrutinen Studio 405
14.2.1. Några ord om Driver Studio 407-biblioteket
14.2.2. Andra Driver Studio 411-klasser
14.2.3. Skapa en drivrutinsmall med Driver Studio 412
14.2.4. Förbättring av drivrutinsmall 422
14.2.5. Grundläggande metoder för 423-enhetsklassen
14.2.6. Implementering av läsning av data 426
14.2.7. Installera drivrutinen för 428
14.2.8. Data Reader 429
14.2.9. Läsa data från andra typer av endpoints 438
14.2.10. "Ren" USB-drivrutin 439
Kapitel 15: Använda FTDI 457-chips
15.1. Funktionsdiagram FT232BM 457
15.2. Kretsdesign FT232BM 460
15.3. Funktioner för D2XX 460
15.4. Övergång från COM till USB 465
15.4.1. Beskrivning av 465-omvandlarkretsen
15.4.2. Ställa in överföringshastigheten 467
DEL V. HANDBOK 469
Kapitel 16. Grundläggande Windows-funktioner 471
16.1. CreateFile och CloseHandle funktioner: öppna och stänga ett objekt.471
16.1.1. Ytterligare information 472
16.1.2. Returvärde 472
16.1.3. Exempelsamtal 472
16.2. Läs filfunktion: läser data 473
16.2.1. Ytterligare information 474
16.2.2. Returvärde 474
16.2.3. Exempel ring 474
16.3. WriteFile-funktion: dataöverföring 475
16.3.1. Ytterligare information 476
16.3.2. Returvärde 476
16.3.3. Exempelsamtal 476
16.4. ReadFileEx-funktionen. APC-dataavläsning 477
16.4.1. Returvärde 479
16.4.2. Ytterligare information 479
16.4.3. Exempel ring 479
16.5. WriteFileEx-funktion: APC-dataöverföring 480
16.5.1. Returvärde 481
16.5.2. Exempel ring 481
16.6. Funktion WaitForSingleObject väntar på signal
objekttillstånd 482
16.6.1. Returvärde 482
16.7. WaitForMultipleObjects funktion: väntar på signal
objektet anger 483
16.7.1. Returvärde 484
16.8. GetOverlappedResult funktion resultat av asynkron operation 484
16.8.1. Returvärde 485
16.9. DeviceIoControl-funktion: Direkt förarkontroll 485
16.9.1. Returvärde 487
16.10. QueryDosDevice funktion: hämta enhetens namn
med hans DOS-namn 487
16.10.1. Returvärde 488
16.10.2. Exempel ring 488
16.11: Definiera Dos-enhetsfunktion: operationer med DOS-enhetsnamn 489
16.11.1. Returvärde 490
16.11.2. Exempel ring 490
Kapitel 17. HID API-funktioner. 492
17.1. HidD_Hello-funktion: kontrollerar bibliotek 492
17.2. Funktion HidD_GetHidGuid: hämta GUID 492
17.3. HidD_GetPreparsedData-funktion: skapa en enhetsbeskrivning 493
17.4. HidD_FreePreparsedData-funktion: frigör enhetens handtag 493
17.5. Funktion HidD_GetFeature: tar emot FEATURE-rapport 494
17.6. HidD_SetFeature-funktion: skickar FEATURE-rapport 494
17.7. Funktionen HidD_GetNumInputBuffers: hämtar antalet buffertar 495
17.8. Funktion HidD_SetNumInputBuffers: ställ in antalet buffertar till 495
17.9. Funktion HidD_GetAtribntes: hämta enhetsattribut 495
17.10. Funktion HidD_GetMamifactnrerStnng. får tillverkarens sträng 496
17.11. Funktion HidD_GetProductString. får produktlinje 497
17.12. Funktion HidD_ Get Serial MumberString. få snöre
serienummer 497
17.13. Funktion HidD_GetIndexedString. få en rad vid index 498
17.14. Funktion HidDjGetlnputReporr. tar emot INPUT-rapport 498
17.15. Funktion HidD_SetOutputReport. skicka OUTPUT-rapport 499
17.16. HidP_GetCaps-funktion: hämta enhetsegenskaper 499
17.17. Funktion HidP_MaxDataListLength: få rapportstorlekar 500
Kapitel 18. UCH 502 Host Controller
18.1. Host Controller Control Register 502
18.1.1. USB Command Register (USBCMD) ..504
18.1.2. USB Status Register (USBSTS) 506
18.1.3. Avbrottskontrollregister (USBINTR) 506
18.1.4. Ramnummerregister (FRNUM) 507
18.1.5. Rambasadressregister (FLBASEADD) 508
18.1.6. Start av Frame Modifier Register (SOFMOD) 508
18.1.7. Port Status and Control Register (PORTSC) 509
18.2. UCH 510 Host Controllers datastrukturer
18.2.1. Lista över ramar 510
18.2.2. Överföringsbeskrivning i 511
18.2.3. Köhuvud 514
18.3. Bearbetar en lista med UCH 516-deskriptorer
Kapitel 19. Verktyg 518
19.1. Microsoft Visual Studio Tools 518
19.1.1. Beror på 518
19.1.2. Felsökning 518
19.1.3. GuidGen 518
19.2. Microsoft DDK 520-verktyg
19.2.1. DeviceTree 520
19.2.2. DevCon.-521
19.2.3. Chklnf och Genlnf. 526
19.3. CompuWare Corporation Tools 527
19.3.1. Monitor 527
19.3.2. SymLink 527
19.3.3. EzDriverlinstaller 527
19.3.4. WdmSniff 527
19.4. Betyder system 528
19.4.1. Winobj 528
19.5. USB Tools Forum 531
19.5.1. HID Descriptor Tool 531
19.6. Hårddiskprogramvara 533
19.7. Sourceforge Tools 533
ANSÖKNINGAR 535
Bilaga 1. Ytterligare funktioner 537
Bilaga 2. Tabell över språkidentifierare (LangID) 539
Bilaga 3. Tabell över tillverkarkoder (leverantörs-ID, enhets-ID) 543
Bilaga 4. Beskrivning av CD 546
Litteratur 548
Ämnesregister 549
Programmering via USB-port
Programmering av enheten för installation parabolantenner SF-50 via USB skiljer sig från programmering via RS-232 endast på det sätt som data överförs från instrumentet till datorn och från datorn till instrumentet. Vid programmering via USB, en bärbar USB-enhet(flash-enhet). Detta är praktiskt när, till exempel, din dator eller, oftare, en bärbar dator (netbook) inte har en seriell RS-232-port på chassit.
För att programmera enheten med en USB-enhet behöver du:
- USB-enhet (flash-enhet), formaterad i filsystem FAT-32;
- AliEditor-redigeringsprogram, som finns i mappen Database_editor_new i mjukvarudelen av OPENBOX SF-50-enheten.
Innan du programmerar måste du överföra databasen från enheten till din dator. För att göra detta, slå på enheten, anslut till porten USB-minne. Kör MENU – System – Spara till USB,
Stäng menyn genom att trycka på MENU-knappen tills den aktuella kanalen visas, eller tills huvudmenybilden om det inte finns några kanaler ännu och ta bort flashenheten. Sätt i flash-enheten i datorn.
Kör programmet Editor.exe från mappen Database_editor_new och öppna bilden på flashenheten i den.
När du uppmanas att välja en databas väljer du Användardatabas.
Klicka på OK. Välj Alla tjänster, en lista över alla skannade och sparade TV-, radio- och tjänstekanaler som finns tillgängliga i databasen öppnas.
Redigera kanaler som du vill, till exempel lämna bara öppna kanaler.
Tryck på på datorns tangentbord Skift-knapp, tryck på nedåtpilen och markera de kanaler du vill ta bort. Klicka på Ta bort för att ta bort den markerade.
För att redigera satellitinställningarna, välj Alla tjänster – Satellitinformation – EUTELSAT W4, W7, tryck på ENTER-knappen.
Om det behövs, redigera värdena i Antenn 1.
För att radera en transponder, ställ dig på den onödiga och tryck på Delete-knappen på datorns tangentbord, bekräfta den valda åtgärden.
För att lägga till en transponder, gå till namnet på satelliten, tryck höger knapp musen och välj Lägg till information (eller markera satelliten och tryck på knappen Infoga på tangentbordet).
Ange data för den nya transpondern, ta den till exempel från webbplatsen lyngsat.com.
Klicka på OK och se till att transpondern är registrerad.
För att lägga till en satellit, gå till raden Satellitinformation, tryck på knappen Insert på tangentbordet och ange parametrarna för den nya satelliten.
stäng redigeringsprogrammet och ta bort enheten.
Sätt in enheten i OPENBOX SF-50-enheten, följ sekvensen MENU – System – Uppdatera från USB, välj läget “SAT&TP List”.
Välj Start. Bekräfta dina avsikter.
Enheten kommer att uppdatera databasen och starta om sig själv. Efter omstarten måste du ställa in menyspråket till ryska på ett nytt sätt. Återställ enheten till fabriksinställningarna.
Stäng inställningsmenyn genom att trycka på MENU-knappen två gånger. Tryck på OK-knappen på den aktuella kanalen och se till att kanallistan är redigerad.
Du kan också se till att listan över transpondrar och satelliter är redigerad.
Programmeringen är klar.
USB-bussen (Universal Serial Bus) dök upp den 15 januari 1996, med godkännandet av den första versionen av standarden av Intel, DEC, IBM, NEC, Northen Telecom och Compaq.
Huvudmålet med standarden som satts upp för dess utvecklare är att skapa möjligheten för användare att arbeta i Plug&Play-läge med kringutrustning. Detta innebär att enheten måste vara ansluten till en kördator, automatisk igenkänning det omedelbart efter anslutning och efterföljande installation av lämpliga drivrutiner. Dessutom är det lämpligt att mata ström till lågeffektsenheter från själva bussen. Busshastigheten borde vara tillräcklig för de allra flesta kringutrustning. USB-kontroller ska bara ta ett avbrott, oavsett antalet enheter som är anslutna till bussen, det vill säga lösa problemet med bristande resurser på de interna bussarna på en IBM PC-kompatibel dator.
Nästan alla uppgifter löstes med USB-standarden och våren 1997 kom datorer utrustade med kontakter för USB-anslutningar enheter. Nu har USB blivit så aktivt implementerat av tillverkare av kringutrustning till datorer att till exempel iMAC-datorn från Apple Computers endast har USB som extern buss.
USB-funktioner 1.0 är följande:
1. hög dataöverföringshastighet (full hastighet) – 12 MB det/Med;
2. maximal kabellängd för höghastighetsutbyte är 5 meter;
3. låg datautbyteshastighet (låghastighet) – 1,5 MB det/Med;
4. maximal kabellängd för låg dataöverföringshastighet är 3 meter;
5. maximalt antal anslutna enheter – 127;
6. möjlig samtidig anslutning av enheter med olika växelkurser;
8. Den maximala strömförbrukningen per enhet är 500 mA.
Därför är det tillrådligt att ansluta nästan alla kringutrustning till USB 1.0, förutom digitala videokameror och höghastighets hårddiskar. Detta gränssnitt är särskilt praktiskt för att ansluta ofta anslutna/bortkopplade enheter, såsom digitalkameror.
Möjligheten att använda endast två datahastigheter begränsar bussens användbarhet, men minskar avsevärt antalet gränssnittslinjer och förenklar hårdvaruimplementeringen.
Strömförsörjning direkt från USB är endast möjlig för enheter med låg effekt som tangentbord, möss, joysticks etc.
USB-signaler överförs via en 4-trådskabel, som visas schematiskt i bilden nedan:
Figur 2.6.1 – Signal USB-kablar
Här är GND den gemensamma trådkretsen för att driva kringutrustning, Vbus är +5 V även för kraftkretsar. D+-bussen är för att överföra data på bussen, och D-bussen är för att ta emot data.
Fullhastighetsbusskabeln är en partvinnad kabel, skyddad av en skärm, och kan även användas för låghastighetsdrift. En kabel för drift endast vid lägsta hastighet (till exempel för att ansluta en mus) kan vara vilken som helst och oskärmad.
Kontakterna som används för att ansluta kringutrustning är uppdelade i serier: "A"-seriens kontakter (kontakt och uttag) är endast avsedda för anslutning till en källa, såsom en dator, "B"-seriens kontakter (kontakt och uttag) är endast avsedda för anslutning till en kringutrustning.
USB-kontakter har följande stiftnummer, som visas i Tabell 2.6.1.
Tabell 2.6.1 – Syfte och märkning USB-kontakter
1999 började samma konsortium av datorföretag som initierade utvecklingen av den första versionen av USB-bussstandarden aktivt utveckla version 2.0 av USB, som utmärkte sig genom införandet av ett extra höghastighetsläge (höghastighet). Bussbandbredden har utökats 40 gånger, upp till 480 Mbit/s, vilket gjorde det möjligt att överföra videodata via USB.
Kompatibiliteten för all tidigare utgiven kringutrustning och höghastighetskablar är helt bevarad. Standardstyrenheten 2.0 är redan integrerad i systemlogikuppsättningen av programmerbara enheter (t.ex. moderkort persondator).
2008 skapade Intel, Microsoft, Hewlett-Packard, Texas Instruments, NEC och NXP Semiconductors standardspecifikationen USB 3.0. I USB 3.0-specifikationen är den uppdaterade standardens kontakter och kablar fysiskt och funktionellt kompatibla med USB 2.0, men utöver de fyra kommunikationslinjerna har ytterligare fyra tillkommit. Men nya kontakter in USB-kontakter 3.0 är placerade separat från de gamla på en annan kontaktrad. USB 3.0-specifikationen förbättras maximal hastighetöverföra information upp till 5 Gbit/s – vilket är en storleksordning större än de 480 Mbit/s som USB 2.0 kan ge. Dessutom har den maximala strömmen höjts från 500 mA till 900 mA per enhet, vilket gör att du kan driva vissa enheter som tidigare krävde en separat strömförsörjning.
Anta att du har utvecklat en USB-enhet som du behöver arbeta med med en dator. Detta kan uppnås på minst två sätt:
1. utveckling av en fullfjädrad drivrutin operativsystem;
2. användning av ett USB-gränssnitt av särskild klass - enheter som kallas HID-enheter (Human Interface Device).
Den första metoden är universell: med tillräcklig kunskap inom området för att skriva drivrutiner kan du programmera den för att fungera med vilken enhet som helst med vilken hastighet som helst som stöds av USB. Men det här är en ganska svår uppgift.
Det andra sättet är som följer. Det finns ett gränssnitt som stöds av moderna operativsystem för dator-mänskliga gränssnittsenheter eller HID-enheter, som:
1. tangentbord, möss, joysticks;
2. olika sensorer och läsare;
3. Spelstyrning och pedaler;
4. knappar, strömbrytare, regulatorer.
En sådan enhet, om den uppfyller kraven för HID-enheter, kommer att kännas igen automatiskt av systemet och kommer inte att kräva att skriva speciella drivrutiner. Dessutom är deras programmering oftast mycket mer lättare att skriva specialiserad enhetsdrivrutin. Tyvärr har denna metod en betydande nackdel: hastigheten för informationsutbytet med HID-enheten är mycket begränsad och uppgår till maximalt 64 kB/s.
I princip, baserat på HID-teknik, är det möjligt att organisera interaktion med vilken enhet som helst, även om den inte i strikt mening är en gränssnittsenhet mellan en person och en dator. Detta eliminerar den tidskrävande utvecklingen av en unik enhetsdrivrutin och sparar tid på att utveckla en ny USB-enhet. På värdsidan kommer kommunikationen med enheten att styras av den vanliga HID-drivrutinen som ingår i operativsystemet. Du behöver bara göra det från enhetens sida minimikrav USB-HID-protokoll.
Det är värt att notera att många USB-enheter, som vid första anblicken inte faller under definitionen av mänskliga interaktionsenheter, fortfarande är mer logiska att implementeras som HID-enheter. Detta fenomen är vanligt inom tillverkningsutrustningsområdet, som nyligen har upplevt en massiv användning av USB-teknik. Tänk till exempel på en laboratorieströmförsörjning med möjlighet att ställa in parametrarna för dess utsignaler från en dator med hjälp av ett USB-gränssnitt. Strömkällan i sig är utan tvekan inte ett sätt att interagera med en person. Dock i i detta fall funktioner implementerade via en USB-anslutning duplicerar tangentbordet, kontrollerna och indikatorerna installerade på själva enheten. Och dessa kontroller faller inom definitionen av HID. Följaktligen är det mest logiskt att organisera en strömförsörjning med dessa USB-funktioner som en HID-enhet.
I det övervägda exemplet för normal drift En låg dataöverföringshastighet räcker i andra fall, enheter kan kräva mycket växelkurs. Låg överföringshastighet är den huvudsakliga begränsningen för HID-enhetsdesignalternativet, som jämfört med 12 Mbit/s fullt USB-hastighet 1.0-bussen verkar vara en stor nackdel med HID-tekniken när det gäller att välja en specifik USB-implementation. Men för många kommunikationsuppgifter är den angivna hastigheten tillräckligt och HID-arkitekturen, som ett specialiserat verktyg, tar sin rättmätiga plats bland metoderna för att organisera datautbyte.
Det finns två typer av HID-enheter: de som deltar (boot) och de som inte deltar i den initiala uppstarten av datorn. Det mest slående exemplet på en startbar USB-HID-enhet är ett tangentbord som börjar fungera när datorn startar.
När du designar en HID-enhet måste följande specifikationskrav uppfyllas:
1. Fullhastighets HID-enhet kan överföra 64000 byte varje sekund eller 64 byte var 1ms; En låghastighets HID-enhet kan överföra upp till 800 byte per sekund, eller 8 byte var 10:e ms.
2. HID-enheten kan schemalägga sin avfrågningsfrekvens för att avgöra om den har nya data att sända.
3. Datautbyte med HID-enheten utförs genom en speciell struktur som kallas en rapport. Varje definierad rapport kan innehålla upp till 65535 byte med data. Rapportstrukturen har en mycket flexibel organisation som gör att du kan beskriva vilket dataöverföringsformat som helst. För att ett specifikt rapportformat ska bli känt för värden måste mikrokontrollern innehålla en speciell beskrivning - en rapportdeskriptor.
Genomfört USB-interaktion direkt på mikrokontrollern på flera sätt:
1. använda en styrenhet med hårdvarustöd, till exempel AT90USB*, från atmega;
2. använda mjukvaruemulering av USB-gränssnittet på valfri mikrokontroller.
För mjukvaruimplementering finns det idag ett antal färdiga lösningar för olika familjer av mikrokontroller. För AVR-mikrokontroller, till exempel Atmega8, är det möjligt att använda följande gratisbibliotek på C-språket:
Båda är ganska lätta att använda, ger full emulering av USB 1.1-låghastighetsenheter, med undantag för hantering av kommunikationsfel och elektriska egenskaper, och körs på nästan alla AVR-kontroller med minst 2 kilobyte flashminne, 128 byte RAM och en frekvens på 12 till 20 MHz.
Att skriva applikationer som stöder Windows USB HID-enheter kräver hid* header-filer som ingår i WDK ( Windows-drivrutin Kit), eller så kan du använda det fritt distribuerade biblioteket hidlibrary eller något annat liknande.
Således är USB-programmering i allmänhet en ganska komplex uppgift, som kräver en speciell mikrokontroller med hårdvarustöd och skrivning av en drivrutin för operativsystemet. Men i praktiken, när du utvecklar enheter, kan du använda ett mycket enklare HID-enhetsgränssnitt, vilket stöd implementeras på nivån av en standardsystemdrivrutin, och programmering förenklas genom att använda befintliga funktionsbibliotek.
Men det räcker inte bara att fysiskt ansluta enheten till datorn, du måste också etablera datautbyte mellan dem. Hur väljer man en port och organiserar en anslutning? För några år sedan standardlösning använde en COM-port. Förresten, olika specialister installerar fortfarande 8, 16 eller till och med 32 COM-portar på industridatorer (det finns en hel kategori av olika PCI-expansionskort för serieportar, kontroller, etc.). Om du behöver ansluta flera externa enheter med ett RS-232-gränssnitt kan du alltså behöva dyra adaptrar och exotiska expansionskort, som enligt den gamla traditionen reser till Ryssland med fartyg i veckor. Förresten, namnet på en vanlig adapter "DB9m/DB25f adapter" kan bara orsaka irritation för en datorbutikschef.
Vad är en HID-enhet
Numera är nästan alla enheter anslutna till en dator via ett USB-gränssnitt. Därför har många nya datorer ingen COM-port alls.
USB-gränssnitt - en typisk lösning för att para ihop en ny extern enhet med en dator, mer exakt, det är ett HID-gränssnitt baserat på USB 1.1-protokollet.
Även om många tror att HID-gränssnittet (Human Interface Device) enbart är avsett för tangentbordet, musen och joysticken, är det lämpligt för många lösningar relaterade till att para ihop externa enheter med en dator.
Om användaren behöver utföra låghastighetsdatautbyte (upp till 64 kbit/s) och samtidigt vill minska tiden som läggs på tråkig utveckling av sina egna drivrutiner, är HID ganska lämplig för honom. Slutresultatet blir enkelt och fullständigt modern lösning baserat på ett standard USB-mjukvarugränssnitt med garanterat stöd på alla vanliga mjukvaruplattformar.
HID-enhetsegenskaper
Ur synvinkel att organisera mjukvarustöd för en HID-enhet ser allt ganska attraktivt ut: att arbeta under Windows kontroll du kan snabbt skapa begriplig, kompakt kod baserad på färdiga, beprövade algoritmer. Samtidigt kommer utvecklaren att ha mycket tid att implementera sitt eget datautbytesprotokoll på toppnivå, eftersom den nödvändiga abstraktionsnivån redan är organiserad genom HID-protokollet (se tabell). Dessutom är det lätt för en programmerare att felsöka ett skriftligt utbytesprotokoll (naturligtvis om det finns en fungerande HID-enhet) - på grund av den relativa stelheten hos själva protokollet räcker det att helt enkelt utveckla ett datorstödsprogram för anordning. Naturligtvis! Skaparen av HID-enheten har redan tagit på sig mycket arbete.
Organisering av datautbyte mellan HID-enheten och datorn
För att beskriva interaktionen mellan en HID-enhet och en dator kommer vi att använda termen "värd". I det här fallet betyder det kontrollanordning i allmänhet fysisk arkitektur interaktion via USB-protokoll. Så alla portar på en dator är värdar. Du kan ansluta olika USB-enheter (flash-enheter, möss, webbkameror, kameror, etc.) som inte har en värd för dem. Värden tillhandahåller enhetsupptäckt, anslutning, frånkoppling, konfiguration, samt statistikinsamling och energihantering.
HID-enheten kan ställa in sin egen avfrågningsfrekvens för att avgöra om den innehåller några nya data. Detta innebär att även på en så låg nivå kan programmeraren lita på systemet, eftersom pollingfrekvensen och andra kommunikationsparametrar måste förinställas i HID-enhetskontrollprogrammet. Det är så HID-protokollet skiljer sig från det allmänna USB-beskrivningar 1.1 eller USB 2.0, som inte har några strikta krav på organisationen av protokollet. Dock för specifika uppgifter som kräver högre nivå säkerhet kan det vara ganska svårt att bli av med cyklisk polling när nästan samma datablock ständigt sänds.
HID-enhetsprogrammeringsfunktioner
HID-enheter har speciella beskrivningar. När värden bestämmer att enheten tillhör HID-klassen, överför den kontrollen över den till lämplig drivrutin. Det förutsätts att ytterligare datautbyte genomförs under hans ledning.
I Windows är HidServ-systemtjänsten ansvarig för åtkomst till HID-enheter. Mer information om funktionerna för förfrågningar till HID-enheter och andra funktioner för att arbeta med HID-drivrutinen beskrivs i arbetet med P. V. Agurov “USB Interface. Praxis för användning och programmering" (S:t Petersburg: BHV-Petersburg, 2005).
Programmera HID-enheter på "toppnivå"
Det hårda livet för "applikations"-programmerare som arbetar i Pascal underlättas av den beprövade HID-modulen. PAS, skalmjukvara för hid. dll (Hid User Library - som anges i filegenskaperna). Kommentarerna till filen visar att den är baserad på modulerna hidsdi.h och hidpi.h från Microsoft. Och själva HID-filen. PAS är en del av JEDI()-paketet.
Att arbeta med en HID-enhet i Delphi miljö för win32 används TJvHidDeviceController-komponenten, vilket är en bekväm global hanterare för åtkomst till HID-enheter. Och redan på grundval av det kan du få en objektinstans för att arbeta med en specifik enhet.
Grundläggande egenskaper och händelser för TJvHidDeviceController-komponenten
Låt oss titta på TJvHidDeviceController-komponenten mer i detalj. OnArrival-händelsen utlöses när en HID-enhet anländer (ansluter) till systemet åtkomst till enheten tillhandahålls i hanteraren för denna händelse genom en instans av klassen TJvHidDevice. Den enkla OnDeviceChange-händelsen reagerar på förändringar i enhetens tillstånd den signalerar bara förändringar i systemet. OnDeviceData-händelsen utlöses när data kommer från en av HID-enheterna och skickar följande till hanteraren: HidDev: TJvHidDevice; - enheten från vilken data togs emot;
Händelsen OnDeviceDataError meddelar om ett dataöverföringsfel genom att skicka HidDev-parametrarna till bearbetningsproceduren: TJvHidDevice; - HID-enhet och fel: DWORD; - felkod. OnDeviceUnplug-händelsen meddelar att en enhet tas bort från listan över installerade på systemet. Typerna av händelsehanterare på Plug och Unplug är desamma (i källtexten: TJvHidUnplugEvent = TJvHidPlugEvent). Ett objekt av klassen TJvHidDevice som motsvarar HID-enheten skickas till hanteraren.
För att sekventiellt räkna upp de HID-enheter som är tillgängliga i systemet genom att anropa Enumerate-metoden, är OnEnumerate-händelsen avsedd, dvs. i händelsehanteraren överförs de hittade enheterna sekventiellt som objekt. Denna händelse framtvingas av Enumerate-metoden, som används för att "passera" befintliga HID-enheter genom en hanterare, till exempel när tillståndet för HID-enheter revideras på initiativ av värden (datorn).
OnRemoval-händelsen utlöses när en enhet fysiskt tas bort från systemet och har samma hanterartyp TJvHidUnplugEvent som för OnDeviceUnplug. Funktionen CountByProductName returnerar antalet enheter som matchar produktnamnet som anges i argumentet, och CountByVendorName returnerar tillverkarens namn som anges i argumentet.
Huvudegenskaper och händelser i klassen TJvHidDevice
Klassen TJvHidDevice är en virtuell representation av en enda HID-enhet. Ett nytt objekt av denna klass kan erhållas, som redan nämnts, från OnArrival- eller OnEnumerate-händelsen. Funktionaliteten hos klasserna TJvHidDeviceController och TJvHidDevice är delvis duplicerad, eftersom den första av dem integrerar vanliga verktyg för att arbeta med en uppsättning HID-enheter som finns tillgängliga i systemet och en mekanism för att komma åt en av dem. En enhet kan identifieras unikt med egenskaperna SerialNumber, ProductName och VendorName. För att få information om ankomsten av data med hjälp av ett sådant objekt kan du använda OnData-händelsen. Data skickas genom metoden WriteFile (i strikt mening - genom en funktion). WriteFile är ett omslag runt WriteFile (kernel32) systemfunktionen.
För att kontrollera om enheten har tagits bort bör du tilldela din egen hanterare till OnUnplug-händelsen. Innan du börjar utbyta data med en HID-enhet måste du se till att ett sådant utbyte är möjligt med HasReadWriteAccess. Den här klassen har till och med en separat OnDataError-händelse när ett datautbytesfel inträffar.
Låt oss nu titta på kodfragment från ett "live"-projekt som implementerar en testklientapplikation för att organisera datautbyte med en icke-standardiserad enhet - HID-baserade plastchipkort. I kampen för realism tog författaren sig friheten att inte kasta ut "extra" tekniska kodkopplingar från listorna.
ScanDevices-metoden (lista 1) är avsedd att initiera processen att söka i systemet efter den nödvändiga HID-enheten. Det mesta av koden, med undantag för anropet till Enumerate-metoden, är valfritt och ger flexibilitet till applikationen, till exempel så att möjligheten att arbeta på ett icke-HID-gränssnitt skulle kunna läggas till i samma testprogram. AddError-metoden visar felsökningsinformation i fönstret medan programmet körs.
Lista 2 visar en OnEnumerate-händelsehanterare för att hitta den externa enheten som krävs. För enkelhetens skull kommer vi att anta att programmet bara kan fungera med en enhet av den typ det behöver.
Innan vi överväger det fortsatta genomförandet av projektet bör vi prata lite om det antagna datautbytesformatet på toppnivå, det vill säga om strukturen utformad för att vara en mellanhand mellan metoderna för att ta emot och överföra data och det specifika applikationsproblemet som ska lösas. Faktum är att här ges utvecklaren möjligheten att förverkliga sina kreativa förmågor. Eller snarare, utvecklare, eftersom processen att skapa ett nytt protokoll ofta är tvåvägs, och den första fiolen spelas av den som har svårare att implementera utbytesalgoritmen. I allmänhet, oavsett vad utbytesprotokollet är, är det alltid trevligt att göra varje mjukvaruenhet så visuell och självförsörjande som möjligt, även på bekostnad av några allmänt accepterade traditioner. För bästa lösningen- något som kommer att implementeras på kort tid med minimal koppling till mjukvarumiljö och med stora möjligheter till vidareutveckling. Baserat på dessa principer skapades ett utbytesprotokoll på toppnivå, där huvudkonceptet är "kommando". Lista 3 visar hur mycket författaren älskar strängdata, vilket har sparat honom mer än en gång vid felsökning av programmoduler. Vad underbart det är att vi ens har en String-typ! Alla protokollkommandon är indelade i kategorier (klasser), inom vilka det finns en kommandokod som unikt karakteriserar dess syfte. Parametern edParam används för att skicka data till enheten, och parametern edAnswerData innehåller data som tas emot från enheten. Strängtypen för de beskrivna postmedlemmarna låter dig fritt och tydligt manipulera data i HEX-strängformat. Och det bästa är att formatet för den beskrivna posten ideologiskt sett står någonstans i mitten mellan dess direkta syfte och de olika formerna av dess presentation (INI, HEX, XML, etc.)
Utförande av kommandot, d.v.s. sändning av data till enheten, implementeras genom att skicka datapaket 8 byte långa (lista 4). Den här längden är inte den enda lösningen. Detta är, som man säger, en smaksak. Den märkliga IsUSBMode-flaggan i ExecuteCommand-metoden (listning 5 i PC World) är kvar som en påminnelse om att vi kan behöva använda en COM-port eller något annat gränssnitt istället för att arbeta med USB. I början av den skickade datagruppen sänds en synkroniseringsserie av ett slumpmässigt valt format (till exempel 3E3E3E2B) till enheten, vilket informerar enheten om att den har helt laglig data vid ingången. Låt mig påminna dig om det i det här fallet vi pratar om inte så mycket om HID, utan om ett specifikt toppnivåprotokoll, ideologiskt skilt från hårdvaran och utformat för att lösa specifika applikationsproblem.
GetDataExecutor-hanteraren för data som tas emot från enheten (ett paket på 8 byte) använder en speciellt skapad OnNewInputData-händelse för att överföra de initialt bearbetade data för vidare bearbetning, vilket indikerar deras gamla och nya värden (lista 6 på "World of PC Disk" ”). På detta sätt frikopplas rådataankomsthändelserna och indikationen för vidare bearbetning, vilket gör att någon specifik algoritm kan läggas till i ett tidigt skede för att varna för felaktig, dubblerad eller onödig inmatningsinformation.
Exemplen på att arbeta med en HID-enhet som presenteras här illustrerar den allmänna idén med artikeln - den relativa lättheten att programmera icke-standardiserade HID-enheter med Delphi.
