Go Down

Topic: Presentazione progetto e primi dubbi (Read 4 times) previous topic - next topic

gamby

Hehe, mi fa piacere trovare un altro chitarrista. Io ne ho terminato uno pochi mesi fa... Un clone di un Hiwatt DR-504, che è proprio un push pull di due EL34... E' stata una grandissima soddisfazione sentire le note della chitarra uscire da quelle valvole!

Tornando al progetto, la maggior parte dei circuiti sono semplicemente delle realizzazioni di alcuni circuiti presi da www.tonepad.com e www.generalguitargadget.com, se ti può interessare qualche dettaglio in particolare chiedimi pure!
La mia soluzione sarà pressapoco quella allegata sotto (ho fatto un po' di modellazione 3D per capire gli spazi): uno chassis in alluminio contenente tutto, da Arduino al display, ai vari regolatori di tensione a tutti i singoli circuiti degli effetti. Solo l'alimentatore principale sarà esterno. Poi con calma mostrerò meglio anche tutto il resto.

Il disturbo di commutazione sinceramente non mi ha mai dato più di tanto fastidio, nemmeno con i pulsanti meccanici. E a questo punto non sarà un problema neanche un ritardo di qualche ms in più, soprattutto se il ritardo software è trascurabile rispetto al ritardo del relay. Il mio dubbio era nato guardando dei filmati su youtube in cui utilizzando display e altre periferiche il ritardo era notevole, soprattutto per la visualizzazione della grafica sul display. Essendo però la visualizzazione meno prioritaria rispetto alla commutazione, a questo punto potrei tranquillamente eseguirla (nel software) dopo tutte le altre operazioni.

Quindi assodato che il relay può essere una soluzione fattibile, mi rimane da capire la questione della gestione digitale, separazione delle masse ed isolamenti. Sto già prevedendo una certa logica per riuscire a dividere le alimentazioni, ma non so fin dove posso tenere il tutto separato... Devo mettermi con calma ed analizzare tutti i circuiti che coinvolgono parti digitali.

MauroTec

Caspita si tratta di un progetto complesso sotto tutti i punti di vista, lato software il problema potrebbe presentarsi subito se non suddividi i compiti realizzando più schede a microprocessore che dialogano fra di loro. Una scheda con micro gestisce i pulsanti e dialoga con il display (display dodato di mcu), un'altra scheda mcu gestisce i relè il mute ecc, in questo modo puoi realizzare un pezzo è testarlo, alla fine metti tutto insieme e sai che funzionerà perchè ogni unita/pezzo/funzione è stata testata. Diciamo che l'approccio di sviluppo software è valido anche lato hardware, con la differenza che qui ci sono entrambe insieme.

Oggi sono in vena: :P

Ipotizziamo di avere 3 relè, 2 ( A e B) sono on e C è off  (on o off mi riferisco alla bobbina se è alimentata o meno), la scheda tastiera invia un dato via I2c a tutti i dispositivi connessi al bus, il dato cambia a secondo del pulsante premuto. Tutti i dispositivi sul bus I2c ricevono questo dato è sanno cosa devono fare (con il bus I2c c'è la possibilità di inviare una chiamata generale senza dover specificare l'indirizzo). Quindi la scheda relè pone A e B in off e C in on, il display è indipendente e può predersi la briga di fare anche giochini grafici, se non ha niente da fare, ma se arriva un dato sul bus I2c visualizzo il nuovo stato corrispondente, se arriva un nuovo dato nel bus mentre che è a lavoro verra messo nel buffer di dati.

La scheda tastiera può essere usata anche per gestire altri eventi esterni, tipo una interfaccia seriale (midi o meno) verso il mondo esterno.

Il display essendo dotato di mcu programmabile può essere usato anche per mostrare l'entita del segnale in modo grafico oltre che i volumi dei pot digitali il tutto agendo in modo indipendente dalla tastiera e dalla scheda relè.

Con questa suddivisione a livello softare non puoi avere problemi di nessun tipo, puoi gestire il debounche dei tasti senza influenzare le altre funzionalità.

Riguardo il rumore di commutazione, durante situazioni live se il rumore è minimo non è avvertibile dal publico, specie se stai suonando al pub, ma in registrazione potrebbe essere un problema, dipende tutto dall'entità del rumore stesso e quando e quante volte avviene una commutazione e questo dipende dal brano che stai suonando.

Se realizzi uno schema a blocchi funzionali, i primi problemi vengono fuori e saranno risolti prima di avere messo mani al portafogli.

Spero di averti dato spunto per future riflessioni.
AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

gamby

La tua soluzione indubbiamente è molto interessante... Vorrei però utilizzare alcuni componenti che ho già in casa, ed in particolare un paio di AD5206 (digital pot) e di MCP23S17 (expander) Sono entrambi su bus SPI e, visto che me ne serviranno due di entrambi avrei pensato di sfruttare ciò che ho in casa e risparmiare qualche buon euro. Cambierebbe qualcosa nelle modalità di comunicazione? Non conosco bene SPI e I2C.
Come display ne ho uno della nuelectronics che ho comprato sull'onda dell'entusiasmo (come quello del link youtube che ho messo sotto, non riesco a linkare direttamente il sito perchè è offline!)... E' molto bello ma occupa tutta la fila di i/o dal 22 al 53, quindi limita la quantità di pin disponibili. Proprio per questo avevo pensato agli expander.

Come gestione delle schede avevo già pensato ad una suddivisione con l'utilizzo di un unico gestore centrale (appunto l'arduino mega) e varie periferiche:
- una scheda con il circuto di debounce, dove ognuno dei pulsanti è collegato direttamente su un ingresso digitale (per il debouncing posso usare un integrato dedicato, ed eventualmente potrei sfruttare i 6 interrupt del mega per i pulsanti che richiedono una rapidità di risposta maggiore)
- una scheda con i relè collegati alle uscite di un expander, in modo che con il bus SPI ed una linea di attivazione gestisco tutta la catena di relè. Questo sarebbe il primo attivato alla pressione di un tasto
- un'altra scheda per i potenziometri digitali, sempre su bus SPI, il cui aggiornamento del valore sarebbe meno prioritario dell'attivazione dei relay
- un'ultima scheda con il secondo expander per i led di segnalazione, stessa logica di sopra ma ancora meno prioritario
- Infine il display, il meno prioritario di tutti, che potrei aggiornare tranquillamente alla fine di tutte le altre operazioni
In questo modo da un veloce calcolo dovrei avere a disposizione porte sufficienti per le varie linee di slave select e per tutti i pulsanti da collegare direttamente ad arduino.

