SVILUPPO DI UN PROTOTIPO DI SIMULATORE

POLIFONICO PER CONCERTO DI CAMPANE

Trieste, 12 marzo 2013

Laureando:

Francesco Guzzi

Relatore:

Prof. Sergio Carrato

Correlatore:

Ing. Piergiorgio Menia

Università degli Studi di Trieste

DIPARTIMENTO DI INGEGNERIA E ARCHITETTURACorso di Laurea in Ingegneria Elettronica

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.

DELAY 1PLAY 1 DELAY 1 PLAYBACK

DELAY 1PLAY 2 DELAY 2 PLAYBACK AUDIO OUT

DELAY 1PLAY 24 DELAY 24 PLAYBACK

...

MEMORIACAMPIONI

INTERFACCIAREMOTO

PC

... ...

SEQUENCERESTERNO

2/ 16

SOLUZIONE IMPLEMENTATA● Boot istantaneo.

● Bassa latenza.

● 24 ingressi digitali.

● 1 uscita monofonica analogica.

● Ritardi programmabili per ogni voce.

● Gestione da remoto.

● Soluzione a memoria distribuita

BUS

MODULO 1

MODULO 2

MODULO 12

PLAY 1

PLAY 2

MCU

PLAY 24

OUT

PC

BUS

BUS

...

...

...

...

...

3/ 16

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

FIRMWARE CUSTOMInit audio structs

Set Pll

Auto Addressing

Check upload startup

Check volume startup

Main code Endless loop

GPIO conf

Init SPI

Enable interrupts

START

Set Hook

– 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

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

SISTEMA DI CONTROLLO– Triggerare esecuzione dei file audio dopo il delay

programmato.

– Rimanere in ascolto sulla porta seriale per esecuzione comandi.

• Propri

• “Helper”

7/ 16

–12 x 2 Input e Output digitali.

– 1 uscita per pilotare il reset moduli;

– UART

– memoria non volatile;

– Prototipo con ATMEGA16L

SISTEMA DI CONTROLLO

8/ 16

– Tutti i nodi in ascolto

– Tx solo se indirizzo coincide

– RS232 logica invertita

– Idle “alto”

– Buffer digitali IN/OUT

BUS SERIALE MULTIDROP

9/ 16

Software di gestione

10/ 16

SISTEMA DI MISCELAZIONESIMULAZIONE

Frequenza [Hz]

Attenuazione[dB]

11/ 16

SCHEMA FINALE SOMMATORE

– Partitore idealizzato

– Uso di entrambi gli opmap nel package

12/16

MODULO ALIMENTATORE

– Alimentazione 12 V CC → 5 V → 3.3 V

– 80 mW / modulo (consumo tipico in play)

13/16

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

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

Grazie per l'attenzione.