Home

Documentazione del progetto

1. I el ea ee I ayiyoud Biyuo I l pue da yu I i T Miur asn xw i l l pug 336pe6 xwy i spnuys zP20 e BAP au i I uo uIN3 I I I 43SN I I i i 1 L i peasy xne Jobped xwgi Mybold yobpeb xwg Jey yoopeb xwr pen yebpeb xwuy asn jobped xu joppeb xuy Diagramma della sequenza di inizializzazione del sistema embedded Figura 5 18 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 121 gadget thmx gadget usb descriptors I l I setup thmx_usb_set_interface enable_ep usb_gadget_get_string thmx_gadget_submit_ep Figura 5 19 Diagramma della sequenza di setup del sistema embedded CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 122 i ithmx gadget char thmx gadget usb ALSA Application write audio samples gthmx usb send samples gthmx_usb_submit_ep Figura 5 20 Diagramma della sequenza relavita all invio di campioni audio al sistema host ri creato dal driver il quale provvedera a inoltrarlo sull endpoint isochronous di input In maniera simile la Figura 5 21 mostra l invio dei messaggi MIDI destinati ai dispositivi MIDI esterni Come si nota a parte la fase iniziale che viene implementata tramite un messaggio di setup da parte dell host la sequenza assai simile a
2. Pipe represents connection abstraction nN A between two horizontal entities Mechanical t Data transport mechanism Electrical Protocol 4 USB relevant format of transported data Figura 3 4 Modello di comunicazione stratificato tra Host e Device USB Fonte 2 2 il livello di dispositivo logico un insieme di endpoint che sono definiti come terminali identificati univocamente lato dispositivo dei flussi di comunicazione tra host e dispositivo Ogni dispositivo viene associa to nel momento del suo collegamento fisico ad un indirizzo univoco tra tutti i dispositivi collegati all host inoltre ogni endpoint ha un numero di endpoint che lo identifica all interno del dispositivo Cos l identificazione univoca dell endpoint fornita da una terna composta da a indirizzo del dispositivo logico b numero di endpoint c direzione del flusso di comunicazione infatti come gi detto ogni flusso pu essere pensato come una pipe unidirezionale in questo CAPITOLO 3 STUDIO DI FATTIBILITA 22 senso possiamo parlare di flussi di input dal dispositivo all host e di output dall host al dispositivo Ogni dispositivo logico dispone inoltre di un endpoint di controllo ov vero l endpoint numero 0 o Default Control Pipe Questo utilizzato lato host dal USB System Software per effettuare tutte le operazioni di setup del dispositivo al momento del suo collegamento fisico Tale USB System Softwa
3. e lato host stato implementato un device driver USB e uno ALSA e lato gadget in un unico modulo del kernel sono stati inclusi un device driver USB Gadget uno a caratteri per la gestione dei campioni audio dal livello applicativo uno UART per la gestione del MIDI out e uno GPIO per l acquisizione del segnale dal pulsante programmabile della Beagle Board Per la descrizione accurata di ognuna delle parti descritte si scelto di procedere idealmente come se si seguisse un ciclo di vita tipico del sistema si partir cos dall avvio cfr 6 2 1 fino ad arrivare alla disconnessione dello strumento cfr 6 2 9 passando da tutti i sotto sistemi che implementano le varie funzionalit del sistema gi presentate nel Capitolo 5 CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 133 6 2 1 L avvio del sistema Come descritto con le sequenze presentate cfr 5 4 la fase di avvio piut tosto semplice ed portata avanti dai due oggetti principali sia lato host che gadget implementati rispettivamente da host usb_module thma c e gad get thma_ gadget c Nel primo caso la funzione thmx_probe viene richia mata dal core USB per l avvio del driver USB e questa alloca il contenitore di dati principale del sistema la struct thmx che contiene i puntatori a tutte le altre strutture dati relative agli altri oggetti necessari all esecuzione Tra i campi di questa struttura viene allocata la coda di attesa thmx wait_q
4. stato notato che la lettu ra di valori float da uno stream di byte interi viene fatta normalizzando i CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 142 valori tra 1 e 1 usando una costante specifica Ci si basati allora su gli esempi presenti per mostrare il funzionamento di aubio vedi il file au bio_ dir examples aubiopitch c e si arrivati a capire che la lettura vie ne fatta tramite una funzione read_float che nel caso di uno stream wav viene inizializzata nel file pem c dentro i sorgenti di libsndfile vedi libsndfile_ dir src pcm c e in particolare dentro la funzione pem_init Qui a seconda del formato dei dati viene usata una funzione read_float differente Nel nostro caso poich riceviamo dati a 16 bit short little endian viene usata la funzione pem_read_les2f Questa preso lo stream di signed int lo trasforma in array di float usando la normalizzazione detta Lo studio effettuato ha permesso di adattare tutto questo al nostro caso e modificare la funzione di decodifica dello stream di byte dentro l oggetto thmx_vtm con la funzione raw_bytes_to_smpl Fatto questo stato ottenuto un buffer di dati floating point che stato passato alla funzio ne thmx_aubio_pitchyin_do per il riconoscimento del pitch del segnale e successivamente alla thmx_aubio_freqtomidi per l estrazione della nota MIDI relativa al pitch ottenuto Generazione di messaggi MIDI Una volta ottenuta una nota MIDI de
5. EJ 20 Audiophile USB tm e x exec _ctl command c init profile x init profile c X Disconnect X Disconnect All 5 Refresh ca AI j x read ctl commands c thmx read profile c thmx set midi out c thmx system clean sh B thmx_user h thm configuration thmx_audio raw daniele danieledevel Laptop Scrivania S03 thereminux thmx_src utility_scripts host thmx_set_midi out false thmx_set_midi out value false written to tt e sysfs file daniele danieledevel Laptop Scrivania S03 nux thmx_src utility scripts host N JACK Audio Con 3 Connections JA Qsynth A fluids EEQ daniele daniel Figura 7 7 Risultato dell esecuzione della rimozione dinamica del MIDI out MIDI out dinamicamente Essendo questo di default attivato per prima cosa stato invocato il comando thmx_set_midi_out false Questo ha portato alla disconnessione e ricreazione dell interfaccia MIDI dello strumento por tando al risultato mostrato in Figura 7 7 Qui come vediamo non pi presente la porta di MIDI out tra i Writa ble Clients di jack control e sulla destra si visualizza l output del comando value false written to the sysfs file 7 4 Test del MIDI out L interfaccia hardware di MIDI out in realt stata sviluppata interamente dando per dei problemi in fase di esecuzione perch le note non riescono ad a
6. functional clock 16 div da cui si ottiene il valore del divisore 31250 48000000 16 div gt div 48000000 16 31250 96 Oltre a questo stato necessario specificare 8 bit di dati usati per la comu nicazione UART_LCR_WLEN8 1 stop bit UART_LCR_STOP e nessun bit di parit UART_LCR_PARITY 6 2 8 La gestione dell hardware programmabile La creazione del driver per il pulsante programmabile della Beagle Board implementato nel file gadget thma_ gadget_ proghw c ha richiesto che ci si interfacciasse al API GPIO definita in lt linux gpio h gt Per questa anche seguendo la documentazione nel kernel trovata in Documentation gpio tat esistono delle semplici funzioni per registrare la linea GPIO tramite la gpio_request e impostarla come output o input il nostro caso gpio_direction_input Fatto questo possibile ricavare la linea di irq relativa al GPIO registrato gpio_to_irq e associarvi un interrupt handler tramite la request_irq All interno di questa funzione stato specificato di avviare l interrupt soltanto sul fronte di salita del segnale ov vero quando il pulsante premuto tramite la macro IRQF_TRIGGER_RISING passata tra i flag di request_irq Oltre a questo l esecuzione dell handler lasciata al thmx_gadget_aux_thread che quando la sua routine viene risvegliata legge il comando di controllo cor rentemente impostato per l hardware al quale lui associato e richiama
7. 4 riconfigurazione un utente privilegiato pu cambiare dinamicamente il profilo di configurazione e registrare le tali modifiche sul dispositivo tramite un apposito comando 1 1 3 Gestione della sicurezza Il device driver implementa alcuni meccanismi di sicurezza In particolare si effettuano controlli su eventuali parametri passati ai comandi di controllo e si verifica ad ogni tentativo di riconfigurazione dell hardware che il profilo che si cerca di impostare sia ben formato e corretto Infine poich il Thereminux appare alle applicazioni come un normale dispositivo MIDI compatibile con gli ambienti audio standard per linux come ALSA 32 i messaggi MIDI possono essere inoltrati sulla porta di MIDI out del Thereminux soltanto attraverso la sua interfaccia MIDI virtuale e dunque soltanto da applicazioni MIDI standard Per questo non viene effettuato un controllo sui messaggi di MIDI out inoltrati in quanto chi li genera considerato affidabile 1 1 4 Ambiente di esecuzione Per ragioni di efficienza l applicazione stata implementata cercando di rispondere al requisito non funzionale di bassa latenza Questo per evitare o comunque minimizzare il ritardo percepibile tra un input sottoposto dal lato hardware e l inizio della nota relativa Per questo il kernel sul sistema host stato riconfigurato per gestire al meglio applicazioni real time Capitolo 2 Requisiti di progetto Di seguito riassunto schematicament
8. CAPITOLO 2 REQUISITI DI PROGETTO 13 RSW_F 10 Il profilo di configurazione dovr contenere il campo comandi di controllo dell esecuzione Questo specifica un elenco di comandi che possibile eseguire dal lato soft ware per controllare i parametri di esecuzione dell hardware Funzionale MustHave RSW_F 11 Il profilo di configurazione do vr contenere il campo associa zioni Questo specifica una serie di coppie elemento hardware comando con cui si impone che un certo comando di controllo dell e secuzione venga eseguito quando si attiva lo elemento hardware Funzionale MustHave RSW_F 12 Il profilo di configurazione dovr contenere il campo MIDI out che indica se possibile inviare da ti MIDI di output attraverso lo strumento Funzionale MustHave RSW_F 13 Il sistema dovr mettere a dispo sizione un comando per leggere il profilo di configurazione Funzionale MustHave RSW_F 14 Il sistema dovr mettere a dispo sizione un comando per modificare in run time la possibilit di inviare messaggi MIDI OUT attraverso lo strumento Funzionale MustHave RSW_F 15 Il sistema dovr mettere a disposi zione dei comandi per invocare dal lato software i comandi di controllo dell esecuzione Funzionale MustHave RSW_F 16 Il sistema dovr mettere a dispo sizione un comando per leggere l elenco dei comandi di controllo dell esecuzione Funz
9. Flusso principale 1 L utente aziona l hardware programmabile sul dispositivo 2 Il sistema embedded verifica quale comando di controllo associato all hardware azionato 3 Il sistema embedded esegue il comando di controllo Flussi alternativi Postcondizioni Il sistema embedded ha eseguito il comando di controllo relativo all hardware azionato CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 84 Nome Caso d uso ExecCtlCommand SW ID CU 5 Attori User Descrizione Permette all utente di eseguire un comando di controllo tramite opportuni comandi sul sistema host Precondizioni Il sistema deve essere inizializzato e attivo dispositivo hardware acceso e collegato all host moduli del kernel caricati e pronti Flusso principale 1 L utente esegue il comando di attivazione del comando di controllo 2 Il sistema host verifica la correttezza del comando invocato 3 Il sistema host invia il comando al sistema embedded 4 Il sistema embedded esegue il comando di controllo Flussi alternativi Il sistema host verifica che il comando che si vuole ese guire non esiste o non corretto Viene mostrato un messaggio di errore all utente Postcondizioni Il sistema embedded ha eseguito il comando di controllo relativo al comando eseguito sul sistema host CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 85 Nome Caso d
10. fornita di seguito l analisi delle sequenze di esecuzione principali del Thereminux cfr 5 4 5 4 Analisi delle sequenze Sequenze del sistema host Iniziamo con la descrizione dei flussi operativi dal punto di vista del sistema host Per la spiegazione che segue sono stati presi in considerazione tutti i casi d uso descritti in precedenza cfr 5 1 pi altre operazioni fondamentali come l inizializzazione del sistema La Figura 5 13 mostra appunto proprio il flusso relativo all inizializzazione del sistema host Per evidenziare il contributo dei vari moduli del kernel che fanno parte del sistema host gli oggetti sono stati inseriti all interno di riquadri che portano il nome dei moduli stessi La sequenza di inizializzazione corrisponde dal punto di vista dell host alla funzione probe implementata all interno del l oggetto thmx Come si vede in Figura questa non fa altro che allocare le varie strutture dati inizializzandone i parametri di base per poi richiamare una per una le funzioni di inizializzazione degli altri oggetti e moduli le quali effettueranno le proprie allocazioni e impostazioni e salveranno il tutto nella struttura passata loro come argomento la struct thmx appunto C da notare che i diagrammi mostrati non pretendono di essere completamente esaustivi ma spesso possibile incontrare delle funzioni che non sono real mente presenti nell API ma descrivono un certo comportamento che
11. permettono di rendere attivo il gadget naturalmente a queste dovranno essere fatte corrispondere opportune fun zioni di unbind e disconnect per liberare le risorse In particolare la disconnect ripulir la configurazione corrente disabilitando i vari end point dichiarati tramite opportune chiamate alla funzione usb_ep_disable Dopo questa chiamata pu essere avviata una nuo va setup per impostare una nuova configurazione oppure potr essere richiamata la unbind per effettuare la disconnessione definitiva Questo sostanzialmente far s che tutte le risorse del driver vengano liberate Infine la funzione di __exit de registrer il driver tramite una chiamata alla funzione usb_gadget_unregister_driver 3 7 2 Il kernel real time Il sistema software del Thereminux sia lato host che lato dispositivo deve ga rantire di mantenere dei valori di latenza pi bassi possibile come specificato anche dai requisiti RSW_NF 2 e RSW_NF 3 Per soddisfare questa necessit CAPITOLO 3 STUDIO DI FATTIBILITA 71 stata utilizzata una patch disponibile e aggiornata per tutte le versioni stabili del kernel fino alla 2 6 33 al momento della scrittura di questo do cumento 56 chiamata patch CONFIG_PREEMPT_RT che definisce quello che viene chiamato Kernel Real Time 42 43 Per applicazioni specificatamen te audio esistono dimostrazioni 45 che mostrano come questo kernel possa raggiungere un tempo di latenza inferiore a
12. ti tra lo user space e il kernel space La parola chiava __user ci fa capire che si tratta di dati coinvolti in tale trasferimenti e quindi occorre prestare particolare attenzione 3 3 3 Il Sysfs In apertura del lavoro cfr 1 1 1 e i requisiti RHW_F 6 e RSW_F 1 stato specificato che il Thereminux funziona attraverso il meccanismo di hotplug ovvero il software in grado di gestire dinamicamente il collegamento e la disconnessione fisica dello strumento dal sistema caricando i moduli neces sari e allocando le informazioni di configurazione corrette per lo strumento Questa funzione che verr descritta nel dettaglio in seguito cfr 3 3 4 gestita nel kernel Linux 2 6 dal Linux Device Model un modello unico per la gestione e il tracciamento di tutti i dispositivi presenti all interno del si stema che viene rappresentato tramite il filesystem virtuale chiamato sysfs normalmente posizionato sotto sys Per quanto una trattazione approfondita del sysfs non sembra centrale per gli scopi di questo progetto importante conoscerne i meccanismi di base per comprendere come il kernel si comporta di fronte a determinate operazioni effettuate dai device driver La struttura centrale alla base del Linux Device Model il kobject Questa struttura mantiene una serie di informazioni importanti come il numero di riferimenti attivi per un certo dispositivo i riferimenti ad altri kobject al quale collegato per l implementazione
13. 1273613046 733427 add devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 host28 target28 0 0 28 0 0 0 scsi UEVENT 1273613046 733482 add class scsi_disk 28 0 0 0 scsi_disk UEVENT 1273613046 741003 add block sdd block UEVENT 1273613046 741041 add block sdd sddi block UEVENT 1273613046 741060 add class scsi_device 28 0 0 0 scsi_device UEVENT 1273613046 741079 add class scsi_generic sg4 scsi_generic Come si pu notare vengono inviati eventi man mano che il dispositivo viene registrato all interno del sysfs L inserimento del nuovo device driver a seguito della regola di udev esegui ta causa una nuova scansione dei driver da parte del core USB che quando ne trova uno che pu gestire il dispositivo magari il driver appena collega to chiama la funzione probe del driver In questo modo il driver pu effettuare le inizializzazioni vere e proprie del dispositivo estraendo dalla struct usb_interface che gli viene passata come argomento le specifiche degli endpoint per poterli allocare Ogni endpoint viene rapprentato co me una struct usb_host_endpoint che a sua volta contiene una struct CAPITOLO 3 STUDIO DI FATTIBILITA 42 usb_endpoint_descriptor con le informazioni vere e proprie sull endpoint Quindi dal punto di vista del device driver USB possiamo supporre che esso venga caricato nel sistema dinamicamente tramite una regola di udev quando il dispositivo viene collegato oppure manu
14. Nessuno Reset Il dispositivo che ri ceve questo messag gio deve reimpostare se stesso ad uno sta to di default di soli to lo stesso che si ha all accensione OxFF Nessuno Tabella 3 2 Messaggi MIDI comuni a tutti i canali CAPITOLO 3 STUDIO DI FATTIBILITA 50 3 5 La rappresentazione dei device MIDI in Li nux il device driver di test mainisnd Come specificato con il requisito RSW_F 4 il Thereminux una volta collegato al pc tramite il cavo USB appare al livello applicativo come un dispositivo MIDI standard Al fine di studiare come implementare questa funzionalit stato sviluppato un piccolo device driver di test chiamato minisnd che si serve di un dispositivo USB qualsiasi nel caso specifico stata utilizzata una comune pen drive e lo inizializza in modo tale che software musicali standard per Linux possano riconoscerlo come dispositivo per l acquisizione di dati MIDI Non stata implementata alcuna funzione per la reale lettura dei dati visto che hardware reale era ben diverso da un dispositivo MIDI Lo sviluppo del driver minisnd ha richiesto lo studio di ALSA Advanced Linux Sound Architecture 32 33 34 ALSA fornisce un insieme di driver una libreria applicativa e diverse utility per la gestione del sistema audio in Linux Dal punto di vista delle applicazioni esistono ormai decine di software professionali che seguono lo standard ALSA tra cui il progetto Jack spic
15. a hmad O I Figura 7 2 Il file di dati audio grezzi aperto con l applicazione Audacity Come vediamo il segnale si presenta piuttosto basso come ampiezza ma questo chiaro visto che stato inviato tramite un microfono direttamente collegato alla Beagle Board senza amplificazione In ogni caso l esecuzione del file mostra che ci che viene inviato dal microfono ricevuto corretta mente Per ottenere una bassa latenza si visto che sufficiente impostare un nu mero di pacchetti inviati con le richieste isochronous pari a 4 e un intervallo di polling delle richieste il parametro urb gt interval di cui si parlato nel paragrafo 6 2 2 pari a 8 Con valori superiori di intervallo si notata una cre scente latenza ottenuta mentre si notata una certa instabilit nel sistema se si impostano richieste troppo stringenti in termini di tempo ad esempio un intervallo di 1 con 32 pacchetti Per farsi un idea dei motivi di questo fatto si provato ad impostare tali richieste di alte prestazioni disabilitando l uso della conversione Voltage To MIDI e quindi della FPU e si notato che le instabilit sparivano riuscendo tranquillamente a sostenere le trasmis sioni Si suppone allora che l uso della FPU richiedendo la disabilitazione CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 153 della preemption con la chiamata da parte di kernel_fpu_begin della funzione preempt_disa
16. ca con particolare rilevanza Questo fornisce un sistema di configurazione e routing per tutti i software ALSA compliant attivi nel sistema La Figura 3 9 mostra l applicativo grafico Jack Control ee __ O JACK Audio Gonneccon Kit defa mt Stopped Col Psa B Stop O Messages 4y Status 3 Connect Dd Patchbay 7 pemer x Connections JACK Audio Connection Kit Audio MIDI ALSA Readable Clients Output Ports v Writable Clients Input Ports E 14Midi Through EB 14 Midi Through 0 Midi Through Port 0 Connect X Disconnect f Disconnect Al 5 Refresh Figura 3 9 Uno screenshot dell applicazione QjackCtl Come detto Jack fornisce un interfaccia generica per il controllo di tutti i CAPITOLO 3 STUDIO DI FATTIBILITA ol software e i dispositivi ALSA nel sistema Come si vede in Figura mette a disposizione un grafo di routing per redirigere i vari flussi elaborativi da un software all altro o da un dispositivo all altro Ad esempio possibile acqui sire i dati da una tastiera MIDI inviarli ad un software per l elaborazione di questi ad esempio il software Qsynth 51 che permette di inserire effetti ed effettuare trasformazioni sul segnale di input ed inoltrare il segnale di uscita di questo software ad un altro software che magari registrer il risultato Quello che si vuole scrivere dunque un driver che permetta di mostrar
17. e contiene i vari elementi in uno stile simile all XML il file di default cos come appare formattato quello che segue lt ConfigurationProfile gt CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 102 lt poliphony gt false lt poliphony gt lt numVoices gt 1 lt numVoices gt lt playingMode gt glissando lt playingMode gt lt midi0QUT gt true lt midi0UT gt lt programmableHW gt lt hw 0 gt PUSHBUTTON 0 lt hw 0 gt lt programmableHW gt lt controlCmd gt lt cmd 0 gt RESET 0 lt cmd 0 gt lt controlCmd gt lt associations gt lt as 0 gt 0 0 lt as 0 gt lt associations gt lt ConfigurationProfile gt Per quanto riguarda infine il controllo in fase di reimpostazione del profilo l applicazione che viene chiamata dall utente amministratore si preoccupa di effettuare il controllo sintattico sul file del profilo mentre successivamente si occupa di scrivere sui file del sysfs per invocarne la modifica al meto do store all interno del driver che spetta a quel punto di effettuare un controllo sui valori immessi in modo da evitare che siano salvate stringhe che non hanno significato sul dispositivo ad esempio hardware e o comandi inesistenti A questo punto possibile che si crei il seguente scenario un utente con privilegi di amministrazione potrebbe scrivere direttamente sui file del sysfs modificandone il valore correttamente ma non passando per il comando di conferma del profilo di co
18. gt longname s card gt shortname snd_card_set_dev card sd gt dev snd_device_new card SNDRV_DEV_LOWLEVEL sd amp ops if err lt 0 snd_card_free card return err CAPITOLO 3 STUDIO DI FATTIBILITA 59 MIDI DEVICE err snd_rawmidi_new card id_midi_string devno 0 1 amp mididev if err lt 0 snd_card_free card return err midi_ops open my_rawmidi_open midi_ops close my_rawmidi_close snd_rawmidi_set_ops mididev SNDRV_RAWMIDI_STREAM_INPUT amp midi_ops mididev gt private_data sd mididev gt info_flags SNDRV_RAWMIDI_INFO_INPUT strcpy mididev gt name minisnd_midi_in err snd_card_register card if err lt 0 snd_card_free card return err sd gt card card sd gt midi_device mididev return 0 EXPORT_SYMBOL snd_minisnd_probe void snd_minisnd_remove struct snd_card sndcard i if sndcard printk KERN_WARNING snd_minisnd_remove NULL sndcard return snd_card_free sndcard EXPORT_SYMBOL snd_minisnd_remove Figura 3 12 Sorgente delle funzioni principali del modulo snd_minisnd CAPITOLO 3 STUDIO DI FATTIBILITA 60 3 5 2 Esecuzione del driver e risultati Perch il codice scritto utilizzando l API di ALSA possa essere compilato per prima cosa occorre ricompilare il kernel abilitando il supporto ad ALSA che in alcune versioni del kernel non c di default In particolare chi scri
19. la struttura contiene un valore di tolerance una soglia passata la quale il risultato si pu considerare trovato di solito come si legge nel sorgente di aubio questo valore viene impostato su 85 La funzione esegue il calcolo della formula mostrata nel paragrafo 3 6 1 cal colando incrementalmente il valore di d T da quello di d 7 Infine tramite la funzione fvec_quadint ritorna l indice del picco del segnale che rap presenta il pitch del suono calcolato tramite interpolazione quadratica Come vedremo pi avanti cfr 6 questo codice stato utilizzato per svilup pare il convertitore pitch to midi importandolo a livello del kernel Infatti anche se l algoritmo richiede una certa quantit di calcoli floating point e questo sembrerebbe non rientrare nelle buone pratiche di programmazione del kernel chiaro che un applicazione come questa che richiede calcoli di CAPITOLO 3 STUDIO DI FATTIBILITA 76 elaborazione del segnale necessiti dell uso di tale tecnica Naturalmente pe r sono state previste delle precauzioni seguendo quanto descritto in 5 57 tutte le operazioni critiche sono state implementate direttamente per essere eseguite nella Floating Point Unit FPU hardware presente nella cpu per fare questo il modulo del kernel sviluppato stato compilato con le opzioni ffast_math e mhard_float e in fase di linking il driver controlla esplici tamente se la cpu su cui in esecuzione in possesso di t
20. modify_attr association midi out ee LI submit _int_out_ep NO PREFIX add uevent var env val check _data le le usb_submit_urb modify_attr I I NO PREFIX add uevent var env val 117 thmx_check profile check_config_file check_config_file Figura 5 15 Diagramma della sequenza relativa alla reimpostazione del profilo di configurazione CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 118 usb_module ithmx_usb thmx_execCtiCmd iocti dev cmd submit int out ep usb_submit_urb Figura 5 16 Diagramma della sequenza relativa all esecuzione di comandi di controllo inviati dal sistema host snd_module usb_module thmx_usb MIDI application thmx_snd_rawmiidi output trigger 6s thmx extract data_from ss thmx usb write submit_int_midi_out_ep Figura 5 17 Diagramma della sequenza relativa all invio di messaggi MIDI di output per dispositivi esterni CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 119 questa write viene implementato passandogli come argomento una struct snd_rawmidi_substream All interno di questa come dati privati salvati al momento dell inizializzazione stato inserito un puntatore alla struttura thmx di riferimento tramite il quale possibile ottenere la funzione di scrittu ra sul dispositivo usb m
21. thmz_src utility_ scripts gadget una versione leggermente modificata di aplay in cui rispetto a quest ultimo sono stati eliminati alcuni controlli nell acquisizione audio come il limite imposto ai file registrati che stato eliminato consentendo di inviare dati indefinitamente o la pulizia del file su cui scrivere i dati prima dell inizio della registrazione fatta da aplay per salvare ogni volta un nuovo file audio che stata saltata perch altrimenti lo script avrebbe eliminato il nodo del dispositivo all interno del file system Inoltre la thmx_gadget_alsa_capture non consente di scegliere tra l acqui sizione di dati audio e la loro riproduzione come invece aplay fa ma mette a disposizione solo la prima funzione Assieme a questo programma lo script thmx_alsa_capture_start stato inserito tra gli script di avvio del sistema e fa s dunque che non appena terminato l avvio del sistema operativo inve ce di avere il prompt per il login il sistema cominci semplicemente a ricevere dati audio inoltrandoli sul driver Infine comunque l esecuzione di questa registrazione pu essere interrotta dall utente tramite ctrl C e il sistema consentir il normale login In questo caso il sistema host smetter di ricevere dati e inizier ad inoltrare richieste di recupero come spiegato nel paragrafo 6 2 2 per cui stato messo a disposizione nel file system del gadget un comando essenzialmente identico a quello
22. uso SetMIDIOut ID CU 6 Attori User Descrizione Permette all utente di attivare disattivare la possibili ta di inviare messaggi MIDI OUT dal sistema host at traverso lo strumento hardware verso strumenti MIDI esterni Precondizioni Il sistema deve essere inizializzato e attivo dispositivo hardware acceso e collegato all host moduli del kernel caricati e pronti Flusso principale 1 L utente esegue il comando di at tivazione disattivazione del MIDI OUT 2 il sistema host modifica la visibilit o meno del dispositivo come device di MIDI OUT in Alsa 3 Il sistema host reimposta il profilo di configurazio ne Flussi alternativi Postcondizioni Il sistema host ha correttamente modificato l imposta zione corrente della funzione di MIDI OUT Nome Caso d uso ModifyConfig ID CU 7 Attori Privileged user Descrizione Permette ad un utente privilegiato di modificare liberamente il profilo di configurazione Precondizioni Il sistema host deve essere stato inizializzato profilo di configurazione caricato Flusso principale 1 L utente Privileged user apre il file del profilo di configurazione per la modifica 2 il sistema host verifica i privilegi dell utente 3 Il sistema host permette la modifica del file Flussi alternativi Postcondizioni Il sistema host ha permesso la modifica del file del profilo di configurazione CAPIT
23. 1 sul sistema di chi scrive e Output device hw 1 0 sul sistema di chi scrive f Altri parametri lasciati con i valori predefiniti 5 fatto questo stata utilizzata l uscita per le cuffie della scheda come output audio 6 in ultimo il sistema audio stato eseguito impostando i giusti para metri di priorit Per fare questo nel file etc set_rlimits conf stata aggiunta la linea daniele usr bin qjackctl nice 10 rtprio 90 memlock 1000000 cfr 3 72 e il programma qjackctl stato eseguito utilizzando il comando set_rlimits usr bin qjackctl Tutto quanto descritto in realt stato implementato in un unico script interattivo che permette di avviare tutte le operazioni descritte necessarie al setup del sistema audio cos da agevolarne l utilizzo Compilazione kernel rt E stato utilizzato il kernel 2 6 31 12 per il quale la patch rt disponibile nel momento in cui si sviluppato il progetto 56 Per il resto la riuscita della compilazione del kernel ha richiesto 1 disattivazione della configurazione relativa al modulo RT2500 che si trova su Device Drivers gt Network device support gt Wireless LAN gt Ralink driver support gt Ralink rt2500 sia la versione PCI che USB questo infatti causa un errore nella compilazione perch pare 54 sia incompatibile con il kernel rt 2 Per il debug dello sviluppo sono state impostate le seguenti configura zioni a Kernel Acking gt D
24. 1 La scheda Beagle Board e PAPI USB Gadget del kernel Linux Esistono in commercio numerose soluzioni hardware per lo sviluppo di ap plicazioni embedded di pi o meno grande complessit La maggior parte di queste mettono a disposizione un microcontroller una certa quantit di memoria e alcune periferiche per I O Per l applicazione descritta in questo documento l attenzione a tali soluzioni principalmente dovuta al fatto che esse offrono un ottima opportunit per risparmare tempo nella progettazione e sviluppo hardware per potersi concentrare cos sul software Tra quelle pi semplici ed economiche vale sicuramente la pena menzionare le schede Ar duino 36 e Teensy 37 Entrambe mettono a diposizione un microcontroller Atmel della famiglia AVR memoria Flash e RAM un convertitore A D per la gestione di segnali analogici e infine un controller USB per la comuni cazione con un pc host Ad un analisi pi approfondita per emerso che queste soluzioni non erano adeguate all applicazione qui descritta Infatti ad esempio Arduino non pensato per permettere la personalizzazione del dispositivo USB fino a ridefinirne le carattestiche strutturali come il numero e il tipo di endpoint mentre fornisce un API gi pronta per implementare ap plicazioni software embedded nascondendo i dettagli dell hardware a livello ad esempio di istruzioni del processore Questo non vale per Teensy che inve ce permette di ridefinire
25. 15 Il driver implementato si trova nel file gadget thma_ gadget_ uart c In fase di inizializzazione funzione gthmx_uart_init si allocano e regi strano le due strutture fondamentali del sistema cio la struct uart_driver e la struct uart_port L inizializzazione di quest ultima la parte pi interessante di questa fase uart port configure uport amp u_data gt port uport gt ops amp gthmx_uart_ops CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 146 spin_lock_init amp uport gt lock uport gt line 0 uport gt dev amp platform gt dev uport gt private_data gthmx uport gt mapbase OMAP_UART3_BASE uport gt membase ioremap_nocache uport gt mapbase GTHMX_UART_SIZE if uport gt membase printk KERN_WARNING thmx_gadget cannot ioremap the mapbase address goto err_plat_dev uport gt iotype UPIO_MEM uport gt flags UPF_BOOT_AUTOCOIF uport gt irq GTHMX_UART3_IRQ uport gt uartclk OMAP16XX_BASE_BAUD 16 uport gt regshift 2 uport gt fifosize GTHMX_UART_FIFO_SIZE ret uart_add_one_port uart uport Dato il basso livello a cui ci si interfaccia la porta UART viene associata ad un generico platform_device appositamente allocato che viene utiliz zato soltanto per l assegnamento al dispositivo della porta uport gt dev amp platform gt dev In realt le risorse fisiche della piattaforma hardware so no state definite staticamente in base alla docume
26. 19 11 devices 1 root root 5 2010 06 30 19 11 minisndcard0 gt card0 1 root root 0 2010 06 30 19 11 modules lrwxrwxrwx r r r CAPITOLO 3 STUDIO DI FATTIBILITA 61 dr xr xr x 2 root root 0 2010 06 30 19 11 oss dr xr xr x 2 root root 0 2010 06 30 19 11 seq r r r 1 root root 0 2010 06 30 19 11 timers r r r 1 root root 0 2010 06 30 19 11 version Inoltre la nuova sound card viene elencata anche nel file proc asound cards daniele danieledevel laptop cat proc asound cards O minisndcardO J minisnd minisnd_card0 minisnd_card0 Infine possibile controllare l avvenuto riconoscimento da parte di Jack Av viando il setup di Jack Control possiamo vedere la sound card minisnd_card0 come selezionabile tra le sound card disponibili nel sistema Figura 3 13 JACK Audio Connection Kit default Stopped 0 x D gt Start r O Messages I Settings Options Display Misc pe cannes Preset Name default Save X Delete Server Server Path usr bin jackd v Driver aisa Parameters Realtime Priority detautt z v hw minisnd cardo gt No Memory Lock Frames Period 1024 v default Unlock Memory Sample Rate 44100 vi Audio Capture Only Soft Mode n Periods Buffer 2 Input Devce hw0 v Monitor Word Length 16 lv Output Device hw 1 1 w Force 16bit A Wait usec 21333 Input Channels 1 Channe
27. ALLEVA Pitch detection with a neural net classifier IEEE Transactions on Signal Processing 39 2 298 307 1991 13 A NAGI A user configurable voice based controller for Midi synthesizer A Prototype for Real Time Performance Master Thesis UPF 2010 14 TEXAS INSTRUMENTS OMAP3530 25 Datasheet 2009 15 TEXAS INSTRUMENTS OMAP35x Applications Processor Technical Reference Manual 2010 16 BEAGLEBOARD ORG BeagleBoard System Reference Manual Rev C4 Risorse web 17 Musical Instrument Digital Interface Wikipedia http en wikipedia org wiki MIDI 18 Glissando TheFreeDictionary http www thefreedictionary com glissando 19 Hot Plug Linux Journal http www linuxjournal com article 5604 20 Plug and Play HOWTO The Linux Documentation Project http tldp org HOWTO Plug and Play HOWTO html 21 Nyquist Shannon sampling theorem Wikipedia http en wikipedia org wiki Nyquist Shannon_sampling_ theorem 22 Analog to Digital Converter Wikipedia http en wikipedia org wiki Analog to digital_converter 23 Audio Converter Wikipedia http en wikipedia org wiki Audio_converter 24 Audio frequency Wikipedia http en wikipedia org wiki Audio_frequency BIBLIOGRAFIA 164 25 ADC most popular types Hitequest website http www hitequest com Kiss A_D htm 26 What actually happens when you plug in a USB device Technovelty weblog of Ian Wienand http www technovelty org code linux pl
28. Cavo USB Fonte 2 Il segnale dei dati viaggia sul cavo attraverso due pin D e D mentre il segnale di voltaggio di riferimento di 5 V portato dal pin V guys in questo modo i dispositivi possono ottenere l alimentazione dallo stesso cavo USB e quello di massa dal pin GND Inoltre il clock viene inviato insieme ai dati attraverso un pacchetto di SYNC in modo che le comunicazioni distribuite possano essere sincronizzate 3 2 2 Modello di Data Flow e protocollo di comunica zione L idea alla base dell USB di offrire una generalit tale da poter sfruttare questo bus per le diverse esigenze di comunicazione di molti dispositivi Per questo i flussi di dati sono gestiti a livello logico attraverso l uso di pipe unidirezionali gestite in modo indipendente una rispetto all altra sul cui numero e tipo l host e il dispositivo possono accordarsi liberamente in base alle esigenze del dispositivo La Figura 3 4 mostra il dettaglio di come questi flussi sono strutturati Come si vede possiamo riconoscere tre livelli di stratificazione 1 il livello fisico l ultimo dal basso in Figura 3 4 dove viene implemen tato il protocollo hardware e i dati vengono scambiati attraverso il cavo USB descritto precedentemente cfr 3 2 1 CAPITOLO 3 STUDIO DI FATTIBILITA 21 Interconnect Physical Device Function acollectian of to an interface Default Pipe to Endpoint Zero E JSB Device USB Host interface E
29. Embedded System General System Playing MIDI playing data done Waiting for System events SW CtiCommand ExecCtlCommand Sw request done HW CtlCommand request done System SendMIDI OUT System Initialization ExecCtiCommand HW error Figura 5 3 Diagramma degli stati che descrive un tipico ciclo di vita del sistema embedded CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 89 Qui notiamo molte delle caratteristiche gi descritte dal sistema host nei diagrammi di approfondimento che verranno forniti tra poco infatti vedre mo come molti degli stati descritti coinvolgono entrambi i lati del sistema L unico stato che si ritenuto importante espandere gi in questo diagramma ExecCtlCommand HW che come descritto dal caso d uso CU 4 permette di eseguire un comando di controllo azionando un elemento hardware program mabile La sequenza descritta da questo macro stato comunque piuttosto semplice in quanto viene essenzialmente effettuato un controllo sul comando da eseguire e se questo non indefinito viene avviata l esecuzione 5 2 1 Dettagli sui principali scenari Molti degli stati descritti nel precedente paragrafo sono in realt dei macro stati che coinvolgono l azione coordinata di pi end user descritti con i casi d uso Vediamone i dettagli Inizializzazione del sistema Per prima cosa l inizializzazione La Figura 5 4 mostra la seque
30. Hardware Interrupt I hw_cmd_exec wake up cmd queue cmd_func Figura 5 22 Diagramma della sequenza relavita all esecuzione di un comando di controllo invocato da un interrupt hardware CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 124 ithmx_gadget usb gadget int out urb ctl cmd ctlcmd_queue _ return data _ data Figura 5 23 Diagramma della sequenza relavita all esecuzione di un comando di controllo invocato dal lato host na gthmx_exec_sw_cmd Pa wait cticmd_queue Capitolo 6 Scelte di implementazione del sistema Dopo aver trattato in maniera approfondita la progettazione astratta per quanto non priva di piccoli test implementativi del sistema di seguito ver ranno forniti i dettagli di come il Thereminux stato effettivamente imple mentato Per fare questo dapprima si presenter la preparazione dell am biente dove il sistema stato sviluppato ed eseguito cfr 6 1 spiegando quali strumenti sono stati utilizzati e come Successivamente si approfondi r il sistema vero e proprio cfr 6 2 Naturalmente l intero codice sorgente del sistema stato allegato al materiale consegnato e documentato oltre che all interno degli stessi file sorgente anche tramite un manuale di riferimento generato tramite Doxygen Tale materiale da considerarsi un valido ausilio alla trattazione che segue 6 1 Ambiente di sviluppo ed esecuzione L ambiente har
31. Output Port w Writable Clients Input Ports w ES 14 Midi Through E 14 Midi Through 16 thmx_snd_cardO E 16 thmx_snd_cardO ES 20 Audiophile USB tm na 20 Audiophile USB tm 130 FLUID Synth 22257 CAPTURE ss MMAP_INTERLEAVED at 16 LE ormat STD i 44100 44100 44100 1 Connect X Disconnect Disconnect All 5 Refresh period time 11609 tstamp mode NONE ia J period step 1 avail_min 512 ren thmx audioraw period event 0 a start threshold 1 stop threshold 22016 D silence threshold 0 gt rr silence size 0 thms configuration boundary 1442840576 appl ptr 0 hw_ptr 0 a daniele daniel JACK Audio Con 3 Connections JA Qsynth A fluids OL Figura 7 3 Uno screenshot di utilizzo del Thereminux le vocale inviato dal microfono piuttosto difficile da analizzare essendo la voce umana estremamente ricca di componenti armoniche e inarmoniche che rendono ardua l estrazione di una sinusoide fondamentale inoltre il segnale viene ricevuto dallo strumento con un volume piuttosto basso come mostrato anche nel paragrafo precedente cfr 7 1 Ancora per evitare di ascoltare un flusso velocissimo di note che si susseguono una dietro l altra stato creato dentro thmx_aux_thread un contatore che consente l invi
32. campioni audio di input o quella di moltiplicarli per una costante Attualmente tali modifiche vengono applicate soltanto per il tempo di una singola esecuzione della thmx_char_write Invii ritardati Infine possibile immaginare che nel caso in cui l applicazione thmx_gadget_alsa_capture venga terminata dall utente il buffer di cam pioni acquisito dal driver pu essere stato riempito soltanto in parte Per come implementata la funzione thmx_char_write la comunicazione di dati da inviare all oggetto thmx_gadget_usb viene effettuata soltanto quan do il buffer pieno per efficienza In questo caso la parte del buffer non inviata andrebbe probabilmente persa Per evitarlo stata utilizzata una workqueue che ha permesso di creare uno speciale thread la cui routine un delayed_work associata ad un timeout se il timeout scatta significa che non sono stati inviati dati per troppo tempo e dunque il momento di inoltrare i dati rimasti all interno del buffer se ce ne sono all oggetto thmx_gadget_usb Il timer della workqueue viene bloccato ogni volta che si entra nella funzione thmx_char_write cos da evitare invii contemporanei e riattivato al suo termine Purtroppo anche qui la documentazione fornita dai testi 5 4 consultati riferendosi al kernel 2 6 11 risultata obsoleta rispetto al kernel utilizzato Per questo stato consultato l articolo 44 ed il driver drivers usb misc ftdi elan c da cu
33. che definisce la secuzione battuta musicale al la quale l esecuzione deve spostarsi Song Messaggio inviato da 0xF3 1 numero del brano Select un device master per musicale far s che lo slave suoni un certo brano Tune Il dispositivo che ri 0xF6 Nessuno Request ceve questo messaggio deve eseguire una rica librazione dell intona zione MIDI Messaggio inviato da 0xF8 Nessuno Clock un device master per mantenere in sincrono uno slave Affinch questo possa avvenire questo messaggio vie ne inviato ad intervalli regolari CAPITOLO 3 STUDIO DI FATTIBILITA 49 Tick Messaggio inviato da un device master per mantenere in sincrono uno slave Affinch questo possa avvenire questo messaggio vie ne inviato ad intervalli regolari di 10ms OxF9 Nessuno MIDI Start Messaggio inviato da un device master per far s che lo slave suoni un certo brano dall inizio battuta 0 OxFA Nessuno MIDI Stop Messaggio inviato da un device master per far s che lo slave inter rompa l esecuzione di un certo brano OxFC Nessuno MIDI Con tinue Messaggio inviato da un device master per far s che lo slave suo ni un certo brano dalla posizione corrente OxFB Nessuno Active Sense Messaggio inviato da un device ogni 300ms quando non c al tra attivit sul bus Questo per comunica re agli altri dispositi vi che il collegamento integro OxFE
34. che in clude tutte le informazioni necessarie all implementazione delle funzionalita Nel dettaglio la struttura definita cosi nell header minisnd h struct minisnd struct snd_card card struct snd_rawmidi midi_device struct usb_data usbd struct device dev int devno struct usb_data struct usb_device udev unsigned char bulk_in_buffer size_t bulk_in_size _u8 bulk_in_endpointAddr __u8 bulk_out_endpointAddr Come si vede la struttura contiene le risorse fondamentali per l esecuzione del driver come i puntatori specifici di ALSA della sound card struct snd_card e del dispositivo MIDI ad essa associato struct snd_rawmidi inoltre contiene un puntatore ai dati specifici del dispositivo usb rappresen tati con la struttura usb_data In essa si trovano il puntatore alla struct usb_device o agli endpoint su cui la comunicazione vera e propria pu avve nire Nel caso specifico gli unici due endpoint considerati sono uno di input e uno di output di tipo bulk cfr 3 2 2 Ai fini dell inizializzazione del la sound card da parte di ALSA sono richieste le informazioni relative alla struct device a cui il dispositivo fa riferimento quindi stato inserito per comodit anche un puntatore a questa struttura Infine viene usato un con tatore per il tracciamento dei dispositivi gestiti dal driver infatti nel caso delle sound card ALSA non pu gestirne pi di otto con lo stesso driver In conc
35. connettori audio tra l altro stata fondamentale per permettere il collegamento allo strumento anche di un comune microfono audio dunque permettendo di po sticipare l implementazione hardware del Theremin analogico Naturalmente per per programmare e gestire una scheda di questa portata non pi sufficiente soltanto l utilizzo di un firmware che possa accedere ai registri e ai pin del processore infatti la Beagle Board viene solitamente utilizzata con un sistema operativo vero e proprio e in particolare com patibile con Linux Embedded 39 In particolare la sequenza di avvio della Beagle dalla sua memoria flash si articola in tre fasi si avvia prima il tool X Loader 40 che si occupa di avviare il firmware U Boot 41 Questo fornisce un interfaccia sul dispositivo dall host tramite il bus seriale permettendo di CAPITOLO 3 STUDIO DI FATTIBILITA 68 eseguire diversi comandi per il debug hardware e inoltre pud avviare un im magine Linux passandogli volendo anche opportuni parametri A questo punto avendo a disposizione un kernel Linux l utilizzo della sche da Beagle Board nella nostra applicazione si traduce sostanzialmente nella necessit di scrivere un device driver USB lato periferica che sia in grado di inizializzare e gestire correttamente l hardware e la comunicazione con l host Per questo il kernel Linux mette a disposizione l interfaccia USB Gadget L API USB Gadget Questa interf
36. del kernel superato il quale necessario utilizzare altri meccanismi come lo SLAB o lookaside cache che permette di allocare degli interi pool di memoria che si possono usare con aree di memoria della stessa CAPITOLO 3 STUDIO DI FATTIBILITA 32 dimensione o le funzioni come get_free_page che permettono di ot tenere direttamente intere pagine libere In ogni caso il kernel ha la possibilit sia di allocare zone di memoria virtuale tramite la vnalloc sia di ottenere indirizzi virtuali che permettono di accedere porzioni di memoria fisica tramite la ioremap Infine per quanto detto finora l astrazione usata per catalogare le zone di memoria diversa tra kernel e user space infatti nel kernel esistono 3 zone che vengono considerate a normal dove l allocazione viene di solito effettuata b DMA capable una zona di memoria preferenziale dove le perife riche effettuano le operazioni di DMA In situazioni normali le pagine libere da allocare vengono ricercare nella normal zone o in questa c High memory una zona per l accesso a quantit di memoria mag giori del solito che per meno usabile possibile specificare la zona di memoria nella quale effettuare l allo cazione come flag passato alla funzione kmalloc 9 altra caratteristica molto interessante della programmazione modulare nel kernel Linux la possibilit di implementare una stratificazione di moduli utilizzando i simboli pubblic
37. delle configurazioni delle in terfacce e degli endpoint per il dispositivo con inoltre una serie di descrittori stringa utilizzati per memorizzare e inviare delle informazioni leggibili e pre sentabili agli utenti Infine nel caso di dispositivi che possono essere eseguiti in high speed necessario specificare sia una configurazione di compatibilit per l esecuzione in full speed dichiarando descrittori di entrambi i tipi e CAPITOLO 3 STUDIO DI FATTIBILITA bmRequestType windex 2 Index or Offset wLength 2 25 O ee oe ve e Characteristics of request D7 Data transfer direction 0 Host to device 1 Device to host Type 0 Standard 1 Class 2 Vendor 3 Reserved Recipient 0 Device 1 Interface 2 Endpoint 3 Other 4 31 Reserved bRequest 1 Specific request Word sized field that varies according to request Word sized field that varies according to request typically used to pass an index or offset Number of bytes to transfer if there is a Data stage Figura 3 5 Struttura di una richiesta USB Fonte 3 inoltre un Device Qualifier che permette al dispositivo di descrivere come si pu comportare ad entrambe le velocit cos che host possa scegliere la migliore per l applicazione da eseguire Quello che dunque fa un dispositivo alla ricezione di una richiesta ad esem pio come la GetDescriptor andare a recuperare il descrittore specificato come
38. delle funzionalit necessarie il codice stato diviso in diversi moduli e file In particolare ogni file implementa una funzionalit ben precisa ed costituito in maniera simile agli oggetti del paradigma object oriented da una serie di attributi propri dell oggetto e da alcune funzioni per lavorare su tali attributi Per evitare confusione si parler qui di moduli quando ci si riferisce ai moduli del kernel mentre saranno definit oggetti i file che compongono i vari mo duli Gli attributi di ogni oggetto sono stati inseriti in una apposita struct cos che esso risulti chiaramente incapsulato Inoltre ogni oggetto ha delle fun zioni pubbliche ovvero che altri oggetti possono richiamare e altre che sono definite private cio per uso interno dell oggetto Queste ultime sono state dichiarate seguendo la sintassi C come static Passiamo ora ad esaminare nel dettaglio i due sistemi host ed embedded Moduli e oggetti per il sistema host Il diagramma che rappresenta la struttura degli oggetti e dei moduli del si stema host mostrato in Figura 5 11 Come possibile vedere stato previsto lo sviluppo di tre diversi moduli del kernel denominati usb_module snd_module e vtm_module Di questi il primo risulta quello centrale che implementa effettivamente il device driver USB per il dispositivo Gli altri due sono stati pensati in modo tale da rende re totalmente indipendente il livello di gestio
39. derivante dal campionamento di un segnale di voltag gio di input di produrre un flusso di messaggi MIDI standard interpretabili da qualsiasi applicazione MIDI che li user per suonarli La descrizione del l hardware rappresenter una sorta di mappa degli elementi peculiari dello strumento collegato come la possibilit o meno di suonare pi note con temporaneamente la presenza di periferiche di input programmabili come pulsanti o altro la possibilit di inviare messaggi MIDI di output attraverso lo strumento ecc CAPITOLO 1 DESCRIZIONE GENERALE DEL PROGETTO T 1 1 1 Configurazione software Il Thereminux possiede la funzionalit di configurazione automatica tramite plug and play 20 usando la funzione di hotplug 19 messa a disposizione da ogni sistema operativo evoluto Questo significa che il profilo di configura zione dello strumento vedi Figura 1 1 viene caricato automaticamente nel sistema host al momento del suo collegamento fisico al computer Tale pro filo di configurazione rappresenta la descrizione astratta delle caratteristiche dello strumento e come verr trattato nel dettaglio pi avanti cfr 5 3 1 implementato come un file di configurazione in cui le diverse sezioni vengono interpretate dal driver Il file di configurazione non scrivibile senza oppor tuni privilegi ed leggibile dagli utenti con privilegi standard solo attraverso opportuni comandi La scrittura di un nuovo profilo pu avvenir
40. di strutture gerarchiche la gestio ne degli eventi di hotplug ecc Si pu senz altro dire che ogni oggetto che esiste all interno del sysfs viene rappresentato con un kobject In particolare la creazione di un nuovo kobject causa l allocazione di una nuova directory all interno del sysfs I file che queste directory contengono rappresentano gli attributi ad esempio il vendorId il productId ecc associati al kobject Moltissime strutture interne del kernel come ad esempio la struct cdev di cui si discusso hanno associato tramite il meccanismo del contenimento all interno della struttura stessa un kobject che le rappresenta all interno del device model Inoltre quindi tutte le funzioni di inizializzazione registrazio ne cancellazione ecc di strutture che rappresentano dispostivi bus o device driver eseguono delle operazioni sul sysfs e sui kobject associati a tali strut ture Ad esempio riprendendo il caso dei driver per dispositivi a caratteri presentato in precedenza cfr 3 3 2 ogni driver che voglia implementare un dispositivo a caratteri deve per prima cosa inizializzare la struttura cdev tramite la funzione cdev_init cdev fops che prende come argomenti la struttura cdev e quella file_operations con le operazioni implementate su CAPITOLO 3 STUDIO DI FATTIBILITA 37 quel dispositivo Ebbene se guardiamo l implementazione di questa funzione all interno del sorgente del kernel file fs char_dev c
41. embedded con il quale il modulo compilato viene copiato sulla scheda SD che contiene il file system usato sulla Beagle Board Anche in questo caso il modulo viene copiato in una sotto directory di lib modules e beagle setup sd script eseguito per effettuare il completo setup del la scheda SD usata sulla Beagle Board Questo script effettua la for mattazione della scheda la copia dei file relativi al bootloader della Beagle Board e del sistema operativo e infine la copia dei file relativi al Thereminux modulo e script a livello applicativo CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 106 5 3 3 Endpoint presenti sul dispositivo Date le funzionalit implementate gli endpoint che vengono forniti dal si stema embedded del Thereminux sono quattro si ricorda che si definisce di input un endpoint che invia dati dal dispositivo all host e di output il viceversa cfr 3 2 1 uno di input di tipo bulk per la gestione di alcune informazioni che il dispositivo invia all host come stringhe di debug o di controllo dello stato di esecuzione 2 uno di input di tipo isochronous per la gestione del flusso di campioni audio che dovranno essere trasformati in MIDI 3 uno di output di tipo interrupt per la gestione dei dati come i comandi di controllo inviati da software che devono essere gestiti nel pi breve tempo possibile 4 un altro di output di tipo interrupt specifico per l invio di messaggi MIDI di output 5 3 4 Co
42. gadget e l interfaccia a caratteri139 6 2 5 La conversione Voltage To MIDI 141 6 2 6 I comandi di controllo dell esecuzione 143 627 Udine UARI Lilia RR OS 145 6 2 8 La gestione dell hardware programmabile 148 6 2 9 La disconnessione dello strumento 148 INDICE 3 7 Test effettuati e risultati ottenuti 150 7 1 Test sulla trasmissione di datiaudio 151 7 2 Far suonare il Thereminux 004 153 7 3 Test dei comandi di controllo 155 7 4 Test del MIDI 0ut LL 157 8 Conclusioni possibili miglioramenti e integrazioni 161 Capitolo 1 Descrizione generale del progetto Nelle pagine che seguono viene presentata la documentazione dettagliata per il progetto dell esame di Sistemi Operativi 3 a a 2010 2011 Il progetto consiste nella realizzazione di un piccolo strumento musicale elettronico il Thereminux interfacciato ad un device driver appositamente realizzato co me modulo del kernel Linux In Figura 1 1 riportato lo schema a blocchi del sistema Come si vede e come verr spiegato diffusamente pi avanti cfr 1 1 il sistema composto da una parte hardware e una software L hardware permette di acquisire un segnale audio analogico e di inoltrarlo tramite usb al sistema host dove un device driver appositamente sviluppato lo elabora e fornisce gli strumenti di controllo remoto del dispositivo Il sistema hardware descritto stato realiz zato uti
43. i valori esadecimali che rappresentano i byte dei messaggi MIDI non sempre sono tra quelli inclusi all interno dei caratteri ASCII CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 159 Co Applicazioni Risorse Sistema Qsynth A fluidd File Modifica Visualizza Terminale Sched Q YE dDI mar 26 lug 15 32 Ka i Connections JACK Audio Connection Kit Audio MIDI ALSA Readable Clients Output Port v Writable Clients Input Ports w E 14 Midi Through E 14 Midi Through daniele danieledevel laptop daniele danieledevel X daniele daniele Gd 08 GS 0008 S 000v00 dov s 04005 6 v 8 848 amp v d v d v 6 05 0489 S v v 04 05 vde f amp El 20 Audiophile USB tm FS 20 Audiophile USB tm E 130 FLUID Synth 22257 Connect X Disconnect 3e Disconnect ai ORetresh IN JACK Audio Con 3 Connections JA Qsynth A fluids RIE el fa fe daniele daniel Figura 7 8 Risultato della scrittura di messaggi MIDI sulla porta di MIDI out standard Quando questo avviene vediamo delle lettere comparire sul la console cosa che non avviene quando la trasmissione impostata ad un baud rate sbagliato Dunque la conclusione tratta stata che il problema debba necessariamente trovarsi
44. lo carica rispettando le sue dipendenze In questo modo il device driver del Thereminux inizialmente non presente viene caricato Gli eventi generati da udev possono essere monitorati da shell tramite il tool udevadm monitor che a fronte della connessione di un nuovo dispositivo usb sul sistema di chi scrive risponde come segue UEVENT 1273613041 732444 add devices pci0000 00 0000 00 1d 7 usb2 2 1 usb UDEV 1273613041 735635 add devices pci0000 00 0000 00 1d 7 usb2 2 1 usb UEVENT 1273613041 735677 add devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 usb UEVENT 1273613041 735698 add class scsi_host host28 scsi_host UEVENT 1273613041 735717 add CAPITOLO 3 STUDIO DI FATTIBILITA 41 devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 usb_endpoint usbdev2 12_ep81 usb_endpoint UEVENT 1273613041 735736 add devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 usb_endpoint usbdev2 12_ep01 usb_endpoint UDEV 1273613041 737999 add devices pci0000 00 0000 00 1d 7 usb2 2 1 usb_endpoint usbdev2 12_ep00 usb_endpoint UDEV 1273613041 821581 add devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 usb UDEV 1273613041 822351 add class scsi_host host28 scsi_host UDEV 1273613041 823172 add devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 usb_endpoint usbdev2 12_ep81 usb_endpoint UDEV 1273613041 824074 add devices pci0000 00 0000 00 1d 7 usb2 2 1 2 1 1 0 usb_endpoint usbdev2 12_ep01 usb_endpoint UEVENT
45. modo da utilizzare le varie partizioni in locale I comandi da lanciare per la configurazione sono a se si vuole partire con un sistema pulito cancellare tutto il con tenuto delle directory OEBASE sources OE_ BASE build conf LOCAL LARGE_DIR build tmp e LOCAL_LARGE_DIR sources downloads b oebb sh config beagleboard c oebb sh update 3 dalla OEBASE lanciare il comando oe environment 4 usare bitbake c lt comando gt 5 ogni volta che si vuole iniziare una sessione con bitbake occorre richia mare dalla OEBASE il comando oe environment Questo imposta la directory corrente come base per le operazioni da eseguire con bitbake 6 OpenEmbedded funziona specificando i vari pacchetti software da in stallare tramite dei file con l estensione bb di solito posizionati nella directory OE_SRC_BASE recipes e nelle sue sotto directory par tendo dalla directory di base delle configurazioni OEBASE nel si stema di chi scrive beagleboard oe angstrom build angstrom setup scripts il file build config local conf contiene le specifiche su dove scaricare i pacchetti dove trovare i file bb all interno del file system il nome della distribuzione di linux da ottenere e quello della macchina target Impostando questi parametri correttamente il sistema otterr dalla rete tutti gli opportuni pacchetti software CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 130 7 fatto questo si
46. non accessibile dal livel lo applicativo Con la chiamata alla funzione snd_card_register successivamente questa viene attivata In particolare vengono crea ti tutti i collegamenti relativi alla sound card e ai suoi dispositivi sia all interno del filesystem proc che sys In quest ultimo vengono creati tutti i kobject relativi ai dispositivi presenti nella sound card rispettando la loro gerarchia all interno del sistema ovvero mostrando i vari dispositivi sonori ad esempio come figli del bus al quale sono collegati All interno del filesystem proc invece vengono creati dei CAPITOLO 3 STUDIO DI FATTIBILITA 52 collegamenti standard di pit facile consultazione Uno tra tutti il fi le proc asound cards contiene la lista di tutte le sound card presenti nel sistema e per ognuna viene mostrata un apposita directory ad esempio proc asound card0 ecc con i dettagli delle varie schede 4 infine la chiamata a snd_card_free libera tutte le risorse preceden temente allocate compresa la scheda sonora e tutti i dispositivi ad essa associati 3 5 1 Dettagli implementativi del driver minisnd Come gi accennato in precedenza cfr 1 1 e 3 3 2 una buona idea per l im plementazione del device driver del Thereminux sembrerebbe essere quella di utilizzare una stratificazione di moduli del kernel in cui gli strati pi ad alto livello dovrebbero fornire funzioni generiche e quelli pi in basso do vrebbero gestir
47. non fa altro che eseguire delle ioct1 sul nodo del dispositivo USB Questa system call verr implementata semplicemente come un inoltro del comando gi precedentemente controllato dall applicazione nello user space al dispositivo remoto Infine l ultima operazione che sembrato importante riportare nel detta glio l invio di note MIDI di output Questa sequenza riportata in Fi gura 5 17 In questa sequenza evidenziato il comportamento che stato trattato nel paragrafo 5 3 6 un applicazione ALSA infatti prover a scrive re sul dispositivo ALSA craeto dal snd_module ed il metodo standard per 116 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE letsicozetpoconeno gt s ess aw ipiw yem E H 1911991 IPIUMEI pus uado piumei pus xwu ananb ajdwes em 1 yore iddy IGIW 4esn y EEE op uyd wz ainpow wi Qupisiqauo gt op wan XWwY ananb ajdwes dn ayem jang anes ayy xne XWF f jnpow qsn Diagramma della sequenza relativa all arrivo di un buffer di campioni audio dall USB Figura 5 14 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE thmx_confirm_profile no association thmx_config_st no midi out usb_module J s L check_data
48. operazioni vengono effettuate ha una particolare se mantica quando si interagisce con hardware Si pensi al riordinamento che possono subire alcune operazioni a causa del compilatore che cer ca di ottimizzare l efficienza se si parla di due semplici scritture su una linea seriale per questo riordinamento pu portare a risultati completamente diversi e non desiderati 7 mentre le applicazioni che utilizzano i meccanismi di memoria virtuale implementati nel sistema possono disporre di un ampia quantit di spazio nello stack personale il kernel mette a disposizione soltanto pochissimo spazio di stack solitamente una singola pagina che viene condiviso da tutto il kernel space Per questo sempre sconsigliabile dichiarare grandi variabili locali nel codice di un modulo ma se si necessita di strutture molto grandi preferibile utilizzare le funzioni di gestione dinamica della memoria interne al kernel come la kmalloc 8 in particolare il kernel non utilizza per l allocazione di memoria una strategia heap like come le applicazioni in user space ma manipola la memoria fisica del sistema che disponibile soltanto in chunck della di mensione di una pagina Per questo la funzione kmalloc pu ritornare delle quantit di memoria maggiori di quelle richieste di solito minimo 32 o 64 byte e ha un limite di allocazione massimo di solito intorno ai 128 KB ma dipendende dall architettura e dalla configurazione
49. passare al modulo snd_usb_audio La procedura seguita la seguente 1 Si spegne la scheda audio 2 si smonta il modulo snd_usb_audio con il comando modprobe r snd_usb_audio 3 si collega nuovamente il modulo con i seguenti parametri modprobe snd_usb_audio index 1 device_setup 0x09 Il valore di index pu variare a seconda del sistema In quello di chi scrive sebbene la Audiophile era la prima scheda audio del sistema caricarla con index 0 fa si che essa non venga rilevata correttamen te Per cui si scelto quello immediatamente successivo Per quanto riguarda invece i dettagli sul parametro device_setup si veda il file detto all interno della documentazione del kernel dove si legge device_ setup 0x09 24bits 48kHz mode with Di disabled Ai Ao Do can be used at the same time hw 1 0 is not available in capture mode hw 1 2 is not available Dove Ai Ao Di e Do significano rispettivamente Analog Input Analog Output Digital Input e Digital Output 4 a questo punto una volta caricata la scheda si procede all impostazione dei parametri di jack control che derivano dalle caratteristiche della scheda come descritte dall argomento device_setup CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 127 a Sample Rate 48000 b spuntare l opzione Force 16 bit c spuntare l opzione Realtime usata tramite il kernel RT e Pim postazione di set_rlimits come spiegato tra poco d Input device hw 1
50. per far partire la registrazione in fase di avvio del sistema che permette di ricominciare l acquisizione di dati audio e il loro invio all host Il dispositivo a caratteri Il nodo sotto dev thma_ gadget viene collegato ad un driver a caratteri per un dispositivo virtuale implementato dall oggetto thmx_gadget_char nel file gadget thma_gadget_ char c che sostanzialmente si occupa di pren dere i dati audio attraverso la system call write invocata dallo script CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 140 nello user space e inoltrarli all oggetto thmx_gadget_usb Per la comuni cazione tra questi due oggetti stata utilizzata una singola kfifo defini ta in lt linux kfifo h gt ovvero un buffer circolare che nello specifico del la nostra applicazione stato utilizzato da un singolo scrittore l oggetto thmx_gadget_char e un singolo lettore l oggetto thmx_gadget_usb Usan do questo meccanismo stato possibile implementare il protocollo senza il bisogno di utilizzare lock tra i diversi oggetti come si legge nella documen tazione nel caso di un solo scrittore e un solo lettore semplificando notevol mente il codice La funzione thmx_char_write che implementa la system call write inoltre si occupa di gestire eventuale modifiche causate dall esecuzione di comandi di controllo da apportare ai campioni audio Come spiegato nel paragrafo 5 3 4 tali modifiche sono la possibilit di azzerare i
51. pu essere fatta in automatico utilizzando il tool in 61 che viene eseguito dallo script beagle setup sd implementato Oltre a questo lo script carica la distribuzione Angtrom customizzata che stata sviluppata e predispone gi il modulo thmx_gadget all interno del sistema e crea una directory dove copia gli script di utilit che possono essere avviati tramite seriale sulla Beagle Board stessa a runtime Infine stata seguita la procedura descritta in 62 per i dettagli sulla creazione della SD card e per l inizializzazione della porta seriale tramite minicom Moduli e applicazioni compilati per la BeagleBoard Per quanto riguarda la compilazione di applicazioni per la BeagleBoard oc corre semplicemente utilizzare un cross compiler in modo da generare esegui bili per l architettura ARM Invece la compilazione di moduli del kernel richiede naturalmente per pri ma cosa i sorgenti del kernel di riferimento Il kernel Angstrom 66 usa di default il kernel 2 6 32 per cui da l si partiti Una volta ottenuti i sorgen ti del kernel si lavorato con un Makefile adattato a questo Ad esempio immaginando di voler compilare un semplice modulo chiamato hello si pu usare un Makefile come il seguente ifneq KERNELRELEASE obj m hello o else KERNELDIR lt path_to_kernel_sources gt PWD shell pwd default MAKE C KERNELDIR M PWD modules endif CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTE
52. quando ad esempio una applicazione richiama la system call read sul dispositivo il kernel richiamera la funzione implementata all interno del device driver per la read e gli passera un rife rimento al file aperto che a sua volta contiene un riferimento alla struttura file_operations corrente Questo utilizzato per implementare una sorta di method overriding in cui un certo metodo in grado di sostituire l imple mentazione dei metodi presenti per il dispositivo in base a certi criteri ad esempio all interno della open il metodo potrebbe controllare i privilegi del processo che ha invocato la system call e modificare i metodi disponibili per il dispositivo di conseguenza mettendone a disposizione alcuni e nasconden done altri Guardando ancora i prototipi mostrati poco sopra ci accorgiamo anche del l uso di buffer per quanto riguarda la read e la write dichiarati come char __user Questo fatto perch i puntatori dello user space non sono di rettamente referenziabili dal kernel infatti referenziare ciecamente un pun tatore dello user space porterebbe ad un evidente problema di sicurezza e oltre a questo la gestione della memoria virtuale dello user space potreb be portare a generare dei page fault cosa che il codice del kernel non ha il permesso di fare Per questo esistono delle apposite funzioni chiamate CAPITOLO 3 STUDIO DI FATTIBILITA 36 copy_to_user e copy_from_user per trasferire in maniera sicura da
53. quella in Figura 5 20 Naturalmente qui la scrittura finale verr effettuata non su un endpoint USB ma sulla porta seriale Infine mostriamo le due sequenze relative all esecuzione di comandi di con trollo che vengano invocati da un interrupt hardware o dal software in ese cuzione sull host La Figura 5 22 mostra il primo caso L oggetto thmx_gadget_proghw responsabile dell hardware programmabile all interno l interrupt handler invocher il kernel thread ausiliare incaricato dell esecu zione del comando di controllo correntemente associato all hardware Infine la Figura 5 16 mostra la sequenza di operazioni per l esecuzione di un comando di controllo invocato dall host Qui la richiesta arriva sull endpoint interrupt adibito alla gestione di tali richieste il quale semplicemente sve glia il thread interno all oggetto thmx_gadget che si occupa dell esecuzione dei comandi di controllo Nel caso in cui il comando di controllo preveda l invio di dati di ritorno questo thread si occuper di chiamare la funzione appropriata dell oggetto thmx_gadget_usb per l invio di tali dati CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 123 i thmx gadget thmx gadget uart H ost setup SEND_MIDI_ OUT thmx_uart_tx_chars uart_tx Figura 5 21 Diagramma della sequenza relavita all invio di messaggi MIDI ad un dispositivo MIDI esterno j ithmx gadget proghw ithmx_gadget aux thread Programmable
54. questo punto lo script legger uno dopo l altro gli attributi e scriver un file human readable leggibile e modificabile dal solo amministratore Per evitare che un utente senza privilegi possa tentare di leggere scrivere direttamente i file del sysfs anche questi verranno creati con privilegi relativi al solo amministratore CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 100 Host System Embedded System User Space Script extract_ config_strings create_ sysfs_files read_ sysfs_files create_user_ config _file Figura 5 10 Diagramma della sequenza relativa all inizializzazione del profilo di configurazione Di seguito viene riportata nel dettaglio la gerarchia che verra creata all in terno del sysfs per rappresentare il profilo di configurazione CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 101 ConfigurationProfile gt poliphony A bool gt numVoices A int gt playingMode A string gt midiOUT A bool gt programmableHW K gt hw x A string gt gt controlCmd K gt cmd x A string gt gt associations K gt as x A string gt Per ogni elemento stato specificato accanto se si tratta di un kobject K e quindi apparir come una directory oppure di un attributo A per cui apparir come un file Inoltre per gli attributi specificato quale sar la ti pologia di dati che conterr Per quanto riguarda le ultime t
55. return 0 Figura 5 9 Funzione di esempio per la creazione di file e directory all interno del sysfs attributi viene effettuata dalle chiamate alle due funzioni kobject_init e kobject_add In quest ultima importante notare che il secondo ar gomento un puntatore al kobject contenuto nel dispositivo USB creato in questo modo stiamo dicendo al kernel di creare una sotto directory della directory relativa al dispositivo Dopo l esecuzione del driver stata creata la directory sys class usb minisnd_snd0 al cui interno troviamo la directory device e all interno di questa la nostra ProvaConfig che contiene il file Attributol Struttura del profilo di configurazione A questo punto possiamo definire il comportamento di inizializzazione del profilo di configurazione In Figura 5 10 presentato un diagramma di se quenza che fornisce un facile modo di visualizzare le sequenze di eventi e verr ampiamente usato in seguito cfr 5 4 con il flusso di azioni per la creazione del file del profilo di configurazione Sostanzialmente verr implementato uno script o una piccola applicazione nello user space Questa verr attivata da un opportuna regola udev col legata alla creazione dell attributo corrispondente all ultimo campo del file di configurazione in questo modo quando l applicazione sar eseguita sa r certa che la rappresentazione del profilo di configurazione all interno del sysfs completata A
56. solo fino a 2 valori binari Ma se prendiamo l intervallo compreso tra 2 e 2 con 0 lt i lt n questo conterr k valori di voltaggio k gt 1 ma verr rappresentato con una sola stringa binaria Non linearit La maggior parte degli ADC vengono detti lineari ovvero tra il valore di voltaggio di input e il valore binario di CAPITOLO 3 STUDIO DI FATTIBILITA 17 output c una relazione lineare Quando questo non avviene c un errore di non linearit che riduce la quantit di valori che pu produrre la conversione Errori di apertura ovvero un incertezza nel campionamento effet tuato quando il segnale variabile nel tempo Qui se il campiona mento non effettuato con una cadenza temporale esatta a causa ad esempio dell utilizzo di clock esterni si possono provocare er rori di accuratezza che possono essere tanto maggiori quanto pi aumenta la frequenza del segnale e la sua ampiezza Nel dominio del progetto qui presentato i primi due parametri risoluzione e frequenza di campionamento sono quelli di maggior interesse in generale infatti nell ambito dei convertitori audio questi vengono catalogati insieme come risoluzione del convertitore 23 Soprattutto per coprire tutto il range delle frequenze udibili teniamo a mente il teorema di Nyquist visto che le frequenza audio vanno dai 20 Hz ai 20 KHz 24 dobbiamo avere a disposizione una frequenza di campionamento di a
57. struct my_device spinlock_t lock struct usb_gadget gadget struct usb_request reg ug config struct usb_ep in_ep out_ep CAPITOLO 3 STUDIO DI FATTIBILITA 69 Qui si nota subito la presenza delle strutture usb_gadget che contiene la rappresentazione dei dispositivi gadget usb_request con le informazioni riguardo le richieste USB che arrivano al dispositivo dall host e usb_ep che rappresenta gli endpoint Come chiaro dunque questo dispositivo defini sce solo un endpoint di input e uno di output Oltre a questa struttura il driver deve definire le stringhe statiche relative alle informazioni di base sul dispositivo vendorId productId ecc e tutti i vari descrittori USB specifici per esso Questi di solito definiti all interno del file include linux usb ch9 h rappresentano le informazioni standard descritte nel capitolo 9 del documento di specifiche dell USB 3 affinch ogni dispositivo USB compliant le adoperi cfr 3 2 3 I principali descrittori sono e device_descriptor contiene informazioni generali sul dispositivo tra cui il numero di configurazioni utilizzate e config_descriptor descrive una configurazione specifica ad esempio specificando il numero di interfacce che contiene e interface_descriptor descrive una interfaccia indice numero di endpoint contenuti ecc e endpoint_descriptor rappresenta un endpoint conservandone tutte le informazioni peculiari come la dire
58. un buon design L approc cio che verr utilizzato quello bottom up dal punto di vista dell utente si partir con lo studiare le possibili interazioni dell utente con il sistema cfr 5 1 dando una prima bozza dei flussi di base che avvengono partendo da queste si analizzer il comportamento del sistema a fronte delle varie intera zioni dando un modello generale degli stati possibili cfr 5 2 dalle diverse prospettive del sistema host e del dispositivo In seguito si dar la descrizio ne strutturale del sistema specificandone i vari oggetti e le interazioni che intercorrono tra di essi cfr 5 3 Infine si dar una descrizione dei princi pali flussi che avvengono all interno del sistema mappandoli sulla struttura fornita cfr 5 4 Per la descrizione di seguito si far un ampio uso di diagrammi UML in modo da fornire rappresentazioni grafiche e maggiormente intuitive del design 5 1 L interazione con l utente use cases Una prima prospettiva utile alla comprensione delle funzionalit del sistema l interazione che l utente pu avere con esso I requisiti precedentemente descritti cfr Capitolo 2 hanno gi dato una lista di quali sono queste in terazioni ma pu essere utile usufruire di un diagramma dei casi d uso per 79 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 80 System i MIDI Application A External MIDI Device ReadCtiCommands ReadConfig Use
59. user space del sistema host al fine di creare un interfaccia con gli utenti o semplicemente delle funzioni batch come quelle descritte nel paragrafo precedente e thmx_init_profile script batch per l inizializzazione del file del pro filo di configurazione a partire dai file del sysfs cfr 5 3 1 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 104 e thmx_check_profile script batch che controlla lo stato di aggiorna mento dei file del profilo di configurazione Per farlo va a leggere la variabile di ambiente THMX_CONFIG generata dall uevent e da questa ricava il nome dell ultimo campo modificato e il suo valore attuale cos da poterlo confrontare con il valore scritto sul file di configurazione per quel campo e thmx_confirm_profile script che pu eseguire soltanto l utente am ministratore e che fa s che un nuovo profilo di configurazione venga impostato Lo script esegue un controllo sulla sintassi del file di confi gurazione e se corretta invia i dati al kernel tramite scritture sui file del sysfs applicando a queste scritture la stringa di prefisso che fa s che non vengano generati vevent e thmx_set_midi_out lt true false gt script eseguibile da un utente qual siasi Imposta la funzionalit di MIDI OUT attraverso lo strumen to Semplicemente effettua una scrittura sul file ConfigurationProfi le midiOUT all interno del sysfs Questo pu provocare l aggiorna mento del file di configurazione tramit
60. verranno ricostruiti quando PURB ritorna Tale terminazione della richiesta gesti ta dalla funzione di callback thmx_read_iso_callback Questa effettua delle importanti operazioni controlla il numero di pacchetti ricevuti e per ognuno copia il contenuto dentro il buffer circolare che verr poi usato per la conversione Voltage To Midi cfr 6 2 5 Inoltre questa funzione effet tua alcuni controlli importanti per la comunicazione in caso di errori gravi nell URB oppure se non vengono ricevuti pacchetti continuativamente per un tempo troppo lungo l esecuzione verr passata nuovamente alla routine principale del thread la quale invier al gadget una richiesta per cercare di effettuare un recovery in caso di errore si bloccher in un attesa di alcuni secondi e riprover a ricevere dati Da parte sua il gadget ricever questa richiesta come un comando di con trollo cfr 6 2 6 e capir che l host non sta ricevendo dati audio Ora se il gadget stesso che non sta pi mandando dati perch l applicazione ALSA nello user space per la cattura dei campioni audio stata bloccata il controllo restituir all host la stringa ISOCH_IN_STOPPED e non effettuer altre operazioni Invece nel caso lui si accorga che attualmente in corso l invio di dati qualcosa non va perch l host dovrebbe riceverli e invece il suo messaggio indica che questa ricezione non avviene In questo caso il recovery implementato semplic
61. 3 92IA9C IGIW BUI9IXI sabessaw Joy BuINEM LNO IGIWPUaS W9ISAS invio di messaggi MIDI a Diagramma degli stati che descrive dispositivi esterni 8 5 Figura CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 97 che si effettuano nell I O per garantire la portabilit del codice del kernel a prescindere dal filesystem e per non introdurre delle politiche all interno del kernel Per evitarlo dunque si utilizzato un approccio diverso Come detto in pre cedenza cfr 3 3 3 il sysfs un importantissimo strumento per il dialogo tra il livello applicativo e il kernel Ogni dispositivo viene rappresentato con una directory all interno di tale filesystem virtuale contenente tutti gli attributi sotto forma di file che lo descrivono Tali attributi per i dispositivi USB descrivono solitamente le caratteristiche strutturali del dispositivo come il numero di endpoint o di interfacce chiaro comunque che ogni device driver ha la potenzialit di pubblicare tutte le informazioni che desidera In particolare implementare una gerarchia di directory e file all interno del sy sfs abbastanza semplice semplificando ogni kobject viene rappresentato come una directory e ogni attributo come un file all interno della directory per cui possibile pubblicare le informazioni in modo gerarchico a piacere con questi strumenti Per il test di quanto affermato stata scritta una pic cola fu
62. 4100 1 msbits 16 buffer size 22016 period size 512 period time 11609 tstamp mode NONE period step 1 avail_min 512 period event 0 start_threshold 1 stop threshold 22016 silence threshold 0 silence size 0 boundary 1442840576 appl ptr 0 hw_ptr 0 47 950469 thmx gadget BULK IN DBG COMMAND received 47 955596 thmx gadget exec ctl bulkindbg sending 16 chars debug string BLK DEBUG STRINR iL 47 967163 bulk buffer BLK DEBUG STRING I for help 115200 8N1 NOR Minicom 2 3 rc VT102 offline B E daniele daniel N JACK Audio con Qsynth A fluids X Connections JA BOOS Figura 7 6 Esecuzione del comando di controllo BULK_IN_DBG sul gadget In maniera simile stato verificato il funzionamento di tutti gli altri comandi di controllo Particolarmente interessante il comando di impostazione del CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 157 G Applicazioni Risorse Sistema e Q AA ESL mar 26 lug 15 34 Ka e Qsynth1 prus daniele danieledevel laptop Scrivania S Audio MIDI ALSA Modifica Visualizza Terminale Schede Aiutc Readable Clients Output Port v Writable Clients Input Ports w ES 14 Midi Through 14 Midi Through iele danieledevel lapt 3 daniele danieledeve 16 rdo ES 20 Audiophile USB tm check profile Othmx_snd_midi 130 FLUID Synth 22257 x check profile c
63. 9 10 P Horowitz W HiLL The Art of Electronics Cambridge University Press 1989 AA VV Universal Serial Bus Specification rev 2 0 2000 Ivi cap 9 pp 239 274 J CORBET A RUBINI G KROAH HARTMAN Linux Device Drivers third edition O Reilly ed 2005 D P BOVET M CESATI Understanding the Linux Kernel third edition O Reilly ed 2005 T IWAI Writing an ALSA Driver documento open source scarica bile da http www kernel org pub linux kernel people tiwai docs writing an alsa driver pdf 2005 D GERHARD Pitch Extraction and Fundamental Frequency History and Current Techniques technical report Dept of Computer Science University of Regina 2003 A DE CHEVEIGN H KAWAHARA Yin a fundamental frequency estimator for speech and music Journal of the Acoustical Society of America 111 4 2002 M NOLL Cepstrum pitch determination The Journal of the Acoustical Society of America 41 2 293 309 1967 M NOLL Pitch determination of human speech by the harmonic pro duct spectrum the harmonic sum spectrum and a maximum likelihood estimate Proceedings of the Symposium on Computer Processing ing Communications 779 97 1969 162 BIBLIOGRAFIA 163 11 F BAcH M JORDAN Discriminative training of Hidden Markov Models for multiple pitch tracking Proceedings of the International Conference on Acoustics Speech and Signal Processing 2005 12 E BARNARD R A COLE M P VEA F A
64. A CD Figura 7 4 Esecuzione del comando thmx_read_profile La formattazione rispetta quella con cui effettivamente salvato il file del pro filo di configurazione Inoltre se utente vuole avere un promemoria soltanto delle stringhe da utilizzare per inviare comandi di controllo pu utilizzare il CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 156 comando thmx_read_ctl_commands L output una semplice stampa di tali stringhe Figura 7 5 ar tp Je ee eps eee eee cee ve daniele danieledevel laptop Scrivania thmx_read ctl commands THEREMINUX AVAILABLE COMMANDS command 0 ISOINZERO command 1 ISOINMULT command 2 BLKDBGSTR command 3 ISODBGSTR Figura 7 5 Esecuzione del comando thmx_read_ctl_commands Successivamente per eseguire effettivamente tali comandi di controllo pos sibile usare il comando thmx_exec_ctl_command In Figura 7 6 viene mostra to il messaggio stampato sul gadget alla ricezione del comando BULK_IN_DBG cfr 5 3 4 i Applicazioni Risorse Sistema Q KA PASY do mar 26 lug 23 56 x daniele danieledevel laptop Scrivania Implementazione thereminux thmx src gadget File Modifica Visualizza Terminale Schede Aiuto daniele danieled 9 daniele danieled 9 daniele danieled daniele danieled X daniele danieled x stream CAPTURE access MMAP_INTERLEAVED T format S16 LE subformat STD channels 2 rate 44100 exact rate 44100 4
65. CDER Figura 3 1 Schema di un Flash ADC Fonte 25 ANALOG INPUT VN DAC DIGITAL OUTPUT SUCCESSIVE APPROXIMATION aca gt REGISTER AND CONTROL Figura 3 2 Schema di un ADC ad approssimazioni successive Fonte 25 CAPITOLO 3 STUDIO DI FATTIBILITA 19 Converter interno I confronti vengono effettuati a partire dal voltaggio di riferimento che rappresenta il massimo voltaggio che il segnale pu raggiun gere Ad esempio 22 supponiamo che il voltaggio di input sia di 60 V e che il voltaggio di riferimento sia 100 V Per prima cosa verr confrontato 60 V con 50 V che la met del voltaggio di riferimento e corrisponde alla stringa binaria 100 0 Il comparatore produrr il valore 1 visto che 60 V gt 50 V e questo sar memorizzato come MSB Most Significant Bit Nella seconda iterazione del processo 60 V confrontato con 75 V il valore mediano tra 50 V e 100 V in binario 1100 0 Poich 60 V lt 75 V il comparatore produrr uno 0 e quindi il secondo bit del risultato verr posto a 0 Al terzo ciclo quindi il voltaggio di input confrontato con 62 5 V il valore mediano tra 50 V e 75 V in binario 10100 0 e anche qui verr memorizzato uno 0 E cos via In pratica si esegue una ricerca binaria sul valore di voltaggio di input per trovare la codifica che approssima meglio Naturalmente per ogni codifica c bisogno di effettuare n passi con n uguale al numero di
66. IDI a dispositivi esterni In questo caso Figura 5 8 un ulteriore end user entra a far parte del dia gramma ovvero il dispositivo MIDI esterno in attesa di messaggi Questo scenario si presenta nel momento in cui un applicazione MIDI nello user space invia dei messaggi MIDI attraverso la porta di MIDI OUT dello strumento si ricorda che perch tale porta sia istanziata presso ALSA ne cessario che il profilo di configurazione sia stato impostato con il MIDI OUT attivato Il sistema embedded per aumentare l efficienza e non ripetere i controlli semplicemente si occupa di inoltrare il messaggio sulla sua porta di MIDI OUT 5 3 Struttura del sistema Dopo aver dato l analisi ad alto livello delle interazioni con gli end user e dei flussi del sistema in questa sezione verranno forniti i dettagli strutturali ovvero le strategie architetturali con cui le varie parti del software saranno divise in moduli non solo nel senso di moduli del kernel linux ma anche in quello di unit di suddivisione delle funzionalit e le relazioni che tali moduli avranno tra loro Come dovrebbe essere chiaro a questo punto della trattazione il sistema host dovr fornire sia dei moduli del kernel che delle applicazioni nello user space che forniscono un interfaccia all interazione di retta con l utente quando questa richiesta ad esempio per riconfigurare il profilo di configurazione o impostare la funzionalit di MIDI OUT Ne
67. IONE DEL SISTEMA SOFTWARE oe vSiv dmas 9 4HOJd Bijuo5 dnjas ejeg sqsanbal y 104 BUINEM suayawesed jeiaquy Bumas uo UNI wajshs pappaquy asn dm s dIAap au 103 uem uonezyeniu waISAS Diagramma degli stati che descrive l inizializzazione del sistema Figura 5 4 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 91 Suonare note MIDI attraverso lo strumento La Figura 5 5 mostra lo scenario in cui un utente inizia a suonare con lo strumento hardware Come si vede in questo scenario sono presenti tre attori il sistema host il sistema embedded e un applicazione MIDI che gira nello user space del sistema host Tutti e tre sono in esecuzione parallela ma il dispositivo ovviamente che inizia la comunicazione quando il segnale comincia ad essere convertito in digitale Il sistema host a questo punto bufferizza i campioni in ingresso e dopo la conversione Voltage to MIDI invia questi messaggi all applicazione in ascolto Reimpostare il profilo di configurazione Altra operazione importante quella di reimpostare il profilo di configurazio ne infatti questa operazione pu coinvolgere anche una comunicazione con il sistema embedded nel caso in cui nel nuovo profilo di configurazione sono state effettuate delle modifiche ai dati mantenuti sul dispositivo ad esempio le associazioni tra elementi hardware programmabili e comandi di contr
68. MA 132 Successivamente la compilazione tramite Makefile dovr avvenire specifican do l architettura di riferimento e il cross compiler utilizzato con il comando seguente si assume che si stia utilizzando la toolchain CodeSourcery G Lite 60 make ARCH arm CROSS_COMPILE arm none linux gnueabi Chiaramente queste indicazioni sono state inserite in un opportuno Makefile per la compilazione dei sorgenti del modulo Fatto questo i moduli del kernel vanno inseriti nella directory lib modules lt kernel_version gt Affinch un modulo venga caricato all av vio necessario inserire un file contenente il nome del modulo sotto la directory etc modutils Ad esempio per caricare il modulo hello prece dentemente compilato ed inserito sotto lib modules lt kernel_ version gt stato sufficiente creare il file etc modutils hello che contiene appunto la stringa hello per poi richiamare il comando update_modules Riavviando il sistema il modulo viene caricato in fase di avvio Quanto descritto stato incluso in un apposito script che viene posto nella home del sistema embedded e permette al primo avvio dopo il setup del la card SD di effettuare tutte le impostazioni necessarie all esecuzione del modulo thmx_gadget 6 2 I device driver sviluppati L implementazione del Thereminux ha richiesto l utilizzo di alcuni diversi sotto sistemi e interfacce presenti nel kernel Linux nell ambito dei device driver
69. OLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 86 Nome Caso d uso ConfirmConfig ID CU 8 Attori Privileged user Descrizione Permette ad un utente privilegiato di reimpostare il profilo di configurazione Precondizioni Il sistema deve essere inizializzato e attivo dispositivo hardware acceso e collegato all host moduli del kernel caricati e pronti Flusso principale 1 L utente Privileged user esegue il comando per la reimpostazione del profilo di configurazione 2 il sistema host verifica che il profilo di configura zione sia ben formato e corretto 3 Il sistema host reimposta il profilo di configurazio ne Flussi alternativi Il sistema host trova un errore nel profilo di configurazio ne Verr inviata una segnalazione di errore all utente specificando l errore riscontrato Postcondizioni Il sistema host ha reimpostato il profilo di configurazio ne Nome Caso d uso SendMIDI OUT ID CU 9 Attori MIDI Application External MIDI Device Descrizione Permette ad un applicazione nello user space di inviare messaggi MIDI attraverso il dispositivo hardware Precondizioni Il sistema deve essere inizializzato e attivo dispositivo hardware acceso e collegato all host moduli del kernel caricati e pronti Flusso principale 1 Un applicazione invia un messaggio MIDI per la porta MIDI OUT dello strumento 2 il sistema host invia il messaggio al
70. Progetto di Sistemi Operativi 3 Daniele Capuano a a 2010 2011 Indice 1 Descrizione generale del progetto 1 1 Il Thereminuz descrizione generale 1 1 1 Configurazione software 1 1 2 Gestione dell esecuzione 1 1 3 Gestione della sicurezza 4 1 1 4 Ambiente di esecuzione LL 2 Requisiti di progetto 3 Studio di fattibilit 3 1 La conversione Analogico Digitale dll Rab BIO lip 3 1 2 ADC ad approssimazioni successive 3 2 Lo Universal Serial Bus rev 2 0 be ee ee wee es dl Sp ciiche cliniche oi a 3 2 2 Modello di Data Flow e protocollo di comunicazione 3 2 3 Definizione di un dispositivo USB 3 3 I Device Driver per Linux e il kernel 2 6 3 3 1 I moduli del kernel Linux gii 3 3 2 Scrivere device driver per Linux Bae DLE ee RRR REED REE ES 3 3 4 udev e la gestione del hotplug 3 3 5 I device driver e il sottosistema USB 3 4 Lo standard MIDI iii eR Re Ra 3 4 1 Il protocollo software e i messaggi MIDI 3 5 La rappresentazione dei device MIDI in Linux il device driver di test SII ri RI A aL 3 5 1 Dettagli implementativi del driver minisnd 3 5 2 Esecuzione del driver e risultati 3 6 La conversione Voltage t0 MIDI 0 04004 3 6 1 Algoritmi time domain INDICE 2 3 6 2 Algoritmi frequency dom
71. _snd_rawmidi_output_drain si occupa si svuotare la coda dei messaggi MIDI di output ancora da inviare al dispositivo prima della reale disconnessione presso ALSA In realt nel caso del Thereminux si visto che questa funzione serve a ben poco visto che in fase di disconnessione il gadget sparito e quindi non pu ricevere altri dati Creazione ed eliminazione dinamica del MIDI out Una volta che il dispositivo MIDI stato creato presso ALSA PAPI AL SA non permette di inserire o eliminare dinamicamente le sue parti che in fase di esecuzione vengono registrate e mantenute fino alla disconnes sione Per questo l implementazione della gestione dinamica del MIDI out ha dovuto eseguire prima una disconnessione dell intera sound card ALSA per poi ricreare un nuovo dispositivo che per mantiene l indice incremen tale di quello vecchio Per la creazione viene usata la stessa funzione thmx_create_snd_device che viene richiamata in fase di inizializza zione Anche qui per occorre prestare attenzione alle risorse condivise infatti il thmx_aux_thread che viene risvegliato dal thread di ricezione di dati audio interno all oggetto thmx_usb richiama la conversione Voltage To MIDI dei dati ricevuti e poi chiama la thmx_snd_rawmidi_receive che inoltra questi dati al livello applicativo usando la funzione standard di ALSA snd_rawmidi_receive Dunque si collega al dispositivo MIDI di input per le sue operazioni e prim
72. a directory etc udev rules d Queste regole permettono di individuare le ca ratteristiche dell evento avvenuto ed eseguire le operazioni desiderate come aggiungere un nodo sotto dev eseguire script caricare moduli nel kernel ecc Se ad esempio si volesse eseguire uno script dopo il collegamento di un dispositivo USB una regola potrebbe essere la seguente SUBSYSTEM usb ACTION add ATTRS serial L72010011070626380 RUN usr sbin a_script Questa regola viene portata a termine quando il demone di udev riceve un evento in cui stato aggiunto ACTION add un dispositivo del sottosiste ma USB SUBSYSTEM usb di cui viene fatto il matching con il numero seriale che presentato come attributo nel sysfs Se l evento si riferisce al dispositivo giusto viene eseguito un certo script Per quanto riguarda il sottosistema USB in particolare la registrazione di un nuovo dispositivo da parte del core USB viene accompagnata dall invio di appositi wevent per pubblicare come variabili di ambiente i dati relativi al dispositivo cfr file drivers usb core message c nel sorgente del kernel if add_uevent_var env INTERFACE d d d alt gt desc bInterfaceClass alt gt desc bInterfaceSubClass alt gt desc bInterfaceProtocol return ENOMEM if add_uevent_var env MODALIAS usb v 04Xph04XdK04Xdc402XdscK402Xdpk02XicKk02Xisc hO2XipKo2X le16_to_cpu usb_dev gt descriptor idVendor le16_to_
73. a 5 11 Oltre a questo interessante notare la presenza di una relazione tra thmx_usb e l oggetto thmx_aux_thread Quest ultimo come verr spiegato tra poco implementa un kernel thread per la gestione del l acquisizione di campioni audio e la loro conversione in MIDI Tale thread rimane bloccato per finch non ci sono dati in ingresso e viene avvertito della presenza di questi dati in ingresso dal modulo thmx_usb In altre parole quando viene completata una comunica zione USB e risultano pronti dei dati in ingresso all host la callback eseguita al termine della transazione USB non fa altro che salvare il contenuto del buffer di input all interno della struttura thmx e sveglia re il thread passandogli la struttura I dettagli di come questo flusso avviene verranno dati nel Paragrafo 5 4 e nel Capitolo 6 e thmx_aux_thread esegue come detto nel punto precedente un thread di utilit che si occupa di invocare la conversione Voltage To Midi pas sandogli il buffer che stato aggiornato da thmx_usb e invare il risultato al livello applicativo utilizzando le funzioni ALSA messe a disposizione in thmx_snd si noti la relazione calls tra il thmx_aux_thread e thmx_snd e thmx_config gestisce il profilo di configurazione secondo quanto de scritto in precedenza cfr 5 3 1 Quindi si occupa di creare i file del sysfs e implementare le funzioni per la lettura e la scrittura delle infor mazioni su tali file nonch c
74. a caratteri per cui necessario mantenere la distinzione e interfacce di rete dispositivi progettati per scambiare pacchetti di dati con altri host Questi non vengono rappresentati all interno del file system e la comunicazione con essi risulta completamente differente rispetto ai dispositivi a caratteri o a blocchi Oltre a questa categorizzazione esistono comunque dei dispositivi che neces sitano di una maggiore stratificazione logica per implementarne il protocollo e dunque sono in qualche modo ortogonali alle definizioni date questo il caso dei dispositivi SCSI o USB questi ultimi verranno visti nel dettaglio pi avanti cfr 3 3 5 Per essi esistono nel kernel dei sotto sistemi ad hoc che gestiscono il protocollo a basso livello per cui si parla in generale di dispositivo SCSI o dispositivo USB ma questi poi possono implementare indipendentemente dispositivi a caratteri a blocchi o interfacce di rete 3 3 1 I moduli del kernel Linux Come detto nella sezione precedente cfr 3 3 i moduli del kernel riescono a mantenere un efficienza del tutto paragonabile al codice collegato stati camente evitando lo scambio di messaggi Questo meccanismo possibile grazie al concetto di simbolo dove ogni simbolo rappresenta una funzione o una variabile che viene resa pubblica all interno del kernel Qui tre sezio ni all interno del codice del kernel sono usate per mantenere le informazioni sui simb
75. a come la seguente daniele usr bin jackd nice 10 rtprio 95 memlock 250000 CAPITOLO 3 STUDIO DI FATTIBILITA 74 In questo modo si specifica che un utente daniele pu eseguire un pro gramma usr bin jackd con opportuni valori di priorit nice nice 10 e real time rtprio 95 Infine si specifica che questo programma potr ot tenere dei lock su fino a 250 MB di memoria memlock 250000 Dopo aver eseguito questa configurazione su tutti i programmi desiderati sar possi bile avviarli con le priorit real time da utente senza privilegi tramite il comando set_rlimits lt nome programma gt 3 7 3 Implementazioni per la pitch detection Come trattato precedentemente cfr 3 6 al fine di implementare la con versione Voltage to MIDI stato necessario utilizzare un algoritmo di pitch detection Tra i progetti open source che forniscono implementazioni gi fatte di questa funzionalit salta all occhio aubio 48 Questo implemen ta una libreria nello user space per l annotazione di informazioni relative ai segnali audio Tra le funzionalit che implementa ci sono filtri digitali ri conoscimento di tempo e ovviamente la pitch detection Ci sono diversi metodi implementati per quest ultima ma anche in base alle valutazioni sul l efficienza di tali metodi quello pi interessante da tenere in considerazione lo YIN Il codice del metodo racchiuso in un unica funzione cfr file aubio_ src pitchyin c a
76. a dei problemi nel caso si usino lock read write in cui ci sono molti lettori che detengono un lock e un solo scrittore In questo caso bisognerebbe aumentare i privilegi e poi ripristinarli per numerosi processi cosa piuttosto inefficente Per questo la politica applicata con la patch che un solo lettore alla volta possa prendere un certo lock cosa che riduce la scalabilit ma mantiene un certo grado di efficienza e gli interrupt vengono convertiti in normali thread del kernel dunque diventano anch essi preemptible L utilizzo delle classiche funzioni di disabilitazione degli interrupt come la spin_lock_irqsave non di sabilitano pi gli interrupt hardware L unico caso in cui viene preserva CAPITOLO 3 STUDIO DI FATTIBILITA 73 to il contesto di esecuzione interrupt quando viene specificato il flag SA_NODELAY alla creazione dell interrupt in questo caso necessario utilizzare il comportamento di locking tradizionale ad esempio trami te la raw_spinlock_t Comunque anche l uso del flag SA_NODELAY viene utilizzato soltanto da parti del kernel molto specifiche e critiche dunque non deve essere considerato una cosa comune e stata utilizzata una nuova infrastruttura per la gestione dei timer in modo da garantire una maggiore risoluzione in caso di timeout o altri eventi con richieste stringenti di tempo Installazione e utilizzo della patch L utilizzo della patch abbastanza semplice In pratica si richiede
77. a di farlo acquisisce un lock specifico di questa risorsa e che appunto deve essere preso anche in fase di riconfigurazione del MIDI out In questo modo quando tale riconfigurazione sta avvenendo si sicuri che il thread che inoltra i messaggi MIDI al livello applicativo non pu accedere al dispositivo di MIDI input In particolare non viene consentito a tale thread di rimanere bloccato in attesa che la risorsa si liberi questo perch in fase di acquisizione continua di dati audio rimanere bloccati su un buffer inevitabilmente porterebbe ad inviare dati obsoleti rispetto a quelli at tualmente ricevuti In questo senso si preferito optare per la possibilit di CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 139 perdere qualche pacchetto di dati ma mantenere una risposta il pi possibile vicina a ci che l utente sta suonando in tempo reale 6 2 4 La gestione di ALSA lato gadget e l interfaccia a caratteri Dal lato del gadget come gi detto cfr 5 3 6 si preferito non im plementare nuovamente un driver gi esistente che semplicemente rice va dati dal convertitore audio della Beagle Board ma si invece utiliz zato il driver ALSA gi esistente e si modificata l utility aplay dispo nibile insieme alle alsa utils 32 per far s che essa una volta cattura ti i dati audio li inoltri sul nodo dev thma_ gadget presente nel file sy stem Il programma thmx_gadget_alsa_capture presente nella directory
78. a nota dell ordine di centesi mi di nota frazioni di mezzo tono da0xE0 a OxEF 2 I due byte vengo no fusi insieme per formare un unica pa rola di 14 bit che de finisce lo spostamento di frequenza della no ta Sia del primo che del secondo byte ven gono considerati i bit da 0 a 6 ponendo i bit da 0 a 6 del primo by te come bit 0 6 della stringa e i bit 0 6 del secondo byte come bit 7 13 della stringa Tabella 3 1 Messaggi MIDI relativi ad un numero di canale CAPITOLO 3 STUDIO DI FATTIBILITA 48 Messaggi MIDI comuni a tutti i canali Nome Descrizione Valore esade Byte di dati cimale System Messaggi usati per in un primo status Qualsiasi numero di Exclusive viare ad un dispositi byte deve esse byte compresi tra i SysEx vo una gran quantita re OxF0O i byte due status byte del di dati oppure dei da di dati e l ultimo messaggio Di solito ti specifici per un certo byte deve essere il secondo byte speci produttore 0xF7 fica il Manufacturer s ID MTC Messaggio inviato da OxF1 1 il valore di timeco Quarter un device master per de 0 127 Frame sincronizzare tempo Message ralmente uno slave Song Posi Messaggio inviato da 0xF2 2 come nel caso del tion Poin un device master per Pitch Wheel questi ter far s che lo slave si po vengono integrati in sizioni ad un determi un unica stringa da 14 nato momento dell e bit
79. a stringa di debug sull endpoint isochronous tutte le altre richieste RA ricevono la risposta dal gadget sull endpoint di input di tipo Bulk Di seguito forniamo la lista dei comandi eseguiti da ognuna delle due funzioni descritte e comandi per thmx_usb_send_ctl_cmd ISO_IN_ZERO azzeramento dei campioni audio di input ISO_IN_MULT moltiplicazione dei campioni audio di input per una costante SET_MIDI impostazione del MIDI out dello strumento SET_ASSOCIATION impostazione di un associazione tra hardware programmabile e comando di controllo e comandi per thmx_usb_send_ra_req ISO_IN_DBG invio da parte del gadget di una stringa di debug sull endpoint isochronous BULK_IN_DBG invio da parte del gadget di una stringa di debug sull endpoint bulk CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 145 CHECK_ISO_IN_STATUS controllo da parte del gadget dello stato di invio dei campioni audio con conseguente invio di una stringa di rapporto sull endpoint bulk cfr 6 2 2 Tra i comandi associati alla prima funzione in realt gli ultimi due SET_MIDI e SET_ASSOCIATION non possono essere considerati veri e propri comandi di controllo in quanto non possono essere associati ad un elemento hardware programmabile In ogni caso sono stati comunque inseriti perch il tipo di comunicazione che richiedono del tutto identica a quella usata per i coman di di controllo Sul gadget i comandi di cont
80. accia definita all interno del sorgente del kernel in include linux usb gadget h non viene solitamente trattata nel normale svi luppo di device driver USB in quanto nella maggior parte dei casi questi vengono eseguiti sul sistema host quindi viene delegata la gestione del pro tocollo vero e proprio al core USB del kernel Nel caso di sistemi che vengono eseguiti sulla periferica USB invece necessario poter dare una definizione di tutti i parametri necessari alla definizione del device USB cfr 3 2 3 come gli endpoint le interfacce i descrittori ecc Oltre al sorgente dell interfaccia all interno del kernel cfr drivers usb gadget sono presenti numerosi esempi di driver gadget che im plementano svariate funzionalit Molti di questi come il semplice gad get_ zero utilizzano il framework composite cfr include linux usb composite h che pensato in particolare per i dispositivi USB composite cfr 3 2 2 Per la nostra applicazione comunque baste r una sola configurazione e una sola interfaccia che utilizza diversi end point per cui ci si basati su driver che non utilizzato tale framework come file_ storage cfr drivers usb gadget file_ storage c o gmidi cfr dri vers usb gadget gmidi c Sostanzialmente per la scrittura di tali driver si procede come segue co me molto spesso avviene nei device driver viene mantenuta una struttura generale di descrizione di tutte le caratteristiche del dispositivo
81. ain 64 3 6 3 Metodi statisti 64 3442 ceser e248 Be EG 65 3 7 Tecnologie esistenti appropriate per il sistema 66 3 7 1 La scheda Beagle Board e API USB Gadget del kernel LE pria e 66 3 7 2 Il kernel realtime 70 3 7 3 Implementazioni per la pitch detection 74 4 Cenni sulla progettazione del sistema hardware 77 a Diapammaa blocchi iii EEE TT 5 Progettazione del sistema software 79 5 1 L interazione con l utente use cases 79 5 1 1 Specifiche dei casi d uso ina 81 5 2 Analisi tramite macchine a stati 87 5 2 1 Dettagli sui principali scenari 89 5 3 Struttura del sistema LLLLk es 95 5 3 1 Il profilo di configurazione iii 95 5 3 2 Script e applicazioni in user space 103 5 3 3 Endpoint presenti sul dispositivo 106 5 3 4 Comandi ioctl implementati 106 5 3 5 Regole udev 0 02 0002 eee eee 106 5 3 6 Il diagramma dei moduli 107 5 4 Analisi delle sequenze cc ii a we OS 113 6 Scelte di implementazione del sistema 125 6 1 Ambiente di sviluppo ed esecuzione 125 6 1 1 Ambiente lato host iii 126 6 1 2 Ambiente lato gadget ciccia paia pia 128 6 2 I device driver sviluppati 2c ei ee dete be eee ee as 132 6 2 1 D avvio del sistema 2 ces be bee Ee EERE Hw ES 133 G22 Lacomunicazione USB 2 44 42 2544 824 oe oS 133 6 2 3 La gestione di ALSA lato host 136 6 2 4 La gestione di ALSA lato
82. al si proceduto in maniera pressoch inversa partendo dal nome della macro che veniva usata andando a trovare a quale registro si riferiva e quali erano i bit che scriveva cos da capirne il comportamento Ad esempio nel codice si scrive nel registro UART_LCR Line Control Regi ster il valore UART_LCR_DLAB LCR Divisor Latch Access Bit Sul file di header lt linux serial_reg h gt si trova la macro UART_LCR_DLAB 0x80 In binario questa corrisponde a 10000000 Sul manuale tecnico 15 si va a cercare il LCR e si vede nella specifica del bitwise che scrivere 0x1 sul bit 7 la numerazione parte da 0 significa accedere al bit DIV_EN e impostare il Divisor Latch Enable ovvero scegliere l operational mode del processore 15 In questo modo stato possibile sfrondare molte delle impostazioni che non servivano alla comunicazione di MIDI out e specificare quelle necessarie Tra CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 148 queste stato necessario impostare il Baud Rate della comunicazione Per programmarlo dinamicamente sul processore OMAP come si legge in 15 necessario specificare un divisore che verr applicato al clock della UART cos da ottenere la velocit desiderata Nel paragrafo 17 1 1 del manuale tec nico 15 si legge che considerando che il clock funzionale della UART a 48 MHz e specificando un oversampling 16 sul clock di base la formula per calcolare il baud rate da programmare Baud rate
83. ale unit hardware usando la macro cpu_has_fpu definita nel file include asm cpufeature h pena l impossibilit per il modulo di essere caricato In ogni caso l ineffi cienza dell esecuzione di istruzioni floating point nel kernel sta nel fatto che la FPU un modulo hardware separato dalla ALU della cpu per cui neces sario salvare e ripristinare il contesto dei registri della FPU ad ogni context switch Questa grave inefficienza pu essere risparmiata preservando l esecu zione tramite le istruzioni kernel_fpu_begin e kernel_fpu_end esse infatti permettono al thread corrente del kernel di dichiarare esplicitamente che ha la necessit di utilizzare la FPU per cui c bisogno di effettuare il salvataggio e ripristino del contesto Quando tali funzioni non sono inserite questa dispendiosa operazione non viene fatta Capitolo 4 Cenni sulla progettazione del sistema hardware Dopo aver trattato nel Capitolo 3 lo studio delle questioni maggiormente critiche del sistema elaborandone le varie possibilit e definendo soluzioni ritenute appropriate in questo capitolo e nel seguente cfr Capitolo 5 verr descritto il sistema vero e proprio Per prima cosa in questo capitolo verr data la descrizione del sistema hardware ovvero la composizione degli stru menti hardware messi a disposizione dalla Beagle Board tramite uno schema a blocchi cfr 4 1 4 1 Diagramma a blocchi In Figura 4 1 viene mostrato il diagra
84. almente in qualsiasi altro momento In ogni caso nella sua funzione di __init il driver deve regi strare le proprie informazioni pi importanti nome del driver tabella degli identificatori puntatori alle funzioni probe e disconnect tramite la funzione usb_register Fatto questo quando il dispositivo viene colle gato e il core USB identifica il device driver come adatto a gestirlo viene richiamata la funzione probe del driver stesso In questa funzione il driver estrae dall interfaccia USB che gli viene fornita le informazioni sugli endpoint specifici per effettuare la comunicazione con il dispositivo per poi richiamare la usb_register_dev con cui si registra la struttura file_operations per questo device driver e si ottiene un Minor Number Infine trattiamo la questione di come la comunicazione effettiva tra device driver e dispositivo USB avviene Tale comunicazione effettuata tramite i cosiddetti USB Request Block URB Un URB permette una comunica zione asincrona tra un device driver e un determinato endpoint all interno del dispositivo e viene rappresentata come una struct urb Un URB ha il seguente ciclo di vita e viene allocato tramite la funzione usb_alloc_urb e viene preparato per il suo utilizzo vero e proprio inserendo nella strut tura urb tutti i dati che si riferiscono a quel trasferimento Per questo esistono delle funzioni helper per i trasferimenti di tipo control bulk o interrupt rispettivamen
85. alogico vengono mostrati con la priorit MayHave Requisiti hardware ID Descrizione Tipo Priorit RHW_F Il sistema dovr essere costruito in prima istanza come un Theremin analogico Funzionale MayHave RHW_F Il sistema dovr convertire il se gnale analogico prodotto in una stringa binaria tramite un modulo A D Funzionale MustHave RHW_F Il sistema hardware dovr comuni care con il pc tramite interfaccia standard USB Funzionale MustHave RHW_F Lo strumento potr disporre di un collegamento di MIDI OUT per il controllo di altri strumenti MIDI compliant Funzionale ShouldHave RHW_F Lo strumento potr disporre di elementi hardware programmabili Funzionale ShouldHave RHW_F Lo strumento dovr garantire i meccanismi hardware per il funzio namento in plug and play tramite hotplug Funzionale ShouldHave RHW_F Lo strumento dovr disporre di un apposito microcontroller per la ge stione delle funzionalit program mabili in hardware e controllabili da software Funzionale MustHave CAPITOLO 2 REQUISITI DI PROGETTO 12 Requisiti software ID Descrizione Tipo Priorit RSW_F Lo strumento dovr garantire i meccanismi software per il funzio namento in plug and play tramite hotplug Funzionale MustHave RSW_F Il sistema attraverso il meccani smo plug and p
86. argomento della richiesta e inviarlo all host nella risposta La struttura di ogni richiesta sempre come quella mostrata in Figura 3 5 e quindi gli attributi vengono inviati utilizzando i campi wValue e o wInder CAPITOLO 3 STUDIO DI FATTIBILITA 26 00000000B CLEAR_FEATURE Feature Zero Zero 00000001B Selector Interface 00000010B Endpoint 10000000B GET_CONFIGURATION Zero ee Configuration Value 10000000B GET_DESCRIPTOR Descriptor Zero or Descriptor Descriptor Type and Language Length Descriptor ID Index 10000001B GET_INTERFACE Interface 10000000B GET_STATUS Zero Two Device 10000001B Interface Interface or 10000010B Endpoint Endpoint Status Alternate Interface 00000000B SET_ADDRESS Device Zero Zero Address 00000000B SET_CONFIGURATION Configuration ee ee ae Value 00000000B SET_DESCRIPTOR Descriptor Zero or Descriptor Descriptor Type and Language Length Descriptor ID Index 00000000B SET_FEATURE Feature Zero Zero 00000001B Selector Interface 00000010B Endpoint 00000001B SET_INTERFACE Alternate Interface Zero Setting Figura 3 6 Elenco delle richieste standard USB Fonte 3 CAPITOLO 3 STUDIO DI FATTIBILITA 27 3 3 I Device Driver per Linux e il kernel 2 6 Consideriamo ora lo studio degli aspetti relativi al kernel Linux Il mate riale presentato in questa sezione si deve principalmente alla consultazione di 4 e 5 La trattazione inoltre non sar rigorosa da un punto di vista dell imp
87. ati gli aspetti relativi alla gestione del protocollo e dei messaggi MIDI cfr requisito RSW_F 4 ma non il livello di descrizione hardware 3 4 1 Il protocollo software e i messaggi MIDI Il protocollo MIDI si basa lato software sullo scambio di messaggi codificati in stringhe di 8 bit 30 Ogni messaggio composto da uno o pi byte Il primo chiamato Status Byte identificato dal MSB posto a 1 mentre tutti gli altri byte hanno questo bit posto a 0 Per la programmazione in CAPITOLO 3 STUDIO DI FATTIBILITA 44 C ricordiamo che questi numeri si esprimono in esadecimale per cui vale la seguente corrispondenza 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111 NTMHoVAWPOAN DAA PWNHR OO I Dunque un byte si pu esprimere con l uso di due numeri esadecimali e pos siamo dedurre che lo Status Byte pu andare da 0x80 a OxFF da notare che PMSB sempre posto a 1 mentre i successivi eventuali byte del messag gio hanno un range che va da 0x00 a 0x7F MSB sempre posto a 0 I bit dello Status Byte di cui abbiamo trattato soltanto il significato del MSB possono essere divisi in due gruppi da quattro bit ciascuno Il primo grup po che contiene il MSB e quindi pu andare da 0x8 a OxF specifica il tipo del messaggio mentre i rimanenti quattro bit specificano il canale sul quale questo messaggio viene inviato Infatti il MIDI pu inoltrare messaggi
88. azione per il debugging hardware so no stati incontrati problemi nello sviluppo hardware e a causa di ci si preferito posticipare l implementazione di tali dispositivi hardware descritti nei documenti precedenti ad un momento futuro concentrando l attenzione sull intero sistema software Cos il Theremin analogico vero e proprio in hardware in questa fase stato sostituito con un semplice microfono audio collegato al convertitore messo a disposizione dalla Beagle Board In questo modo stato comunque possibile mettere a punto e testare l intero progetto senza risentire dell assenza di tale hardware 1 1 Il Thereminuz descrizione generale Come detto il sistema hardware interamente fornito dalla scheda Beagle Board di cui verranno forniti alcuni dettagli pi avanti cfr 3 7 Il sistema software che accompagna lo strumento hardware rappresenta un interprete di segnali di voltaggio che arrivano da uno strumento analogico elettronico o elettrificato generico Da questo punto di vista l idea stata di produrre un modulo software la cui funzione principale la conversione voltage to MIDI del segnale di ingresso dallo strumento ma che mantiene una descrizione astratta della configurazione dell hardware collegato via USB in modo da poter essere riconfigurato per lavorare anche con strumenti hardware diversi Ricordiamo che con l espressione voltage to MIDI si intende qui la capacit data una stringa binaria
89. azioni importanti che non sempre si applicano alli normali software di livello applicativo Le mentre di solito le applicazioni svolgono una procedura dall inizio alla fine i moduli si presentano diversamente ogni modulo inizia il suo ci clo di vita registrando se stesso tramite una funzione dichiarata con la parola chiave __init all interno del sistema pubblicando cos le fun zionalit simboli che fornisce Una volta fatto questo le applicazioni e il kernel possono richiamare in ogni momento queste funzionalit Quando il modulo viene rimosso dal kernel le sue funzionalit vengono semplicemente rese non pi disponibili e viene richiamata una funzione di uscita dichiarata come __exit i moduli non possono utilizzare nel loro codice librerie esterne al kernel In particolare ad esempio non permesso l uso delle librerie standard mentre un fallimento da parte di un applicazione viene gestito in ma niera sicura dal kernel se un modulo del kernel fallisce questo porta sicuramente alla morte del processo corrente se non al blocco dell intero sistema i moduli del kernel lavorano in kernel space dove si possono effettuare operazioni con privilegi superiori rispetto allo user space e inoltre il kernel non effettua controlli di integrit per le operazioni effettuate dal proprio codice considerandolo chiaramente affidabile mentre quanto arriva dallo user space sempre verificato prima di ess
90. azioni possono richiamare dove ognuna di queste funzioni viene poi implementata dal driver per map pare la richiesta dell utente sui comandi specifici per il dispositivo Esistono tre tipi fondamentali di dispositivi che i device driver devono gestire cos come vengono descritti in 4 anche se questa distinzione non rigida e dispositivi a caratteri vengono acceduti come uno stream di byte Per questi dispositivi vengono sempre messe a disposizione system call fon damentali come open close read e write Inoltre essi vengono rappre sentati all interno del sistema come speciali file che si trovano dentro la directory dev e dispositivi a blocchi nei sistemi Unix tradizionalmente questi dispo sitivi si distinguevano da quelli a caratteri perch essi permettevano soltanto trasferimenti di blocchi di dati solitamente di 512 byte In Linux comunque questa distinzione non mantenuta in quanto il ker nel Linux permette di accedere ad un dispositivo a blocchi per trasferire un numero qualsiasi di byte cos come per quelli a caratteri Inoltre anche questi dispositivi sono rappresentati tramite file sotto dev In generale comunque viene definito dispositivo a blocchi un dispositivo CAPITOLO 3 STUDIO DI FATTIBILITA 29 in grado di ospitare un filesystem Inoltre la rappresentazione interna al kernel cos come l interfaccia tra il kernel e il device driver diver sa tra i dispositivi a blocchi e quelli
91. bit di risoluzione dell ADC Questo tipo di convertitori necessi tano di avere una frequenza di clock uguale alla frequenza di campionamento desiderata per il numero di bit di risoluzione felock Tsamaling Nbit Ad esempio nel nostro caso per un campionamento a 44 1 KHz e 16 bit di risoluzione c bisogno di una frequenza di clock di cira 705 KHz Questi convertitori sono molto usati per la loro accuratezza e il costo relati vamente basso 3 2 Lo Universal Serial Bus rev 2 0 Lo Universal Serial Bus 2 un bus che permette lo scambio di dati tra un Host centrale e una serie di dispositivi Device che possono essere collegati e scollegati dinamicamente anche durante l esecuzione delle operazioni I dispositivi possono essere di due tipi e Hub che permettono di collegare nuovi client all Host centrale e Funzioni i client veri e propri che forniscono funzionalit aggiuntive al sistema Lo scambio dei dati pu avvenire in diverse modalit e High speed con un bit rate fino a 480 Mb s solo USB 2 0 e Full speed bit rate fino a 12 Mb s CAPITOLO 3 STUDIO DI FATTIBILITA 20 e Low speed con un bit rate fino a 1 5 Mb s L esistenza delle ultime due velocita di scambio dei dati ha senso principal mente per un fattore di retrocompatibilita con le versioni precedenti dell U SB 3 2 1 Specifiche elettriche La Figura 3 3 mostra lo schema del cavo USB VBUS VBUS D D D D a GND GND Figura 3 3
92. ble e oltre a questo effettuando il salvataggio e ripristino dello stato dei registri della FPU ad ogni ciclo di esecuzione influi sca notevolmente sulle prestazioni generali del sistema costringendo a non sforzare troppo In ogni caso impostazione dei parametri come descritti pocanzi ha permesso di ottenere dei valori di latenza del tutto accettabili per lo meno per quanto riguarda la risposta del sistema a orecchio 7 2 Far suonare il Thereminux Il test su come lo strumento suona stato fatto collegandolo dopo aver inizializzato il sistema audio con jack pronto e funzionante Una volta che il gadget si attivato inizia immediatamente a inviare campioni audio che vengono tradotti in messaggi MIDI e inviati al livello applicativo Qualora in fase di avvio il gadget ritarda troppo ad iniziare l invio di dati rispetto alle richieste dell host causando la mancata ricezione di pacchetti iniziali subito l host invia una richiesta di ripristino e riceve dal gadget la stringa ISOCH_IN_STOPPED che dimostra semplicemente che il gadget ancora non ha avuto il tempo di iniziare le trasmissioni Una volta collegato e attivo lo strumento appare nell interfaccia di jack control con i due dispositivi MIDI allocati di default il profilo di configura zione inviato dal gadget abilita anche il MIDI out La schermata mostrata in Figura 7 3 evidenzia quanto detto Nella Figura sono mostrati alcuni aspetti salienti
93. cpu usb_dev gt descriptor idProduct le16_to_cpu usb_dev gt descriptor bcdDevice usb_dev gt descriptor bDeviceClass CAPITOLO 3 STUDIO DI FATTIBILITA 39 usb_dev gt descriptor bDeviceSubClass usb_dev gt descriptor bDeviceProtocol alt gt desc bInterfaceClass alt gt desc bInterfaceSubClass alt gt desc bInterfaceProtocol return ENOMEM Questo evento potr essere catturato da un apposita regola di udev che ma gari pu essere utilizzata per caricare dinamicamente tutti i moduli che hanno dichiarato di poter gestire quel dispositivo pubblicando ad esempio il numero seriale il vendorId ecc del dispositivo al quale fanno riferimento La regola potrebbe apparire come la seguente 26 ENV MODALIAS RUN sbin modprobe use blacklist env MODALIAS Questa regola verr portata a termine per tutti gli eventi che hanno impostato la variabile di ambiente MODALIAS ed eseguir il caricamento dei moduli che possono gestire i dati conservati in questa variabile Per ulteriori dettagli sul sottosistema USB rispetto allo sviluppo di device driver USB si veda il paragrafo 3 3 5 3 3 5 I device driver e il sottosistema USB I driver USB sono dipendenti naturalmente dall apposito sottosistema al l interno del kernel Il sottosistema USB si occupa di gestire come descritto accuratamente nella documentazione ufficiale 2 un interfaccia di comunica zione tra i dispositivi USB e i device driver in modo
94. dard USB per il collegamento verso il pc requisito RHW_F 3 vedi Sezione 3 2 lo sviluppo di un device driver USB per Linux kernel 2 6 requisito RSW_NF 1 vedi Sezione 3 3 lo standard MIDI per la gestione del flusso di dati di input e output requisito RSW_F 4 vedi Sezione 3 4 la rappresentazione dei device MIDI in Linux requisito RSW_F 4 vedi Sezione 3 5 la conversione voltage to MIDI requisito RSW_F 3 vedi Sezione 3 6 Studiamo nel dettaglio ognuno di questi punti al fine di analizzare le varie caratteristiche necessarie per soddisfare i requisiti del sistema e arrivare cfr 3 7 alle tecnologie che meglio si adattano a ci che emerge da questa analisi 3 1 La conversione Analogico Digitale Il meccanismo di conversione di un segnale analogico in una stringa digitale consiste nel trovare un numero digitale proporzionale all ampiezza del segnale 15 CAPITOLO 3 STUDIO DI FATTIBILITA 16 analogico di input 1 una tecnica utilizzata ogni qual volta c la necessit di controllare con sistemi digitali un esperimento o un processo che vede coinvolte quantit analogiche livelli continui di voltaggio o di corrente I parametri fondamentali nella scelta di un ADC appropriato ad una specifica applicazione sono 22 e Risoluzione numero di valori discreti che il convertitore pu produr re sul range di valori analogici Questo parametro viene espresso in bit ad esempio un ADC con risoluzi
95. definita tale funzione ritorna allo user space con un EINVAL e stampa un messaggio comunicando l impossibilit di eseguire l operazione In ogni caso in fase di debug questa funzionalit stata utilizzata con il programma in user space thmx_debug_get_audio eseguibile da un utente privilegiato cfr 5 3 2 che esegue un loop di letture sul dispositivo e salva il risultato nel file Scrivania thmx_audio raw L applicazione tiene conto del fatto che la thmx_read ritorna il valore ERESTART quando la fifo vuota nel momento in cui si cerca di leggerla In questo caso il programma effettua un polling di letture finch non arrivano dati validi e a quel punto li salva sul file di output Una volta salvato tale file stato poi aperto con un comune pro gramma audio per Linux stato usato l editor di file audio Audacity 69 il quale dando in input i parametri di descrizione dello stream audio S16_LE cfr 6 2 5 riuscito ad interpretare correttamente tale stream e a suonarlo come normale file audio Figura 7 2 CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 152 Co Applicazioni Risorse Sistema Q Qa dB do mar 26 lug 22 01 Ka als thmx audio File Modifica Visualizza Tracks Genera Effetti Analizza Aiuto x thmx_audi v Mono 44100Hz 32 bit float Project Rate Hz Selection Start End Length Audio Position 4aroo Snap To O cohoomoosxcohoom00s 00h00m 00 s7 E
96. dell esecuzione sulla de stra una console mostra il collegamento seriale con il gadget il quale si trova in uno stato di invio e resta fermo sul messaggio verboso stampa to dal thmx_gadget_alsa_capture All interno dell editor di connessioni di jack control invece sono mostrati i due dispositivi MIDI uno di input tra i Readable Clients e uno di output tra i Writable Clients In particola re la porta di MIDLin stata collegata ad un sintetizzatore audio il Fluid Synth che in grado di suonare i messaggi MIDI che riceve inviandoli alla scheda audio In questo modo possibile applicare svariati suoni ai messag gi prodotti dal Thereminux di default il sintetizzatore utilizza il suono di un pianoforte Poich il profilo di configurazione impostato inizialmente sul glissando le note suonate vengono collegate tra loro come era l effetto desiderato Certo salta all orecchio una certa inaccuratezza della conversione delle note cantate in note MIDI che spesso si avvicinano a quanto inviato attraverso il microfono ma spesso non rappresentano precisamente le nota suonate I problemi in questo caso sono sicuramente diversi per prima cosa il segna CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 154 Co Applicazioni Risorse Sistema Se Q gre mar 26 lug 15 31 Ka ayia Qsynth1 Connections JACK Audio Connection Kit Audio MIDI ALSA Readable Clients
97. dev che permette la creazione dinamica di nodi sotto dev a fronte di eventi di hotplug cfr 3 3 3 Una volta creato il nodo all interno del filesystem dal livello applicativo pos sono essere eseguite delle richieste tramite le system call standard eseguite CAPITOLO 3 STUDIO DI FATTIBILITA 35 sul file del dispositivo Non a caso ad esempio il puntatore alla system call open ha come argomento anche l inode che si riferisce al nodo del filesystem int open struct inode struct file Tra le altre informazioni la struttura inode contiene i campi dev_t i_rdev che mantiene i numeri di dispositivo e struct cdev i_cdev che mantiene la rappresentazione dei dispositivi a caratteri all interno del kernel Altro punto importante guardiamo i prototipi di alcune operazioni dichiarate all interno della struttura file_operations int open struct inode struct file ssize_t read struct file char __user size_t loff_t ssize_t write struct file const char size_t loff_t _user Ci accorgiamo che tutte prendono come argomento che gli viene passato dal kernel un puntatore ad una struct file Questa ben diversa dalla struct FILE con cui la libc rappresenta i puntatori a file per le applicazioni La struct file identifica all interno del kernel un file aperto e contiene tra le altre cose un riferimento alla struttura file_operations per quella istanza del dispositivo aperto Quindi
98. di di controllo possono effet tuare operazioni in generale non predicibili per cui si ritenuto meglio eseguirli in un thread separato Ma la fase di inizializzazione del sistema embedded viene in realt completata quando il sistema host manda la richiesta di setup Figura 5 19 Il sistema richieder al driver i suoi descrittori per poi confermare la configurazione inviata dal sistema embedded Questo far si che gli endpoint diventino ef fettivamente attivi ma prima dell inizio delle comunicazioni il sistema host richieder i descrittori stringa del profilo di configurazione in modo da po terlo impostare lato host Una sequenza che dal punto di vista del sistema embedded diventa par ticolarmente semplice l invio del flusso audio sull endpoint isochronous mostrata in Figura 5 20 Una volta introdotta l applicazione nello user space che legge i campioni audio appoggiandosi al driver ALSA standard infatti questa applicazione dovr soltanto scrivere sul nodo del dispositivo a caratte 120 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE aean peany L Quur peasy xne xwwb pee lt l i I I I l i Be N Sea gt i mu peasy spw7p gt i l Ss Seep di I I I I i I Il I 1 J I Duur myboid xwb I i une iero oi enza ie dii ae uu nap gt i lt Mur eyy xwwb T 1 i ce Pere eae l yur pen Miur pen xwpb
99. dispositivo hardware 3 il sistema embedded inoltra il messaggio sulla porta MIDI OUT dello strumento Flussi alternativi Il sistema host trova un errore nel messaggio MIDI da inviare Verr inviata una segnalazione di errore all utente Postcondizioni Il sistema ha inviato correttamente il messaggio MIDI al dispositivo MIDI esterno CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 87 5 2 Analisi tramite macchine a stati Grazie alla prima analisi effettuata dal punto di vista dell interazione con gli end user del sistema sono emerse diverse caratteristiche da approfondire cer cando di soffermare l attenzione sul sistema vero e proprio Per fare questo possiamo utilizzare i diagrammi di stato Attraverso tale strumento pos sibile individuare graficamente il ciclo di vita del sistema dando una prima intuizione dei flussi interni che regolano le diverse attivit descritte dai casi d uso In questa sezione quindi daremo una descrizione generale del ciclo di vita del sistema host e di quello embedded per poi fornire ulteriori dettagli sui flussi relativi alle principali operazioni da implementare cfr 5 2 1 La Figura 5 2 mostra il ciclo di vita del sistema host Host System General Reconfiguring ALSA for MIDI OUT System Playing System y MIDI SendMIDI OUT set MIDI input from MIDI for OUT device external dev Waiting for nts Sys
100. dopo averla applicata tramite il comando patch p1 di effettuare le seguenti configurazioni e CONFIG_PREEMPT_RT abilitato e High Resolution Timer HR Timer abilitato e disabilitare opzioni di power management come ACPI o APM Successivamente necessario ricompilare il kernel Fatto questo bisogna defi nire alcuni parametri affinch applicazioni specifiche nello user space possano usufruire delle priorit di scheduling real time nel kernel che altrimenti sono richiamabili esplicitamente soltanto dal kernel stesso Infatti il kernel asse gna ai processi due valori di priorit quello regolare impostabile con la system call nice che va da 20 priorit massima a 19 priorit minima e quello real time che va da 1 priorit pi alta a 99 priorit pi bassa 5 Usando il kernel real time pu essere importante far s che alcune applicazio ni nello user space possano essere eseguite con determinati valori di priorit real time oltre che al valore di priorit regolare Per fare questo possibile modificare il file etc security limits conf ma esiste il tool open source set_rlimits per eseguire questa operazione in ma niera pi user friendly 47 Attraverso questa utility possibile impostare manualmente alcuni importanti parametri relativi all esecuzione di specifiche applicazioni da parte di specifici utenti Ad esempio il file di configurazione etc set_rlimits conf potrebbe contenere una rig
101. dware dove il sistema stato sviluppato ed eseguito compo sto da un notebook che ha funzionato ha host la scheda Beagle Board come gadget e una scheda audio esterna collegata tramite USB all host per la ge stione dei flussi audio e MIDI Dal punto di vista software stato utilizzata una distribuzione Linux Ubuntu 8 04 e il kernel 2 6 31 lato host una versione base della distribuzione Angstrom 66 di Linux Embedded e il kernel 2 6 32 lato gadget 125 CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 126 6 1 1 Ambiente lato host Per lo sviluppo del Thereminux il sistema Linux configurato ad hoc distri buzione Ubuntu 8 04 stato ospitato su un computer host in una partizione dedicata Il sistema host utilizzato stato un pc con processore Intel Core Duo P8400 Di seguito viene data la descrizione dettagliata di come questo ambiente stato impostato per il corretto funzionamento Configurazione audio Il primo passo stato quello di configurare la scheda audio principale quella che si occupa della gestione di default dei dati audio MIDI stata utiliz zata per questo la scheda audio Audiophile USB 52 Per la configurazione si proceduto seguendo la documentazione su 53 e al l interno del kernel sul file Documentation sound alsa Audiophile Usb tat La scheda Audiophile infatti mette a disposizione diverse interfacce audio analigiche e o digitali per cui occorre selezionare i giusti parametri da
102. e RSEC_NF La modifica della presenza o meno della funzionalit di MIDI OUT tramite apposito comando dovra poter essere effettuata con privilegi standard Non Funzionale MustHave RSEC_NF L invocazione dei comandi di con trollo dell esecuzione dovr po ter essere effettuata con privilegi standard Non Funzionale MustHave RSEC_NF La lettura dell elenco dei comandi di controllo dell esecuzione dovra poter essere effettuata con privilegi standard Non Funzionale MustHave RSEC_NF Il sistema dovra effettuare dei con trolli su tutti gli eventuali parame tri passati ai comandi di controllo dell esecuzione Non Funzionale MustHave RSEC_NF Il sistema dovr verificare ad ogni tentativo di riconfigurazione che il profilo di configurazione sia ben formato e corretto Non Funzionale MustHave Capitolo 3 Studio di fattibilita In questo capitolo verranno analizzate tutte le questioni emerse dall analisi dei requisiti cfr Capitolo 2 per mostrare l esistenza di tecnologie appro priate per lo sviluppo degli aspetti hardware software del sistema studiarne le caratteristiche e descrivere le soluzioni trovate Per la realizzazione del sistema ci sono diverse questioni da analizzare 1 Ot 6 la conversione A D del segnale analogico in uscita del dispositivo audio di input requisito RHW_F 2 vedi Sezione 3 1 Putilizzo dello stan
103. e il Thereminux come dispositivo MIDI che viene elencato tra quelli standard presentati da Jack Fare questo significa inizializzare il dispositivo MIDI non solo tramite la procedura normale di gestione dei disposivi USB discussa in precedenza cfr 3 3 5 ma utilizzando in pi le funzioni messe a disposizione dal API ALSA al fine di incapsulare il dispositivo USB dentro un disposi tivo MIDI ALSA compliant La procedura per lo sviluppo di un device driver ALSA sostanzialmente la seguente 1 allocazione di una sound card infatti ogni dispositivo che in grado di poter emettere o acquisire eventi sonori visto da parte di ALSA come una scheda sonora ovvero un dispositivo che contiene l implementazio ne delle varie funzionalit audio MIDI ecc ALSA identifica ogni scheda sonora tramite identificativi del tipo hw n dove n il numero della scheda sonora 2 aggiunta dei vari dispositivi alla sound card come accennato in pre cedenza la scheda sonora soltanto un contenitore nel quale vanno successivamente allocati tutti i dispositivi realmente implementati co me quelli per l acquisizione e o riproduzione audio MIDI Gli identifi catori di tali dispositivi seguono da quelli delle sound card ad esempio il primo dispositivo della prima scheda identificato con hw 0 0 e cos via 3 registrazione della sound card e dei suoi dispositivi in tutta la fase di inizializzazione la scheda sonora era vista come
104. e per Puso dei raw_spinlock_t deve rappresentare un eccezione valida solo in de terminati contesti particolarmente critici come lo scheduler o alcune porzioni di codice che hanno a che fare direttamente con hardware e viene implementata priority inheritance per gli spinlock e i semafori interni al kernel per comprendere questo occorre prima spiegare il fenomeno della priority inversion Supponiamo che un processo A con bassa priorit detenga un lock L1 e che arrivi un processo B con media priorit a chiedere il controllo del processore Poich il lock preemp tible il processo A ceder il processore a B Supponiamo poi che un processo C ad alta priorit cerchi di acquisire il lock su L1 C si bloc cher su questa richiesta ma il processo A non potr terminare la sua sezione critica per diverso tempo in quanto bloccato dal processo B Per questo si parla di priority inversion perch il processo con maggiore priorit costretto ad aspettare quello con priorit minore Per evitare questo fenomeno la priority inheritance fa si che in uno scenario come quello descritto il processo A prenda soltanto per il tempo necessario a concludere la sua sezione critica e quindi a rilasciare il lock i privilegi del processo C In questo modo sempre nell esempio esposto A potreb be riconquistare il processore in quanto appare come un processo di priorit maggiore a B e rilasciare il lock il prima possibile Questo comunque cre
105. e concretamente la comunicazione con l hardware Il device driver minisnd stato gi progettato secondo queste considerazioni in mo do da effettuare un primo esperimento sulle modalit implementative di tale stratificazione La struttura che ne risultata mostrata dal diagramma in Figura 3 10 snd minisnd snd_minisnd_probe sd struct minisnd int snd_minisnd_remove sndcard struct sndcard void I lause dev struct minisnd usb_minisnd_probe interface usb_interface id usb device id int usb_minisnd_disconnect interface usb_interface void Figura 3 10 Diagramma dei moduli che costituiscono il driver minisnd Come si pu vedere sono stati implementati due diversi moduli Il pri mo quello a pi alto livello snd_minisnd che fornisce una serie di fun zioni che servono ad implementare un dispositivo di MIDI input basato su ALSA I dettagli del dispositivo vero e proprio vengono gestiti dal modulo usb_minisnd che implementa un driver USB generico e richiama le funzioni CAPITOLO 3 STUDIO DI FATTIBILITA 53 messe a disposizione da snd_minisnd per la registrazione degli aspetti ri guardanti ALSA La pubblicazione delle funzioni da parte di snd_minisnd effettuata esportando degli opportuni simboli nella Kernel Symbol Table tramite la EXPORT_SYMBOL Infine tutte le informazioni vengono scambiate tra i due moduli utilizzando un unica struttura la struct minisnd
106. e da parte di un utente privilegiato che dopo aver modificato il file di configurazione invoca un apposito comando che rende le modifiche effettive Le sezioni presenti nel profilo sono 1 gestione della polifonia ovvero la capacit dello strumento di suonare pi note contemporaneamente 2 numero di voci valutato solo se lo strumento gestisce la polifonia dice fino a quante note contemporaneamente possibile suonare con lo strumento 3 playing mode indica se le diverse note vanno interpretate come un suono continuo glissando 18 il modo standard in cui il Theremin suona o come suoni separati e ben distinti come un pianoforte ad esempio 4 hardware programmabile un elenco di parole chiave e indici che de scrivono la presenza di un determinato elemento programmabile Ad esempio la presenza di due pulsanti la cui funzionalit programmabile si potrebbe indicare con le linee PUSHBUTTON 0 PUSHBUTTON 1 5 comandi di controllo dell esecuzione una lista di comandi con cui pos sibile controllare lo strumento durante la sua esecuzione Ad esempio si pu configurare l hardware per eseguire alcune trasformazioni sul va lore di voltaggio da inviare via USB uso di costanti moltiplicative o divisive azzeramento di tutti i bit da inviare ecc CAPITOLO 1 DESCRIZIONE GENERALE DEL PROGETTO 8 6 associazioni ovvero una lista di coppie elemento hardware comando tramite le quali si definisce una ass
107. e l elenco completo dei requisiti che il sistema Thereminux soddisfa L elenco suddiviso in tre categorie 1 Requisiti hardware HW 2 Requisiti software SW 3 Requisiti di sicurezza SEC Ad ogni requisito stata associata una stringa identificativa che ne indica e La tipologia primaria HW SW SEC e La tipologia secondaria Funzionale Non Funzionale e L identificativo numerico progressivo Ad esempio un requisito software funzionale sar associato all identificativo RSW_F X dove X rappresenta un dentificativo numerico Inoltre ad ogni requisito associato un livello di priorit Questa informa zione utilizzata come riferimento nelle varie fasi di sviluppo per stabilire e quali funzionalit del sistema sono pi importanti e devono quindi essere necessariamente presenti fin dall inizio MustHave e quali funzionalit potrebbero essere implementate solo parzialmente all inizio e poi perfezionate in un successivo aggiornamento del software ShouldHave e quali funzionalit infine possono essere implementate direttamente in successivo aggiornamento del software MayHave 10 CAPITOLO 2 REQUISITI DI PROGETTO 11 Chiaramente come gi detto in apertura della relazione poich il siste ma hardware stato sviluppato soltanto per quanto riguarda le funzionalit messe a disposizione dalla Beagle Board alcuni dei requisiti hardware come l implementazione in hardware del Theremin an
108. e l inizializzazione del dispositivo come in terfaccia MIDI Per fare ci prima di tutto verifica la disponibilit di slot per questo dispositivo considerando il limite SNDRV_CARDS posto a otto in include sound core h In seguito alloca una nuova sound card tramite la funzione snd_card_create Il parametro SNDRV_DEFAULT_IDX1 che vale 1 come definito nel file sound core init c all interno dei sorgenti del kernel indica ad ALSA di allocare la sound card in un qualsiasi slot libero Suc cessivamente dopo aver specificato alcune informazioni riguardanti la sound card come il driver che la gestisce o le stringhe di descrizione si associa la sound card al dispositivo vero e proprio a cui fa riferimento tramite la CAPITOLO 3 STUDIO DI FATTIBILITA 57 snd_card_set_dev Successivamente si inizia con l allocare i dispositi vi contenuti nella sound card Il primo rappresenta la sound card stessa ed infatti specificato come SNDRV_DEV_LOWLEVEL ovvero un sound driver di basso livello In seguito viene allocato il dispositivo MIDI tramite la snd_rawmidi_new a cui vengono passati come argomenti la sound card una stringa identificativa il numero del dispositivo il numero di canali di output e quelli di input e infine un puntatore alla struttura snd_rawmidi da allocare Nel nostro caso questo driver crea soltanto un dispositivo di MIDI input quindi i parametri sono coerenti con questa scelta Anche al dispositivo MIDI creato ve
109. e la generazione dell uevent e l invio del nuovo valore al gadget se il valore dell attributo cambia e thmx_read_profile script eseguibile da un utente qualsiasi Sempli cemente legge il file del profilo di configurazione e lo stampa formattato e thmx_read_ctl_commands script eseguibile da un utente qualsiasi Questo legge il profilo di configurazione e stampa i comandi di controllo in esso contenuti e thmx_exec_ctl_command lt nome_comando gt script eseguibile da un uten te qualsiasi Permette di eseguire un comando di controllo sul disposi tivo hardware Questi comandi dopo aver superato il check da parte dello script stesso che controlla se esistono tra quelli disponibili verran no inviati al kernel tramite funzioni ioct1 Per la lista dei comandi che sono stati implementati si veda 5 3 4 e thmx_edit_profile script eseguibile soltanto dall utente privilegiato Semplicemente apre il file di configurazione utilizzando l editor wim e thmx_system_clean script batch invocato da una regola udev eseguita nel momento della disconnessione dello strumento Esso si occupa di scollegare i moduli del driver eliminare i nodi sotto dev e il file di configurazione creato CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 105 e thmx_debug_get_audio script di debug eseguibile soltanto dall utente privilegiato Esso stato sviluppato come verra trattato in seguito cfr 7 per ottenere una registrazione in tempo reale d
110. e standard che tutti i dispositivi USB devono gestire si faccia riferimento alla Figura 3 6 I successivi due campi wValue e wInder variano a seconda del tipo di richiesta ma sono utilizzati per passare dei parametri al dispositivo assieme alla richiesta Infine wLength specifica quanti byte di dati ci si aspetta come risposta Come si vede in Figura 3 6 le richieste standard che ogni dispositivo USB deve essere in grado di gestire sono molte e mettono in evidenza altri due fondamentali concetti che devono essere implementati dal dispositivo le con figurazioni e i descrittori Ogni dispositivo USB infatti pu avere diverse configurazioni fondamentalmente una configurazione un insieme di inter facce implementate dal dispositivo e l insieme delle impostazioni alternative di ogni interfaccia Se come detto ogni interfaccia associata ad un in sieme di endpoint che la implementano usando un impostazione alternativa per quell interfaccia essa pu variare dinamicamente il numero e il tipo di endpoint a cui associata Per quanto sicuramente permette la gestione di dispositivi anche molto complessi questa caratteristica comunque raramen te utilizzata I descrittori invece sono le strutture dati con cui effettivamente vengono specificati tutti gli attributi del dispositivo Tra questi attributi abbiamo la specifica del dispositivo numero di configurazioni numero di interfacce numero di endpoint vendor ecc la specifica
111. e tramite il comando depmod col leghiamo il dispositivo Questo evento viene rilevato dal kernel che incarica il core USB di gestirlo 26 Il core USB utilizza un driver USB generico implementato in drivers usb core generic c per effettuare delle operazioni comuni a tutti i dispositivi USB tra cui comunicare con il dispositivo ri chiedendogli le informazioni sulle interfacce sulle configurazioni e sui vari descrittori che lo identificano cfr 3 2 e cos allocare una nuova interfaccia USB ovvero una struct usb_interface con le caratteristiche inviategli da esso Il driver generico a questo punto esegue una scansione di tutti i driver USB gi caricati nel sistema confrontando gli indentificativi invatigli dal dispositivo con quelli che ogni driver dichiara attraverso la tabella degli identificativi di poter gestire Quando trova un driver tra quelli gi cari cati nel kernel che dichiara di poter gestire il dispositivo il driver generico richiama la funzione probe implementata da quel driver Infine genera un vevent in cui pubblica le informazioni del dispositivo come variabili di ambiente e questo fa s che se il driver che pu gestire il dispositivo non era stato ancora caricato il caricamento possa avvenire infatti l uevent genera to risveglia udev che attraverso una opportuna regola cfr 3 3 4 richiama il comando modprobe il quale esegue una scansione dei moduli disponibili e se ne trova uno adatto al dispositivo
112. ebug preemtible kernel b Kernel Acking gt RT Mutex debugging deadlock detection CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 128 c Kernel Acking gt Lock Debugging prove locking correctness d Kernel Acking gt Tracers gt Trace syscalls 3 abilitazione del Power Management Support gt ACPI Support ma sen za includere le seguenti sotto configurazioni di questo a Button b Fan c Processor d tutte le configurazioni nominate come deprecated Il fatto che ACPI vada comunque abilitato dipende dal fatto che si incontrano problemi nella compilazione e utilizzo dei hr timer se questo completamente disabilitato 55 4 disabilitazione del Power Management Support gt APM BIOS Support Il file con la configurazione del kernel stato incluso nel materiale consegnato all interno della directory thereminux thma_ src utility_ scripts host system_ scripts 6 1 2 Ambiente lato gadget Compilazione kernel e distribuzione Linux per la BeagleBoard Per la compilazione del kernel lato gadget sono stati fatti alcuni tentativi di compilazione a mano risultando per in alcune instabilit del kernel e della distribuzione del sistema operativo quando questo veniva eseguito sulla Beagle Board Infatti si voleva evitare di utilizzare l intera distribuzione Angstrom di Linux Embedded in quanto mette a disposizione una quantit di strumenti che creano un completo ambiente interattivo da gestire tra
113. eds sN eqep Mau suonesijddy 0 IGIW pues UOIsJaAUOD IGIW 0 2623 0A ejep 104 ute M IGIW BUIAEId W3ISAS Diagramma degli stati che descrive l esecuzione di note MIDI suonate da parte dello strumento hardware Figura 5 5 93 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE sabajinud ou 10149 asuodsay 6umoys asuodsay 40 Bue M Ruas sw ammIaxg Syuogwuyuop 9 HOJd lt asuodsay uo ein by uod 1 I ejep auop 6ulpuas Bumas l m03d Joy GUNIEM wW3IS S ISOH p uey gt ejep adinap ejeg spuewwos 2dinag bumas Joy Buren waysks p pp qwq BiyuogUUIJUO Wa sks Diagramma degli stati che descrive l operazione di reimpostare il profilo di configurazione Figura 5 6 94 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE asuodsay 104 Buren asuodsay 6Buimous puewwo7 BupjseyD jues pw DIO pw aImDaxg asuodsay quas puewwo gt ejyep lt euop 6ulpuas pus Buipuas Pw JO BUINEM wayshs ISOH a a es a r a I a a as puewwo gt puewwo7 spuewwod 6unn x3 6uiy2 42 103 BUINEM Ks wa3skS pappaqua LL MS puewiwo9jzIIXI W3ISAS Diagramma degli stati che descrive l esecuzione di comandi di controllo invocata dal lato host Figura 5 7 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 95 Inviare messaggi M
114. ell audio che viene inviato al sistema tramite il Thereminux Tale stream audio viene salvato su un file audio grezzo che possibile ascoltare con opportune applicazioni audio standard e thmx_config rules file installato sotto la cartella etc udev rules d che contiene le regole udev per l esecuzione del sistema come descritto finora e thmx_node_create programma in esecuzione sul sistema embedded che viene eseguito tra gli script di avvio del sistema operativo e crea il nodo sotto dev che rappresenta il dispositivo a caratteri implemen tato tra le altre interfacce esposte dal modulo installato sul sistema embedded cfr 5 3 6 e thmx_gadget_alsa_capture programma in esecuzione sul sistema embedded che legge i campioni audio in ingresso e li invia al device driver gadget utilizzando la sua interfaccia a caratteri per i dettagli cfr 5 3 6 e thmx_alsa_capture_start script eseguito tra quelli di avvio del si stema operativo del sistema embedded e il cui compito semplicemente di avviare l esecuzione del programma thmx_gadget_alsa_capture Oltre a questi sono stati implementati alcuni script di utilit che hanno agevolato il lavoro di sviluppo del sistema e cp_thmx_mod_fs script usato per il sistema host con il quale il modulo compilato viene copiato in una sotto directory della directory di sistema adibita ai moduli lib modules e viene invocato il comando depmod e cp_thmx_mod_sd script usato per il sistema
115. ementa un loop di letture sul dispositivo audio della Beagle Board che ac cessibile tramite il driver ALSA standard Ogni volta che i dati sono disponibili questa applicazione riempie un buffer e lo manda al modulo gadget_module tramite normali system call come la write Il pro blema per che l interfaccia USB Gadget non mette a disposizione le system call per l I O dal livello applicativo Per questo il driver imple menta un semplice dispositivo a caratteri sul quale il livello applicativo pu inviare le sue write L implementazione di questa system call semplicemente inoltra i dati sull endpoint isochronous di input all host e thmx_gadget_proghw un oggetto che implementa un elemento hard ware programmabile sul dispositivo Questo significa semplicemente che viene salvato un riferimento alla linea di irq a cui associato quel l hardware in modo da registrare un interrupt handler per tale irq ed eseguirlo ogni volta che un interrupt arriva su quella linea Questo essenzialmente ci che questo oggetto fa L unica cosa su cui c da pre stare attenzione che l esecuzione del comando di controllo associato all hardware programmabile andrebbe effettuata all interno dell inter rupt handler ma questo rischioso perch ci si trova in un contesto in cui non si pu andare in sleep o prendere lock e il comando di con trollo da eseguire potrebbe in linea di principio effettuare operazioni arbitrar
116. emente prova a disabilitare tramite la funzio ne usb_ep_disable ea riabilitare usando usb_ep_enable endpoint inviando poi all host la stringa ISOCH_IN_RESTART Oltre a questo per garantire la comunicazione su tutti gli endpoint il gad get in fase di inizializzazione avvia una richiesta pendente sugli endpoint di interrupt usati per l output ovvero per le comunicazioni dall host al gadget cos che quando arrivano dati questi effettivamente vengano ricevuti Invece per le comunicazioni di input sar l host ad inviare richieste mentre il gadget eseguir l invio soltanto quando effettivamente ci sono dati da mandare In fine per quanto riguarda la possibilit di conflitti sui dati inviati sull enpoint isochronous il gadget non si occupa di gestire la mutua esclusione della ri sorsa come l host ma si limita a rispondere a richieste che vengono gi fatte dall host rispettando tale sincronizzazione 6 2 3 La gestione di ALSA lato host Sull host l interfaccia ALSA del Thereminux gestita interamente dal mo dulo thmx_snd vedi il file host snd_module thma_ snd c CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 137 Inizializzazione Visto che questo modulo fornisce delle funzionalita liberamente accessibili da altri moduli che sono costruiti sull interfaccia del Thereminux ovvero che usano come struttura principale la struct thmx stato necessario adope rare un po di attenzione in fase d
117. ere utilizzato ogni modulo del kernel va programmato considerando la concorrenza Infatti esistono diverse fonti di concorrenza all interno del kernel a la presenza di pi processi che possono richiedere contemporanea mente le funzionalit dei moduli b la possibilit dell arrivo di interrupt che possono intervenire in maniera asincrona imponendo l esecuzione di un apposito handler interrompendo cos l esecuzione del codice del driver in un punto arbitrario CAPITOLO 3 STUDIO DI FATTIBILITA 31 c la possibilit che uno stesso modulo possa essere eseguito concor rentemente questo pu avvenire sia per la presenza di architetture SMP ma anche dal kernel 2 6 a causa del fatto che il kernel stato reso preemtible A causa di questo fatto necessario implementare ogni modulo uti lizzando i meccanismi di sincronizzazione come mutex spinlock ecc messi a disposizione dal kernel 6 i device driver devono fornire meccanismi e non politiche mentre i primi implementano una generica astrazione dell hardware che appare al livello applicativo come una scatola nera su cui possibile effet tuare diverse operazioni le seconde forniscono le regole e i protocolli con cui utilizzare le varie operazioni permesse sull hardware L unico caso in cui di solito vengono implementati all interno dei device driver aspetti che riguardano le politiche la sicurezza ad esempio quando l ordine con cui le
118. evice driver specifico per il dispositivo senza do ver fare i conti con il protocollo USB vero e proprio per i dettagli cfr 3 3 Inoltre non verranno in questa sede considerati i dettagli per l implemen tazione hardware dell USB sul dispositivo in quanto cfr 3 7 1 come gi CAPITOLO 3 STUDIO DI FATTIBILITA 24 accennato in apertura del lavoro la scheda hardware utilizzata fornisce oltre ad un microprocessore programmabile integrato tutta la circuiteria necessa ria all implementazione hardware del protocollo USB Ci che dunque rimane comunque necessario impostare il firmware del dispositivo hardware perch sia in grado di rispondere correttamente alle ri chieste che il sistema operativo gli invier una volta effettuato il collegamento fisico e fornita l alimentazione La specifica USB 3 fornisce tutti i dettagli su come queste richieste devono essere gestite da parte del dispositivo Ogni richiesta da parte dell host arriva al dispositivo attraverso la sua De fault Control Pipe endpoint 0 Questa richiesta formata da diversi campi come mostrato in Figura 3 5 Il campo bmRequestType una bitmap specifica le caratteristiche generali del trasferimento cio la direzione il tipo di richiesta standard riferita alla classe del dispositivo ecc e l oggetto a cui fa riferimento dispositivo in terfaccia endpoint bRequest un codice che identifica la richiesta vera e propria per una lista delle richiest
119. evono essere identificati come valori numerici univoci al l interno dell intero sistema per evitare che venga inviato un certo comando al dispositivo sbagliato e che questo riuscendolo ad interpretare corretta mente esegua un operazione magari dannosa 5 Per prima cosa dunque stato necessario allocare un magic number univoco all interno del sistema che rappresenta un primo bitfield a cui vengono aggiunti dei valori numerici progressivi cos da costruire i comandi ioctl finali per il dispositivo Con sultando all interno del kernel il file Documentation ioctl ioctl number tat si visto che x al momento della scrittura di questo documento un magic number libero Successivamente sono state create le ioctl per i vari comandi La funzione thmx_ioctl esegue il parsing degli argomenti passati in input e se stato inviato un comando valido richiama una delle due fun zioni thmx_usb_send_ctl_cmd o thmx_usb_send_ra_req per eseguire realmente il comando Di queste due funzioni la prima si occupa di prende re il comando e i suoi eventuali argomenti costruire un URB sull endpoint di output di tipo interrupt generico e inviare il comando La seconda funzione invece implementa quelle che sono state chiamate richieste Request Answer RA Requst ovvero che prevedono l invio di un comando al gadget e una risposta da parte di quest ultimo A parte il comando di controllo per l invio da parte del gadget di un
120. g about com od networkcables g bldefnullmodem htm 69 Audacity Free Audio Editor and Recorder http audacity sourceforge net
121. gle Board non permettendo cos al driver del Thereminux di prenderne possesso b stato abilitato il solo la modalit gadget nello stack OTG device_drivers gt usb_support gt inventra_highspeed_dual_role_controller gt driver_mode usb_peripheral infatti lo USB 2 0 permette di definire dei dispositivi USB OTG On The Go ovvero che riescono ad assolvere ad entrambe le fun zioni sia di gadget rispetto ad un host al quale sono connessi sia di host rispetto a dispositivi che a loro volta si connettono a lo ro Sebbene la Beagle Board metta a disposizione la possibilit di questa modalit di funzionamento non stata utilizzata perch per prima cosa non serviva per la nostra applicazione e secondo si visto che richiedeva di fornire una alimentazione supplemen CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 131 tare alla scheda rispetto a quella che viene portata dal cavo USB e questo non sembrato desiderabile nel nostro caso c sono stati caricati come moduli tutti i gadget drivers device_drivers gt usb_gadget_support gt usb_gadget_drivers m per il loro possibile utilizzo in fase di test Avvio BeagleBoard Come gi detto in precedenza cfr 5 3 2 stato sviluppato uno script che permette di inizializzare una card SD MMC formattandola con due diverse partizioni una fat di avvio dove andr il boot loader U Boot e l immagine del kernel e una ext3 dove andr il rootfs e i moduli La formattazione
122. i infatti in questo modo alcuni moduli possono affidarsi ad altri per la gestione di particolari funzio nalit semplicemente richiamando le funzioni appropriate disponibili nella kernel symbol table Per l implementazione di questo meccani smo di dipendenza tra moduli ogni modulo contiene all interno della sua struct module un elemento chiamato modules_which_use_me una lista in cui vengono inseriti tutti i moduli che sono dipendenti da esso All avvio del sistema viene invocato il comando depmod che scorre tutti i moduli installati nel sistema ovvero presenti all interno di lib modules e ne calcola le dipendenze salvandole nel file modu les dep Grazie alla stratificazione dei moduli possibile implementare archi tetture in cui esistono alcuni moduli pi generici che utilizzano dei simboli che poi vengono implementati da moduli di pi basso livello che si interfacciano ad esempio con un hardware specifico La Figura 3 8 mostra l implementazione di tale stratificazione per quanto riguar da il device driver della porta parallela all interno del kernel 2 6 La stratificazione un ottima cosa in fase di progettazione perch per mette di mantenere la modularit e la semplicit di ogni modulo Nel nostro caso come vedremo pi avanti nel dettaglio cfr 5 e 6 stato CAPITOLO 3 STUDIO DI FATTIBILITA 33 Low level device Port sharing i operations i ASI Kernel API and device I devic Message reg
123. i 3ms La patch scritta e mantenuta da Ingo Molnar basata sull assunzione che per ottenere i migliori risultati possibili in termini di latenza del kernel biso gna massimizzare la quantit di codice preemtible interno al kernel cercando di cambiare il meno possibile in termini di codice Per questo vengono introdotte diverse caratteristiche non native e tutte le primitive di locking interne al kernel semafori spinlock seq lock ecc vengono rese preemptible Questo crea alcune sostanziali dif ferenze rispetto al comportamento normale ad esempio uno spinlock viene di solito acquisito in contesti atomici ovvero in cui chi possie de il lock esegue le sue istruzioni rapidamente senza andare in sleep e senza essere interrotto a parte in caso di interrupt se non stata usata la funzione spin_lock_irqsave anche perch i processi che rimangono bloccati su quel lock implementano un attesa attiva su di esso Permettere che il processo che detiene lo spinlock possa perdere il controllo del processore anche all interno della sezione critica fa s che alcune modifiche siano imposte ad esempio i processi in attesa su quel lock possono andare in sleep Naturalmente non viene intaccata la si curezza della sincronizzazione visto che comunque tutti i processi sono sincronizzati sul lock per diventa importante che il lock non sia preso quando sono stati disabilitati gli interrupt o la funzione di preemption in quanto por
124. i di vol taggio lo strumento in grado di generare uno stream di messaggi MIDI standard relativi a questi valori di modo che un applicazione in user space pu vedere il Thereminux come un dispositivo di MIDI input standard da cui pu leggere dati Nel caso in cui il profilo di configurazione impostato per supportare anche il MIDI out il dispo sitivo appare ai livelli software applicativi anche come un interfaccia di MIDI output standard su cui poter inviare messaggi Quest ultima funzionalit pu variare in runtime ad esempio un dispositivo MIDI esterno potrebbe venire collegato o scollegato al Thereminux quando questo gi in esecuzione Per questo stato implementato un apposito comando eseguibile da un utente con privilegi standard che permette di attivare e disattivare dinamicamente questa funzione CAPITOLO 1 DESCRIZIONE GENERALE DEL PROGETTO 9 3 controllo di esecuzione dello strumento i vari comandi di controllo che vengono elencati all interno del profilo di configurazione oltre a poter essere associati agli elementi hardware programmabili possono anche essere invocati dal software in esecuzione sul host In particolare sono stati messi a disposizione dei comandi eseguibili con privilegi standard con i quali possibile invocare queste funzioni di controllo La lista dei comandi di controllo disponibili pu essere ottenuta tramite uno dei comandi che permettono di leggere il profilo di configurazione
125. i inizializzazione Infatti ogni dispositivo basato su thmx che cerca di registrarsi ad ALSA viene associato ad una sound card che viene allocata nel sistema e per questa c bisogno di un identificativo univoco Esso dichiarato come variabile intera statica e glo bale all interno del modulo cos che venga incrementata ogni volta che un modulo di basso livello come lo usb_module del Thereminux richiama la funzione thmx_snd_probe Per questo assieme all indice increntale viene mantenuto anche un mutex statico snd_sem che viene acquisito per il tempo necessario all inizializzazione del dispositivo audio da parte del modulo Tale inizializzazione viene effettuata dalla funzione thmx_create_snd_device Essa integra quanto gi presentato per il modulo di test minisnd cfr 3 5 allocando una sound card e associando ad essa i dispositivi MIDI richiesti Per questo punto il driver di basso livello che in base al valore letto dal profilo di configurazione inviato dal dispositivo imposta questa variabile di default il Thereminux mette a disposizione il MIDI out attivo Comunicare con le applicazioni ALSA La comunicazione tra il dispositivo e il livello applicativo a questo punto interamente gestita dalle funzioni relative agli stream MIDI Come si legge in 6 per ogni dispositivo MIDI necessario implementare oltre alle normali open e close tre funzioni che vengono richiamate dal core ALSA in fase di inizializzazio
126. i si tratto un esempio di utilizzo dell API CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 141 6 2 5 La conversione Voltage To MIDI Il modulo vmt_module implementato all interno del file host vtm_module thma_vtm c mette pubblicamente a disposizione del ker nel una singola funzione di utilit oltre a quella di inizializzazione e discon nessione che dato in input un puntatore ad una struct thmx estrae da tale struttura un buffer di campioni audio ed effettua la conversione Voltage To MIDI su di esso Per l acquisizione del buffer stata utilizzata come nel caso descritto nel paragrafo 6 2 4 una kfifo in cui l unico scrittore il thmx_usb e l unico lettore thmx_vtm Come gi detto cfr 3 7 3 tale operazione ha comportato l utilizzo della FPU hardware presente sul sistema host e dunque in fase di inizializzazione viene effettuato un controllo sulle caratteristiche della CPU del sistema sul quale si sta eseguendo il driver se la FPU non presente il caricamento del modulo thmx_vtm non sar possibile cosa che far ritornare l intera procedura di inizializzazione del sitema con errore Nel caso in cui la piattaforma hardware sia compatibile con l esecu zione possibile avviare la procedura di conversione VTM Per fare questo stato necessario approfondire lo studio della libreria aubio gi presentata cfr 3 7 3 e 48 portando alla necessit di effettuare alcune importanti operazioni sul f
127. ie Per questo l handler crea un kernel thread che si occupa di eseguire il comando corrente associato all hardware programmabile che ha inviato l interrupt In questo modo l interrupt handler rimane il pi efficiente possibile Inoltre il fatto che l hardware programmabile sulla Beagle Board sia in realt un pulsante hardware ha fatto s che per la gestione di tale dispositivo di input stato necessario implementare un piccolo device driver GPIO General Purpose Input Output Questo tipo di dispositivi si veda il file Documentation gpio tat all interno dei sorgenti del kernel fornisce dei semplici segnali controllati da software e quindi pu essere associato a diversi elementi fisici trovati sulle co muni schede hardware pulsanti linee JTAG ecc Nel nostro caso stato necessario registrare il driver GPIO per il pulsante program mabile ricavando da questo la linea di irq associata a tale elemento hardware per poi usarlo nell applicazione e thmx_gadget_aux_thread come spiegato al punto precedente que sto un kernel thread che si occupa di eseguire una singola funzione associata all hardware programmabile che ha inviato un interrupt CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 113 La struttura presentata in questa sezione verr approfondita ulteriormente quando si tratteranno nel dettaglio gli aspetti di implementazione del sistema cfr Capitolo 6 Per concludere la descrizione progettuale verr
128. interamente il firmware eseguito sul microcontroller e quindi anche le specifiche del dispositivo USB e fornisce un applicazione semplicissima lato host per il caricamento di tale firmware sul dispositivo In questo caso purtroppo il problema stato riscontrato sulle capacit di CAPITOLO 3 STUDIO DI FATTIBILITA 67 calcolo della scheda infatti il microcontroller AT90USB1286 montato sul Teensy mette a disposizione un convertitore A D ad approssimazioni succes sive con 10 bit di risoluzione e con un massimo di performance garantita di 200 KHz cosa che cfr 3 1 fa capire come tale controller troppo lento per la nostra applicazione in cui si richiede un campionamento del segnale sonoro in tempo reale a 44 1 KHz Dunque ci si spostati su un prodotto computazionalmente pi potente Dopo un attenta ricerca la Beagle Board 38 sembrata fare al caso nostro Figura 3 17 Figura 3 17 La Beagle Board Fonte 16 Questa scheda infatti oltre a mettere a disposizione risorse hardware pit potenti come il processore OMAP3530 14 basato su un microcontroller ARM a 720 Mhz specifica per lo sviluppo di applicazioni multimediali ad esempio fornisce un convertitore A D ad approssimazioni successive a 16 bit in grado di effettuare campionamenti fino a 48 KHz mette a disposizio ne connettori mini jack standard per le applicazioni audio e anche controller specifici per la gestione e l elaborazione video La presenza di tali
129. ionale MustHave RSW_F 17 Il sistema dovr mettere a disposi zione un comando per rendere ef fettive le modifiche al profilo di configurazione effettuate Funzionale MustHave RSW_NF 1 Il device driver andr implementa to per il kernel Linux 2 6 Non Funzionale ShouldHave RSW_NF 2 Il kernel dovr essere ottimizzato per lavorare in real time Non Funzionale MustHave RSW_NF 3 Il sistema dovr avere una bassa latenza tra gli input e gli output Non Funzionale ShouldHave CAPITOLO 2 REQUISITI DI PROGETTO 14 Requisiti di sicurezza ID Descrizione Tipo Priorit RSEC_NF La lettura del profilo di configura zione dovr poter essere effettuata con privilegi standard Non Funzionale MustHave RSEC_NF La lettura del profilo di configura zione da parte di utenti con pri vilegi standard dovr poter es sere effettuata solo attraverso i comandi messi a disposizione dal sistema Non Funzionale MustHave RSEC_NF Il sistema dovr permettere a uten ti con privilegi di amministrazione di leggere e modificare con qual siasi editor il file del profilo di configurazione Non Funzionale MustHave RSEC_NF Il comando presente nel sistema per rendere effettive le modifi che al profilo di configurazione dovr poter essere invocato sol tanto da utenti con privilegi di amministrazione Non Funzionale MustHav
130. istration parport printing driver registration port allocation Ip etc Figura 3 8 Stratificazione dei moduli del driver per la porta parallela nel kernel Linux 2 6 Fonte 4 interessante implementare tale stratificazione in modo da fornire un in terfaccia generica come era stato detto in apertura del lavoro cfr 1 1 per la gestione dei segnali di voltaggio che arrivano da un qualsiasi stru mento musicale analogico tale interfaccia poi gestita a basso livello da un altro modulo che si occupa della gestione dell hardware specifico collegato al sistema 3 3 2 Scrivere device driver per Linux Per la seguente trattazione prenderemo in considerazione i dispositivi a ca ratteri visto che presentano molte caratteristiche che sono state applicate anche nel caso del Thereminux oltre a fornire un esempio semplice di uti lizzo dei principali concetti relativi alla programmazione di device driver Come detto questo tipo di dispositivi rappresentato come un file sotto dev Ad ognuno di questi file e dunque ad ogni dispositivo sono associati due numeri di identificazione il Major Number e il Minor Number Di que sti il primo identifica quale device driver associato al dispositivo mentre il secondo identifica esattamente il dispositivo al quale si fa riferimento con quel nodo del filesystem In questo secondo caso in realt il kernel assume semplicemente che il Minor Number si riferisca al dispositivo implementato da
131. l lock si liberi teoricamente il thread di ricezione potrebbe mantenerlo per l in tera esecuzione del sistema ma utilizzer la funzione down_trylock per verificare se la risorsa libera La funzione thmx_usb_iso_read esegue la lettura vera e propria allocando un opportuno URB e inviandolo al disposi tivo Per l invio l endpoint isochronous permette di specificare che vengano inviate pi richieste contemporaneamente al dispositivo cos da garantire che il flusso di dati possa essere acquisito il prima possibile Tale meccani smo viene specificato anche nella ricezione fatta dall oggetto thmx_usb con l inizializzazione seguente urb gt dev usb gt udev urb gt context dev urb gt pipe usb_rcvisocpipe usb gt udev iso_in gt iso_in_endpointAddr urb gt interval 16 urb gt transfer_flags URB_ISO_ASAP urb gt transfer_buffer iso_in gt iso_in_buffer if urb gt transfer_buffer retval EINVAL goto error x urb gt complete thmx_read_iso_callback urb gt number_of_packets NUM_ISO_PACKETS urb gt transfer_buffer_length iso_in gt iso_in_size for i 0 i lt NUM_ISO_PACKETS i urb gt iso_frame_desc i offset i iso_in gt maxpacket urb gt iso_frame_desc i length iso_in gt maxpacket CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 136 Come si nota viene impostata la struttura urb gt iso_frame_desc che de scrive i vari frame che verranno acquisiti uno per pacchetto e
132. l seguito verranno trattati i vari aspetti da considerare per l implementazione delle componenti principali come il profilo di configurazione e le applicazioni dello user space per poi cfr 5 3 6 definire la struttura generale del sistema software sia host che embedded 5 3 1 Il profilo di configurazione Il profilo di configurazione dello strumento senza dubbio una delle carat teristiche centrali per l esecuzione del sistema Come descritto nei requisiti RSW_F 2 e RSW_F 5 tale profilo caricato dinamicamente al momento del collegamento fisico dello strumento all host e come descritto dal requisito RSEC_NF 3 esso viene fornito almeno agli utenti con privilegi di amministra zione come un file leggibile e modificabile all interno del filesystem Come riferito da numerose fonti per tra cui ad esempio l articolo in 50 una buona pratica all interno della programmazione del kernel dice che il codi ce del kernel non dovrebbe effettuare operazioni di I O con file all interno del filesystem prima di tutto per evitare i classici errori di programmazione 96 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE asuodsay 6uiMoys asuodsay Joy ue Mm abessow IGIW Buipuas uoiesijddy igiw a2eds sN asuodsay 6uipuas abessow Hulpuas ejep 404 BUINEM Wa SAS 3S0H abessow IGIW piemuo SPUELILUOI Joy uem wayshs pappaquwua abessan DaXx
133. l device driver identificato dal Major Number Il nodo del filesystem che rappresenta il dispositivo pu essere considerato per utilizzare una terminologia tipica della programmazione a oggetti un oggetto appunto e questo ha i suoi metodi Essi sono forniti da una strut tura detta file_operations che viene dichiarata per ogni dispositivo e contiene una serie di puntatori alle operazioni che possono essere effettuate su di esso Queste operazioni corrispondono alle system call standard richia mabili dal livello applicativo ad esempio open close read write ioct1 ecc e infatti viene eseguita dal kernel una certa operazione definita nella struttura file_operations quando arriva una richiesta dal livello applica CAPITOLO 3 STUDIO DI FATTIBILITA 34 tivo per la system call corrispondente a quella operazione Ogni operazione dichiarata nella struttura file_operations come detto in realt un pun tatore a funzione che pu essere fatto corrispondere all implementazione di quella operazione specifica per il dispositivo oppure pu essere posto a NULL se non viene fornita un implementazione per quella operazione Ad esem pio all interno del sistema host del Thereminux viene mostrata la seguente dichiarazione della struttura file_operations static struct file_operations thmx_fops owner THIS_MODULE open thmx_open release thmx_release ioctl thmx_ioctl read thmx_read Qui si pu notare come
134. l metodo zero crossing un tipico esempio di que sto approccio in cui si calcola il periodo del segnale calcolando il tempo che trascorre tra i primi due valori zero del segnale stesso In questo modo appli cando la semplice relazione matematica tra la frequenza e il periodo f si ottiene la frequenza I problema fondamentale con questo metodo sta nel Vassunzione che all interno di un segnale lo zero venga attraversato due sole volte per periodo Ma nel caso di segnali con alta inarmonicit come quello mostrato in Figura 3 15 questo porta a ricavare un informazione sbagliata b 0 9sin x 0 1sin 20x 0 5 1 15 2 angle pi Figura 3 15 Un segnale inarmonico dove lo zero viene attraversato pi di due volte per periodo Fonte 7 Un metodo sicuramente pi interessante usa la funzione matematica di au tocorrelazione 7 Se la correlazione tra due segnali una misura della loro similarit l autocorrelazione una misura di un segnale con se stesso ovvero con una sua versione ritardata nel tempo In questo caso si pu chiaramen te supporre che i due segnali comparati saranno esattamente identici quando il ritardo temporale zero oppure un intero periodo cio quando il segnale in fase con se stesso in maniera simile si prevede che i due segnali mo streranno la differenza massima quando il ritardo di mezzo periodo ovvero quando il segnale esattamente fuori fase con se stesso S
135. la gthmx_exec_ctl_cmd cfr 6 2 6 6 2 9 La disconnessione dello strumento In ultimo quando lo strumento viene disconnesso fisicamente dal sistema o scollegato come modulo avviene la pulizia sia lato gadget sia lato ho st Come spiegato nelle sequenze mostrate nel paragrafo 5 4 questo task CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 149 essenzialmente avviene richiamando una per una le funzioni di pulizia defini te dai singoli oggetti contenuti nell oggetto principale thmx e thmx_gadget rispettivamente per poi de registrare il modulo presso il kernel Essendo coivolti diversi kernel thread per l esecuzione questo ha richiesto una sincro nizzazione per la terminazione di tali thread Tale sincronizzazione stata implementata impostando una opportuna variabile atomica da ambo i la ti thmx disconnect_state sull host e thmx_gadget running sul gadget Visto che tutti i thread eseguono dei loop infiniti in cui rimangono in attesa su delle apposite wait _queue finch il chiamante non li sveglia e solo allora eseguono il proprio lavoro per poi tornare in attesa stato sufficiente inserire dei controlli ogni volta che i thread escono dall attesa se stata imposta ta la variabile di disconnessione del sistema l esecuzione pu terminare In questo modo il thread principale semplicemente imposta tale variabile e poi sveglia il thread Infine per la sincronizzazione stata forzata utilizzando delle struct c
136. lay dovr impo stare automaticamente il profilo di configurazione Funzionale MustHave RSW_F Il device driver dovr acquisi re le stringhe binarie di ingres so ed effettuare una conversione voltage to MIDI di queste Funzionale MustHave RSW_F Il device driver dovr fornire un in terfaccia MIDI standard verso il livello applicativo Funzionale MustHave RSW_F Lo strumento dovr essere configu rato tramite un profilo di configu razione che rappresenta la descri zione astratta delle caratteristiche dello strumento Funzionale MustHave RSW_F Il profilo di configurazione do vr contenere il campo di ge stione della polifonia in cui si specifica se lo strumento ha la possibilit di suonare pi note contemporaneamente Funzionale MustHave RSW_F Il profilo di configurazione dovr contenere il campo numero voci valutato soltanto se lo strumento gestisce la polifonia Funzionale MustHave RSW_F Il profilo di configurazione dovr contenere il campo playing mode Questo specifica se le note van no suonate in maniera continua 0 discreta Funzionale MustHave RSW_F Il profilo di configurazione dovr contenere il campo hardware pro grammabile ovvero un elenco di parole chiave e indici che descri vono i diversi elementi hardware programmabili ad esempio push button presenti nello strumento Funzionale MustHave
137. lementazione delle varie funzioni descritte ma sar finalizzata al la descrizione delle caratteristiche peculiari della programmazione di device driver e moduli del kernel in generale e dei punti chiave nella progettazione e programmazione di tali moduli Come si pu vedere in Figura 3 7 il kernel Linux un sistema molto com plesso e comprendente numerose componenti I tipi di kernel esistenti sono sostanzialmente due microkernel e monolitico 5 Nel primo caso soltan The System Call Interface Process i i Memory i Filesystems y Device y Networking i management 2 management i control Nortel i subsystems Concurrency Files and dirs Ttys amp o Features multitasking the VFS device access Connectivity implemented sea i File system Character i i Network i Mar Memory types i devices i subsystem lependent i manager pro i 3 F O da Software 3 ia support i Fdrivers n Hardware preuerene EEN CPU Memory Disks amp CDs Consoles Network etc interfaces Ei features implemented as modules Figura 3 7 Vista del kernel linux Fonte 4 CAPITOLO 3 STUDIO DI FATTIBILITA 28 to una minima porzione delle operazioni implementata nell eseguibile del kernel ma la maggior parte delle funzionalit fornita da moduli dinamici Questo permette una maggiore dinamicit e versatilit del codice a scapito per dell efficienza visto che i vari moduli devono necessariame
138. lizzando una scheda Beagle Board 38 cfr 3 7 permettendo quindi di implementare completamente l intero protocollo di comunicazione tra host e gadget Lo strumento utilizza il protocollo standard MIDI Musical Instru ment Digital Interface 17 per la comunicazione e l esecuzione musicale Di seguito verr fornita la descrizione dettagliata del progetto procedendo come segue e verr data una descrizione generale del sistema software sviluppato cfr i e verranno descritti i requisiti di progetto cfr 2 e verr mostrato lo studio di fattibilit effettuato prima dell implemen tazione cfr 3 per quanto concerne il sistema software sviluppato e verr fornita la documentazione di progettazione del sistema anche attraverso diagrammi UML cfr 5 CAPITOLO 1 DESCRIZIONE GENERALE DEL PROGETTO Hardware Figura 1 1 Diagramma a blocchi del Thereminuz CAPITOLO 1 DESCRIZIONE GENERALE DEL PROGETTO 6 e verranno dati i dettagli tecnici dell intero sistema software sviluppato descrivendo per ogni modulo le scelte a livello implementativo cfr 6 e si tratteranno i test effettuati e i risultati ottenuti cfr 7 e infine si parler dei lavori futuri di miglioramento del sistema e si concluder la relazione cfr 8 In questo documento verr presentato soltanto quanto concerne il sistema software del Thereminux infatti soprattutto a causa dell assenza da parte dell autore di una adeguata strument
139. lmeno 40 KHz Non a caso nei sistemi audio si usa la frequenza standard di 44 1 KHz Per quanto riguarda il numero di bit solitamente i convertitori audio lavorano a 8 16 o 24 bit anche se quelli a 8 bit risultano un po datati Per una scelta appropriata del convertitore da usare per l applicazione qui esposta presentiamo infine le due principali tipologie di ADC i flash ADC e i convertitori che lavorano per approssimazioni successive 3 1 1 Flash ADC In questa configurazione mostrata in Figura 3 1 il segnale di input inviato in parallelo a una serie di comparatori di cui ognuno confronta il segnale con la propria tensione di riferimento regolata attraverso una serie di partitori di tensione solo un comparatore quindi produrr un output che verr inviato ad un encoder digitale che generer il codice per quella tensione Questo il tipo pi veloce di ADC anche se molto costoso e tende a produrre dei glitch sul segnale di output 3 1 2 ADC ad approssimazioni successive La Figura 3 2 mostra lo schema di un convertitore AD ad approssimazioni successive Il funzionamento di questo convertitore molto semplice l idea quella di effettuare vari tentativi di codifiche binarie in cui ad ogni tentativo la stringa convertita in analogico tramite un modulo DAC Digital Analog CAPITOLO 3 STUDIO DI FATTIBILITA REFERENCE RESISTOR LADDER VREF YN 2 1 COMPARATORS N BIT DIGITAL OUTPUT ENC
140. ls default Output Channels default H W Meter Ignore HW PortMaximum 256 w Input Latency default Verbose messages Timeout msec 500 v Output Latency default Figura 3 13 Uno screenshot dell applicazione QjackCtl dopo l avvenuto riconoscimento della sound card minisnd_card0 Oltre a questo andando nella tabella di routing dei dispositivi e software au dio MIDI vediamo disponibile il dispositivo di MIDI input che desideravamo Figura 3 14 sotto il nome minisnd_midi_in che era quello che avevamo impostato all interno del driver cfr Figura 3 12 CAPITOLO 3 STUDIO DI FATTIBILITA 62 JACK Audio Connection Kit default Stopped o x gt Start B Stop x Quit D Messages dye Status Setup 3 Connect I Dd Aatahhba ria a T m GCONNECLIONS JAGK Audio GONTECLION Kit Audio MIDI ALSA Readable Clients Output Ports Writable Clients Input Ports By 14 Midi Through T FY 14 Midi Through Ej 16 minisnd_card0 0 minisnd_midi_in af Connect X Disconnect gt Disconnect All 5 Refresh Figura 3 14 Uno screenshot dell applicazione QjackCtl dopo l avvenuto riconoscimento del device di MIDI input minisnd_midi_in 3 6 La conversione Voltage to MIDI Come specificato con il requisito RSW_F 3 il sistema dovr effettuare una conversione delle stringhe binarie acquisite da input attra
141. lti meno dettagli Infine altre due funzioni che possono essere molto utili per far s che il di spositivo comunichi dati importanti come particolari descrittori o stringhe non comunicati nella fase di setup esistono le apposite funzioni usb_get_descriptor e usb_get_string 3 4 Lo standard MIDI Il protocollo MIDI Musical Instrument Digital Interface uno standard commerciale dal 1983 che implementa un linguaggio completo di descrizione musicale in forma digitale La Midi Manufacturers Association MMA 29 infatti ha definito in maniera chiara ed esplicita ogni livello dello standard hardware protocollo di comunicazione messaggi ammessi in modo da crea re un modello condiviso da tutti per la comunicazione soprattutto in vista della necessit evidente dal punto di vista musicale di interconnettere mac chine di tipo e costruttore diversi Per la completa realizzazione della porta di MIDI out nello strumento cfr requisito RHW_F 4 sarebbe stato previsto lo sviluppo di una interfaccia hard ware per la conversione dei segnali elettrici generati dalla porta seriale RS 232 in segnali TTL compatibili con il MIDI come descritto in 4 1 In ogni caso come gi detto in apertura della relazione cfr 1 in questa fase dello sviluppo non sono stati implementati dispositivi hardware ma comunque stato realizzato tutto il sistema software che permette l uso del MIDI out Per questo motivo in questa sezione verranno tratt
142. lusione alleghiamo il codice relativo alle funzioni principali la probe e la disconnect per il modulo usb_minisnd Figura 3 11 e snd_minisnd Figura 3 12 La funzione usb_minisnd_probe alloca la struttura minisnd del driver e la inizializza con i dati specifici del dispositivo Per fare questo effettua una CAPITOLO 3 STUDIO DI FATTIBILITA 54 static int __devinit usb_minisnd_probe struct usb_interface interface const struct usb_device_id id static int devno static struct minisnd dev NULL struct usb_data usb_dev NULL struct usb_host_interface iface_desc struct usb_endpoint_descriptor endpoint size_t buffer_size int i int retval ENOMEM allocate memory for our device state and initialize it dev kmalloc sizeof struct minisnd GFP_KERNEL if dev NULL err Out of memory goto error i memset dev 0x00 sizeof struct minisnd usb_dev kmalloc sizeof struct usb_data GFP_KERNEL if usb_dev NULL err Out of memory goto error memset usb_dev 0x00 sizeof struct usb_data dev gt usbd usb_dev dev gt usbd gt udev usb_get_dev interface_to_usbdev interface dev gt dev amp interface gt dev dev gt devno devno set up the endpoint information use only the first bulk in and bulk out endpoints iface_desc interface gt cur_altsetting for i 0 i lt iface_desc gt desc bNumEndpoints i endpoint amp iface_de
143. lusso di dati audio in input infatti le normali applicazioni nello user space tra cui quelle che usano la libreria aubio lavorano con file in formati complessi come il WAV e non con i byte grezzi Perch un file audio RAW possa essere interpretato infatti necessario specificarne il formato di codifica audio i campioni audio possono essere codificati in molteplici modi ovvero usando rappresentazioni a 8 16 o 24 bit con o senza segno e disposte in Little Endian o Big Endian I motivi dei tanti formati chiaramente es senzialmente l esistenza sul mercato di molteplici standard commerciali che si sono diffusi nel tempo Poich come si legge in 48 il sistema Pitch to MIDI messo a disposizione dalla libreria aubio lavora con file in formato WAV stato necessario adoperare lo stesso formato ovvero una rappresentazione di campioni a 16 bit con segno Little Endian codificata in aplay con la stringa S16_LE Una volta arrivati questo buffer di byte grezzi quindi per prima cosa stato effettuato un parsing di questi dati da cui si ottiene un array di parole di 16 bit con segno per i quali normalmente si utilizzano degli short Oltre a questo necessario ottenere i valori floating point che sono rappresentati da queste parole Studiando il codice della libreria aubio ci si accorti che essa si poggia su un altra libreria utilizzata pressoch ovunque nelle applicazioni audio per Linux la libsndfile 67 In particolare
144. mandi ioctl implementati I comandi ioctl che forniti sono e ISO_IN_ZERO azzera i valori delle stringhe che vengono inviate dal dispositivo tramite l endpoint isochronous di input e ISO_IN_MULT lt val gt moltiplica i valori binari che verranno inviati sull endpoint isochronous di input per la costante moltiplicativa val e BULK_IN_DBG fa s che il dispositivo invii una stringa di debug sull end point bulk di input e ISO_IN_DBG fa s che il dispositivo invii una stringa di debug sull end point isochronous di input 5 3 5 Regole udev Sono state implementate le seguenti regole udev presenti nel file thmx_config e caricamento liberazione dei moduli in plug n play e esecuzione dello script di inizializzazione del profilo di configurazione thmx_init_profile rules CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 107 e esecuzione dello script per il controllo dell aggiornamento del profilo di configurazione thmx_check_profile e esecuzione dello script per la pulizia del sistema thmx_system_clean 5 3 6 Il diagramma dei moduli Le informazioni ricavate dalle analisi precedenti hanno permesso infine di sviluppare una modularizzazione delle funzionalit da inserire nel sistema ho st cos come in quello embedded Prima di entrare nel dettaglio di ognuno dei due qualche considerazione generale Si utilizzato un modello di progetta zione object like nel senso che come risultato dell analisi
145. mata appunto thmx In altre pa role stato pensato un sistema di comunicazione basato sull incapsulamento delle informazioni attraverso strutture di contenimento dei dati condivise I dettagli di come ci funzioni saranno chiari man mano che si entrer pi in profondit nella struttura del sistema I moduli di utilit snd_module e vtm_module esportano le loro funzioni pubbliche come simboli del ker nel utilizzando la EXPORT_SYMBOL in modo tale che il modulo principale possa richiamarle Il modulo principale come detto usb_module Que sto definisce tutti gli oggetti necessari per la gestione dei dati del sistema c un oggetto che contiene i dati per la gestione della comunicazioni USB thmx_usb un oggetto per la gestione dei dati relativi al profilo di configura zione ecc Tutti i dati definiti da tali oggetti vengono mantenuti all interno di un unica struttura chiamata struct thmx Tale struttura viene passata alle funzioni proprie dei moduli di utilit che la potranno modificare e o leggere Per capire alcuni aspetti di come questo viene effettuato vediamo nel dettaglio i vari oggetti del modulo usb_module e thmx_usb contiene una struttura con le informazioni sugli endpoint del sistema e le funzioni per operare su di essi Come vedremo nella descri zione dell implementazione cfr 6 inoltre stata definita all interno di questo oggetto una struttura di tipo thmx_usb_ops Questa in real t c
146. mite console mentre per la nostra applicazione poteva essere utile avere anche soltanto un sistema minimale che mettesse a disposizione una console con comandi base stato utilizzato allora il sistema di sviluppo OpenEmbedded 63 e lo stru mento BitBake 65 con il quale stato possibile ottenenere un interfaccia a pi alto livello per la configurazione e la compilazione dei sorgenti del kernel e la costruzione di una distribuzione ad hoc per la nostra specifica architettura target In particolare questo sistema gestisce automaticamente tutte le varie dipendenze tra i pacchetti software da includere nella distribuzione costruita in maniera da garantire una corretta esecuzione del sistema sull architettura target Per questo si proceduto seguendo 63 per la configurazione iniziale CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 129 di OpenEmbedded sul sistema host Una volta generato il kernel e la distri buzione stato implementato lo script beagle setup sd cfr 5 3 2 per la raccolta di queste informazioni e il loro inserimento nella scheda SD da usare con la Beagle Board In particolare la configurazione in locale stata effettuata seguendo i se guenti passi 1 cancellazione della directory 7 0e se esiste 2 dalla directory OE_ BASE nel sistema locale beagleboard oe angstrom build angstrom setup scripts viene lancia to lo script oebb sh messo a disposizione con OpenEmbedded e mo dificato in
147. mma a blocchi che descrive il sistema hardware usato Audio Mic Figura 4 1 Diagramma a blocchi del sistema hardware del Thereminux TT CAPITOLO 4 CENNI SULLA PROGETTAZIONE DEL SISTEMA HARDWARE78 Un microfono audio stato collegato alla Beagle Board tramite cavo audio standard con connettore di tipo jack Da qui il segnale viene convertito tramite il modulo A D presente sulla scheda 16 bit 44 1 KHz e i cam pioni bufferizzati all interno della memoria dalla quale poi vengono inviati al sistema host tramite USB Oltre a questo come specificato nel requisito RHW_F 4 il sistema dispone di un uscita MIDI out tramite la quale sareb be possibile controllare altri strumenti MIDI Questa caratteristica stata predisposta utilizzando l interfaccia RS 232 presente sulla scheda infatti il MIDI essenzialmente un protocollo seriale anche se occorre prestare qual che attenzione riguardo il collegamento di un circuito MIDI ad un cotroller seriale RS 232 I dispositivi RS 232 49 infatti lavorano su due livelli di voltaggio da 3 a 25 volt per il livello negativo e da 3 a 25 volt per quello positivo Effettuare una conversione tra segnale RS 232 e MIDI quindi non banale per prima cosa occorre programmare opportunamente il baud rate di trasmissione seriale secondo lo standard MIDI ovvero a 31 250 bit secondo Questo comunque non un grosso problema in quanto come riferito in 16 la Beagle Board permet
148. ne del dispositivo 1 la rawmidi_input_trigger implementata con la thmx_snd_rawmidi_input_trigger viene eseguita quando viene at tivata disattivata l interfaccia di ricezione MIDI dal dispositivo In pratica il core ALSA richiama questa funzione passando il substream di MIDI input allocato sul dispositivo e un flag che indica se si tratta di una attivazione o disattivazione Il driver a questo punto mantiene lo stato corrente tramite un bit in una apposita bitflag thmx_snd rxtx_enable_flag e pu valutare se possibile inviare dati al livello applicativo questo verr comunque fatto quando ci sono messaggi MIDI pronti ovvero dopo la conversione Voltage To MIDI 2 la rawmidi_output_trigger implementata con la thmx_snd_rawmidi_output_trigger fa la stessa cosa descritta al CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 138 punto precedente per quanto riguarda l output In particolare per essendo questa funzione relativa a dati che arrivano dal livello appli cativo verso il driver in caso di attivazione dell output la funzione gi esegue la reale ricezione dei dati Per fare questo richiama la funzione ALSA snd_rawmidi_transmit_peek con cui acquisisce i messaggi MIDI e successivamente chiama la thmx_snd_rawmidi_send che semplicemente utilizza la funzione di write dichiarata dall oggetto usb del Thereminux cfr 6 2 2 per inoltrare dati sulla usb 3 la rawmidi_output_drain implementata con la thmx
149. ne del dispositivo USB e fornire delle funzionalit generiche e pienamente riusabili su altri dispositivi che rispettano l interfaccia del Thereminux Tali funzionalit sono la creazione e la gestione di un dispositivo ALSA costruito su un dispositivo esistente di tipo Thereminux e la conversione Voltage To MIDI di buffer di campioni audio In questo modo si cercato di seguire quanto affermato nella presen tazione generale del lavoro cfr 1 1 e cio che il sistema software avrebbe CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 108 snd_module vtm_module RETI O terenietezento SI F ets i i l i l i l I I I I i ins ff feslsa ete i i creztese ana contains _ Calls T i a o EEES I I i j lt contains thmx_aux thread e dad i 4 _thmx usb po SARER i i eall PEENES E OA i i l I E PEL EEE lene eta sordo aaa go od po te Rieke prio _j calls Figura 5 11 Diagramma dei moduli e degli oggetti relativi al sistema host CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 109 implementato un interprete di segnali di voltaggio che arrivano da uno stru mento analogico elettronico o elettrificato generico Si pu parlare di una sorta di tipo Thereminux in quanto tutti i moduli con dividono una singola struttura di dati chia
150. nel convertitore RS232 to MIDI sviluppato Dopo aver effettuato tutti i test statici del caso usando un normale tester per verificare i valori di voltaggio nei vari punti del circuito cos come inviando segnali fissi di voltag gio in input del circuito e vedendo l output che hanno dato risultati positivi si deciso di rimandare ad un momento futuro in cui si avr a disposizione un oscilloscopio o un logic analyser con il quale poter confrontare i segnali in uscita da dispositivi differenti Per esempio la scheda Audiophile ha integra ta una porta di MIDI out che invia segnali correttamente Per verificarlo stato collegata in loopback con la porta di MIDI in della stessa scheda e poi i messaggi prodotti dal Thereminux sono stati inoltrati tramite jack control su tale MIDI out hardware I valori ottenuti sul MIDI in della Audiophile CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 160 quindi sono stati inviati al sintetizzatore software con il risultato le note so no state suonate correttamente Per questo con l ausilio di un oscilloscopio sar possibile acquisire un campione prodotto da tale porta di MIDI out e confrontarlo con quello prodotto dalla scheda sviluppata Questo permetter di ottenere dati rilevanti sul segnale che viene generato da tale scheda Capitolo 8 Conclusioni possibili miglioramenti e integrazioni Sebbene il lavoro abbia richiesto un tempo maggiore di quello pensato al l inizio i risultati so
151. nfigurazione In questo caso il profilo rimarrebbe in uno stato obsoleto rispetto al reale valore mantenuto dal driver Per ov viare a ci sarebbe stato necessario che ogni chiamata alla funzione store causasse un controllo del file del profilo di configurazione per verificarne l in tegrit rispetto ai dati contenuti nel kernel e sul gadget Il problema in questa soluzione sta nell evidente inutilit di effettuare questo controllo anche quan do il file di configurazione stesso ad essere stato modificato e le chiamate alla store si effettuano come una registrazione di queste modifiche tramite l apposito script di conferma Infatti qui non possibile che i dati inviati al kernel siano diversi da quelli del file di configurazione derivando questi dati proprio da tale file Per questo stata utilizzata una doppia strategia per far s che nel caso in cui l apposito programma di riconfigurazione del profilo a scrivere sui file del sysfs il controllo di integrit del file di configurazione non venga fatto ma invece venga effettuato solo quando un utente root esegue delle scritture CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 103 direttamente sui file del sysfs e il programma di riconfigurazione del profilo aggiunge ai buffer di scrit tura sul sysfs una stringa di prefisso la stringa THMXCFG_ che quando riconosciuta dal kernel previene l invocazione del controllo sul file di configurazione e se questa
152. ngono associate le funzioni per la gestione degli eventi e i vari descrittori per la sua identificazione Infine la sound card viene registrata presso ALSA tramite la funzione snd_card_register La disconnessione dello strumento viene gestita dalla funzione usb_minisnd_disconnect che richiama la snd_minisnd_remove la qua le non fa altro che deallocare la sound card tramite la snd_card_free Infine il dispositivo viene deregistrato presso il bus USB tramite la funzione usb_deregister_dev CAPITOLO 3 STUDIO DI FATTIBILITA 58 int snd_minisnd_probe struct minisnd sd int err int devno struct snd_rawmidi mididev NULL struct snd_rawmidi_ops midi_ops struct snd_card card NULL char id_card_string 25 char id_midi_string 25 struct file_operations fops static struct snd_device_ops ops dev_free minisnd_chip_free if sd sd gt usbd I sd gt dev return EINVAL devno sd gt devno if devno gt SNDRV_CARDS return ENODEV if enable devno devnot return ENOENT snprintf id_card_string sizeof id_card_string minisnd_card d devno snprintf id_midi_string sizeof id_midi_string minisnd_rawmidi d devno err snd_card_create SNDRV_DEFAULT_IDX1 id_card_string THIS_MODULE devno amp card if err lt 0 return ENOMEM strcpy card gt driver minisnd strcpy card gt shortname id_card_string sprintf card
153. no sembrati piuttosto soddisfacenti Naturalmente nei capitoli precedenti sono stati trattati alcuni aspetti riguardanti l uso del l applicazione finale implementata che hanno bisogno di alcune migliorie Tra questi l accuratezza della conversione delle note ricevute in input un punto importante da sviluppare e che probabilmente richieder l ausilio di tecniche pi avanzate coma la onset detection come spiegato nel paragrafo 7 2 Inoltre la possibilit di utilizzare come era stato auspicato all inizio uno strumento come il Theremin in grado di generare delle sinusoidi pure potrebbe semplificare di molto il processo di riconoscimento delle note es sendo la voce umana cos come la maggior parte degli strumenti acustici molto complessa nella sua composizione armonica Infine l invio di note di MIDI out attraverso lo strumento stato implementato in software ma an cora manca l interfaccia hardware per il collegamento fisico dello strumento creato con altri dispositivi Detto ci il sistema sviluppato ha rappresentato un esercizio importante di implementazione kernel side permettendo di esplorare svariati sotto sistemi e API messe a disposizione del kernel Dato il personale interesse dell autore per lo sviluppo a basso livello questo lavoro rester una risorsa importante a cui attingere anche nella prosecuzione della carriera di studio e professionale 161 Bibliografia 1 2 3 4 7 8
154. ntazione tecnica 15 in questo modo si trovata la locazione dove la porta UART3 quella che si inter faccia al connettore RS232 sulla Beagle Board mappata in memoria fisica cio OMAP_UART3_BASE 0x49020000 Da qui la zona di memoria utilizzata per le porte di I O non pu essere trattata allo stesso modo delle normali zone in RAM ad esempio per queste importante che venga mantenuto stretta mente l ordine delle operazioni che vengono specificate nel driver evitando possibili ottimizzazioni da parte del compilatore che potrebbero portare a cambiare l ordine delle scritture sulle linee fisiche Inoltre la memoria di I O rappresenta la zona di memoria messa a disposizione proprio dal chip interes sato in questo senso esistono zone dedicate ai trasferimenti audio ethernet di dati grafici ecc Tra questi il processore OMAP3550 usa una zona di I O relativa alla porta UART che dobbiamo usare Per ottenerla per prima cosa dobbiamo effettuare una traduzione dell indirizzo di memoria fisica di cui disponiamo verso una area di memoria virtuale che permetta l accesso a tale zona di I O e questo fatto tramite la ioremap_nocache usata qui la CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 147 versione _nocache perch nella stessa area di I O sono presenti registri per la scrittura dei dati e per la configurazione dell hardware per cui non de siderabile il caching delle operazioni Successivamente come mos
155. nte comuni care tra loro attraverso una qualche forma di messaggi Nel secondo caso invece il kernel implementato come un unico blocco di codice che contiene tutte le funzionalit Questo approccio bench manchevole di modularit e quindi pi rigido pu portare ad una maggiore efficienza visto che il codice del kernel collegato staticamente e quindi l accesso alle varie funzionalit immediato L approccio del kernel Linux in qualche modo cerca di sfruttare i vantaggi di entrambe le scuole esso infatti sostanzialmente un kernel monolitico in Figura 3 7 vediamo che la gran parte dei sotto sistemi imple mentati sono statici con un ampio supporto alla modularizzazione tramite l utilizzo di moduli dinamici che possono essere aggiunti e tolti in runtime Inoltre per una volta aggiunto il codice di ogni modulo equiparabile al codice collegato staticamente al kernel eliminando quindi la necessit del lo scambio di messaggi e mantenendo l efficienza infatti i moduli possono comunicare tra loro e con le funzionalit principali del kernel semplicemente tramite l invocazione delle funzioni che implementano tali funzionalit I device driver fanno appunto parte dei moduli del kernel I device driver si occupano di fornire uno strato software che nasconde alle applicazioni uten te i dettagli dei vari dispositivi hardware fornendo un interfaccia composta da funzioni standard le system call che le applic
156. nte user di leggere il profilo di configurazione Precondizioni Il sistema deve essere stato inizializzato profilo di configurazione caricato Flusso principale 1 L utente user esegue il comando di lettura del profilo di configurazione 2 Il sistema host legge il profilo di configurazione e lo stampa in forma tabulare Flussi alternativi Postcondizioni Il sistema host ha stampato correttamente il profilo di configurazione per l utente Nome Caso d uso ReadCtlCommands ID CU 3 Attori User Descrizione Permette all utente di conoscere l elenco dei comandi di controllo Precondizioni Il sistema host deve essere stato inizializzato profilo di configurazione caricato Flusso principale 1 L utente esegue il comando di lettura dei comandi di controllo 2 Il sistema host legge il profilo di configurazione e stampa in forma tabulare i comandi Flussi alternativi Postcondizioni Il sistema host ha stampato correttamente i comandi di controllo per l utente CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 83 Nome Caso d uso ExecCtlCommand HW ID CU 4 Attori User Descrizione Permette all utente di eseguire un comando di controllo tramite hardware programmabile Precondizioni Il sistema deve essere inizializzato e attivo dispositivo hardware acceso e collegato all host moduli del kernel caricati e pronti
157. nza di byte simile a quella seguente 0x90 0x3C 0x7F Questo invia un messaggio di Note On 0x90 cfr Tabella 3 1 specificando la Nota numero 0x3C cfr ad esempio 31 per una tabella riassuntiva dei valori delle note nel MIDI e la velocity 0x7F ovvero la rapidit di esecuzione della nota nel MIDI questa viene presa come parametro che definisce l intensit della nota stessa Nel momento in cui la nota finisce perch il tasto della tastiera viene rilasciato viene inviato il messaggio seguente 0x90 0x3C 0x00 ovvero un messaggio di Note On con velocity uguale a 0 in alternativa si poteva mandare anche un messaggio di Note Off Quando vengono inviati diversi messaggi relativi allo stesso Status Byte il protocollo MIDI permette di specificare questo Status Byte soltanto la prima volta In questo modo ad esempio lo stream appena esaminato pu essere inviato nel modo seguente 0x90 0x3C 0x7F 0x3C 0x00 Questo ha esattamente lo stesso effetto che ripetere lo Status Byte miglio rando per l efficienza della comunicazione CAPITOLO 3 STUDIO DI FATTIBILITA 46 Messaggi MIDI relativi ad un numero di canale Nome Descrizione Valore esade Byte di dati cimale Note Off Indica che una cer da 0x80 a 0x8F 2 il primo specifica ta nota deve essere il numero di nota 0 rilasciata 127 e il secondo la velocity 0 127 Note On Indica che una certa da 0x90 a 0x9F 2 il primo specifi nota deve e
158. nza di ini zializzazione in cui sia il sistema embedded che quello host sono coinvolti La linea tratteggiata al centro del macro stato principale simboleggia l ese cuzione concorrente dei due stati contenuti In questo caso il sistema host e quello embedded sono eseguiti naturalmente in parallelo con degli esplici ti punti di sincronizzazione dell esecuzione corrispondenti agli istanti in cui una delle due macchine avvia una comunicazione con l altra Chiaramente come si pu anche constatare consultando il codice dell implementazione del sistema lo stato Sending Setup Data d qualitativamente la descrizione del flusso di setup del sistema che in realt coinvolge pi interazioni in cui il sistema host richiede le configurazioni al sistema embedded ne seleziona una e richiede le stringhe che compongono il profilo di configurazione Per il resto la sequenza abbastanza semplice ma una cosa importante da notare la presenza dello stato Setup Config Profile che avviene dopo la ricezione dei dati di setup da parte del dispositivo Infatti all interno del dispositivo verr salvato sottoforma di pi descrittori stringa un profilo di configurazione di default che risulta funzionante con il dispositivo stesso In questo modo alla fine della procedura di inizializzazione il profilo di configurazione sar gi caricato sul sistema host per i dettagli sul profilo di configurazione si veda 5 3 1 90 CAPITOLO 5 PROGETTAZ
159. nzione come estensione del device driver minisnd presentato sopra cfr 3 5 che pubblica sotto la directory kobject del dispositivo un altra directory chiamata ProvaConfig e un file all interno di essa La Figura 5 9 mostra il codice di questa funzione La struttura thmx_config si presenta come segue struct thmx_config char config_name struct kobject config_kobj char attri a config_name il nome della directory base rappresentata dal kobject config_kobj la stringa attr1 mantiene l informazione della stringa da pub blicare all interno dell attributo La funzione dopo aver inizializzato il ko bject inizializza l importante struttura kobj_type Questa contiene la fun zione release che viene richiamata quando il reference count per questo kobject arriva a zero una lista di attributi e un puntatore ad una struttura sysfs_ops Quest ultima contiene soltanto due funzioni la show viene richiamata ogni volta che si tenta di leggere i file degli attributi di questo tipo e la store implementa la scrittura su tali file Per questo esempio le funzioni che vengono salvate su questi puntatori sono solo fittizie ma altri menti possono implementare la lettura e scrittura dei dati sui file del sysfs In particolare la show sar implementata ritornando la stringa relativa all attributo da leggere mentre la store modificher l attributo Dopo aver inizializzato le varie strutture la creazione del kobjec
160. o la bandwidth richiesta per i trasferimenti i limiti sulla dimensione dei pacchetti trasferiti le caratteristiche dell endpoint associato alla pipe ad esempio la dire zione del flusso il tipo di trasferimento In particolare lo USB definisce quattro tipi di trasferimento di dati Control trasferimenti di tipo non peridico richiesti dall host per funzioni di controllo del dispositivo CAPITOLO 3 STUDIO DI FATTIBILITA 23 Isochronous comunicazioni di flussi continui di informazioni che hanno dei requisiti stringenti di tempo real time Interrupt trasferimenti periodici di pacchetti di solito piuttosto piccoli di informazioni che vanno gestite con una certa urgenza Bulk trasferimenti non periodici di grandi quantit di dati che non hanno particolari requisiti di tempo ma possono anche subire ritardi senza per questo intaccare la qualit della comunicazione Quindi ad attach time Vhub principale dell host rileva un nuovo dispositivo consultando un opportuno status bit quando il dispositivo viene rilevato ini zia la fase di configurazione in cui prima di tutto l host assegna un indirizzo univoco al dispositivo successivamente tramite la Default Control Pipe l ho st richiede al dispositivo tutte le informazioni relative alla struttura dei flussi di comunicazione necessari al dispositivo stesso interfacce endpoint ecc Successivamente il device driver sull host alloca tu
161. o dei messaggi al livello applicativo soltanto una volta ogni 5 buffer ricevuti Anche questo pu causare qualche leggero spostamento delle note di output rispetto a quelle correntemente inviate Infine come trattato anche nella tesi 13 in cui si cercato di sviluppare un controller MIDI basato sulla voce confrontando diversi metodi e librerie i risultati sperimentali della pitch detection della libreria aubio presi da soli sono spesso non troppo accurati In quella tesi infatti visti gli scarsi risultati dei metodi soltanto basati su pitch detection si deciso di adoperare un approccio pi complesso in cui i flussi audio sono prima sottoposti ad un algoritmo di onset detection riconoscimento della CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 155 presenza o meno di una nota nel segnale e l output di questo poi usato per la pitch detection Dunque sembra che sarebbe necessario un un ulte riore approfondimento di queste tecniche di manipolazione di segnali audio rimanendo la questione dell estrazione dei valori di pitch da tali segnali uno dei problemi aperti all interno del Digital Signal Processing 7 3 Test dei comandi di controllo Ognuno dei comandi di controllo stato testato ed risultato funzionante Per cominciare una volta collegato lo strumento il file di configurazione vie ne creato sul desktop cfr Figura 7 3 non leggibile n scrivibile dall utente comune Tramite il comando thmx_read_p
162. ociazione tra comandi di controllo dell esecuzione dello strumento e elementi hardware programmabili pre senti In questo modo si pu impostare lo strumento affinch un certo comando venga eseguito quando l elemento hardware associato viene utilizzato Ad esempio un comando di controllo pu essere eseguito quando viene premuto un pulsante programmabile 7 MIDI out indica se possibile inviare messaggi MIDI di output attra verso lo strumento Questa funzionalit pu essere utilizzata quando lo strumento collegato oltre che al computer tramite USB anche ad un altro dispositivo MIDI compliant tramite cavo MIDI standard In questo modo un applicazione MIDI che gira in user space pu invia re messaggi MIDI standard tramite il device driver allo strumento il quale li inoltrer al dispositivo MIDI collegato Questa architettura pu essere utilizzata quando si vuole controllare altri dispositivi MIDI tramite lo strumento un applicazione molto comune con la tecnologia MIDI 1 1 2 Gestione dell esecuzione In runtime ovvero una volta caricato il modulo del kernel nel sistema host come si vede in Figura 1 1 il device driver in grado di fornire quattro caratteristiche principali all utente 1 lettura del profilo di configurazione la configurazione hardware cor rente pu essere consultata dinamicamente tramite opportuni comandi dallo user space 2 interfaccia MIDI standard quando l hardware invia dei valor
163. ogni puntatore a funzione di cui si vuole fornire un implementazione viene assegnato alla funzione realmente implementata all interno del driver si noti come il primo puntatore non punta ad alcuna funzione ma bens ad un identificativo del modulo che possiede la struttu ra dichiarata Una volta che il driver risulta attivo dunque le applicazioni potranno richiamare ad esempio la system call open sul file del dispositivo e questo far s che il kernel richiami la funzione assegnata al puntatore open dentro scull_fops ovvero la scull_open Questa funzione potr eseguire ogni inizializzazione di cui necessita la comunicazione con il dispositivo Ma come avviene questa attivazione del device driver all interno del siste ma Dopo aver allocato all interno del sistema lo spazio ovvero il Major number per il device driver successivamente si procede a registrare il dispositivo provvedendo alla creazione di un Minor Number associando al dispositivo la struttura file_operations desiderata e infine aggiungendo effettivamente il dispositivo al sistema tramite nel caso di dispositivi a caratteri la funzio ne cdev_add Questo rende il device driver pronto a ricevere richieste in qualsiasi momento L aggiunta del nodo sotto dev deve poi essere eseguita separatamente uti lizzando il Minor e il Major Number Questa operazione viene effettuata tramite la system call mknod oppure caso per noi pi interessante tramite u
164. oli a cui si pu far riferimento all interno del kernel la __kstrtab contiene l elenco dei nomi dei simboli disponibili mentre la __ksymtab e la __ksymtab_gpl registra gli indirizzi di memoria rispettivamente dei normali simboli del kernel e di quelli che vengono esplicitamente detti compatibili con la licenza GPL Infatti il kernel Linux per promuovere lo sviluppo di software libero e scoraggiare l inserimento di parti proprietarie all interno del proprio codice utilizza fondamentalmente due strategie far s che parti sostanziali del kernel come l algoritmo di gestione della memoria o di scheduling siano incluse staticamente nel kernel e rendere disponibili alcune funzionalit del kernel soltanto ai moduli che dichiarano di essere compatibili con la licenza GPL Oltre alle sezioni descritte per la gestione dei simboli del kernel ogni modulo descritto all interno del kernel da una apposita struttura module contiene l insieme dei simboli che pubblica usando gli elementi syms e gpl_syms della CAPITOLO 3 STUDIO DI FATTIBILITA 30 struttura module Cosi in fase di linking tali simboli possono essere pubbli cati nel sistema all interno del file proc kallsyms per poi essere cancellati da questo file quando il modulo scollegato Quindi a causa del fatto che i moduli vengono eseguiti in un contesto dove molte risorse vengono naturalmente condivise la programmazione dei moduli del kernel richiede una serie di consider
165. ollo cfr 1 1 1 e requisito RSW_F 11 La Figura 5 6 mostra i dettagli di questo scenario Da notare il controllo sui privilegi dell utente chiamante solo un utente pri vilegiato infatti pu effettuare questa operazione e la correttezza del pro filo di configurazione che si vuole impostare come specificato nei requisiti RSEC_NF 4 e RSEC_NF 9 Inoltre gi lo script di livello applicativo effet tua un controllo sul file di configurazione da impostare per poi delegare il controllo sulla semantica del contenuto al kernel Esecuzione di un comando di controllo Questa operazione descritta in Figura 5 7 si riferisce allo scenario in cui dal lato host viene invocato tramite un opportuno comando dallo user space un comando di controllo dello strumento cfr requisito RSW_F 15 Questo scenario come si vede molto simile al precedente a parte l assenza del controllo dei privilegi ogni utente pu utilizzare questi comandi e il fatto che viene sempre stabilita una connessione con il dispositivo hardware per questa operazione visto che quest ultimo che eseguir fisicamente i comandi di controllo Anche qui l applicazione esegue prima di passare il controllo al kernel delle verifiche sui comandi richiesti se questi sono mal formati o inesistenti si dar un messaggio di errore e non verr invocato il kernel 92 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE IGIW Bulkeldg 9 0U IGIW Jos BUINEM uonesijddy H
166. ompletion ogni volta che il thread padre risveglia un figlio per la terminazione utilizza la funzione wake_up_interruptible_sync la quale fa s che il processo chiamante mantenga la cpu anche dopo la chiamata a tale funzione che comunque non atomica Questo per evi tare che il thread figlio acquisisca il processore prima che il thread chia mante non lo stia aspettando per la terminazione Infatti subito dopo la chiamata a wake_up_interruptible_sync il thread chiamante esegue la wait_for_completion attendendo cos la terminazione del thread sve gliato Questo una volta risvegliato e dopo aver notato che il modulo si trova in uno stato di terminazione prima di uscire chiama la complete che risveglia il processo in attesa di tale terminazione Capitolo 7 Test effettuati e risultati ottenuti Il sistema in esecuzione mostrato in Figura 7 1 Figura 7 1 Il setup del Thereminux in esecuzione Come si nota il sistema host stato collegato alla Beagle Board tramite cavo USB Mini AB che permette anche la funzionalit OTG cfr 6 1 2 Inoltre La Beagle Board mette a disposizione la sua porta RS232 tramite un header 150 CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 151 hardware a 10 pin 16 per cui stato necessario implementare un cavo per convertire questo connettore in un classico connettore seriale a 9 pin Da questo tramite un cavo Null Modem 68 il cavo seriale stato collegato ad un con
167. one che ne viene fornita in 4 e 5 si riferisce al kernel 2 6 11 che purtroppo ha subito delle modifiche nelle successive versioni dal la 2 6 13 27 e quindi divenuta purtroppo obsoleta Il modello valido fino al kernel 2 6 12 infatti prevedeva che il kernel generas se attraverso il device model un evento di hotplug ogniqualvolta avveniva un cambiamento nella configurazione del sistema ovvero ogni volta che veniva creato o eliminato un kobject Questo evento veniva catturato nello user space da alcuni script di hotplug che potevano eseguire diverse operazio ni utilizzando variabili di ambiente che venivano impostate dal kernel come parte dell evento di hotplug Il programma udev si limitava ad utilizzare le CAPITOLO 3 STUDIO DI FATTIBILITA 38 informazioni pubblicate nel sysfs per creare i nodi dei dispositivi nel filesy stem I sistemi attuali implementano un modello interamente basato sul manager dei dispositivi udev 27 28 Udev un applicativo formato da un demone udevd che rimane in ascolto su un socket di tipo PF_NETLINK e sulla por ta NETLINK_KOBJECT_UEVENT di particolari eventi generati dal kernel che vengono chiamati uevent Il kernel genera un uevent impostando variabili di ambiente e quant altro possa far reagire udev nel modo corretto Questa reazione da parte di udev avviene attraverso una serie di regole che ven gono scritte all interno di file statici posti nel sistema di chi scrive nell
168. one di 8 bit pu produrre fino a 28 256 valori discreti In alternativa attraverso il numero di bit utilizzati si pu esprimere la risoluzione del convertitore come la di mensione in volt dell i simo intervallo in cui possibile dividere il valore complessivo di voltaggio del segnale di input In altre parole si pu scrivere _ Vretut Vref LOW a 2M 1 dove Vrerar VrefLow SONO rispettivamente il valore massimo e mini mo di voltaggio che il segnale pu raggiungere e M il numero di bit del convertitore e Frequenza di campionamento poich il segnale realmente ricostruito a partire dall insieme dei punti discreti ottenuti con il campionamen to attraverso formule di interpolazione necessario essere sicuri che i campioni siano presi abbastanza frequentemente da riuscire a rico struire con una fedelt accettabile il segnale originale Il teorema di Shannon Nyquist 21 a questo proposito afferma che per ricostrui re una qualsiasi forma d onda necessario avere a disposizione una frequenza di campionamento almeno uguale al doppio della massima frequenza presente nel segnale e Accuratezza si riferisce alla vicinanza del numero digitale trovato rispetto al valore reale di voltaggio del segnale Fonti di errore in questo senso sono Errori di quantizzazione inevitabili a causa del numero finito di bit che vengono usati per la conversione in generale dati n bit possibile esprimere
169. ontiene un solo puntatore a funzione la write che viene utilizzata per la comunicazione tra il modulo snd_module e quello usb_module Infatti la creazione del dispositivo MIDI fa s che ALSA crei i suoi pro pri nodi nel filesystem solitamente sotto dev snd Le applicazioni ALSA compliant come jack prendono come riferimento questi nodi e non quelli creati dal modulo USB In questo modo non si avrebbe ac cesso all implementazione dei metodi per la reale lettura scrittura di dati USB dal modulo snd_module visto che questi vengono dichiarati dentro usb_module Al fine di risolvere questa questione per effettuare la scrittura di dati MIDI sul dispositivo USB quando questi vengono inviati al Thereminux usando il file ALSA si salver un puntatore alla funzione che si occupa di inoltrare questi dati MIDI al sistema embed ded funzione di cui mantenuto un riferimento dentro la struttura thmx_usb che contenuta a sua volta dentro thmx Un puntatore alla struct thmx verr sempre salvato tra i dati privati delle altre struttu re di utilit ad esempio la struct snd_card di ALSA per cui sar sempre accessibile dai diversi moduli e dalle diverse funzioni di call CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 110 back In questo modo quando il snd_module riceve dati sul file ALSA pu inoltrarli al modulo usb_module utilizzando la funzione salvata Questa la motivazione della relazione calls descritta nel diagram ma in Figur
170. osite funzioni per provvedere alle risposte In questo modo l oggetto thmx_gadget riceve le richieste di setup standard funzione stardard_setup_req e ne effettua il parsing valutando il va lore dei vari campi della richiesta cfr 3 2 3 come il bRequest per il no me della specifica richiesta e il w_value contenente l argomento opzionale passato insieme alla richiesta Tra le funzioni pi importanti richiamate all interno di questo parsing c gthmx_usb_req_send_desc definita in gadget thma_ gadget_ usb c che tra i suoi parametri prende in argomento il tipo di descrittore da consegnare e lo ritorna Questa funzione anche usata per inviare i descrittori stringa relativi al profilo di configurazione Dal punto di vista dell host la situazione pi semplice Infatti il sotto sistema USB del kernel si occupa di inviare queste richieste di setup al gad get e di costruire la struct usb_interface che viene passata alla funzione thmx_probe descritta sopra Nell inizializzazione dell oggetto usb vedi la funzione thmx_usb_init in host usb_module thma_usb c tale struttura dell interfaccia USB viene usata per verificare che il dispositivo connesso seppure dichiara di poter essere gestito da questo driver tramite il suo ven dorID e productID effettivamente mette a disposizione tutti gli endpoint necessari per l esecuzione In tal caso vengono allocate tutte le strutture dati per la gestione di questi endpoint nonch
171. ostrata in Figura con il nome di thmx_usb_write implementata all interno di thmx_usb Tale funzione semplicemente inoltra i dati sull endpoint specifico per il MIDI out Sequenze del sistema embedded Passiamo ora a considerare il punto di vista del sistema embedded Poich l API del kernel Linux relativa a questo sistema si riferisce ai gadget i vari prefissi dei nomi seguono questo stile per cui ad esempio il modulo del kernel si chiama gadget_module In particolare le funzioni di questo modulo vengono di solito iniziate con il prefisso gthmx dove appunto la g sta per gadget La Figura 5 18 mostra la fase di inizializzazione del sistema da questo punto di vista In maniera simile a quanto visto per il sistema embedded anche qui l oggetto centra le thmx_gadget implementa la funzione di inizializzazione principale la bind e dopo aver allocato le strutture dati richiama le funzioni di inizia lizzazione degli altri moduli impostando cos gli endpoint la porta seriale il dispositivo a caratteri per I O dal livello applicativo gli elementi hardware programmabili e infine alloca anch esso un kernel thread interno che per mette di gestire i comandi di controllo che arrivano dal sistema host Infatti tali comandi arrivano dal callback che viene eseguito alla fine dell URB su uno degli endpoint interrupt Da questo contesto generalmente indicato non eseguire operazioni arbitrarie e i coman
172. per lavorare a questa velocit cos come anche il driver sul gadget In questo modo avviene la seguente cosa la fase di avvio della Beagle Board controllata dal boot loader ed impostata di default a 115200 bps non viene interpretata correttamente da minicom e risulta in una serie di caratteri illeggibili fino ad arrivare all inizializzazione di thmx_gadget che riconfigura la velocit della porta e fa s che quanto stampato successivamente si legga correttamente e in ultimo si verificato che le scritture effettivamente avvenissero Per fare questo si reimpostato il baud rate a 115200 cos da permettere un debug tramite minicom e si iniziato a inoltrare quanto arriva va sulla porta di MIDI in del Thereminux alla sua porta di MIDI out Questo ha fatto s che i messaggi prodotti venissero direttamente inol trati al gadget e che questo li scrivesse sulla linea seriale Il risultato mostrato in Figura 7 8 Sulla destra vediamo l editor di connessioni di jack control Qui la porta di MIDL in stata collegata oltre che con il solito sintetizzatore software anche con il MIDI out dello strumento Sulla sinistra vedia mo la finestra che mostra i dati scritti sulla seriale dallo strumento che vengono riportati da minicom come una serie di byte effettivamente in viati Il fatto che questi byte siano visualizzati in parte illeggibili nella finestra di minicom pur essendo il baud rate quello corretto dovuto al fatto che
173. pu iniziare la configurazione generale di tutto ci che serve per ottenere i sorgenti del kernel da installare sulla macchina tar get tramite bitbake c configure virtual kernel dove virtual kernel specifica il kernel migliore per l architettura ri chiesta e specificata nel file di configurazione l interfaccia offerta da bitbake permette di eseguire una serie di comandi come bitbake c clean lt pacchetto gt bitbake c compile lt pacchettoltarget gt bitbake c deploy lt pacchetto target gt rispettivamente per il reset dell ambiente la compilazione e la distri buzione di un pacchetto ad esempio linux 2 6 32 o di un target generico A questo proposito su 64 vengono descritti diversi target standard forniti da OpenEmbedded per generare diverse tipologie di distribuzioni di base ad esempio includendo o no le librerie grafiche ecc Come detto all inizio del paragrafo per il sistema embedded del Thereminux stata utilizzata una distribuzione con le sole funzionalit di base 8 successivamente stata utilizzata una configurazione del kernel modifi cata rispetto a quella messa a disposizione dalla distribuzione Angtrom Partendo da questa sono state fatte le seguenti modifiche a stato disabilitato il supporto ai pulsanti GPIO device_drivers gt input_device_support gt keyboards gt gpio_buttons in quanto caricava un modulo che registrava la linea di GPIO che corrisponde al pulsante programmabile della Bea
174. r NN SendMIDI OUT ExecCtiCommand HW ExecCtlCommand SW Modify Config Privileged user ConfirmConfig i Figura 5 1 Diagramma dei casi d uso per il sistema ottenerne una visione migliore La Figura 5 1 mostra quali sono i casi d uso con cui l interazione avviene Ogni caso d uso rappresenta un flusso di azioni che parte da un input del l utente Come possibile vedere vengono mostrati utenti umani e non Ad esempio le applicazioni MIDI che girano nello user space del sistema host vengono considerate utenti in quanto interagiscono con il sistema co me tali Questo vale anche per i dispositivi MIDI esterni che possono essere collegati al sistema tramite la porta hardware di MIDI out al momento non implementata Gli utenti umani sono di due tipi utente non privilegiato o privilegiato Quest ultimo pu effettuare sul sistema tutte le azioni concesse al primo da cui mostrato come estendere l utente non privilegiato ere ditandone cos le possibilit di interazione Il sistema a cui si fa riferimento all interno del diagramma contiene sia gli aspetti del sistema software che di quello hardware infatti come si nota sono presenti elementi di interazione sia del primo che del secondo tipo Per chiarezza comunque nel seguito si fa r riferimento al sistema embedded o semplicemente gadget quando si parla CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 81 del software che gira sul disposi
175. rceforge net projects u boot 42 Real Time Linux Wiki rtwiki webpage https rt wiki kernel org 43 A realtime preemption overview lwn net Linux info from the source http lwn net Articles 146861 44 Workqueues get a rework lwn net Linux info from the source http lwn net Articles 211279 45 Hyper Low Latency Audio with a Real Time Kernel youtube video tu torial http www youtube com watch v zzvyVihyDYc 46 Kernel Locking Techniques Linux Journal website http www linuxjournal com article 5833 47 Version 1 3 0 of set_rlimits Jonathan Woithe s Home page http www physics adelaide edu au jwoithe set_rlimits 1 3 0 tgz 48 aubio a library for audio labelling aubio website http aubio org 49 RS 232 specifications and standard Lammert Bies Computer Interfa cing website http www lammertbies nl comm info RS 232_specs html 50 Driving Me Nuts Things You Never Should Do in the Kernel Linux Journal http www linuxjournal com article 8110 51 Qsynth Qt GUI Interface for FluidSynth Qsynth website http qsynth sourceforge net BIBLIOGRAFIA 166 52 M Audio website http www m audio com 53 Using the M Audio Audiophile USB Digital Audio Interface with Linux http people uleth ca daniel odonnell Blog using the m audio audiophile usb digital audio interface with linux 54 kernel build cp config oldconfig xconfig LinuxMusicians website http www linuxm
176. re composto da tutte le funzionalit messe a di sposizione dal sistema operativo dell host per gestire lo USB a basso livello fornendo cos al programmatore un interfaccia sulla quale basare lo sviluppo del driver specifico del dispositivo il livello di funzione ogni funzione composta da un insieme di inter facce ognuna delle quali raggruppa l insieme di endpoint che la imple mentano Un dispositivo che implementa pi di una interfaccia viene detto composite device A questo livello la comunicazione logica avvie ne tra client software lato host ovvero il device driver vero e proprio e una interfaccia sul dispositivo Questa astrazione permette al soft ware sull host di concentrarsi sul richiamare le funzionalit descritte dall interfaccia del dispositivo utilizzando quindi un particolare bundle di endpoint associati a quella interfaccia Per chiarire meglio dunque il dispositivo definisce una serie di endpoint ognuno con le sue caratteristiche identificativo direzione della comunicazio ne Oltre a questo definisce una o pi interfacce con le funzioni specifiche fornite dal dispositivo La comunicazione logica tra il software sull host e un endpoint sul dispositivo avviene attraverso una pipe USB ovvero un flusso di comunicazione che permette di accedere ad un certo endpoint dal soft ware sull host definendo le caratteristiche di questa comunicazione Le pi importanti tra queste caratteristiche son
177. re directory ogni attributo in esse contenuto sar nella forma oggetto x dove x un indice incrementale Il contenuto di questi file sar una stringa la cui semantica va ria a seconda della directory gli attributi sotto la directory programmableHW saranno stringhe con la descrizione del tipo di hardware disponibile e l indice separati dal carattere Per il prototipo del Thereminux stata inclusa la sola stringa PUSHBUTTON 0 visto che come detto in precedenza cfr 4 1 presente un unico pulsante programmabile a rappresentare questi elementi Per quanto riguarda i comandi di controllo questi sono stati scritti sui file tramite stringhe nella forma COMMAND x con x l indice del comando Infine i file con le associazioni contengono delle stringhe nella forma x y dove x e y sono valori interi rappresentanti rispettivamente un indice di un elemento hardware e un indice di un comando Vista l organizzazione con cui il profilo di configurazione viene impostato nel sysfs segue che anche sul sistema embedded i dati relativi al profilo di configurazione sono stati mantenuti in diversi descrittori stringa ognuno formattato come nome_attributo valore_attributo dove il nome dell at tributo quello che diventera il nome del file relativo sul sysfs Il file prodotto dallo script in user space stato posto in una directory di configurazione del sistema in questa fase prototipale del sistema all interno del Desktop
178. re un task in sleep e ripristinarlo crea un overhead ag giuntivo che non giustificabile se il tempo di mantenimento del lock troppo breve 46 e visto che tali sezioni critiche diventano preemptible anche l uso delle cosiddette variabili per CPU necessita una maggiore cura infatti possibile che un processo che si trova all interno di una sezione critica in cui sta per aggiornare la variabile per CPU perda il controllo della CPU e venga messo in scheduling su un altra CPU il che far s che aggiorner la variabile sbagliata visto che come noto una variabile per CPU viene mantenuta in diverse copie per i diversi processori Per evitare ci in questo caso necessario disabilitare esplicitamente la preemption per il tempo necessario all aggiornamento della variabile Questo pu essere fatto utilizzando la funzione get_cpu_var o la CAPITOLO 3 STUDIO DI FATTIBILITA T2 preempt_disable oppure usando un lock specifico per le variabili per CPU e nel caso in cui si rende necessario utilizzare gli spinlock nel modo tra dizionale sempre possibile dichiararli come raw_spinlock_t e utiliz zando la stessa API dei classici spinlock_t La patch stata pro gettata per implementare una sorta di method overridding in cui le medesime funzioni si comportano nella maniera classica se gli viene passato un raw_spinlock_t mentre eseguono il locking preemptive in caso di spinlock_t Come si legge sulla documentazion
179. reare gli eventi di udev per l esecuzione del le applicazioni nello user level per la gestione del file di configurazione nel file system e thmx l oggetto principale del modulo Contiene un riferimento a tutte le strutture relative agli oggetti precedenti e funziona da coordinato re di questi Ad esempio alloca tutte le strutture dati dei vari oggetti e in fase di inizializzazione richiama le loro funzioni di inizializzazio ne registrando di fatto il dispositivo presso i vari sotto sistemi USB ALSA Inoltre gestisce i metodi standard che vengono invocati dal livello applicativo sul nodo del dispositivo USB registrato In parti colare questo dispositivo implementa soltanto le system call open e ioctl utili per l I O visto che tutte le altre vengono effettuate indirettamente tramite il file ALSA o scrivendo sul sysfs CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 111 Moduli e oggetti del sistema embedded Il sistema embedded Figura 5 12 sebbene pi semplice organizzato se condo principi simili all host gadget module thmx_gadget_usb thmx_gadget_uart ba il e L lt contains contains I I thmx_ gadget _ contains thmx Duo char gore il I i contains j L_ _ contains eee Sea V V thmx gadget _proghw _ creates thmx gadget aux thread Figura 5 12 Diagramma dei moduli e degli oggetti relativi al sistema embedded Come si nota cos
180. rivante dalla conversione Voltage To MIDI stato comunque necessario leggere il valore del playingMode dentro il profilo di configurazione del thmx In base al valore ottenuto sono stati generati due diversi stream di messaggi MIDI 1 se il playingMode impostato sulla stringa staccato verranno ge nerati soltanto messaggi di Note On cfr 3 4 1 uno per ogni nota riconosciuta dalla conversione 2 invece se nel playingMode specificato glissando per ogni nota viene generato uno stream di quattro messaggi MIDI che cercano di dare un effetto di transizione morbida da una nota all altra a per prima cosa viene risuonata l ultima nota suonata messaggio di Note On b a questa applicato un Pitch Bend ovvero un glissando sul suono della nota cos che si avvicini alla nota successiva da suonare c arrivati al massimo effetto di bending per collegare le due note viene suonata la nuova nota e rilasciato il pitch bend Questo comporta l invio di due messaggi contemporaneamente uno di Note On con la nuova nota e uno di Pitch Bend rilasciato Il CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 143 Figura 6 1 Un esempio di Pitch Wheel installata su un noto sintetizzatore audio senso di quest ultimo messaggio sta nell utilizzo classico con cui nato nella tastiere elettroniche infatti quasi sempre presen te una manopola a forma di ruota Figura 6 1 Questa ha uno stato di ripo
181. rofile si ottiene l output mo strato in Figura 7 4 Li Applicazioni Risorse Sistema Q Qa aSdo mar 26 lug 23 49 E daniele danieledevel laptop Scrivania Implementazione thereminux thmx src utility scripts 0 File Modifica Visualizza Terminale Schede Aiuto daniele danieled 3 daniele danieled daniele danieled 3 daniele danieled 3 daniele danieled 3 system scripts thmx read profile 2 daniele danieledevel laptop Scrivania Implementazione thereminux thmx_src utility scripts host thmx_read profile x x x CONFIGURATION PROFILE lt ConfigurationProfile gt lt poliphony gt false lt poliphony gt lt numVoices gt 1 lt numVoices gt lt playingMode gt glissando lt playingMode gt lt midi0UT gt true lt midi0UT gt lt programmableHw gt lt hw 0 gt PUSHBUTTON 0 lt hw 0 gt lt programmableHw gt lt controlCmd gt lt cmd 0 gt ISOINZERO 0 lt cmd 0 gt lt cmd 1 gt ISOINMULT 1 lt cmd 1 gt lt cmd 2 gt BLKDBGSTR 2 lt cmd 2 gt lt cmd 3 gt ISODBGSTR 3 lt cmd 3 gt lt controlCmd gt lt associations gt lt as 0 gt 0 0 lt as 0 gt lt associations gt lt ConfigurationProfile gt EEE EEE SEES EEE EEE EEE EEE EEE EEE EEE ZZZ EEE EE EE daniele danieledevel Laptop Scrivania Implementazione thereminux thmx_src utility_scripts host I B E daniele daniel N JACK Audio Con A Qsynth A fluids X Connections J
182. rollo di qualsiasi tipo vengono ricevuti con la callback relativa all endpoint di input di tipo interrupt generico funzione int_out_complete nel file gadget thma_gadget_ usb c Questo sempli cemente prende il buffer ricevuto e risveglia il thread interno all oggetto thmx_gadget che si occupa di effettuare il parsing di questa richiesta ed eseguire la funzione appropriata Nello user space del sistema host i comandi di controllo vengono eseguiti tramite il comando thmx_exec_ctl_command invocabile da un utente qual siasi grazie al fatto che stato impostato il SUID su di esso e quindi riesce ad aprire il file dev thereminux in scrittura per i comandi ioctl 6 2 7 Il driver UART Lo sviluppo del driver UART usato per la scrittura dei dati di MIDI out ha rappresentato forse la fase di implementazione in cui ci si dovuti inter facciare a pi basso livello con i dispositivi hardware veri e propri Infatti anche se PAPI UART definita nel kernel in lt linux serial_core h gt rap presenta gi di per s un astrazione che nasconde i dettagli del driver TTY sottostante c comunque il bisogno per la scrittura dei dati e per il setup dettagliato della porta di avere a che fare con i registri fisici trovati sull hard ware Per questo ci si ispirati al driver implementato nel kernel 2 6 37 in drivers serial omap serial c e soprattutto alla documentazione tecnica per la programmazione dei processori della serie OMAP35x
183. rrivare correttamente all interfaccia di MIDI in della scheda audio Audio phile La verifica della parte software stata effettuata in maniera esaustiva arrivando alla conclusione che sono necessari degli strumenti di debug hard ware pi avanzati di quelli in possesso come ad esempio un oscilloscopio CAPITOLO 7 TEST EFFETTUATI E RISULTATI OTTENUTI 158 Per verificare il lato software sono stati effettuati test sui vari parametri impostati per la connessione seriale e per prima cosa si tentato di collegare il sistema normalmente al monitor seriale dell host tramite minicom come detto questo lavora ad un baud rate di 115200 bps 8 bit di dati 1 stop bit e nessun bit di parit In pratica sono le stesse impostazioni del MIDI eccezion fatta per il baud rate Allora per prima cosa stato modificato il divisore per l impostazione della UART cfr 6 2 7 cos da mandarlo a 115200 bps e la comunicazione avviene correttamente e successivamente si provato a vedere se funziona la reimpostazione del baud rate tramite la tecnica del divisore descritta nel paragrafo 6 2 7 Per verificarlo si doveva provare a vedere se si riusciva ad ot tenere una connessione a minicom con un altro baud rate specificato Poich il MIDI ha una velocit di 31250 bps non standard rispetto al set di velocit disponibili per la UART si provato con una velocit che si avvicina a questa ovvero 38400 bps Dunque si impostato minicom
184. sc gt endpoint i desc if dev gt usbd gt bulk_in_endpointAddr amp amp endpoint gt bEndpointAddress amp USB_DIR_IN amp amp endpoint gt bmAttributes amp USB_ENDPOINT_XFERTYPE_MASK USB_ENDPOINT_XFER_BULK printk KERN_INFO we found a bulk in endpoint buffer_size endpoint gt wMaxPacketSize dev gt usbd gt bulk_in_size buffer_size dev gt usbd gt bulk_in_endpointAddr endpoint gt bEndpointAddress dev gt usbd gt bulk_in_buffer kmalloc buffer_size GFP_KERNEL CAPITOLO 3 STUDIO DI FATTIBILITA 55 if dev gt usbd gt bulk_in_buffer err Could not allocate bulk_in_buffer goto error if dev gt usbd gt bulk_out_endpointAddr amp amp endpoint gt bEndpointAddress amp USB_DIR_IN amp amp endpoint gt bmAttributes amp USB_ENDPOINT_XFERTYPE_MASK USB_ENDPOINT_XFER_BULK printk KERN_INFO we found a bulk out endpoint dev gt usbd gt bulk_out_endpointAddr endpoint gt bEndpointAddress if dev gt usbd gt bulk_in_endpointAddr amp amp dev gt usbd gt bulk_out_endpointAddr err Could not find both bulk in and bulk out endpoints goto error retval snd_minisnd_probe amp dev if retval lt 0 err Could not initialize audio goto error save our data pointer in this interface device usb_set_intfdata interface dev we can register the device now as it is ready retval usb_register_dev interface amp usb_minisnd_cla
185. scrittori necessari a rispondere correttamente alle richieste dell host Tra questi cfr 3 2 il device descriptor il config descriptor l interface descriptor i vari descrittori per gli endpoint e per le stringhe del file di configurazione Inoltre per quanto riguarda gli endpoint come descritto nella Sezione 3 2 lo standard USB 2 0 richiede che quando un dispositivo vuole presentarsi con una configurazione High Speed cfr 3 2 e questo il caso del Thereminux deve comunque dichiarare anche i descrittori adatti per la comunicazione Full Speed per cui nel file gadget thma_ gadget_ usb c troviamo le varie coppie di CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 134 descrittori per ogni endpoint Inoltre troviamo la dichiarazione del device qualifier che espone le caratteristiche della configurazione in High Speed che il Thereminux utilizza come preferenza Inizializzazione In fase di inizializzazione delle strutture di comunicazione USB vedi la fun zione gthmx_usb_init in gadget thmx_gadget_usb c il gadget verifica se il dispositivo sul quale in esecuzione compatibile con la modalit High Speed tramite la funzione gadget_is_dualspeed e se questo ve ro come nel nostro caso inizializza i descrittori High Speed dichiarati per gli endpoint Per quanto riguarda la comunicazione l oggetto principale del modulo vedi gadget thma_ gadget c ad occuparsi di acquisire le richie ste standard e a chiamare le app
186. seppur importante all interno della sequenza ad un livello di dettaglio troppo par ticolareggiato per essere incluso punto per punto nel diagramma pena un drastico peggioramento della leggibilit Si preferito dunque mostrare il flusso principale e tralasciare i dettagli eccessivi che sono ovviamente forniti con il codice dell implementazione In Figura 5 13 c da notare la creazione di due kernel thread infatti uno rappresentato dal thmx_aux_thread gi trattato questo in fase di inizializ zazione non fa altro che bloccarsi su una coda di attesa per essere risvegliato solo quando sono presenti dati di input da gestire Oltre a questo l oggetto thmx_usb crea un altro kernel thread che non stato mostrato nel diagram ma di Figura 5 11 cfr 5 3 in quanto interno all oggetto thmx_usb questo si occupa della ricezione vera e propria dei dati isochronous eseguendo un loop di ricezioni continue sull endpoint e gestendo i possibili errori In particolare 114 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE an0 Ipiw yas esje xwy Jad1Aap esje a ean ananb ajdwes yem jnpow pus ezep Wan pui Peas a a Se SSS it ajnpow wy m el OS Qeqoad win x uoeas gt quanan gt pue dnjas sysAs SSP see oe a ee i eee Qermord yur buds x
187. si picchi il periodo legata alla frequenza fondamentale del segnale originale La procedura ora descritta mostrata in Figura 3 16 a waveform U 2 A E 5 10 15 20 25 30 35 40 45 time ms 60 b spectrum 8 40 a E 20 500 1000 1500 2000 2500 frequency Hz 5 T T T T vr c log spectrum amplitude 500 1000 1500 2000 2500 frequency Hz d cepstrum amplitude 2 4 6 8 10 12 14 16 18 20 22 quefrency ms Figura 3 16 La procedura dell algoritmo cepstrum Fonte 7 3 6 3 Metodi statistici Questa classe di algoritmi piuttosto laboriosa nell implementazione cerca di effettuare una classificazione dei diversi frame del segnale tramite algoritmi CAPITOLO 3 STUDIO DI FATTIBILITA 66 di apprendimento automatico Per questo tali algoritmi hanno bisogno di un periodo di training la cui accuratezza ne influenza fortemente i risultati finali La classificazione effettuata al fine di stabilire se un determinato frame fa parte dell insieme che rappresenta un certo pitch oppure no I metodi che sono stati implementati per questa classe utilizzano reti neurali 12 o Hidden Markov Model 11 3 7 Tecnologie esistenti appropriate per il siste ma Dopo aver studiato nei paragrafi precedenti i vari aspetti da considerare per l implementazione del sistema Thereminux descriviamo in questa sezione alcune tecnologie esistenti che sono state sfruttate all interno del progetto 3 7
188. so e pu essere spostata sia verso l alto producendo un innalzamento del pitch della nota sia verso il basso con una conseguente diminuzione del pitch Il messaggio MIDI di Pitch Bend anche detto a causa di questa immagine di Pitch Wheel cfr 3 4 1 stato creato proprio per l utilizzo di questo dispositivo hardware I messaggi MIDI cos prodotti sono poi scritti dentro un apposito buffer che viene letto dal modulo thmx_aux_thread che aveva richiamato la fun zione di conversione Voltage To MIDI e inviato al livello applicativo tra mite le funzioni ALSA messe a disposizione di thmx_snd In realt per ottenere il giusto effetto descritto poco fa per l invio dei messaggi di Pit ch Bend il thmx_aux_thread implementa una pausa tra il primo messag gio di Note On e il primo Pitch Bend cos che vengano interpretati co me messaggi arrivati in momenti differenti mentre invia in un unico buf fer i successivi due messaggi cos che ALSA li interpreti come avvenuti nello stesso istante Tale pausa implementata tramite una chiamata a wait_event_interruptible_timeout 6 2 6 I comandi di controllo dell esecuzione All interno dell oggetto thmx_usb stata creata la funzione thmx_ioct1 per la gestione dei comandi di controllo dell esecuzione gestiti come comandi ioctl inviati dallo user space Per implementare dei comandi ioctl bisogna CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 144 considerare che essi d
189. spetta l inizia lizzazione delle risorse del driver come gli endpoint A questo proposito il file drivers usb gadget epautoconf c fornisce alcune funzioni di utilit per la configurazione iniziale di tali endpoint come la usb_ep_autoconfig che verifica la disponibilit degli endpoint definiti tramite i vari descrit tori sull hardware sul quale il driver eseguito Una volta terminata la procedura di bind il gadget risulta attivo e pu ricevere richieste sulla sua control pipe ep0 Quando tali richieste cfr 3 2 3 e Figura 3 6 per lelen co completo arrivano al dispositivo viene richiamata la funzione setup che solitamente viene implementata tramite un blocco switch case a questa funzione viene passata una struttura usb_ctrlrequest con le spe cifiche della richiesta corrente e una struttura usb_request che contiene un buffer in cui inoltrare le risposte Ad esempio a fronte della richiesta USB_REQ_GET_DESCRIPTOR verr copiata tramite una semplice memcpy la struttura con il descrittore richiesto sul buffer dell endpoint oppure per la richiesta USB_REQ_SET_CONFIGURATION l host richiede al dispositivo di ren dere attiva la configurazione presentatagli cosa che impone al dispositivo di attivare gli endpoint allocati chiamando la funzione usb_ep_enable Infine al termine delle varie richieste il dispositivo inoltra i dati di risposta all host tramite la funzione usb_ep_queue Se le funzioni bind e setup
190. ss if retval something prevented us from registering this driver err Not able to get a minor for this device usb_set_intfdata interface NULL goto error let the user know what node this device is now attached to printk KERN_INFO USB MINISND device now attached to USBminisnd d interface gt minor return 0 error if dev kfree dev return retval CAPITOLO 3 STUDIO DI FATTIBILITA 56 static void __devexit usb_minisnd_disconnect struct usb_interface interface struct minisnd dev int minor interface gt minor prevent usb_minisnd_open from racing usb_minisnd_disconnect lock_kernel dev usb_get_intfdata interface snd_minisnd_remove dev gt card usb_set_intfdata interface NULL give back our minor usb_deregister_dev interface amp usb_minisnd_class unlock_kernel printk KERN_INFO USB MiniSound d now disconnected minor Figura 3 11 Sorgente delle funzioni principali del modulo usb_minisnd scansione degli endpoint presenti nel dispositivo e carica soltanto quelli volu ti Infine richiama la funzione snd_minisnd_probe per l inizializzazione della parte relativa ad ALSA e per concludere registra il dispositivo sul bus USB tramite la usb_register_dev La struttura con i dati salvati del di spositivo vengono salvati come dati generici della interface USB in modo da poter essere recuperata in seguito La snd_minisnd_probe esegu
191. ssere suo ca il numero di no nata Ogni messaggio ta 0 127 e il se di Note On deve essere condo la velocity 0 seguito prima o poi 127 Una velocity 0 dal relativo messaggio pu essere usata per di Note Off o da un implementare il Note messaggio di Note On Off con velocity 0 Aftertouch Nei dispositivi che da OxA0 a OxAF 2 numero di no hanno un sensore del la pressione esercitata quando si tiene pre muta una nota questo messaggio permette di controllare questo parametro ta 0 127 e pressure amount 0 127 CAPITOLO 3 STUDIO DI FATTIBILITA 47 Controller Il MIDI mette a di sposizione una serie di controller che possono mandare messaggi di versi rispetto al suo nare una nota o rila sciarla Questi vengo no gestiti con questi comandi da0xB0 a OxBF 2 numero del control ler 0 127 e valore per quel controller 0 127 Program Change Permette di cambia re un determinato pro gramma una patch uno strumento o al tro a seconda di come viene interpretato dal dispositivo da0xC0 a 0xCF 1 numero del pro gramma da impostare 0 127 Channel Pressure Permette di controlla re la pressione media dei tasti su una tastie ra diverso dall After touch in cui il control lo di pressione per la singola nota da0xD0 a 0xDF 1 valore di pressione 0 127 Pitch Wheel Permette di alzare o abbassare il pitch fre quenza di un
192. stringa di prefisso non presente il driver crea un uevent che attraverso un opportuna regola di udev fa s che venga eseguito uno script che controlla lo stato di aggiornamento del file di configurazione e se non dovesse risultare aggiornato richiama lo script di inizializzazione del file che ne ricostruisce i valori L evento di udev che viene inviato crea una variabile di ambiente in cui viene pubblicato il nome del campo modificato e il suo valore attuale Lo script in questo modo potr verificare se il campo salvato sul file risulta aggiornato La variabile di ambiente cos formata THMX_CONFIG MODIFY name value dove name il nome del campo del profilo modificato e value il suo valore La limitazione che salta subito all occhio per quanto riguarda questa strategia che poich verosimilmente l utente privilegiato pu conoscere la stringa di prefisso potrebbe usarla lui stesso nelle scritture a mano sul sysfs bypassan do cos il controllo e facendo s che gli uevent non siano creati opportunamen te In ogni caso la soluzione sembrata comunque ragionevole perch tali scritture sono permesse solo all utente privilegiato per cui sembra opportuno assumere che le sue azioni siano affidabili 5 3 2 Script e applicazioni in user space Verranno qui fornite le specifiche dei vari script o applicazioni se troppo complesse per essere implementate come semplici script che sono stati im plementati nello
193. su 16 diversi canali logici da 0x0 a OxF Lo Status Byte quindi si compone come segue 4 bit per il tipo di messaggio e 4 per il canale In realt i messaggi codificabili con i primi quattro bit sono i seguenti li vedremo in seguito nel dettaglio 0x8 Note Off 0x9 Note On OxA AfterTouch ie key pressure 0xB Control Change OxC Program patch change OxD Channel Pressure OxE Pitch Wheel CAPITOLO 3 STUDIO DI FATTIBILITA 45 Per ognuno di questi possibile specificare il canale di riferimento con i suc cessivi quattro bit Gli Status Byte che vanno da 0xF0 a OxFF invece sono riservati per messaggi che non si riferiscono a nessun canale in particolare Questi infatti sono messaggi che servono a controllare tutti i dispositivi che vengono indirizzati attraverso i vari canali ad esempio inviando messaggi di sincronizzazione Vengono divisi in due sotto categorie i messaggi System Common da 0xF0 a 0XF7 e i messaggi System Realtime da 0xF8 a OxFF Le tabelle 3 1 e 3 2 forniscono un quadro riassuntivo di tutti i principali mes saggi MIDI con la loro descrizione di base il range di valori esadecimali che il loro Status Byte pu assumere e la presenza o meno di eventuali byte di dati che seguono allo status byte In generale ad esempio supponiamo di voler suonare una certa nota di ciamo il Do centrale del pianoforte tramite una tastiera Quando viene premuto il tasto relativo il dispositivo invia una seque
194. t e dei suoi CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 98 create a dummy kobject directory within the device kobject and a dummy file attribute within this directory static int init_sysfiles struct minisnd dev struct kobj_type ktype struct attribute attr struct thmx_config config int retval if dev dev return EINVAL config kmalloc sizeof config GFP_KERNEL if config return ENOMEM memset config 0 sizeof config config gt config_kobj kmalloc sizeof struct kobject GFP_KERNEL if config gt config_kobj return ENOMEM memset config gt config_kobj 0 sizeof struct kobject config gt config_name ProvaConfig config gt attri Attributol attr kzalloc sizeof struct attribute GFP_KERNEL if attr return ENOMEM attr gt name config gt attri attr gt owner THIS_MODULE attr gt mode S_IRUGO ktype kzalloc sizeof struct kobj_type GFP_KERNEL if ktype return ENOMEM ktype gt release kobj_release ktype gt sysfs_ops amp sysops ktype gt default_attrs kzalloc sizeof struct attribute GFP_KERNEL ktype gt default_attrs 0 attr CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 99 kobject_init config gt config_kobj ktype retval kobject_add config gt config_kobj amp dev gt dev gt kobj config gt config_name if retval lt 0 return EINVAL dev gt config config
195. tale che questi ultimi possano ragionare in termini di endpoint e interfacce cfr 3 2 ma senza gestire i livelli inferiori del protocollo Il sottosistema USB fornisce auto maticamente un Major Number a tutti i device driver USB che si devono preoccupare di allocare un proprio Minor Number richiamando la funzione usb_register_dev Inoltre ogni device driver deve implementare due funzioni fondamentali la probe e la disconnect La prima si occupa delle inizializzazioni specifi che che il driver fa con il dispositivo che gestisce mentre la seconda si occupa di effettuare la pulizia quando un dispositivo viene scollegato dal sistema Ma andiamo con ordine Supponiamo come nel caso di nostro interesse di dover collegare un nuovo dispositivo USB per il quale si dispone di un opportuno device driver che vogliamo caricare dinamicamente Il device dri ver deve dichiarare una tabella con gli identificativi del dispositivo che pu servire Questa dichiarazione nel driver lato host del Thereminux appare cos CAPITOLO 3 STUDIO DI FATTIBILITA 40 static struct usb_device_id thmx_table USB_DEVICE USB_THMX_VENDOR_ID USB_THMX_PRODUCT_ID Terminating entry MODULE_DEVICE_TABLE usb thmx_table Una volta che il device driver installato nel sistema ovvero inserito in una directory standard per i moduli del sistema nel caso di chi scrive lib modules e registrato con le sue eventuali dipendenz
196. te usb_fill_control_urb usb_fill_bulk_urb e usb_fill_int_urb mentre per i trasferi menti di tipo isochronous cfr 3 2 l inizializzazione deve essere fatta a mano Sostanzialmente deve essere specificato all interno della strut tura urb il dispositivo e l endpoint verso da il quale il trasferimento deve avvenire il return handler che viene eseguito al termine dell urb il buffer dei dati di trasferimento pi altri parametri dipendenti dal ti po di urb Ad esempio per un trasferimento di tipo isochronous si pu specificare il numero di frame che possono essere mandati all interno di un singolo urb e la frequenza di trasferimento e viene inviato al core USB con la funzione usb_submit_urb Questo passa il controllo al core USB che si preoccupa di effettuare effettiva mente il trasferimento e al termine viene richiamata la funzione handler CAPITOLO 3 STUDIO DI FATTIBILITA 43 e ogni urb pu essere cancellato in qualsiasi momento Questo viene fatto tramite due funzioni la usb_kill_urbQ richiamata di solito quando il dispositivo viene disconnesso dal sistema e la usb_unlink_urb quando il device driver vuole annullare un certo urb In realt quando si tratta di invare semplici messaggi di tipo bulk o control possibile evitare la procedura di gestione di urb ma esistono delle apposi te funzioni sincrone chiamate usb_bulk_msg e usb_control_msg che permettono tale scambio di dati specificando mo
197. te di programmare il baud rate delle sue trasmissioni seriali Inoltre il segnale fornito dal protocollo MIDI 0 e 5 volt rispetta lo stan dard TTL di comunicazione digitale mentre la RS 232 considera come non definito un segnale che si trova tra i 3 e i 3 volt La conversione tra i due dovr dunque essere assegnata ad una apposito modulo hardware non im plementato In questa fase il sistema di invio di messaggi MIDI out tramite il Thereminux stato implementato in software e testato utilizzando delle utility per la connessione seriale con il sistema host come minicom Infine come richiesto dal requisito RHW_F 5 il sistema deve fornire elementi hardware programmabili tramite opportuni messaggi dal sistema host Per implementare questa funzionalit stata sfruttata una caratteristica gi in tegrata all interno della Beagle Board Infatti la scheda viene fornita con un pulsante hardware programmabile dall utente Per gli scopi di test del prototipo del Thereminux questo sembrato essere gi sufficiente Capitolo 5 Progettazione del sistema software In questo capitolo verranno trattate tutte le questioni relative alla progetta zione effettuata per l implementazione del sistema software In questo senso si cercato di documentare al meglio varie prospettive quella dell utente che interagisce quella del dispositivo quella della struttura software ecc al fine di analizzare ogni aspetto e cercare di ottenere
198. tem Initialization System De registration CtiCommand request done Privileged User amp amp Setting Config Profile System ConfigConfirm System ExecCtiCommand SW Print Config File Print Control Commands CtiCmd Figura 5 2 Diagramma degli stati che descrive un tipico ciclo di vita del sistema host Come facile vedere il sistema host si basa interamente sul paradigma event CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 88 driven in quanto come noto questa la normale modalit di esecuzione dei device driver Gli stati principali descritti in questo diagramma ver ranno ulteriormente approfonditi pi avanti Tra quelli per i quali manca un diagramma di approfondimento troviamo Reconfiguring ALSA for MIDI OUT che semplicemente inizializza o elimina la funzionalit di MIDI OUT registrandola o de registrandola presso ALSA allo stesso modo non stato fornito un approfondimento dei semplici stati Print Config File e Print Con trol Commands in quanto il loro compito essenzialmente quello di stampare una versione formattata e user friendly del contenuto del profilo di configu razione Infine anche lo stato System De registration effettua soltanto la liberazione delle risorse per cui stato lasciato non ulteriormente specificato a questo livello di descrizione Il ciclo di vita del sistema embedded assai simile al precedente Figura 5 3
199. tituito da un unico modulo del kernel che ne incorpora le varie funzionalit Allo stesso modo del sistema host anche qui troviamo un oggetto principale che funge da contenitore delle strutture relative agli altri oggetti e ne richiama le funzioni Un analisi pi in dettaglio di queste funzio ni permetter di comprendere anche il funzionamento di base del dispositivo per cui vediamole singolarmente e thmx_gadget_usb l oggetto che definisce le strutture e le funzioni per l implementazione della comunicazione USB con Vhost Contiene una struttura thmx_gadget_config con cui definisce il profilo di configu razione come un insieme di descrittori stringa definisce gli endpoint e tutte le strutture necessarie per implementare un dispositivo USB gadget cfr 3 7 1 e thmx_gadget_uart implementa un driver seriale basato sul modello TTY per la comunicazione con la porta RS 232 della Beagle Board Per questo utilizza API UA RT definita nel file include linux serial_ core h Tramite questa il driver implementa un dispositivo seriale per la co municazione di dati MIDI di output verso dispositivi esterni e thmx_gadet_char per l acquisizione dei campioni audio in ingresso sembrato inutile implementare un driver ALSA che ricalchi interamen CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 112 te quello gi esistente all interno del kernel Per questo si deciso di utilizzare un applicazione ALSA che gira nello user space e impl
200. tivi nel riconoscimento l algoritmo pesa i valori trovati sulla media dei valori precedenti di 7 ay Lu z jai hl Questo metodo sembra particolarmente interessante per i nostri scopi dato il fatto che sembra essere adatto alla nostra applicazione e la disponibilita di implementazioni open source cfr 3 7 3 3 6 2 Algoritmi frequency domain Questa classe di algoritmi si basa sulla rappresentazione del segnale cam pionato tramite le armoniche che lo compongono Tale rappresentazione ottenuta tramite metodi standard come la trasformata di Fourier I due prin cipali metodi di questa categoria sono l algoritmo di maximum likelihood 10 e il cepstrum 9 Nel primo caso si cerca di trovare uno spettro abbastanza simile a quello di input utilizzando molti spettri possibili Naturalmente questo algoritmo richiede un certo numero di spettri di confronto per otte nere buoni risultati e risulta funzionare abbastanza bene nel caso di segnali CAPITOLO 3 STUDIO DI FATTIBILITA 65 con intonazione fissa Nel secondo caso invece viene prodotta la trasfor mata di Fourier del logaritmo dello spettro di ampiezza del segnale Infatti la trasformata di Fourier produce una serie di picchi in corrispondenza delle armoniche del segnale Utilizzando la scala logaritmica questi picchi vengo no smussati in ampiezza e il segnale di output prodotto diventa un segnale periodico nel dominio della frequenza in cui la distanza tra i diver
201. tivo hardware al sistema hardware quando si parla di elementi hardware e infine di sistema host per riferirsi al sistema software in esecuzione sull host In ultimo forniamo di seguito cfr 5 1 1 una lista di tabelle che danno i dettagli sempre a livello qualitativo dei flussi eseguiti per ogni caso d uso 5 1 1 Specifiche dei casi d uso Nome Caso d uso PlayMIDI ID CU 1 Attori User MIDI Application Descrizione Permette all utente user di suonare note MIDI tramite lo strumento hardware queste note MIDI vengono cat turate da applicazioni MIDI in ascolto nello user space e suonate Precondizioni Il sistema deve essere attivo e inizializzato dispositivo hardware acceso e collegato all host moduli del kernel caricati e pronti Flusso principale 1 L utente inizia a suonare lo strumento hardware 2 Il sistema embedded converte il segnale analogico in stringa binaria 3 Il sistema embedded invia il risultato della conversione sul bus USB 4 Il sistema host effettua una conversione Voltage to MIDI del segnale in ingresso 5 Il messaggio MIDI viene inviato al livello applicativo Flussi alternativi Postcondizioni Il sistema host ha inviato la nota MIDI relativa al segnale di input allo user space CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 82 Nome Caso d uso ReadConfig ID CU 2 Attori User Descrizione Permette all ute
202. trato nella funzione gthmx_uart_request_port richiamata dal kernel sempre in fase di inizializzazione si utilizza la request_mem_region per ottenere tutta l area di memoria da indirizzare per usare la porta UART3 Infine si nota che stato specificato il clock della porta come viene specificato in 15 e usando una macro che stata ripresa dal file arch arm mach omap1 serial c Successivamente una volta chiamata la funzione uart_add_one_port il kernel richiama alcuni metodi di inizializzazione definiti dal driver stesso per il setup dell hardware Tra questi c la gthmx_uart_request_port gi vista ma pi importante la gthmx_uart_set_termios che si occupa proprio della scrittura fisica nei registri per impostare le caratteristiche del protocollo di comunicazione Per sfruttare questi registri stata utilizzata la seguente procedura 1 viene visto dal manuale tecnico 15 il nome del registro da utilizzare e si trova il suo nome nell header lt linux serial_reg h gt 2 viene capito quali sono i bit da scrivere su quel registro per ottenere l effetto desiderato 3 vengono letti i valori esadecimali specificati dalle macro contenute in lt linux serial_reg h gt specifiche per quel registro 4 vengono tradotti quei valori esadecimale in binario 5 viene scelta la macro che scrive sui bit che serve siano attivati Chiaramente per la fase di studio partendo dal codice di esempio del dri ver omap seri
203. tte le strutture per gestire questi flussi di comunicazione Fatto questo il protocollo sostanzialmente basato sul polling con l host che inizia periodicamente ogni trasmissione inviando i dati nel caso di flussi di output o chiedendo al dispositivo se ce ne sono di nuovi nel caso di flussi di input Queste operazioni sono sempre iniziate da parte dell host inviando dei pacchetti di token che specificano una richiesta per una trasmissione indi rizzata ad un certo endpoint sul dispositivo Quest ultimo risponde a questa richiesta inviando un pacchetto di handshake che pu confermare la disponi bilit a iniziare la trasmissione pacchetto ACK oppure se impossibilitato a ricevere o non ha nulla da inviare declinare la richiesta pacchetto NAK Nel caso in cui l host effettui una richiesta per un operazione non valida o non supportata dal dispositivo questo pu inviare il pacchetto di handshaking STALL dopo il quale il dispositivo si trova in uno stato indefinito 3 2 3 Definizione di un dispositivo USB Sostanzialmente dunque per quanto spiegato nel paragrafo precedente cfr 3 2 2 Phost si occupa di rilevare un nuovo dispositivo USB collegato e invia re le richieste per la sua configurazione e per effettuare lo scambio dei dati Queste funzionalit all interno dell host sono gi implementate a livello di sistema operativo in maniera trasparente all utente al quale viene fornita una API per sviluppare il d
204. u 1 peauuy ur osi xwyy azea n squiodpua dnas 6quo5 Xu x lt iui gsn xwy spnNS a02 pe ME ZE gt a gt nap fasn 2351681 t ani inna if eres l gt i RE gt I 1 t l l i I f sint d gt i I 1 1 j RE gt 1 1 eae f gt i y l I 1 fi i Qeqgid xwyy 2 Aap ay UO un i H pue yene l l i H JSN I 1 I L L xuqy 3105 gsm jnpow qsn Diagramma della sequenza di inizializzazione del sistema host Figura 5 13 CAPITOLO 5 PROGETTAZIONE DEL SISTEMA SOFTWARE 115 questo thread si occupa di risvegliare l aux thread quando ci sono dati dispo nibili ma anche di verificare le ricezioni implementando dei meccanismi di recovery quando per qualche motivo ci sono errori nella ricezione Lo scenario relativo all esecuzione sullo strumento appunto presentato in Figura 5 14 La prima cosa che viene eseguita quando viene completato PURB relativo all endpoint isochronous di input handler thmx_read_iso_callback den tro thmx_usb Questo non fa altro che copiare il buffer di input e svegliare il thread il quale richiama la funzione di conversione Voltage To Midi e quan do questa gli restitusce il messaggio MIDI contenente la nota MIDI risultata dalla conversione lo invia al livello applicativo Quest ultima operazione eseguita sfr
205. u un segnale limitato temporalmente ad una finestra di grandezza N la funzione di autocorrelazione la seguente 7 N 1 v fas x n x n v n CAPITOLO 3 STUDIO DI FATTIBILITA 64 Come si pu notare anche la funzione di autocorrelazione una funzione periodica e in particolare mostra il comportamento detto quando il segna le ritardato di mezzo periodo rispetto all originale segnale fuori fase con se stesso la R raggiunge un minimo mentre quando il segnale con ritardo viene portato ad avere uno shift di un intero periodo segnale in fase con se stesso la funzione raggiunge un massimo Quindi il primo picco massi mo della funzione di autocorrelazione viene solitamente preso come periodo del segnale da cui dedurre la frequenza portante Certo possono comun que nascere dei problemi quando si analizzano segnali complessi come quello in Figura 3 15 infatti per questo segnale la funzione di autocorrelazione riconoscerebbe non il periodo principale ma quello di una delle armoniche superiori del segnale Per evitare questo un metodo che sembra avere ottimi risultati sperimentali lo YIN 8 Seppur basato sull autocorrelazione il metodo YIN cerca di minimizzare la differenza tra il segnale e la sua versione ritardata piutto sto che massimizzare il prodotto tra i due L equazione che ne deriva la seguente di t 2 Ej J WwW In realt per ridurre il rischio di avere dei falsi posi
206. ubio_pitchyin_do aubio_pitchyin_t o fvec_t input fvec_t out smpl_t tol o gt tol fvec_t yin o gt yin uint_t j tau 0 sint_t period smpl_t tmp 0 tmp2 0 yin gt data 0 1 for tau 1 tau lt yin gt length taut yin gt data tau 0 for j 0 j lt yin gt length j tmp input gt data j input gt data j taul yin gt data tau SQR tmp tmp2 yin gt dataltau yin gt data tau tau tmp2 period tau 3 if tau gt 4 amp amp yin gt data period lt tol amp amp CAPITOLO 3 STUDIO DI FATTIBILITA 75 yin gt data period lt yin gt data period 1 out gt data 0 fvec_quadint yin period goto beach out gt data 0 fvec_quadint yin fvec_min_elem yin beach return Sono state definite diverse strutture e costanti all interno del codice di aubio Ad esempio smpl_t definito come float mentre uint_t e sint_t sono definiti come intuibile rispettivamente come unsigned int e signed int Oltre a questo la struttura fvec_t definita come segue typedef struct uint_t length smpl_t data fvec_t Con length la lunghezza del buffer e data l array di campioni del segna le Inoltre vediamo come argomento della funzione una struttura di tipo aubio_pitchyin_t definita tramite typedef dall analoga _aubio_pitchyin_t struct _aubio_pitchyin_t fvec_t yin smpl_t tol F Oltre all array di campioni yin
207. ueue che viene utilizzata nel sistema per implementare degli sleep basati su timeout tramite la funzione wait_event_interruptible_timeout Questi sleep sono utilizzati per effettuare una sincronizzazione sia quando l host deve ricevere dati dal gad get come si vede nella funzione thmx_usb_send_ra_req in host usb_module thmax_ usb c Vattesa qui permette di essere certi che questi dati sono stati inviati sia di inviare messaggi MIDI al livello applicativo co me in call_vtm_conversion dentro host usb_module thma_ aux_thread c l attesa permette di far s che ALSA interpreti i messaggi come avvenuti in momenti differenti mentre inviare un unico buffer fa s che i messaggi sono interpretati come avvenuti nello stesso istante Per il resto ogni oggetto viene inizializzato con una sua funzione specifica allocando tutte le risorse che gli sono necessarie come verr spiegato in seguito Sul gadget la situazione molto simile il sotto sistema USB in questo caso richiama la funzione gthmx_bind dichiarata nel driver usb gad get thma_ gadget c la quale si occupa di inizializzare tutti gli oggetti con tenuti nella struct thmx_gadget richiamando le loro funzioni specifiche 6 2 2 La comunicazione USB La comunicazione tra host e gadget tramite USB stata implementata se guendo quanto gi descritto in precedenza cfr 3 3 5 e 3 7 1 Per prima cosa il gadget dichiara staticamente nel file gadget thma_gadget_usb c tutti i de
208. ugging in usb html 27 udev wikipedia http en wikipedia org wiki Udev 28 Writing udev rules reactivated net website http www reactivated net writing_udev_rules html 29 MIDI Manufacturers Association MMA website http www midi org 30 The MIDI Specification oktopus hu website http www oktopus hu imgs MANAGED Hangtechnikai_tudastar The_MIDI_Specification pdf 31 MIDI Note Numbers somascape org website http www somascape org midi help notes html 32 ALSA official website http www alsa project org 33 ALSA unofficial unofficial website http alsa opensrc org 34 Writing an ALSA driver Ben Collins Technical ramblings of a Linux developer http ben collins blogspot com 2010 04 writing alsa driver html 35 Real time Pitch Detection Francois Germain Schulich School of Music http www music mcgill ca francois Pitch_Presentation Pitch_summary pdf 36 Arduino Arduino HomePage http www arduino cc 37 Teensy USB Development Board PJRC Electronic Projects Compo nents Available Worldwide http www pjrc com teensy index html BIBLIOGRAFIA 165 38 Beagle Board BeagleBoard org website http beagleboard org 39 Beagle Board eLinux support eLinux org website http elinux org BeagleBoard 40 BeagleBoard org X Loader BeagleBoard org website http beagleboard org project X Loader 41 Das U Boot Universal Bootloader sourceforge website http sou
209. usicians com viewtopic php f 27 amp t 1008 amp start 15 55 RT PREEMPT HOWTO https rt wiki kernel org index php RT_PREEMPT_HOWTO 56 Index of pub linux kernel projects rt http www kernel org pub linux kernel projects rt 57 Linux Kernel and Floating Point Lifting the Earth using Linux http www linuxsmiths com blog p 253 58 BeagleBoardLinuxKernel http elinux org BeagleBoardLinuxKernel 59 Running Real time distribution on beagleboard http groups google com group beagleboard browse_thread thread 8b56060586cc62e9 cd9016eb812a5c51 1nk gst amp q real time amp pli 1 60 Sourcery G http www codesourcery com sgpp lite arm portal subscription template lite 61 mkcard sh v0 5 http www angstrom distribution org demo beagleboard mkcard txt 62 Validating Beagle Board Rev C4 and Rev Br with Tests Diagnostics http code google com p beagleboard wiki BeagleboardRevC3Validation 63 Getting Started OpenEmbedded http wiki openembedded net index php Getting_Started 64 Useful Target Recipes http docs openembedded org usermanual usermanual htm1 id442079 BIBLIOGRAFIA 167 65 Bitbake User Manual http bitbake berlios de manual 66 Beagleboard demo files http www angstrom distribution org demo beagleboard 67 The libsndfile API http www mega nerd com libsndfile api html 68 Null Modem Serial Cable Null Modem Cables Explained http compnetworkin
210. uttando PAPI ALSA standard e quindi inviando i messaggi MI DI alle applicazioni che gi sono collegate al dispositivo e sono in attesa di tali messaggi Andando avanti la Figura 5 15 mostra il flusso di reimpostazione del profilo di configurazione una volta che l amministratore lo ha modificato Come detto in precedenza cfr 5 3 1 tale operazione stata implementata attraverso una serie di scritture sui file attributo del dispositivo all interno del sysfs cosa che causer l invocazione di altrettante funzioni store Per tutte le modifiche che non riguardano n le associazioni tra elementi hardware programmabili e comandi di controllo n la reimpostazione del MIDI out questa operazione lavorer in locale semplicemente aggiornando le variabili interne del driver e poi creando delle variabili di ambiente di udev per lo script thmx_check_profile se nelle store non stato inviata la stringa di prefisso insieme ai valori dei campi del profilo che controller l aggior namento del file del profilo Quando invece le modifiche verranno apportate alla sezione associations o a quella midiOUT del profilo di configurazione sar necessaria una comunicazione con il dispositivo che verr effettuata ri chiamando un opportuno metodo di thmx_usb Ancora la Figura 5 16 mostra la sequenza relativa all esecuzione di comandi di controllo da software Tale sequenza in realt molto semplice il programma thmx_execCt1Command infatti
211. ve ha lavorato con un kernel 2 6 32 sul quale stato necessario abilitare le seguenti configurazioni Device Drivers gt lt M gt Sound card support gt lt M gt Advanced Linux Sound Architecture gt lt M gt Sequencer Support lt M gt OSS Mixer API lt M gt OSS PCM Digital Audio API lt gt OSS Sequencer API lt gt Support old ALSA API lt gt Verbose procfs contents lt gt USB sound devices Successivamente dopo la compilazione dei due moduli stato sufficiente inserirli tra i moduli del sistema in una sotto directory di lib modules e al fine di ricostruire le dipendenze tra usb_minisnd e snd_minisnd richiamare il comando depmod Fatto questo i moduli sono stati caricati tramite modprobe In particolare grazie alla dipendenza tra i due il comando modprobe usb_minisnd ha fatto s che venisse caricato prima snd_minisnd e dopo usb_minisnd A quel punto la nuova scheda audio stata perfettamente riconosciuta da ALSA Infatti il procfs stato modificato daniele danieledevel laptop 1s proc asound card0 cards devices minisndcard0 modules oss seq timers version Come possiamo vedere appare sia la nuova cardo che il dispositivo minisndcard0 che altro non che un link simbolico alla directory cardo daniele danieledevel laptop ls 1 proc asound totale 0 dr xr xr x 2 root root 0 2010 06 30 19 11 card0 r r r 1 root root 0 2010 06 30 19 11 cards r r r 1 root root 0 2010 06 30
212. vediamo che risulta cos void cdev_init struct cdev cdev const struct file_operations fops memset cdev 0 sizeof cdev INIT_LIST_HEAD amp cdev gt list kobject_init amp cdev gt kobj amp ktype_cdev_default cdev gt ops fops Come possiamo vedere dopo alcune operazioni di inizializzazione la funzione pi importante senza dubbio la kobject_init che si occupa natural mente di inizializzare il kobject per il dispositivo da aggiungere al sistema stata menzionata in precedenza l organizzazione gerarchica del sysfs Que sta viene ottenuta in due modi Il primo il puntatore parent posto all in terno della struttura kobject che punta al kobject che al livello superiore nella gerarchia Il secondo modo l utilizzo dei kset Questi permettono l ag gregazione di un insieme di kobject dello stesso tipo dove il tipo identifica caratteristiche comuni come gli attributi di default condivisi e le operazioni che si possono effettuare su tali attributi attraverso il sysfs Oltre a questo il device model mette a disposizione a basso livello le strutture per la rappre sentazione e gestione di bus device e device driver che per non verranno approfondite ulteriormente qui 3 3 4 udev e la gestione dell hotplug La gestione dell hotplug come gi detto cfr 3 3 3 anch essa affidata al device model La trattazione di questa questione richiede qualche attenzione in quanto la descrizi
213. verso il bus USB in opportuni messaggi MIDI Perch questo possa avvenire sostanzialmente necessario riconoscere il pitch nota del segnale in ingresso e generare la nota MIDI coerente con questo Naturalmente per questa operazione non banale visto che l unica informazione che possiamo ricavare dall ADC la lista dei campioni che rappresentano i vari valori dell ampiezza del segnale mentre il pitch in relazione con la frequenza dell armonica fondamentale del segnale stesso Ogni segnale tra cui quelli sonori infatti composto da pi componenti sinusoidali dette armoniche o parziali e spesso ma non necessa riamente queste sono in relazione armonica con la parziale pi bassa detta fondamentale La relazione armonica implica che le componenti armoniche superiori alla prima abbiano una frequenza pari ad un multiplo della fonda mentale Effettuare il riconoscimento del pitch relativo ad un certo segnale di ingresso significher quindi estrarre l informazione relativa all armonica fondamentale del segnale stesso Questa operazione detta pitch detection 7 35 In generale gli algoritmi di pitch detection possono ricardere in tre diver se categorie algoritmi time domain algoritmi frequency domain e algoritmi CAPITOLO 3 STUDIO DI FATTIBILITA 63 basati su metodi statistici 3 6 1 Algoritmi time domain Nel caso di algoritmi time domain si cerca di sfruttare la periodicit del segnale nel tempo I
214. vertitore RS232 USB che ha permesso il collegamento seriale con Phost Il gadget stato monitorato tramite il comando minicom in cui la comuni cazione stata impostata seguendo la guida su 39 con un Baud Rate a 115200 bps 8 bit di dati 1 stop bit e nessun bit di parit La scheda audio Audiophile esterna cfr 6 1 1 inoltre stata anch essa collegata tramite USB all host permettendo di avviare il sistema jack Sono stati effettuati diversi test approfonditi per la validazione del lavoro svolto Nel seguito verranno descritti dettagliatamente 7 1 Test sulla trasmissione di dati audio Per prima cosa stata validata la connessione audio tra host e gadget pro cedendo a verificare che i dati audio inviati dal gadget fossero corretti Per fare questo stato implementato il metodo read accessibile dal nodo dev thereminuz il quale semplicemente effettua le letture sulla kfifo contenente i campioni audio letti dal thread isochronous al posto del modu lo thmx_vtm cfr 6 2 2 e 6 2 5 Per fare questo in ogni caso stata prevista una macro chiamata THMX_AUDIO_DEBUG nel file host headers thmz h che quando definita fa s che il thread di ricezione sull endpoint isochronous non chiami la conversione Voltage To MIDI sui campioni letti evidando cos i possibili conflitti di lettura dalla kfifo e che la funzione thmx_read ef fettivamente effettui la lettura di questi dati Infatti quando la macro non viene
215. viene inizializzato il campo usb_ops gt write interno alla struttura thmx_usb come descritto in prece denza cfr 5 3 6 e 5 4 infatti il modulo thmx_snd all arrivo di dati di MIDI out sul suo nodo ALSA usa questa funzione per inoltrare tali messag gi all oggetto USB del Thereminux che si occuper di inviarli al gadget Infine l inizializzazione della comunicazione USB termina con l inizializza zione e l avvio del kernel thread che si occupa della ricezione dei campioni audio dall endpoint isochronous Le funzioni relative a queste operazioni sono contenute nel file host usb_module thma_ usb c CAPITOLO 6 SCELTE DI IMPLEMENTAZIONE DEL SISTEMA 135 Comunicazioni sugli endpoint Il thread di ricezione semplicemente definisce una routine principale thmx_usb_receive che gestisce la lettura sull endpoint isochronous Co me vedremo pi avanti cfr 6 2 6 tale endpoint rappresenta una risorsa condivisa in quanto viene utilizzato anche per la ricezione della stringa di debug che viene mandata dal gadget in seguito ad un opportuno comando di controllo Per prevenire conflitti in queste comunicazioni la prima cosa che il thread di ricezione fa acquisire un lock relativo proprio all endpoint isochronous lock che viene mantenuto per l intera durata delle ricezioni di pacchetti audio Naturalmente il processo che tenta di eseguire il comando di controllo relativo allo stesso endpoint non rester bloccato in attesa che i
216. zione di trasferimento dei da ti USB_DIR_IN o USB_DIR_OUT e gli attributi dell endpoint come il tipo e usb_descriptor_header un contenitore per i vari descrittori sopra dichiarati in modo da descrivere facilmente la funzione implementa ta dal dispositivo da ricordare che nella specifica USB i dispositivi periferici vengono definiti anche appunto funzioni cfr 3 2 e usb_string struttura di comodit definita nell interfaccia include linux usb gadget h per definire un descrittore stringa che com prende un id e la stringa di caratteri vera e propria e usb_gadget_strings contenitore per il raggruppamento di un array di stringhe espresse nella stessa lingua ad esempio come si legge nel sorgente dell API si pu specificare 0x0409 for en us In seguito dopo aver dichiarato tali descrittori viene definita la struct usb_gadget_driver che contiene i puntatori alle principali funzioni che ver ranno richiamate dal kernel nel momento opportuno In particolare alcune di queste rivestono particolare interesse e verranno descritte tra poco Come CAPITOLO 3 STUDIO DI FATTIBILITA 70 tutti i moduli del kernel anche i driver gadget hanno una funzione di __init e una di __exit All interno della prima solitamente viene registrata la struttura usb_gadget_driver tramite la funzione usb_gadget_register_driver prima che questa ritorni il kernel richia ma la funzione bind definita dal driver a questa che

Documentazione del progetto

Contents

Download Pdf Manuals

Related Search

Related Contents