Per quanto riguarda la parte software ho già messo in conto di partire da una cosa molto basilare, del tipo: alla pressione di un tasto attivo una serie di relè e una serie di led, se ri-premuto li disattivo. Poi potrei aggiungere la regolazione dei pot digitali (ad esempio alla pressione di un altro tasto aumento il valore di un potenziometro che mi intensifica un certo effetto). Infine aggiungerei le funzionalità del display.

Il display mi servirebbe essenzialmente per programmare alcune funzioni senza ricorrere al PC, ad esempio decidere quali relay attivare alla pressione di un tasto, modificare manualmente il valore di un pot.digitale e cose simili

http://www.youtube.com/watch?v=mzndn86Vs1c

MauroTec

Visto che hai già materiale dentro è d'obbligo usarlo e alla fine quelli che hai elencato vanno bene. Tra I2c e SPI cambia il numero di pin necessari per ogni device connesso al bus, 2 soli fili per I2c e 3 per ISP più 1 per il chip select.

Quindi gestirai tutto con l'arduino Mega?

Controlla quanto memoria flash e ram occupa la gestione del display, così da sapere quanto ti puoi allargare con il codice di gestione generale.

La rogna può essere la gestione dei pulsanti, se devi scrivere un debounce software questo o viene complicato oppure impiega un certo tempo in cui il micro non può fare altro che aspettare. Gli interrupt a tempo o esterni sono comodi per la gestione di eventi che devono essere serviti subito, infatti il micro sospende quello che sta facendo e salta ad eseguire la routine di interrupt ed esce da questa dopo avere eseguito tutto il codice contenuto, in questo frangente il loop non gira e se premi un pulsante il software non se ne accorge. Per questo motivo il codice della routine di interrupt deve impiegare il minor tempo cpu possibile.

Quote
Per quanto riguarda la parte software ho già messo in conto di partire da una cosa molto basilare, del tipo: alla pressione di un tasto attivo una serie di relè e una serie di led, se ri-premuto li disattivo. Poi potrei aggiungere la regolazione dei pot digitali (ad esempio alla pressione di un altro tasto aumento il valore di un potenziometro che mi intensifica un certo effetto). Infine aggiungerei le funzionalità del display.


Devi mantenere in memoria lo stato attuale di ogni relè, ho usi una struttura (classe) o un array definendo delle #define come indici dell'array, tipo
#define IDX_RELE_BOOST     0
#define IDX_RELE_FLANGER 1
#define IDX_RELE_BYPASS    2
stateRele[10]

if (!stateRele[IDX_FLANGER])
    stateRele[IDX_FLANGER] = 1;

ecc.

Aspetto lo schema a blocchi funzionali.

Ciao.
AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

gamby

Si, è un arduino mega.
Non so se è sufficiente sapere questo, ma ho compilato uno sketch di esempio contenente tutto il necessario (librerie e codice) per alcuni menu, caratteri e touchscreen, e mi restituisce:

Dimensione del file binario dello sketch: 19.456 bytes (su un massimo di 258.048 bytes)

Per la gestione dei pulsanti non ho problemi ad utilizzare un debounce esterno (lo ho già testato con altre applicazioni), mentre per l'interrupt teoricamente tra una pressione e l'altra di un pulsante passa qualche istante (diciamo almeno mezzo secondo), quindi ci sarebbe il tempo per eseguire qualche operazione.

Per lo schema a blocchi mi serve un po' di tempo. Nei prossimi giorni sono piuttosto occupato, ma vedrò di disegnare qualcosa.

Grazie di tutti i consigli!

Go Up