Home
Accesso / Registrazione
 di 

Architettura USB Stack per Applicazioni Mediche della Freescale

usb stack applicazioni mediche freescale

Lo Stack USB per applicazioni mediche permette di utilizzare i microcontrollori Freescale S08 e CFV1 per realizzare i dispositivi sopracitati.

La porta USB (Universal Serial Bus) viene utilizzata per collegare alcuni tipi di periferiche al computer. L'interfaccia USB costituisce una delle più diffuse interfacce per connettere dispositivi come videocamere, tastiere, microfoni, stampanti ecc. Anche nel settore medico il collegamento tramite USB si sta diffondendo rapidamente.

Se desideri maggiori informazioni su questo prodotto Freescale, invia una richiesta ad Arrow utilizzando il seguente modulo.

/Medical_Applications_USB_Stack_Architecture
Medical Applications USB Stack Architecture

I layers “class driver” implementano vari class driver ai quali corrispondono diverse funzioni. Questi driver si interfacciano con il layer dei dispositivi (device layer) per alcune funzioni di basso livello. Per alcune funzioni, i device layers non forniscono funzionalità aggiuntive e chiamano le funzioni di basso livello. La maggior parte delle operazioni di validazione dei parametri viene fatta in questo livello. Questo livello deve essere indipendente dall'hardware sottostante e di conseguenza può essere adattato a diverse piattaforme hardware con variazioni davvero minime. Il device layer si trova al di sopra del controller layer, ossia dal layer dipendente dall'hardware e che si interfaccia con i registri hardware.

L'architettura a strati così' delineata facilita lo sviluppo di applicazioni e, allo stesso tempo, non preclude allo sviluppatore la possibilità di interfacciarsi con le API di basso livello se necessario.

S08_and_CFV1_USB_Stack_Architecture_Layers
S08 and CFV1 USB Stack Architecture Layers

Flussi Software
Il flusso di inizializzazione comincia quando l'applicazione inizializza il class driver che a sua volta inizializza il driver di basso livello e il controller. Il class driver registra anche i callbacks che vengono richiesti per gli eventi che accadono sul BUS USB. A volte, dopo di tutto questo, il computer host inizia il processo di enumerazione spedendo il pacchetto di setup per ottenere i descrittori per il dispositivo, la configurazione e le stringhe. Queste richieste sono gestite dal class driver che usa i descrittori definiti dall'applicazione. La enumerazione termina quando l'host imposta la configurazione del dispositivo. A questo punto, il class driver notifica all'applicazione che la connessione è stata stabilita.

Flusso di trasmissione
L'applicazione trasmette i dati all'host USB chiamando l'API specifica per il class driver. Il class driver verifica lo stato corrente della coda. Se la coda è piena allora la funzione restituisce lo stato BUSY, se vi è già una richiesta che non è stata completata, viene accodata alla richiesta, e prepare il tutto perchè la richiesta venga passata al driver di basso livello. Controlla inoltre se il bus è sospeso oppure no. Se il bus è sospeso, “risveglia” il bus e a questo punto il bus spedice la richiesta al driver di basso livello. Quando l'operazione di spedizione è completa, il class driver rimuove la richiesta dalla coda e spedisce la successiva nella coda (se esiste).

Flusso di Ricezione
Quando il controller riceve i dati sulla porta ricettrice, il driver di basso livello spedisce un evento al class driver. Il class driver chiama il driver di basso livello per ricevere il pacchetto nei suoi buffer. Se la dimensione del pacchetto è minore della dimensione del buffer end-point, allora il class driver analizza il pacchetto immediatamente. Se la dimensione del pacchetto è maggiore della dimensione del buffer end-point, allora il class driver attende un evento dal driver di basso livello con il pacchetto completo. Il class driver analizza il pacchetto dopo che è stato ricevuto.

Sviluppare un applicazione
Ecco i passi da seguire per sviluppare una nuova applicazione:
1. Creare una nuova directory per l'applicazione sotto la directory /device/app. Tale direcotry è creata appositamente per ospitare la nuova applicazione
2. Copiare i file seguenti dalle applicazioni (simili) pre-esistenti
3. main.c
4. usb_descriptor.c
5. usb_descriptor.h
6. user_config.h

Modificare questi file per adattarli agli scopi della nuova applicazione. I file usb_descriptor.c e usb_descriptor.h contengono i descrittori per USB che sono dipendenti dall'applicazione e dal class driver. Il file user_config.h contiene le opzioni di configurazione. Il file main.c contiene il codice iniziale per il dispositivo. Se il dispositivo viene cambiato, tale file deve essere opportunamente modificato.

3. Creare la directory CodeWarrior dove i file del progetto per la nuova applicazione possono essere creati
4. Creare un nuovo file per creare l'applicazione principale e la funzione callback come sopra indicato.

new_application_directory
New Application Directory

