Dov'è esattamente la specifica USB che spiega cosa fare quando il cavo viene collegato per la prima volta?

Quindi conosco le specifiche USB 2.0 che si trovano sul sito USB.org .

Sono un po 'pigro e impaziente. Qualcuno può dirmi dove andare per scoprire esattamente cosa ci si aspetta dal mio dispositivo periferico quando è collegato il cavo USB?

Ad esempio, se il mio dispositivo periferico è una stampante, come faccio a dire al computer all'altro capo che una stampante (con una descrizione del modello specifico, suppongo) è stata appena collegata? Quindi, nel computer, come fa il driver della stampante a sapere quale porta USB è stata collegata alla stampante?

La mia applicazione è in realtà USB MIDI. Ho anche ottenuto questo documento USB-MIDI , ma sono carente del protocollo USB più fondamentale.

Solo per informazione delle persone, il chip USB che sto usando è FTDI FT220x ed è collegato all'SPI di un SHARC ADSP-21479. Ora lo usiamo semplicemente per le comunicazioni di testo usando il PC (con TeraTerm) come "console" . Ho accesso al codice che configura la porta SPI e si collega al chip FTDI, ma non esiste un codice che esegua le comunicazioni iniziali. Non so cosa faccia l'FT220x quando viene collegato per la prima volta al PC.

Non sono infelice da leggere e da imparare, ma vorrei sapere da dove iniziare a leggere, e una specifica USB da 100 MB è un bersaglio troppo grande per sparare. Un sincero ringraziamento a chiunque per l'aiuto attuabile.

USB ha diversi livelli, che sono descritti nelle specifiche USB 2.0 . Se hai familiarità con il modello di rete a strati OSI, puoi pensarlo in questo modo:

• Livello sessione = Capitolo 10 Hardware e software host USB (driver di dispositivo)
• Transport layer = Chapter 9 USB Device Framework
• Livello di rete = Capitolo 8 Protocol Layer (bitstream)
• Livello collegamento dati = capitolo 7 elettrico (circuito)
• Livello fisico = capitolo 6 meccanico (cavo e connettore)

