Università degli Studi di Trieste

Presentazione sul tema: "Università degli Studi di Trieste"— Transcript della presentazione:

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 Laureando: Francesco Guzzi Relatore: Prof. Sergio Carrato Correlatore: Ing. Piergiorgio Menia 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 Boot istantaneo. Bassa latenza. 24 ingressi digitali. 1 uscita monofonica analogica. Ritardi programmabili per ogni voce. Gestione da remoto. Soluzione a memoria distribuita MODULO 2 ... 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 4/ 16

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][C HK] || [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.