- usb_descriptor.c
Questo file contiene l'interfaccia USB. Contiene inoltre vari descrittori definiti dallo standard USB, i descrittori di dispositivo, il descrittore di configurazione, il descrittore stringa e altri descrittori specifici. Per la personalizzazione, l'utente può modificare queste variabili e l'implementazione della funzione per adattarsi alle specifiche.

a) variabili
Questa lista sottostante mostra le variabili modificabili dall'utente per una implementazione di un class driver. L'utente dovrebbe modificare anche le corrispondenti macro definita nel file usb_descriptor.h. Per risparmiare spazio in memoria nel dispositivo S08, le costanti sono memorizzate nella memoria ROM

- usb_desc_ep
Questo è un array di strutture endpoint. La struttura endpoint descrive le proprietà quali numero, dimensione, direzione, tipo e così via. Questo array dovrebbe contenere tutti gli endpoint necessari definiti nelle specifiche USB. Un esempio di codice implementato per usb_desc_ep per la classe HID è illustrato qui di seguito:

const USB_ENDPOINTS usb_desc_ep =
{
HID_DESC_ENDPOINT_COUNT,
{
HID_ENDPOINT,
USB_INTERRUPT_PIPE,
USB_SEND,
HID_ENDPOINT_PACKET_SIZE,<---User Modifiable
}
< User can add other endpoints depending on class requirement >
};

g_device_descriptor: questa variabile contiene il descrittore del device USB
g_config_descriptor: questa variabile contiene l'USB Configurazion Descriptor
String Descriptor: gli utenti possono modificare i descrittori stringa per personalizzare il tutto secondo le proprie necessità. I descrittori di stringa sono scritti in formato UNICODE. Un linguaggio appropriato per l'identificazione numerica è specificato in UBS_STR_0. Può essere inoltre aggiunto un supporto per linguaggi multipli.

Standard descriptor table: gli utenti possono modificare la tavola dei descrittori standard per ottenere il supporto per descrittori specifici e/o per descrittori per strumenti proprietari.
g_valid_config_values: questa variabile contiene le configurazioni valide per il dispositivo. Questo valore rimane fisso per un certo dispositivo

uint_8 const g_valid_config_values[USB_MAX_CONFIG_SUPPORTED+1]={0,1};

g_alternate_interface: questa variabile contiene una interfaccia alternativa valida per una configurazione data. L'implementazione in esempio utilizza una sola configurazione. Se l'utente implementa ulteriori interfacce allora deve essere modificata la macro USB_MAX_SUPPORTED_INTERFACES nel file usb_descriptor.h
static uint_8 g_alternate_interface[USB_MAX_SUPPORTED_INTERFACES];

b) Interfacce
Le interfacce vengono chiamate dai livelli più bassi dello stack USB e dai class driver
USB_Desc_Get_Descriptor: questa interfaccia viene invocata dal framework USB. Questa chiamata viene realizzata quando il framework riceve la chiamata GET_DESCRIPTOR dall'host
USB_Desc_Get_Endpoints: questa interfaccia viene chiamata dal class driver. Restituisce un puntatore a una struttura USB_ENDPOINT
USB_Desc_Get_Interface: questa interfaccia viene invocata dal framework USB. Questa funzione restituisce un'interfaccia alternativa alla specifica interfaccia
USB_Desc_Remote_Wakeup: questa interfaccia viene invocata dal framework USB. Se l'applicazione supprta il wakeup remoto, allora questa funzione restituisce TRUE oppure FALSO
USB_Desc_Set_Interface: questa interfaccia viene chiamata dal Framework USB. Imposta un valore alternativo per l'interfaccia specificata
USB_Desc_Valid_Configuration – questa interfaccia viene hicamata dal framework USB
USB_Desc_Valid_Interface: questa interfaccia viene chiamata dal class driver per verificare se l'interfaccia è valida o no.

- usb_descriptor.h
Di questo file è necessaria l'implementazione. Il framework USB e i class driver includono questo file per la definizione dei prototipi e per le strutture dati descritte nel file usb_descriptor.c Gli utenti che modificano il file usb_descriptor.c devono anche modificare le MACRO nel file

- user_config.h
Questo file viene richiesto per la definizione di macro. Questi parametri sono essenziali per la compilazione di codice sorgente.

Reference:
Medical Applications USB Stack

RICHIESTA DI CONTATTO
Se desideri maggiori informazioni su questo prodotto Freescale, invia una richiesta ad Arrow utilizzando il seguente modulo.

 

 

Scrivi un commento all'articolo esprimendo la tua opinione sul tema, chiedendo eventuali spiegazioni e/o approfondimenti e contribuendo allo sviluppo dell'argomento proposto. Verranno accettati solo commenti a tema con l'argomento dell'articolo stesso. Commenti NON a tema dovranno essere necessariamente inseriti nel Forum creando un "nuovo argomento di discussione". Per commentare devi accedere al Blog

 

 

Login   
 Twitter Facebook LinkedIn Youtube Google RSS

Chi è online

Ci sono attualmente 16 utenti e 72 visitatori collegati.

Ultimi Commenti