Microcontrollori con USB Host

Il mercato delle soluzioni tecnologiche basate su dispositivi intelligenti, quali microprocessori e microntrollori, si è arricchito, da una decina d’anni, di nuovi dispositivi hardware integrati. L’interfaccia USB, con il suo standard, rappresenta senza dubbio una grossa novità. Grazie a questa nuova tecnologia la caratteristica denominata plug&play è diventata una solida realtà. Negli anni questa tecnologia ha soppiantato i tradizionali standard seriali per l’enorme facilità di colloquiare con dispositivi periferici quali stampanti, tastiere, mouse, memorie a velocità superiori. Certamente il bus USB rappresenta una grossa novità e fornisce un seguìto commerciale non indifferente ed è altrettanto vero che la disponibilità di un USB host rende ancora più interessante il ruolo delle applicazioni ad esse legate.

HOST & FUNCTION

Come mostra la figura 1, la topologia del bus USB è di tipo a stella, la comunicazione è di tipo master/slave e un unico master è responsabile della configurazione e della comunicazione sul bus.

Figura 1. La topologia di una rete di dispositivi USB

Figura 1. La topologia di una rete di dispositivi USB

Solo il dispositivo host, in possesso della funzionalità di master, può iniziare il trasferimento dei dati sul bus. Per questo motivo non possono esserci dei trasferimenti di dati tra due dispositivi  functions  senza un intervento dell’host. Per questa ragione, i costruttori hanno pensato di immettere  in  commercio   dispositivi che supportano entrambe le funzionalità. Si supponga di dover realizzare un piccolo progetto per monitorare un sistema di test e che, per tale scopo, vengano utilizzate un insieme di interfacce quali: stampante, tastiera, un flash driver e un personal computer. I ruoli di queste interfacce sono le seguenti:

  • La stampante viene utilizzata per emettere un report delle attività e un log del diagnostico del sistema;
  • La tastiera è  utilizzata  per inserire dati/comandi come stimolo al sistema;
  • Il flash driver è una unità di memoria utilizzata per memorizzare i diagnostici;
  • Il personal computer gestisce l’interfaccia uomo/macchina mediante l’uso di un sistema grafico minimale.

Tutti questi dispositivi sono connessi tra loro mediante una rete USB. I requisiti progettuali prevedono alcune restrizioni, per esempio le periferiche e il PC sono mutuamente esclusivi. In questo sistema gli attori, dal punto di vista USB, sono:

  • host, è il personal computer;
  • functions, sono la stampante, tastiera e flash driver.

Il dispositivo individuato come host deve quindi essere in grado di comunicare con i devices (functions) e i dispositivi functions non possono comunicare direttamente tra loro. Esiste un’altra caratteristica dell’USB che è bene chiarire: è il concetto di endpoint. L’endpoinè  il  punto  finale della comunicazione tra host e function. È possibile trovare all’interno di un dispositivo più di un endpoint, in questo caso ogni endpoint deve essere identificato da un numero. Di norma, è possibile avere più connessioni logiche tra host e device, ma esiste solo una connessione fisica e ogni connessione è chiamata pipeLa  pipe,  quindi,  identifica  il canale di comunicazione di un endpoint. Lo standard USB impone che ogni dispositivo deve contenere l’endpoint0 (che è di tipo control).  Le  pipe  degli  endpoint non  di  tipo  zero sono  monodirezionali  e  di  tipo  stream. Quando un device viene inserito  nella  rete  USB,  la  prima cosa che deve fare è attivare la control   pipe   dell’endpoint0. Infatti,  questo  endpoint  viene utilizzato in fase di configurazione per acquisire informazioni sul  dispositivo  attivando  così la fase di riconoscimento. L’endpoint0  è di  tipo  IN/OUT, ovvero   la  comunicazione   è bidirezionale  (in  generale  la connessione di  tipo  control  è sempre bidirezionale). Di seguito è riassunta la tipologia di questi endpoint.

  • IN: Un endpoint di questo tipo trasmette i dati all’host;
  • OUT: Un endpoint Out riceve i dati spediti dall’host;
  • IN/OUT: Questi, invece, sono di tipo bidirezionali.

