SVILUPPO DI UN PROTOTIPO DI SIMULATORE POLIFONICO PER CONCERTO DI CAMPANE

1. Università degli Studi di Trieste DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA Corso di Laurea in Ingegneria Elettronica SVILUPPO DI UN PROTOTIPO DI SIMULATORE POLIFONICO PER CONCERTO DI CAMPANE Relatore: Prof. Sergio Carrato Correlatore: Ing. Piergiorgio Menia Laureando: Francesco Guzzi Trieste, 12 marzo 2013

2. PREMESSA E SPECIFICHE: • Simulare un gruppo di 12 campane → 12 semitoni • Sistema da collegare ad un sequencer esterno. • Riproduzione campioni audio pre-registrati → 10 s • Gestione ritardi. • 2 file per campana → 24 file • Latenza < 10 ms. • Basso costo totale. 2/ 16

3. SOLUZIONE IMPLEMENTATA MCU MODULO 1 BUS PLAY 1 PLAY 2 MODULO 2 ... • Boot istantaneo. • Bassa latenza. • 24 ingressi digitali. • 1 uscita monofonica analogica. • Ritardi programmabili per ogni voce. • Gestione da remoto. • Soluzione a memoria distribuita OUT ... ... ... ... MODULO 12 PLAY 24 BUS BUS PC 3/ 16

4. MODULO VS1000mod • 12 moduli • Alimentazione 5 V. • Formato DIP32. • File in formato VORBIS (o WAV). • SoC VS1000 programmabile. • Funzioni tipiche in ROM istruzioni. • Poca RAM istruzioni. • Sorgenti firmware di default. • GPIO a livelli CMOS. • FLASH SPI da 16 Mbit. → 23,7 s • Uscita audio analogica lineout 16 4/

5. FIRMWARE CUSTOM – Usa funzioni di libreria del firmware originario – Accesso FLASH-SPI – Lettura/scrittura filesystem a blocchi – “Raw” TX/RX UART – Implementato decoder software WAV – GPIO “manuale”. – Protocollo → upload file. → set volume. 5/ 16

6. UPLOAD FILES: protocollo – Implementato protocollo a pacchetto di tipo “stop and wait” – Risposta ACK / NACK – ByteStuffing / De-stuffing – Campo dati a lunghezza variabile (MAX 240 Byte) – Gestione timeout, overflow, address-mismatch – Struttura pacchetto: [STX] || [Indirizzo][Tipo_pacchetto][num_sequenza][dati][CHK] || [ETX] 6/ 16

7. SISTEMA DI CONTROLLO – Triggerare esecuzione dei file audio dopo il delay programmato. – Rimanere in ascolto sulla porta seriale per esecuzione comandi. • Propri • “Helper” –12 x 2 Input e Output digitali. – 1 uscita per pilotare il reset moduli; – UART – memoria non volatile; – Prototipo con ATMEGA16L 7/ 16

8. SISTEMA DI CONTROLLO 8/ 16

9. BUS SERIALE MULTIDROP – Tutti i nodi in ascolto – Tx solo se indirizzo coincide – RS232 logica invertita – Idle “alto” – Buffer digitali IN/OUT 9/ 16

10. Software di gestione 10/ 16

11. SISTEMA DI MISCELAZIONE Attenuazione [dB] SIMULAZIONE Frequenza [Hz] 11/ 16

12. SCHEMA FINALE SOMMATORE – Partitore idealizzato – Uso di entrambi gli opmap nel package 12/ 16

13. MODULO ALIMENTATORE – Alimentazione 12 V CC → 5 V → 3.3 V – 80 mW / modulo (consumo tipico in play) 13/ 16

14. CONSIDERAZIONI FINALI – Sistema prototipo funzionante egregiamente. – Test protocollo con azioni disturbanti – Unplug cavo durante trasmissione. – Generazione di semplici errori nel pacchetto. – Problemi / semplicità derivanti da: – scelta del sistema modulare. – uso di campioni pre-registrati. 14/ 16

15. SVILUPPI FUTURI – Implementazione di una funzionalità di “sequencer autonomo” tipo “carillon”. – Play standalone ma gestione su PC. – Auto-apprendimento del tempo di ritardo. – Riduzione firmware moduli. – Miglioramento sicurezza protocollo. 15/ 16

16. Grazie per l'attenzione.