include 18f2455 -- libreria per MK usati
--
enable_digital_io() -- commuta tutti gli ingressi in modalità digitale
--
alias pulsante È perno_B7 -- visto che abbiamo un pulsante connesso, dichiaralo
pin_B7_direction = ingresso -- il pulsante funziona per noi all'ingresso
--
- una riga - e abbiamo tutto il necessario per lavorare con USB CDC
include usb_serial -- libreria usb
--
usb_serial_init() -- --inizializza USB CDC
ciclo per sempre-- ciclo principale, funziona continuamente
usb_serial_flush() - aggiornamento usb. Questa procedura fa tutto il necessario
-- azioni per mantenere la connessione con il PC
ciclo finale
Compilazione dato codice Scrivendo il file HEX risultante su MK utilizzando un bootloader e avviando il dispositivo, è possibile osservare come viene definito un nuovo dispositivo nel sistema: Virtual com-port.
Ora che il dispositivo funziona già, insegniamogli a comunicare.
Per leggere il byte ricevuto c'è una funzione usb_serial_read( byte ) : booleano. Se c'è un byte ricevuto, lo memorizza nella variabile specificata e restituisce VERO, altrimenti ritorna falso.
C'è una procedura per inviare un byte usb_serial_data. È camuffato da variabile, quindi per inviare un byte è sufficiente assegnargli il valore del byte che si sta inviando.
Dichiariamo una variabile con una dimensione di byte prima del ciclo principale, nel ciclo principale verificheremo la presenza di byte ricevuti e, se ce ne sono, li rispediremo.
includere 18f2455
--
enable_digital_io()
--
alias pulsante È perno_B7
pin_B7_direction = ingresso
--
--
includere usb_serial
--
usb_serial_init()
var byte cap -- dichiarare una variabile
ciclo per sempre-- ciclo principale
usb_serial_flush()
Se(usb_serial_read(ch)) Poi-- se viene ricevuto un byte, verrà scritto in ch
usb_serial_data=ch -- inviare indietro il byte ricevuto
finisci se
ciclo finale
Compiliamo, teniamo premuto il pulsante, distorciamo l'alimentazione, lanciamo il bootloader, cambiamo il firmware, lo lanciamo.
Il dispositivo è stato nuovamente rilevato nel sistema, ora abbiamo bisogno di software per testare il funzionamento del dispositivo.
Anche se non abbiamo il nostro, utilizziamo un terminale già pronto: ho usato il programma RealTerm.
Apriamo la porta con il numero desiderato e inviamo i dati.
E otteniamo ciò che abbiamo inviato. Quindi tutto funziona come dovrebbe.
Noi creiamo nuovo progetto, disperdiamo i componenti necessari nella forma:
SpinEdit1 - per specificare il numero di porta
Button1 - per stabilire una connessione
Button2 - per interrompere la connessione
SpinEdit2 - per inserire un byte in forma decimale
Button3 - per inviare un byte
Memo1 - per visualizzare le informazioni ricevute.
Come accennato in precedenza, è necessario lavorare con la porta COM allo stesso modo di una normale. file di testo: Utilizzo delle funzioni CreateFile, WriteFile e ReadFile.
Per non entrare nei dettagli, prendiamo una libreria già pronta per lavorare con una porta com: ComPort.
Appendiamo l'attività necessaria su ciascun pulsante e otteniamo il codice finale:
unità Unità1;interfaccia
utilizza
Windows, Messaggi, SysUtils, Varianti, Classi, Grafica, Controlli, Moduli,
Dialoghi, StdCtrls, Spin, ComPort;tipo
TForm1 = classe(TForm)
SpinEdit1: TSpinEdit;
Pulsante1: Pulsante T;
Pulsante2: Pulsante T;
SpinEdit2: TSpinEdit;
Pulsante3: Pulsante T;
Nota1:TMemo;
procedura OnRead(Sender: TObject; ReadBytes: array di Byte );
procedura Button1Click(Sender: TObject);
procedura Button2Click(Sender: TObject);
procedura FormDestroy(Mittente: TObject);
procedura Button3Click(Sender: TObject);
privato
(Dichiarazioni private)
Porta: TComPort;
pubblico
(Dichiarazioni pubbliche)
FINE;var
Modulo1: TForm1;
num: numero intero;
implementazioneProcedura TForm1.Button1Click(Sender: TObject);
inizio
Porta:= TComPort.Create(SpinEdit1.Value, br115200); // crea una connessione
Port.OnRead:= In lettura; //crea un flusso per leggere i dati ricevuti
Button2.Enabled:= true ; //attiva il pulsante di chiusura della connessione
FINE;Procedura TForm1.Button2Click(Sender: TObject);
inizio
Porto libero; // chiude la connessione
Button2.Enabled:= falso ; //disabilita il pulsante
FINE;Procedura TForm1.Button3Click(Sender: TObject);
inizio
se Button2.Enabled allora Port.Write();
FINE;Procedura TForm1.FormDestroy(Sender: TObject);
inizio
se Button2.Enabled allora
Porto libero;
FINE;Procedura TForm1.OnRead(Sender: TObject; ReadBytes: array di Byte );
var
i:intero;
inizio
for i:= Da Low(ReadBytes) a High(ReadBytes) fare //passa attraverso l'array di byte ricevuti
inizio
Memo1.Text:= Memo1.Text + "." +InttoHex(ReadBytes[i],2); //aggiungo il suo valore HEX alla finestra
inc(num); //conta il numero di byte ricevuti
FINE;
se num > 10 allora inizia
Nota1.Linee.Add("" ); //linea di trasferimento
numero:=0;
FINE;
FINE;
Iniziamo, stabiliamo una connessione, inviamo byte:
Quindi il nostro terminale più semplice è pronto per funzionare con il dispositivo USB più semplice.
Come puoi vedere, la lettura e la scrittura sono array dinamici di byte.
Elaborando le informazioni ricevute, è possibile redigere il protocollo di scambio necessario adatto all'attività corrente.
includere 18f2455
--
enable_digital_io()
--
alias pulsante È perno_B7
pin_B7_direction = ingresso
--
--
includere usb_serial
--
usb_serial_init()
var byte cap
var byte io -- dichiara la seconda variabile
ciclo per sempre-- ciclo principale
usb_serial_flush()
Se(usb_serial_read(ch)) Poi-- se il byte viene ricevuto, eseguire le azioni necessarie
caso ch di -- iterare sul numero di byte
0 : usb_serial_data = 0xff
1 : usb_serial_data = Pulsante -- invia lo stato del pulsante
ALTRIMENTI bloccare-- se si riceve qualcos'altro
per 16 utilizzando io ciclo continuo-- invia 10 byte di dati
usb_serial_data = ch +i -- da ch a ch+15
ciclo finale
blocco finale
caso finale
finisci se
ciclo finale
> includere la stampa
...
vardword dati
print_dword_hex (usb_serial_data, dati)
Il nome di tutti i comandi può essere trovato nel file della libreria.
Mentre(usb_cdc_line_status() == 0x00) ciclo continuo
ciclo finale
const byte USB_STRING3=
{
24 , -- lunghezza dell'array
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 ,
"UN", 0x00 ,
"R", 0x00 ,
"D", 0x00 ,
" " , 0x00 ,
"=" , 0x00 ,
")" 0x00
}
Ma purtroppo, dopo aver installato i driver, il dispositivo cambierà il suo nome in quello specificato nel file .inf, quindi cambieremo anche il nome lì
DESCRIPTION="Demo CDC"
Prima di tutto, devi assegnare un produttore e un valore di prodotto univoci al tuo dispositivo per identificarlo facilmente tra centinaia di altri firmware CDC standard.
VID e PID vengono dati per soldi, quindi seguiamo la strada dei cinesi: prendiamoci tranquillamente valori ovviamente gratuiti.
firmware:
Due variabili devono essere dichiarate nel firmware prima di collegare la libreria USB
parola costante USB_SERIAL_PRODUCT_ID = 0xFF10
parola costante USB_SERIAL_VENDOR_ID = 0xFF10
Autisti:
Poiché i driver non sono progettati per la nostra combinazione di VID e PID, aggiungeremo manualmente i nostri valori al file .inf:
%DESCRIPTION%=Installazione driver, USB\VID_FF10&PID_FF10
%DESCRIPTION%=Installazione driver, USB\VID_FF10&PID_FF10
Morbido:
Per rilevare gli eventi di connessione/disconnessione del dispositivo, collegheremo la libreria ComponentUSB. Non ritengo necessario spiegare ogni riga: tutte le modifiche sono visibili nel progetto allegato.
Come puoi vedere, organizzare lo scambio di dati tra MK e PC tramite USB non è il compito più difficile. La connessione risultante può essere utilizzata non solo per scopi finali: è anche adatta per il debug di un programma. Dopotutto, inviare i risultati dei calcoli, gli stati correnti dei registri e delle variabili a un computer è molto più chiaro che far lampeggiare una coppia di LED in codice Morse.
E infine, ti consiglio di esaminare fonte lampade d'atmosfera. Puoi trovarne parecchi lì. una buona opzione elaborazione dei dati ricevuti per organizzare un comodo protocollo di scambio.
Bel libro, spiega molte cose. Utile per chi vuole capire come vengono trasferiti i dati sul bus USB.
Introduzione 1
Per chi è questo libro: 2
Cosa troverai nel libro 2
Requisiti software 3
Requisiti hardware 4
Informazioni sul codice 4
Breve descrizione dei capitoli 4
Notazione 6
Grazie 7
PARTE I. INTRODUZIONE ALL'USB 9
Capitolo 1. Cos'è l'USB 11
1.1. Storia dell'USB 11
1.2. Confronto di USB con altre interfacce 14
1.3. USB Concetti di base 16
1.3.1. Architettura generale del bus 16
1.3.2. Architettura del bus fisico e logico 16
1.3.3. Componenti di USB 18
1.3.4. Proprietà del dispositivo USB 18
1.3.5. Proprietà del mozzo 19
1.3.6. Proprietà ospitanti 20
1.4. Esempi di dispositivi USB 20
1.4.1. Mouse e tastiera., 21
1.4.2. Monitor 21
1.4.3. Adattatori da USB a COM e da USB a LPT 22
1.4.4. Scanner 23
1.4.5. Modem 23
1.4.6. Altoparlanti 24
1.4.7. Unità flash 25
1.4.8. Mozzi 28
1.4.9. Tecnologia di misurazione 28
1.4.10. Gadget esotici 29
1.5. connessione di rete tramite USB 30
1.5.1. Convertitore da USB a Ethernet 31
1.5.2. Connessione diretta tramite porta USB 31
1.6. Trasferimento dati 31
1.6.1. Principi di comunicazione 32
1.6.2. Meccanismo di interruzione 32
1.6.3. Interfacce adattatore host 32
1.6.4. Capacità di accesso diretto alla memoria 34
1.6.5. Modalità di comunicazione 34
1.7. Installazione e configurazione dei dispositivi USB 35
1.7.1. Impostazioni del BIOS per USB 38
1.7.2. Risoluzione dei problemi 41
1.8. Limiti USB 45
1.9. Se acquisti un computer 46
1.9.1. HS e USB 2.0 non sono la stessa cosa! 46
1.9.2. Scheda madre 47
1.9.3. Edificio 48
1.9.4. USB per modelli di computer "vecchi" 48
1.10. Risorse online per questo capitolo 49
capitolo 2 Hardware USB 51
2.1. Cavi e connettori 51
2.1.1. Tipi di cavi 52
2.1.2. Lunghezza cavo 53
2.1.3. connettori 53
2.2. Interfaccia fisica 55
2.2.1. Codifica dei dati 57
2.2.2. Identificazione del dispositivo 58
2.3. Nutrizione 59
2.3.1. Tipi di alimentazione dei dispositivi USB 59
2.3.2. Gestione dell'energia 60
2.3.3. Entrando in modalità basso consumo energetico 61
2.4. Risorse online per questo capitolo 61
SECONDA PARTE. ORGANIZZAZIONE INTERNA USB 63
Capitolo 3 Organizzazione interna di Tyre 65
3.1. Livelli logici della comunicazione 65
3.1.1. Software client livello 66
3.1.2. Driver di sistema USB livello 67
3.1.3. Controller host interfaccia livello 68
3.1.4. Bus periferico livello 68
3.1.5. Dispositivo logico USB livello 69
3.1.6. Livello funzionale del dispositivo USB 69
3.2. Trasferimento di dati a più livelli 69
3.3. Tipi di trasferimento dati 71
3.4. Sincronizzazione con trasmissione isocrona 73
3.5. Personale 77
3.6. Punti finali 78
3.7. Canali 79
3.8. Pacchetti 81
3.8.1. Formato dei pacchetti di token IN, OUT, SETUP e PING 83
3.8.2. Formato pacchetto SOF 83
3.8.3. Formato pacchetto dati 84
3.8.4. Formato del pacchetto di riconoscimento< 84
3.8.5. SPLIT * 84 formato pacchetto
3.9. Somma di controllo 85
3.9.1. Algoritmo di calcolo CRC 86
3.9.2. Calcolo software del CRC 87
3.10. Transazioni 90
3.10.1. Tipi di transazione 91
3.10.2. Conferma della transazione e controllo del flusso 92
3.10.3. Protocolli di transazione 93
Capitolo 4. Organizzazione interna del dispositivo 96
4.1. Richieste a dispositivi USB 96
4.1.1. Pacchetto di configurazione 96
4.1.2. Interrogazioni dispositivo standard 99
4.1.3. Descrittori del dispositivo 105
Capitolo 5. Organizzazione interna dell'host e degli hub 123
5.1. Mozzi 123
5.1.1. Interazione del controller host con l'hub 126
5.1.2. Descrittore mozzo 127
5.1.3. Hub richiede 129
5.1.4. Richiedi CLEAR_HUB_FEATURE 130
5.1.5. Richiedi CLEAR PORT_FEATURE 130
5.1.6. Richiesta GET_BUS_STA TE 131
5.1.7. Richiedi GET_HUB_DESCRfPTOR 131
5.1.8. Richiedi GET_HUB_STATUS 131
5.1.9. Richiedi GET_PORT_STA TUS 132
5.1.10. Richiedi SET_HUB_DESCRIPTOR 134
5.1.11. Richiedi SET_HUB_FEATURE 134
5.1.12. richiesta SET PORT FEATURE. 134
5.2. Collaborazione dispositivi con velocità diverse 135
Capitolo 6. USB senza PC 137
6.1. connettori OTG 138
6.2. Tipi di dispositivi OTG 138
6.3. Descrittore dispositivo OTG 139
6.4. Risorse online per questo capitolo 140
PARTE III. PRATICA DI PROGRAMMAZIONE 141
Capitolo 7 Supporto USB su Windows 143
7.1. Modello WDM 144
7.2. Interazione con il driver USB 146
Capitolo 8 Dispositivi HID * 149
8.1. Proprietà del dispositivo HID 149
8.2. Come comunicare con un dispositivo HID 151
8.3. Installazione di un dispositivo HID 152
8.4. Identificazione del dispositivo HID 152
8.4.1. Identificazione dei dispositivi di avvio 153
8.4.2. Descrittore di configurazione del dispositivo HID 153
8.4.3. Descrittore HID 154
8.4.4. Descrittore di rapporto 156
8.5. Struttura del descrittore del rapporto 156
8.5.1. Struttura degli elementi del rapporto 156
8.5.2. Segnala i tipi di elementi 157
8.5.3. Esempi di descrittori 165
8.6. Richieste al dispositivo HID 168
8.6.1. richiesta GET_REPORT. 169
8.6.2. SET_REPORT richiesta 169
8.6.3. richiesta GETJDLE. 170
8.6.4. Richiedi SETJDLE 170
8.6.5. Richiedi GET_PROTOCOL 171
8.6.6. Richiedi SET_PROTOCOL 171
8.7. Utensili 171
8.8. Interazione con il driver HID 172
Capitolo 9 Introduzione a WDM 181
9.1. Strati driver 183
9.2. Nomi simbolici dei dispositivi 184
9.3. Procedure di base del driver WDM 189
9.3.1. Procedura DriverEntry 190
9.3.2. Procedura AddDevice 192
9.3.3. Procedura di scarico 194
9.3.4. Procedure operative del conducente 196
9.3.5. Servire richieste IOCTL 203
9.4. Caricamento del driver e chiamata del driver Procedure 209
9.4.1. Procedura operativa del driver 209
9.4.2. Registrazione del conducente 210
9.4.3. Con riferimento alle procedure di lavoro 217
9.4.4. Riporre il driver all'interno file eseguibile 218
9.5. Strumenti per la creazione di driver 220
9.5.1. NuMega Driver Studio 220
9.5.2. Jungo WinDriver 220
9.5.3. Jungo driver del kernel 220
Capitolo 10 Specifiche USB PnP 221
10.1. informazioni generali sul sistema Plug and Play 221
10.1.1. Compiti e funzioni Plug and Play 221
10.1.2. Avvio di una procedura PnP 222
10.1.3. Componenti software PnP 224
10.2. Plug and Play per USB 225
10.2.1. Configurazione dei dispositivi USB 226
10.2.2. Numerazione dispositivo USB 226
10.2.3. ID dispositivo USB PnP 228
10.3. Ottenere un elenco di dispositivi USB 229
10.4. File INF 234
10.4.1. Struttura file INF 234
10.4.2. Sezione Versione 235
10.4.3. Sezione produttore 237
10.4.4. Directory di destinazione Sezione 239
10.4.5. Modello 241 Descrizione Sezione
10.4.6. Sezione xxx.AddReg e xxx.DelReg. 242
10.4.7. Sezione xxx.LogConfig 244
10.4.8. Sezione xxx.CopyFiles 244
10.4.9. Sezione Stringhe 245
10.4.10. Collegamenti di sezione 246
10.4.11. Creazione e verifica dei file INF 247
10.4.12. Installazione di dispositivi utilizzando un file INF 248
10.5. Rami di registro per USB 249
Capitolo 11 Funzionalità del BIOS 251
11.1. Servizio BIOS 1AH 251
11.1.1. Funzione B101H - rilevamento della presenza di PCI BIOS 252
11.1.2. Funzione В102Н: ricerca di un dispositivo PCI tramite identificatori
dispositivo e produttore 253
11.1.3. Funzione B103H: cerca un dispositivo PCI in base al codice classe 254
11.1.4. Funzione B108H - lettura registro configurazione (Byte) 255
11.1.5. Funzione ВУ9Н - lettura del registro di configurazione (Word) 256
11.1.6. Funzione B10AN - lettura registro configurazione (DWord) 256
11.1.7. Funzione В10ВН - scrittura registro configurazione (Byte) 257
11.1.8. Funzione B10CH - scrittura registro configurazione (Word) 257
11.1.9. Funzione B10DH - Scrivi registro di configurazione (DWord) 258
11.2. Esempio di utilizzo 259
PARTE IV. CREAZIONE DI DISPOSITIVI USB 283
Capitolo 12 Periferiche USB 285
12.1. Patatine Atmel 286
12.1.1. Microcontrollori con architettura MSC-51 286
12.1.2. Hub controller 289
12.1.3. Hub a microprocessore con core AVR 289
12.1.4. Altri circuiti integrati Atmel 290
12.2. Chip Cygnal 291
12.2.1. Microprocessori C8051F320 e C8051F321 291
12.2.2. Altri circuiti integrati Cygnal 293
12.3. Chip FTDI 296
12.3.1. Chip FT232AM e FT232BM 297
12.3.2. Chip FT245AM e FT245BM 298
12.3.3. Chip FT2232BM 299
12.3.4. Chip FT8U100AX 300
12.3.5. Debug kit e moduli 301
12.3.6. Autisti 302
12.3.7. Utenze aggiuntive 303
12.3.8. Altri moduli 304
12.4. Chip Intel 304
12.5. Chip Microchip 308
12.6. I circuiti integrati Motorola 308
12.7. Chip Philips 309
12.7.1. Microchip USB 310
12.7.2. Mozzi 311
12.7.3. Altri chip Philips 313
12.8. Microcircuiti Texas Instruments 314
12.9. Chip Trans Dimensione 317
12.10. Circuiti integrati di protezione dell'alimentazione 318
12.11. Risorse online per questo capitolo 319
Capitolo 13 Dispositivo HID Atmel AT89C5131 322
13.1. Schema strutturale di АТ89С5131 322
13.2. USB registra AT89C5131 324
13.2.1. Registrati USBCON 324
13.2.2. Registrati USBADDR 326
13.2.3. Registrati USBINT 327
13.2.4. Registrati USBIEN 328
13.2.5. Registro UEPNUM. 329
13.2.6. Registra UEPCONX 330
13.2.7. Registro UEPSTAX. 331
13.2.8. Registro UEPRST. 334
13.2.9. registro UEPINT. 335
13.2.10. Registrati UEPIEN 336
13.2.11. Registra UEPDATX 337
13.2.12. Registrati UBYCTLX 337
13.2.13. Registrati UFNUML 338
13.2.14. Registrati UFNUMH. 338
13.3. Circuito AT89S5131 338
13.4. Strumenti di programmazione 339
13.4.1. compilatore 341
13.4.2. Programmatore 342
13.5. Programma per microprocessore 349
13.5.1. La prima versione del programma per АТ89С5131 349
13.5.2. Aggiunta di descrittori di stringa 369
13.5.3. Aggiunta di endpoint 374
13.5.4. Creazione di un dispositivo HID 377
13.5.5. Comunicazione con un dispositivo HID 381
13.6. Lettura dei report in Windows 388
13.7. Funzioni aggiuntive WindowsXP396
13.8. Dispositivo con segnalazioni multiple 397
Capitolo 14 Creazione di un dispositivo USB ATMEL AT89C5131 402
14.1. Dispositivo non HID 402
14.2. Creazione di un driver con Autista studio 405
14.2.1. Qualche parola sulla libreria Driver Studio 407
14.2.2. Altre classi Driver Studio 411
14.2.3. Creazione di un modello di driver utilizzando Driver Studio 412
14.2.4. Perfezionamento del modello di driver 422
14.2.5. Metodi di base della classe del dispositivo 423
14.2.6. Implementazione della lettura dei dati 426
14.2.7. Installazione del driver 428
14.2.8. Lettore dati 429
14.2.9. Lettura di dati da altri tipi di endpoint 438
14.2.10. Pulisci il driver USB 439
Capitolo 15 Utilizzo dei chip FTDI 457
15.1. Schema funzionale FT232BM 457
15.2. Circuito FT232BM 460
15.3. Funzioni D2XX 460
15.4. Transizione da COM a USB 465
15.4.1. 465 Descrizione del circuito del convertitore
15.4.2. Impostazione della velocità di trasmissione 467
PARTE V. MANUALE 469
Capitolo 16 Caratteristiche di Windows 471
16.1. Funzioni CreateFile e CloseHandle: aprire e chiudere un oggetto.471
16.1.1. Ulteriori informazioni 472
16.1.2. Valore restituito 472
16.1.3. Chiama l'esempio 472
16.2. Funzione di lettura file: lettura dati 473
16.2.1. Ulteriori informazioni 474
16.2.2. Valore restituito 474
16.2.3. Chiama l'esempio 474
16.3. Funzione WriteFile: trasferimento dati 475
16.3.1. Ulteriori informazioni 476
16.3.2. Valore restituito 476
16.3.3. Chiama l'esempio 476
16.4. Funzione ReadFileEx. Dati di lettura APC 477
16.4.1. Valore restituito 479
16.4.2. Ulteriori informazioni 479
16.4.3. Chiama l'esempio 479
16.5. Funzione WriteFileEx: trasferimento dati APC 480
16.5.1. Valore restituito 481
16.5.2. Chiama l'esempio 481
16.6. Funzione WaitForSingleObject in attesa di un segnale
stato dell'oggetto 482
16.6.1. Valore restituito 482
16.7. Funzione WaitForMultipleObjects: in attesa di un segnale
oggetto stati 483
16.7.1. Valore di ritorno 484
16.8. Funzione GetOverlappedResult risultato dell'operazione asincrona 484
16.8.1. Valore di ritorno 485
16.9. Funzione DeviceIoControl: controllo diretto del driver 485
16.9.1. Valore restituito 487
16.10. Funzione QueryDosDevice: ottenere il nome del dispositivo
con il suo nome DOS 487
16.10.1. Valore di ritorno 488
16.10.2. Chiama l'esempio 488
16.11: Definisci funzione dispositivo DOS: Operazioni nome dispositivo DOS 489
16.11.1. Valore di ritorno 490
16.11.2. Chiama l'esempio 490
Capitolo 17 Funzioni API HID 492
17.1. Funzione HidD_Hello: Controllo libreria 492
17.2. Funzione HidD_GetHidGuid: ottieni il GUID 492
17.3. Funzione HidD_GetPreparsedData: creazione di un descrittore di dispositivo 493
17.4. Funzione HidD_FreePreparsedData: liberare l'handle del dispositivo 493
17.5. Funzione HidD_GetFeature: ottenere il report FEATURE 494
17.6. Funzione HidD_SetFeature: invio report FEATURE 494
17.7. Funzione HidD_GetNumInputBuffers: ottenere il numero di buffer 495
17.8. Funzione HidD_SetNumInputBuffers: impostazione del numero di buffer 495
17.9. Funzione HidD_GetAttribntes: Ottieni gli attributi del dispositivo 495
17.10. Funzione HidD_GetMamifactnrerStnng. ottenere la stringa del produttore 496
17.11. Funzione HidD_GetProductString. ottieni la linea di prodotti 497
17.12. Funzione HidD_ Ottieni Serial MumberString. ottenere una stringa
numero di serie 497
17.13. Funzione HidD_GetIndexedString. ottieni la riga all'indice 498
17.14. Funzione HidDjGetlnputReport. ricevere un rapporto INPUT 498
17.15. Funzione HidD_SetOutputReport. invia il rapporto OUTPUT 499
17.16. Funzione HidP_GetCaps: ottieni le proprietà del dispositivo 499
17.17. Funzione HidP_MaxDataListLength: recupero delle dimensioni del report 500
Capitolo 18 Controllore host UCH 502
18.1. 502 Registri di controllo del controller host
18.1.1. Registro comandi USB (USBCMD) ..504
18.1.2. Registro di stato USB (USBSTS) 506
18.1.3. Registro di controllo delle interruzioni (USBINTR) 506
18.1.4. Registro numero telaio (FRNUM) 507
18.1.5. Registro degli indirizzi di base del frame (FLBASEADD) 508
18.1.6. Start of Frame Modifier Register (SOFMOD) 508
18.1.7. Registro dello stato e del controllo delle porte (PORTSC) 509
18.2. Strutture dati del controller host UCH 510
18.2.1. Elenco telai 510
18.2.2. Descrittore di trasmissione i 511
18.2.3. Intestazione coda 514
18.3. Elaborazione dell'elenco dei descrittori UCH 516
Capitolo 19 Strumenti 518
19.1. Strumenti di Microsoft Visual Studio 518
19.1.1. Dipende 518
19.1.2. Ricerca errori 518
19.1.3. GuidGen 518
19.2. Strumenti Microsoft DDK 520
19.2.1. Albero dei dispositivi 520
19.2.2. DevCon.-521
19.2.3. Chklnf e Genlnf. 526
19.3. CompuWare Corporation 527 strumenti
19.3.1. Monitoraggio 527
19.3.2. Collegamento simbolico 527
19.3.3. EzDriverInstaller 527
19.3.4. WdmSniff 527
19.4. Strumenti di sistema 528
19.4.1. WinObj 528
19.5. Strumenti USB Forum 531
19.5.1. Strumento descrittore HID 531
19.6. Strumenti software HDD 533
19.7. Sourceforge 533 Strumenti
APP 535
Appendice 1 Funzionalità aggiuntive 537
Appendice 2. Tabella degli identificatori linguistici (LangID) 539
Appendice 3. Tabella dei codici fornitore (Vendor ID, Device ID) 543
Appendice 4 Descrizione del CD 546
Letteratura 548
Indice 549
Programmazione tramite porta USB
Programmazione dell'apparecchiatura per l'installazione parabole L'SF-50 via USB differisce dalla programmazione via RS-232 solo per il modo in cui i dati vengono trasferiti dallo strumento al computer e dal computer allo strumento. Durante la programmazione tramite USB, un portatile chiavetta USB(unità flash). Questo è utile quando, ad esempio, il tuo computer o, più spesso, un laptop (netbook) non ha una porta seriale RS-232 sullo chassis.
Per programmare il dispositivo con utilizzando l'USB lo stoccaggio avrà bisogno di:
- Unità USB (unità flash) formattata in sistema di file FAT-32;
- Programma editor AliEditor, che si trova nella cartella Database_editor_new della sezione software OPENBOX SF-50.
Prima di iniziare la programmazione è necessario trasferire il database dal dispositivo al computer. Per fare ciò, accendi il dispositivo, connettiti a porta USB unità flash. Esegui MENU - Sistema - Salva su USB,
Uscire dal menu premendo il pulsante MENU fino a quando non viene visualizzato il canale corrente o all'immagine del menu principale se non ci sono ancora canali e rimuovere la chiavetta USB. Inserire l'unità flash nel computer.
Esegui il programma Editor.exe dalla cartella Database_editor_new e apri l'immagine sull'unità flash al suo interno.
Quando viene richiesto di selezionare un database, selezionare Database utente.
Premere OK. Selezionare Tutti i servizi, si aprirà un elenco di tutti i canali TV, radio e di servizio scansionati e salvati nel database.
Modifica i canali come desideri, ad esempio, lascia solo i canali aperti.
Premi sulla tastiera del computer Pulsante spostamento, premi Freccia giù ed evidenzia i canali che desideri eliminare. Premere Elimina per eliminare la selezione.
Per modificare le impostazioni del satellite, selezionare Tutti i servizi - Informazioni sui satelliti - EUTELSAT W4, W7, premere il tasto ENTER.
Se necessario, modificare i valori in Antenna 1.
Per eliminare un transponder, selezionane uno non necessario e premi il pulsante Elimina sulla tastiera del computer, conferma l'azione selezionata.
Per aggiungere un transponder posizionarsi sul nome del satellite, premere bottone giusto mouse e selezionare Aggiungi informazioni (oppure selezionare il satellite e premere il pulsante Inserisci sulla tastiera).
Inserisci i dati per il nuovo transponder, prendendoli, ad esempio, dal sito lyngsat.com.
Premere OK, assicurarsi che il transponder sia registrato.
Per aggiungere un satellite, posizionati sulla riga Informazioni sul satellite, premi il tasto Ins sulla tastiera e inserisci i parametri del nuovo satellite.
chiudere il programma editor, rimuovere l'unità.
Inserire il drive nel dispositivo OPENBOX SF-50, eseguire in sequenza MENU - Sistema - Aggiorna da USB, selezionare la modalità "SAT&TP List".
Seleziona Avvia. Conferma le tue intenzioni.
Il dispositivo aggiornerà il database e si riavvierà da solo. Dopo il riavvio, nelle impostazioni, dovrai impostare la lingua del menu russo in un modo nuovo. Ripristina il dispositivo alle impostazioni di fabbrica.
Uscire dal menu delle impostazioni premendo due volte il pulsante MENU. Premere il pulsante OK sul canale corrente e assicurarsi che l'elenco dei canali sia stato modificato.
Puoi anche assicurarti che l'elenco dei transponder e dei satelliti sia stato modificato.
Programmazione completata.
Il bus USB (Universal Serial Bus - Universal Serial Bus) è apparso il 15 gennaio 1996 con l'approvazione della prima versione dello standard da parte di Intel, DEC, IBM, NEC, Northen Telecom e Compaq.
L'obiettivo principale dello standard posto davanti ai suoi sviluppatori è consentire agli utenti di lavorare in modalità Plug&Play con i dispositivi periferici. Ciò significa che deve essere possibile collegare il dispositivo a un computer funzionante, riconoscimento automatico immediatamente dopo aver collegato e quindi installato i driver appropriati. Inoltre, è desiderabile fornire alimentazione ai dispositivi a bassa potenza dal bus stesso. La velocità del bus dovrebbe essere sufficiente per la stragrande maggioranza delle periferiche. Il controller USB dovrebbe ricevere un solo interrupt, indipendentemente dal numero di dispositivi collegati al bus, ovvero per risolvere il problema della mancanza di risorse sui bus interni di un computer compatibile con PC IBM.
Quasi tutte le attività sono state risolte nello standard USB e nella primavera del 1997 i computer hanno iniziato ad apparire dotati di connettori per Connessioni USB dispositivi. Ora l'USB è diventato così attivamente implementato dai produttori di periferiche per computer che, ad esempio, nel computer iMAC di Apple Computers, c'è solo USB come bus esterno.
Le caratteristiche dell'USB 1.0 sono le seguenti:
1. scambio di dati ad alta velocità (piena velocità) - 12 Mb Esso/Con;
2. lunghezza massima del cavo per alto tasso di scambio - 5 metri;
3. basso tasso di scambio dati (bassa velocità) - 1,5 Mb Esso/Con;
4. lunghezza massima del cavo per basso tasso di cambio - 3 metri;
5. il numero massimo di dispositivi collegati è 127;
6. eventuale connessione simultanea di dispositivi con cambi diversi;
8. consumo massimo di corrente per dispositivo - 500 mA.
Pertanto, è consigliabile collegare quasi tutti i dispositivi periferici a USB 1.0, ad eccezione di videocamere digitali e dispositivi ad alta velocità. dischi fissi. Questa interfaccia è particolarmente utile per collegare dispositivi connessi/disconnessi frequentemente come fotocamere digitali.
La possibilità di utilizzare solo due velocità dati limita l'applicabilità del bus, ma riduce significativamente il numero di linee di interfaccia e semplifica l'implementazione dell'hardware.
L'alimentazione diretta da USB è possibile solo per dispositivi a bassa potenza come tastiere, mouse, joystick, ecc.
I segnali USB vengono trasmessi tramite un cavo a 4 fili, mostrato schematicamente nella figura seguente:
Figura 2.6.1 - Cavi segnale USB
Qui GND è un circuito a filo comune per alimentare dispositivi periferici, Vbus - +5 V anche per circuiti di alimentazione. Il bus D+ serve per la trasmissione dei dati sul bus e il bus D- per la ricezione dei dati.
Il cavo per supportare la piena velocità del bus (full-speed) è realizzato come un doppino intrecciato, protetto da una schermatura e può essere utilizzato anche per il funzionamento in modalità a velocità minima (low-speed). Il cavo per il funzionamento solo alla velocità minima (ad esempio, per il collegamento di un mouse) può essere qualsiasi e non schermato.
I connettori utilizzati per collegare le periferiche sono divisi in serie: i connettori della serie "A" (maschio e femmina) servono solo per il collegamento a una sorgente, come un computer, i connettori della serie "B" (maschio e femmina) servono solo per il collegamento a un unità periferica.
I connettori USB hanno la seguente numerazione dei pin mostrata nella Tabella 2.6.1.
Tabella 2.6.1 - Scopo e marcatura dei contatti USB
Nel 1999, lo stesso consorzio di società di computer che ha avviato lo sviluppo della prima versione dello standard bus USB ha iniziato a sviluppare attivamente la versione 2.0 di USB, che prevede l'introduzione di una modalità aggiuntiva ad alta velocità (Hi-speed). La larghezza di banda del bus è stata aumentata di 40 volte, fino a 480 Mbps, il che ha reso possibile il trasferimento di dati video tramite USB.
La compatibilità di tutte le periferiche rilasciate in precedenza e dei cavi ad alta velocità è completamente preservata. Il controller dello standard 2.0 è già integrato nell'insieme della logica di sistema dei dispositivi programmabili (ad esempio, scheda madre personal computer).
Nel 2008, Intel, Microsoft, Hewlett-Packard, Texas Instruments, NEC e NXP Semiconductors hanno creato la specifica USB 3.0. Nella specifica USB 3.0, i connettori ei cavi dello standard aggiornato sono fisicamente e funzionalmente compatibili con USB 2.0, ma oltre alle quattro linee di comunicazione, ne sono state aggiunte altre quattro. Tuttavia, nuovi contatti in connettori USB 3.0 si trovano separatamente da quelli vecchi su una riga di contatto diversa. La specifica USB 3.0 aumenta la velocità massima di trasferimento dati a 5 Gbps, un ordine di grandezza superiore ai 480 Mbps che USB 2.0 può fornire. Inoltre, la corrente massima è stata aumentata da 500 mA a 900 mA per dispositivo, il che consente di alimentare alcuni dispositivi che in precedenza richiedevano un'alimentazione separata.
Supponiamo di aver sviluppato un dispositivo USB con cui vuoi lavorare utilizzando un computer. Ciò può essere ottenuto in almeno due modi:
1. sviluppo di un driver completo sistema operativo;
2. utilizzando un'interfaccia USB di classe speciale - dispositivi chiamati dispositivi HID (Human Interface Device).
Il primo metodo è universale: avendo una conoscenza sufficiente nel campo della scrittura dei driver, puoi programmarlo per funzionare con qualsiasi dispositivo a qualsiasi velocità supportata da USB. Ma questo è un compito piuttosto difficile.
Il secondo modo è il seguente. Esiste un'interfaccia supportata dai moderni sistemi operativi per dispositivi di interazione uomo-computer o dispositivi HID, come ad esempio:
1. tastiere, mouse, joystick;
2. vari sensori e lettori;
3. sterzo e pedaliera del gioco;
4. pulsanti, interruttori, regolatori.
Qualsiasi dispositivo di questo tipo, se soddisfa i requisiti per i dispositivi HID, verrà automaticamente riconosciuto dal sistema e non richiederà la scrittura di driver speciali. Inoltre, programmarli è in genere molto più semplice che scrivere un driver di dispositivo personalizzato. Purtroppo il metodo presenta un notevole inconveniente: la velocità di scambio delle informazioni con il dispositivo HID è molto limitata e ammonta ad un massimo di 64 kB/s.
In sostanza, sulla base della tecnologia HID, è possibile organizzare l'interazione con qualsiasi dispositivo, anche se non è in senso stretto un dispositivo di interfaccia tra una persona e un computer. Ciò elimina lo sviluppo dispendioso in termini di tempo di un driver di dispositivo univoco e consente di risparmiare tempo nello sviluppo di un nuovo dispositivo USB. Lato host, lo scambio con il dispositivo sarà gestito da un driver HID standard incluso nella distribuzione del sistema operativo. Devi solo eseguire dal lato del dispositivo requisiti minimi Protocollo HID USB.
Vale la pena notare che molti dispositivi USB, che a prima vista non rientrano nella definizione di dispositivi di interazione umana, sono ancora più logici da implementare come dispositivi HID. Questo fenomeno si verifica spesso nel campo delle apparecchiature di produzione, che ha recentemente registrato una massiccia introduzione delle tecnologie USB. Ad esempio, considera un alimentatore da laboratorio con la possibilità di impostare i parametri dei suoi segnali di uscita da un computer utilizzando un'interfaccia USB. Senza dubbio, la fonte di energia stessa non è un mezzo di interazione con una persona. Tuttavia, dentro questo caso le funzioni implementate tramite connessione USB duplicano la tastiera, i controlli e gli indicatori installati sul dispositivo stesso. E questi controlli rientrano nella definizione di HID. Di conseguenza, l'alimentatore con queste funzioni USB è organizzato in modo più logico come un dispositivo HID.
Nell'esempio considerato, una piccola velocità di trasferimento dati sarà sufficiente per il normale funzionamento, mentre in altri casi i dispositivi possono essere molto esigenti in termini di velocità di scambio. La bassa velocità di trasferimento è il principale limite del design del dispositivo HID, che, rispetto ai 12 Mbps pieni Velocità USB Il bus 1.0 sembra un grande svantaggio della tecnologia HID in termini di scelta di un'implementazione USB specifica. Tuttavia, per molte attività di comunicazione, questa velocità è sufficiente e l'architettura HID, in quanto strumento specializzato, occupa un posto degno tra i modi per organizzare lo scambio di dati.
Esistono due tipi di dispositivi HID: partecipanti (avviabili) e non partecipanti all'avvio iniziale del computer. L'esempio più eclatante di dispositivo USB-HID avviabile è la tastiera, che inizia a funzionare con l'avvio del computer.
Quando si sviluppa un dispositivo HID, devono essere soddisfatti i seguenti requisiti imposti dalla specifica:
1. Il dispositivo HID a piena velocità può trasferire 64000 byte al secondo o 64 byte ogni 1 ms; un dispositivo HID a bassa velocità ha la capacità di trasferire fino a 800 byte al secondo o 8 byte ogni 10 ms.
2. Il dispositivo HID può designare la sua velocità di polling per determinare se ha dati nuovi da trasmettere.
3. Lo scambio di dati con il dispositivo HID avviene tramite una struttura speciale denominata report (Report). Ciascun report definito può contenere fino a 65535 byte di dati. La struttura del report ha un'organizzazione molto flessibile che consente di descrivere qualsiasi formato di trasferimento dati. Affinché un formato di rapporto specifico diventi noto all'host, il microcontrollore deve contenere una descrizione speciale: un descrittore di rapporto.
La comunicazione USB è implementata direttamente sul microcontrollore in diversi modi:
1. utilizzando un controller con supporto hardware, come AT90USB*, di atmega;
2. utilizzando l'emulazione software dell'interfaccia usb su qualsiasi microcontrollore.
Per l'implementazione del software, esistono attualmente numerose soluzioni già pronte per varie famiglie di microcontrollori. Per i microcontrollori AVR come Atmega8 è possibile utilizzare le seguenti librerie C gratuite:
Entrambi sono abbastanza facili da usare, forniscono l'emulazione completa dei dispositivi USB 1.1 a bassa velocità ad eccezione della gestione degli errori di comunicazione e delle caratteristiche elettriche e funzionano su quasi tutti i controller AVR con almeno 2k flash, 128 byte di RAM e da 12 a 20 MHz.
Per la scrittura di applicazioni con supporto USB Windows I dispositivi HID richiedono i file di intestazione hid* inclusi con il WDK ( Driver Windows Kit), oppure puoi utilizzare la libreria hidlibrary liberamente ridistribuibile o un'altra simile.
Pertanto, nel caso generale, la programmazione USB è un'attività piuttosto complicata, che richiede uno speciale microcontrollore con supporto hardware e la scrittura di un driver del sistema operativo. Tuttavia, in pratica, quando si sviluppano dispositivi, è possibile utilizzare un'interfaccia HID molto più semplice - dispositivi, il cui supporto è implementato a livello di un driver di sistema standard e la programmazione è semplificata utilizzando le librerie di funzioni esistenti.
Ma non è sufficiente collegare fisicamente il dispositivo al computer, è necessario anche stabilire uno scambio di dati tra di loro. Come scegliere una porta e organizzare una connessione? Alcuni anni fa soluzione standard stava usando la porta COM. A proposito, vari specialisti installano ancora 8, 16 o anche 32 porte COM su computer industriali (esiste un'intera categoria di diverse schede di espansione PCI per porte seriali, controller, ecc.). Pertanto, se è necessario collegare diversi dispositivi esterni con un'interfaccia RS-232, potrebbero essere necessari adattatori costosi e schede di espansione esotiche che, secondo l'antica tradizione, navigano in Russia per settimane su battelli a vapore. A proposito, il nome di un normale adattatore "adattatore DB9m / DB25f" può solo causare irritazione al gestore di un negozio di computer.
Cos'è un dispositivo HID
Ora quasi tutti i dispositivi sono collegati a un computer tramite un'interfaccia USB. Pertanto, molti nuovi PC non dispongono affatto di una porta COM.
Interfaccia USB: una soluzione tipica per l'associazione di un nuovo dispositivo esterno con un computer, più precisamente, è un'interfaccia HID basata sul protocollo USB 1.1.
Sebbene molte persone pensino che l'interfaccia HID (Human Interface Device) sia esclusivamente per tastiera, mouse e joystick, è adatta a molte soluzioni relative all'interfacciamento di dispositivi esterni e un computer.
Se l'utente ha bisogno di eseguire uno scambio di dati a bassa velocità (fino a 64 kbps) e allo stesso tempo è desiderabile ridurre il tempo per lo sviluppo noioso dei propri driver, HID è abbastanza adatto a loro. L'output sarà una soluzione semplice e completamente moderna basata su un'interfaccia software USB standard con supporto garantito su tutte le piattaforme software comuni.
Proprietà del dispositivo HID
Dal punto di vista dell'organizzazione del supporto software per un dispositivo HID, tutto sembra piuttosto interessante: lavorare sotto Controllo Windows puoi creare rapidamente un codice compatto comprensibile basato su algoritmi collaudati già pronti. In questo caso, lo sviluppatore avrà tutto il tempo per implementare il proprio protocollo di scambio dati di primo livello, poiché il livello di astrazione necessario è già organizzato dal protocollo HID (vedi tabella). Inoltre, è facile per un programmatore eseguire il debug di un protocollo di scambio scritto (ovviamente, se esiste un dispositivo HID funzionante) - a causa della relativa rigidità del protocollo stesso, è sufficiente sviluppare semplicemente un programma per supportare il dispositivo da un computer. Lo farei ancora! Molto lavoro è già stato fatto dal creatore del dispositivo HID.
Stabilire lo scambio di dati tra un dispositivo HID e un computer
Per descrivere l'interazione di un dispositivo HID con un computer, useremo il termine "host". In questo caso, si riferisce a un dispositivo di controllo nell'architettura fisica generale della comunicazione tramite il protocollo USB. Quindi, tutte le porte di un computer sono host. È possibile collegare ad essi vari dispositivi USB (unità flash, mouse, webcam, fotocamere, ecc.) che non dispongono di un host. L'host fornisce rilevamento, connessione, disconnessione, configurazione del dispositivo, nonché raccolta di statistiche e gestione dell'alimentazione.
Il dispositivo HID stesso può impostare la frequenza di polling, durante la quale viene rilevata la presenza di eventuali nuovi dati. Ciò significa che anche a un livello così basso, il programmatore può fidarsi del sistema, poiché la velocità di polling e altri parametri di comunicazione devono essere preimpostati nel programma del controller del dispositivo HID. In questo, il protocollo HID differisce dalla descrizione generale di USB 1.1 o USB 2.0, che non ha requisiti rigorosi per l'organizzazione del protocollo. Tuttavia, per attività specifiche che richiedono un elevato livello di sicurezza, può essere piuttosto difficile eliminare i sondaggi ciclici, quando vengono costantemente trasmessi quasi gli stessi blocchi di dati.
Caratteristiche della programmazione dei dispositivi HID
I dispositivi HID hanno descrittori speciali. Quando l'host determina che il dispositivo appartiene alla classe HID, ne trasferisce il controllo al driver appropriato. Si presume che l'ulteriore scambio di dati venga effettuato sotto la sua guida.
Su Windows, il servizio di sistema HidServ è responsabile dell'accesso ai dispositivi HID. Maggiori dettagli sulle funzioni delle richieste ai dispositivi HID e altre caratteristiche del lavoro con il driver HID sono descritti nel lavoro di P. V. Agurov “Interfaccia USB. La pratica dell'uso e della programmazione” (San Pietroburgo: BHV-Petersburg, 2005).
Programmazione di dispositivi HID al "livello superiore"
La dura vita dei programmatori "applicati" che lavorano su Pascal è facilitata dal collaudato modulo HID. PAS, il guscio per nascondere. dll (Hid User Library - come specificato nelle proprietà del file). I commenti al file dicono che è basato sui moduli hidsdi.he hidpi.h di Microsoft Corporation. E il file HID stesso. PAS fa parte del pacchetto JEDI().
Per lavorare con un dispositivo HID in Ambiente Delfi per win32, viene utilizzato il componente TJvHidDeviceController, che è un comodo gestore globale per l'accesso ai dispositivi HID. E già sulla base, puoi ottenere un'istanza dell'oggetto per lavorare con un dispositivo specifico.
Principali proprietà ed eventi del componente TJvHidDeviceController
Consideriamo più in dettaglio il componente TJvHidDeviceController. L'evento OnArrival si attiva quando un dispositivo HID arriva (si connette) al sistema, l'accesso al dispositivo viene fornito nel gestore di questo evento tramite un'istanza della classe TJvHidDevice. Il semplice evento OnDeviceChange reagisce a un cambiamento nello stato del dispositivo, segnala solo cambiamenti nel sistema. L'evento OnDeviceData si attiva quando i dati arrivano da uno dei dispositivi HID e passano quanto segue al gestore: HidDev: TJvHidDevice; - il dispositivo da cui sono stati ricevuti i dati;
L'evento OnDeviceDataError notifica un errore di trasferimento dati passando i parametri HidDev alla procedura di elaborazione: TJvHidDevice; - Dispositivo HID ed errore: DWORD; - codice di errore. L'evento OnDeviceUnplug notifica che un dispositivo è stato rimosso dall'elenco dei dispositivi installati nel sistema. I tipi di gestori di eventi su Plug and Unplug sono gli stessi (nel testo sorgente: TJvHidUnplugEvent = TJvHidPlugEvent). Un oggetto della classe TJvHidDevice corrispondente al dispositivo HID viene passato al gestore.
Per enumerare sequenzialmente i dispositivi HID disponibili nel sistema chiamando il metodo Enumerate, si intende l'evento OnEnumerate, ovvero, nel gestore eventi, i dispositivi trovati vengono trasmessi sequenzialmente come oggetti. Questo evento viene attivato forzatamente dal metodo Enumerate, utilizzato per "passare" i dispositivi HID esistenti attraverso il gestore, ad esempio, durante il controllo dello stato dei dispositivi HID avviato dall'host (computer).
L'evento OnRemoval si attiva quando il dispositivo viene fisicamente rimosso dal sistema e ha lo stesso tipo di gestore TJvHidUnplugEvent di OnDeviceUnplug. La funzione CountByProductName restituisce il numero di dispositivi che corrispondono al nome del prodotto specificato nell'argomento e CountByVendorName restituisce il numero di nomi di fornitori specificati nell'argomento.
Principali proprietà ed eventi della classe TJvHidDevice
La classe TJvHidDevice è una rappresentazione virtuale di un singolo dispositivo HID. Un nuovo oggetto di questa classe può essere ottenuto, come già accennato, dall'evento OnArrival o OnEnumerate. La funzionalità delle classi TJvHidDeviceController e TJvHidDevice è parzialmente duplicata, poiché la prima di esse integra un toolkit comune per lavorare con una serie di dispositivi HID disponibili nel sistema e un meccanismo per accedere a uno di essi. Un dispositivo può essere identificato in modo univoco dalle proprietà SerialNumber, ProductName e VendorName. È possibile utilizzare l'evento OnData per ottenere informazioni sull'arrivo dei dati utilizzando tale oggetto. I dati vengono inviati tramite il metodo WriteFile (in senso stretto, tramite una funzione). WriteFile è un wrapper per la funzione di sistema WriteFile (kernel32).
Per controllare il fatto che il dispositivo venga rimosso, devi assegnare il tuo gestore all'evento OnUnplug. Prima di iniziare lo scambio di dati con un dispositivo HID, è necessario assicurarsi che tale scambio sia possibile utilizzando HasReadWriteAccess. Questa classe ha anche un evento OnDataError separato per il verificarsi di un errore di scambio di dati.
E ora diamo un'occhiata ai frammenti di codice di un progetto "live" che implementa un'applicazione client di test per organizzare lo scambio di dati con un dispositivo non standard: chip card in plastica basate su HID. Nella lotta per il realismo, l'autore si è preso la libertà di non eliminare dagli elenchi collegamenti di codice tecnologico "extra".
Il metodo ScanDevices (Listato 1) è progettato per avviare il processo di ricerca nel sistema del dispositivo HID richiesto. La maggior parte del codice, ad eccezione della chiamata al metodo Enumerate, è facoltativa e fornisce flessibilità applicativa, ad esempio, in modo da poter aggiungere la possibilità di lavorare su un'interfaccia non HID allo stesso programma di test. Il metodo AddError stampa le informazioni di debug nella finestra mentre il programma è in esecuzione.
Il listato 2 mostra il gestore dell'evento OnEnumerate per trovare il dispositivo esterno richiesto. Per semplicità, assumeremo che il programma possa funzionare con un solo dispositivo del tipo di cui ha bisogno.
Prima di considerare l'ulteriore implementazione del progetto, dovremmo parlare un po' del formato di scambio dati di primo livello accettato, ovvero della struttura progettata per essere un intermediario tra i metodi di ricezione e trasmissione dei dati e lo specifico compito applicato da risolvere . Il fatto è che qui allo sviluppatore viene data l'opportunità di realizzare le proprie capacità creative. O meglio, sviluppatori, perché il processo di creazione di un nuovo protocollo è molto spesso bidirezionale, e il primo violino lo suona chi ha più difficoltà ad implementare l'algoritmo di scambio. In generale, qualunque sia il protocollo di scambio, è sempre bello rendere ogni entità software il più visiva e autosufficiente possibile, anche a scapito di alcune tradizioni generalmente accettate. Per La decisione migliore- uno che verrà implementato in breve tempo con un minimo riferimento a ambiente software e con un grande potenziale di ulteriore sviluppo. Sulla base di questi principi, è stato creato un protocollo di scambio di primo livello, dove il concetto principale è "comando". Il listato 3 mostra quanto l'autore ami i dati delle stringhe, cosa che lo ha salvato più di una volta durante il debug dei moduli del programma. Che meraviglia che abbiamo persino un tipo String! Tutti i comandi del protocollo sono suddivisi in categorie (classi), all'interno delle quali è presente un codice di comando che ne caratterizza univocamente lo scopo. Il parametro edParam viene utilizzato per inviare dati al dispositivo e il parametro edAnswerData contiene i dati ricevuti dal dispositivo. Il tipo stringa dei membri record descritti consente di manipolare liberamente e visivamente i dati nel formato stringa HEX. E ciò che è più piacevole, il formato del record descritto si trova ideologicamente da qualche parte nel mezzo tra il suo scopo diretto e le varie forme della sua presentazione (INI, HEX, XML, ecc.)
L'esecuzione del comando, ovvero l'invio di dati al dispositivo, viene implementata utilizzando l'invio di pacchetti di dati con una lunghezza di 8 byte (Lista 4). Questa lunghezza non è l'unica decisione, questa scelta è dettata dai requisiti del protocollo di livello superiore e può essere diversa in ogni caso specifico. Questa è quella che si chiama una questione di gusti. Lo strano flag IsUSBMode nel metodo ExecuteCommand (Lista 5 in PC Disk World) viene lasciato come promemoria che invece di lavorare con USB, potremmo aver bisogno di usare una porta COM o qualche altra interfaccia. All'inizio del gruppo di dati inviato, una sequenza di sincronizzazione di un formato scelto arbitrariamente (ad esempio, 3E3E3E2B) viene trasmessa al dispositivo, informando il dispositivo che ha dati completamente legali all'ingresso. Lascia che te lo ricordi in questo caso noi stiamo parlando non tanto sull'HID, ma su uno specifico protocollo di primo livello, ideologicamente separato dall'hardware e progettato per risolvere specifici problemi applicati.
Nel gestore GetDataExecutor dei dati ricevuti dal dispositivo (pacchetto di 8 byte), è stato utilizzato un evento OnNewInputData appositamente creato per trasferire i dati inizialmente elaborati per ulteriori elaborazioni, indicando i loro vecchi e nuovi valori (Lista 6 su "World del disco del PC"). Pertanto, gli eventi di arrivo di dati grezzi e un'indicazione di ulteriore elaborazione vengono disaccoppiati, consentendo l'aggiunta di alcuni algoritmi di avviso specifici in una fase iniziale per informazioni di input errate, ripetute o non necessarie.
Gli esempi di lavoro con un dispositivo HID presentati qui illustrano l'idea generale dell'articolo: la relativa semplicità della programmazione di dispositivi HID non standard utilizzando gli strumenti Delphi.