Host, functions e Hub sono dunque i tre soggetti  che hanno  un  preciso  ruolo  nello standard USB:

  • Host:  È  responsabile  della comunicazione sul bus. Inizia la comunicazione sul bus e gestisce dinamicamente la rete che in questo modo viene costruita.  L’host  deve essere in grado di gestire le connessioni e/o le di sconnessioni degli oggetti (functions) che verranno inseriti o tolti dalla rete. Il dispositivo classificato come host rappresenta nel sistema il master e, quindi, controlla e schedula le attività di comunicazione.
  • Hub:  Un  Hub  è un  nodo  di comunicazione che interconnette i dispositivi. Ogni Hub permette di moltiplicare le connessioni e adatta la velocità dei dispositivi sulla rete. Dopo un primo momento, nel quale la comunicazione viene fissata alla velocità massima, successivamente il flusso di informazioni viene trasmesso ad una velocità compatibile con tutti i dispositivi presenti. Solo un host device (tipicamente un PC) include il cosiddetto “root hub”.
  • Functions:  Chiamati  anche devices, sono i punti terminali della rete a stella e sono identificati i dispositivi quali terminali, tastiere, mouse… Un dispositivo function deve essere in grado di rispondere a tutti i comandi previsti dal protocollo per consentire all’Host di riconoscere la periferica durante la fase di configurazione. Lo standard USB classifica le periferiche in due grandi famiglie: i dispositivi stand-alone o quelli cosiddetti compound   device.  I  dispositivi  stand-alone sono  quello  catalogati  come  single  function unit, per esempio un mouse; mentre compound device sono quelli che hanno più di una periferica che condividono una porta USB, come per esempio una video camera.

Detto questo è chiaro che lo strato software cambia se un oggetto è un Host o un functions. Per implementare un USB functions (cioè una periferica), il software deve essere in grado di sopperire agli handshakes del protocollo e alle class description. Il software sviluppato, invece, per gestire un host è, di solito, più complicato in quanto deve essere in grado di interfacciarsi con un host controller (potrebbe essere un altro dispositivo), gestire il protocollo USB e il driver per il dispositivo. Per minimizzare i rischi di progetto è possibile ricorre alle librerie software messe a disposizione dal costruttore  del dispositivo stesso: idea interessante se per esempio si intende sviluppare un USB host. Ricorrere a un software commerciale può risultare conveniente? La risposta sembra scontata. Le soluzioni commerciali sicuramente garantiscono una maggiore affidabilità e forniscono librerie d’interfaccia verso diversi sistemi operativi. Inoltre, per concludere, sicuramente il produttore è in grado di fornire diverse soluzioni per ogni esigenza, per esempio possono fornire o meno il codice sorgente. Nel panorama commerciale esistono diversi dispositivi  che  prevedono  un  mini-host  insieme alle funzionalità di function.

EMBEDDED USB DRIVER

Diversi costruttori mettono a disposizione librerie, ready-to-go,  per  accedere  ai  propri  dispositivi USB sia in modalità function che host. Infatti, rispetto  ad una RS232 per supportare lo standard USB viene richiesto uno strato di software non indifferente sia sul lato  target  (firmware on board) che su un host (un personal computer). Fortunatamente la maggior  parte dei costruttori mette  a  disposizione  tutta  la  documentazione necessaria, con il relativo software, per implementare lo standard USB per il proprio prodotto. Elemento da non sottovalutare è la possibilità di utilizzare il firmware esonerando l’acquirente a costruirsi e testarsi una propria suite per la gestione della modalità minihost. La proposta prevede, inoltre, l’uso di una libreria di funzioni utilizzabili in una applicazione embedded insieme a delle funzioni di callback. La figura 2 evidenzia l’architettura software di una delle prime proposte di Fujitsu. Come mostra la figura 2, la libreria è divisa in tre parti: la USB Host Library, l’Hardware Abstraction  Layer (HAL) e l’Operating System Abstraction Layer (OSAL).

Figura 2. L’architettura software per applicazioni USB di Fujitsu

Figura 2. L’architettura software per applicazioni USB di Fujitsu