Concettualmente l'USB si basa su flussi di dati, chiamati Endpoint , che possono essere IN (all'host) o OUT (dall'host). Ogni dispositivo ha Endpoint 0, che viene utilizzato per controllo e stato. Un dispositivo può avere endpoint aggiuntivi per i dati dell'applicazione. Ogni endpoint si comporta come un buffer FIFO.

I dati vengono trasferiti su un endpoint sia come Bulk (come TCP / IP, garantito che arrivano tutti i byte e nell'ordine corretto), sia Isochronous (come UDP / IP, garantito per essere aggiornato ma può eliminare i pacchetti). Esiste un tipo di trasferimento " Interrompi " fuorviante , che è in realtà appena sottoposto a polling dall'host.

USB 2.0 utilizza una coppia differenziale per datalink. Non entrerò nei dettagli poiché questo è coperto dal capitolo 7. Specifiche USB 2.0. Generalmente sul layout PCB trattiamo questo come una coppia differenziale di lunghezza abbinata e inseriamo i resistori di serie richiesti da qualunque USB PHY (Physical Interfaccia) in uso. La periferica USB utilizza un resistore di alto valore su una delle linee D + o D per segnalare all'host che si tratta di una periferica ad alta o bassa velocità.

Subito dopo che l'host USB ha scoperto che è presente un dispositivo, l'host richiede un gruppo di descrittori dal dispositivo. Questo è curato dietro le quinte dal chip FTDI. I descrittori sono descritti nel capitolo 9.5 . Questi includono dispositivo descrittore , Configurazione descrittore , interfaccia descrittori , Endpoint descrittori , String descrittori , forse anche HID Rapporto descrittori .

Il descrittore del dispositivo include i numeri USB VID (Identificazione del fornitore) e PID (Identificazione del prodotto). Il sistema operativo utilizza questa coppia di numeri, VID_PID, per determinare quale driver di dispositivo deve essere utilizzato per questo dispositivo. Nota che il numero VID viene rilasciato avendo l'appartenenza al forum degli implementatori USB, quindi questo è un problema se sei un singolo inventore.

Inoltre, esiste il driver di classe HID (Human Interface Device), che fornisce input piuttosto generico per tastiera / mouse / ecc., Nonché qualsiasi input / output generico. Un vantaggio di HID è che non richiede la fornitura di un driver di dispositivo personalizzato, ma la sua velocità effettiva è in qualche modo limitata rispetto a un driver di massa personalizzato. Esiste un altro documento di specifica sui descrittori HID; e un documento Tabella utilizzo HID che descrive in dettaglio tutti i numeri di codice che descrivono le varie funzioni disponibili su un determinato dispositivo con interfaccia umana.

Chip FTDI come il foglio dati FT220X fornisce il "motore di interfaccia seriale" USB (da non confondere con seriale SPI o seriale RS232). Questo si occupa della maggior parte delle cose di basso livello descritte nei capitoli 6, 7 e 8.

FTDI utilizza una EEPROM (offchip su FT2232H, on-chip su FT220X) per contenere un po 'delle informazioni contenute nei descrittori. È possibile personalizzare i valori VID / PID e fornire stringhe di descrizione personalizzate.

Il comportamento e l'interazione dei "partner" USB (un host e un dispositivo) sono sparsi tra le specifiche USB. Il modo migliore per ottenere alcuni motivi è quello di esaminare il "framework dei dispositivi", capitolo 9, che descrive i possibili stati (obbligatori) dei dispositivi (Figura 9-1) e il framework degli host (e hub), nei Capitoli 10 e 11. dettagli del protocollo (pipe / tipi di transazione / livelli di protocollo OSI astratti, layout PCB, ecc.), una migliore presa sull'interazione iniziale può essere ottenuta studiando il diagramma dello stato delle porte (Figura 11-10).

In sostanza, se il cavo non è collegato tra host e dispositivo, le porte host sono in "Powered State" (VBUS è ON), ma "Disconnected". I fili D + e D sono tenuti bassi con 15k pull-down.

Quando il cavo è collegato, il VBUS entra nel dispositivo. Il dispositivo riconosce che è in fase di connessione e segnala un evento di "connessione" tirando ALTO uno dei fili D, D + se è un dispositivo FS / HS e D- se è un dispositivo LS.

Tirare i fili D +/- su una determinata porta dà un interrupt al software host, segnalando "cambio dello stato della porta". Il software host (di solito ehci.sys) avvia quindi il sequenziamento "port reset" su quella particolare porta. Al completamento con esito positivo del "Ripristino porta USB", la porta host viene abilitata per la comunicazione USB. La porta diventa attiva (i pacchetti di frame iniziano a fluire).

Utilizzando il protocollo USB, l'host assegna un indirizzo univoco a questo dispositivo e legge "descrittore dispositivo". Questo avvia il processo di "enumerazione dei dispositivi". Il descrittore del dispositivo contiene informazioni su quale classe di dispositivi appartiene (HID, COM, MIDI, Stampante, ecc.) E VID / PID di quel particolare dispositivo, oltre a un mucchio di altre informazioni, vedere la Tabella 9-8.

Dopo aver ottenuto la classe del dispositivo e VID / PID, il software host tenta di abbinare queste informazioni nel registro del dispositivo e carica il driver DEVICE corrispondente, uno generico o specifico del fornitore (se presente). Il driver del dispositivo termina quindi il processo di enumerazione selezionando l'interfaccia del dispositivo che termina con l'impostazione "Configurazione dispositivo". Ovviamente l'intera comunicazione USB viene riconosciuta solo dietro questa particolare porta , anche se tutti i pacchetti vengono trasmessi a tutte le porte abilitate.

Quanto sopra è il quadro generale del protocollo di connessione USB. Il pacchetto di dati per qualsiasi scopo particolare (come il MIDI) è una storia diversa, e viene gestito a livello di applicazione o a livello di driver di dispositivo, se il sistema ottiene una classe di dispositivi adeguata. Per ottenere una comunicazione MIDI nativa, il dispositivo deve avere questa classe nel suo descrittore e seguire tutte le definizioni di classe MIDI .