La parte di USB host della libreria gestisce le richieste di bus e il trasferimento dei dati sull’hardware Abstraction Layer (HAL). Lo strato HAL si occupa dell’accesso verso i registri dell’USB host. Infine,  l’OSAL  è  l’interfaccia  verso  il  sistema operativo. La libreria richiede un meccanismo di sincronizzazione per garantire la sua corretta funzionalità ed è possibile trasportare la libreria verso applicazioni senza RTOS. Il costruttore fornisce due varianti di questa libreria: una prevede l’uso delle tecniche di debugging attraverso l’uso di una UART del microcontrollore, un’altra è una vera e propria versione USB di produzione.

Le Application Protocol Interface (API) collezionano librerie USB e sono state progettate per nascondere la complessità del bus USB. Le API incapsulano la completa funzionalità del bus USB, prevedendo uno strato software di alto livello e uno strato più prettamente legato all’hardware (un register-level): questa stratificazione consente  di  accedere  alle  funzionalità  USB  in modo flessibile, operando in due modi: host mode e function mode. Un esempio di questa architettura software  è mostrata in figura 3: essa è composta da un insieme di USB firmware embedded e da un insieme di funzionalità software residenti sul cosiddetto system processor.

Figura 3. L’architettura software proposta da Atmel

Figura 3. L’architettura software proposta da Atmel

Qui l’embedded USB firmware è costituito dall’Host  USB Controller Driver (HUSBCD) e dal System Interface Controller Driver (HSICD). Questi oggetti sono complessivamente referenziati verso l’embedded USB host stack. Il componente HUSBCD implementa le dipendenze hardware del protocollo USB, il HSICD gestisce il flusso dei dati tra il system processor e l’AT43USB370. L’host System Library viene utilizzato come link tra AT43USB370 host stack e l’applicazione che è in esecuzione sul system processor. Tutto viene svolto mediante un’insieme di primitive (API): queste gestiscono in maniera trasparente il protocollo USB e sono utilizzate anche per sviluppare un USB device driver.

PC  USB DRIVER

L'idea è di aiutare il progettista di soluzioni embedded per proporre soluzioni che prevedano il coinvolgimento del PC. Con la libreria su lato target il costruttore ha predisposto un USB software development kit per PC. Questa tecnologia si basa per esempio sulla tecnologia COM di Microsoft  e può essere  integrato in VisualBasic, Delphi e altri linguaggi di programmazione. Questo pacchetto prende il nome di USBIO device driver e fornisce una interfaccia di programmazione nativa, basato su Win32, mediante l’uso di API. In questo modo le funzioni di Win32, quali CreateFile(), DeviceIoControl(), ReadFile() e WriteFile() sono utilizzati per colloquiare con il driver. La figura 4 mostra un esempio schematico per comprendere meglio questo tipo di driver.

Figura 4. La struttura del driver USBIO

Figura 4. La struttura del driver USBIO

Dalla figura emerge che esistono tre oggetti: UBSIO client application, USBIO COM object, UBSIO device driver con le relazioni verso l’USB driver stack che è parte del sistema operativo Windows. Tutti i driver sono integrati nell’architettura stratificata WDM (Windows Driver Model).

I moduli di questo USB driver stack sono così classificati:

  • USB Host Controller. È la parte hardware adibita al controllo dell’Universal Serial Bus.
  • OpenHCI.SYS. È il driver che gestisce la modalità Open Host Controller Interface. In linea di massima può essere rimpiazzato da un driver che è conforme al UHCI (Universal Host Controller Interface) o EHCI (Enhanced Host Controller Interface).
  • UBSD.SYS. È l’USB Bus Driver che controlla e gestisce i dispositivi connessi alla rete USB. Questo modulo è  fornito  da  Microsoft  come parte del suo sistema operativo.
  • USBHUB.SYS. È l’USB Hub Driver, responsabile della gestione e controllo degli Hubs USB.
  • USBIO.SYS. È il generico USB  device  driver USBIO.
  • USBIO.COM. È la parte che interfaccia direttamente l’applicazione Windows.
  • Win32 Application è un’applicazione client che usa l’USBIO COM. Questo modulo è scritto in un linguaggio di programmazione ad alto livello, come Visual Basic e/o Delphi.

 

 

STAMPA     Tags:, ,

Una risposta

  1. Maurizio Di Paolo Emilio Maurizio Di Paolo Emilio 9 dicembre 2016

Scrivi un commento

ESPertino è la nuova scheda per IoT compatibile ARDUINO.
Scopri come averla GRATIS!