Pic Micro, Arduino, Atmel, Microchip, Freescale, Texas Instrument, ecc. Strumenti di sviluppo, firmware e progetti.
Avatar utente
da Gio55
#4102
Salve.

Sto utilizzando in un progetto un DSK6713 dotato del codec AIC23 della TI. Sto cercando la documentazione dei comandi da invaire al codec, dicamo una sorta di descrizione del protocollo di funzionameto.

La documentazione purtroppo è scarsa e non sono risucito fin ora a trovare nulla a rigurado, mi sembra sia disponibile solo il Data Manual che però non contiene nulla a rigurado.

Da quello che ho capito, il codec è connesso al DSP della board tramite la seriale 1, in cui il canale di trasmissione serve per niviare i campioni del segnale da generare, mentre il canale di ricezione per la acquisizione dei segnali dall'esterno.

La seriale 0 serve invece per inviare i comandi all' AIC23.

Non voglio utilizzare le funzioni delle librerie varie BSL, mi serve in particolare il comando per richiedere la lettura del prossimo campione (credo da seriale 0).


p.s. Visto che la documentazione è partricolarmente scarna, magari sto prendendo una direzione sbagliata e la lettura dei camponi dall'ADC non viene gestita con comandi, ma vado per ipotesi in analogia con altri sistemi che invece prevedono comandi per far partire le acquisizioni
da zioelp
#4103
Non ho esperienza diretta coi DSP e col mondo dell'audio digitale, ma se dovessi indagare a fondo sul problema che riferisci partirei dal significato tecnico del termine "codec", dato dall'unione di "coder", cioè codificatore, e "decoder", ovvero decodificatore.
Nelle applicazioni in campo audio, il coder accetta un segnale analogico proveniente da microfono o altra fonte sonora, e lo "codifica" in un flusso ininterrotto di numeri. Il decoder svolge l'operazione inversa, consistente nell'accettare il flusso ininterrotto di numeri e "decodificarlo" al fine di riavere il segnale analogico d'origine.
Detto così sembra semplice: da un lato entra l'audio ed escono i numeri; dall'altro entrano i numeri ed esce l'audio, esattamente come nei classici ADC (da analogico a digitale) e DAC (da digitale ad analogico).
In realtà il principio sembra semplice, ma la realizzazione pratica deve fare i conti con le varie esigenze tecniche, legate ad esempio alla qualità e alla gamma dinamica dell'audio da trattare, e con le ancor più varie esigenze economiche, legate più che altro al costo e all'ingombro dei componenti necessari.
Per farla breve: il classico CD audio "ragiona" con 44100 numeri al secondo, ciascuno dei quali occupa 16 bit ovvero 16 "percorsi elettrici" distinti e separati.
I mixer digitali per la produzione audio possono "ragionare" anche con centinaia di migliaia di numeri al secondo, ciascuno dei quali occupa anche 32 bit.
Alla luce di quanto sopra, la semplice idea di far passare i numeri che escono dallo stadio ADC ed entrano nello stadio DAC attraverso 32 piste in un circuito stampato è già poco allettante in sé, e diventa subito impraticabile per la quasi totalità dei gadget moderni, di solito proposti al pubblico a 19,90 IVA compresa. :)
Scherzi a parte, una possibile "furbata tecnica " per evitare metri di piste parallele consiste nel serializzare i bit, ovvero prenderne una badilata di 32 dall'uscita dell'ADC, e quindi inviarli rapidamente uno per uno attraverso un solo percorso elettrico uscente dal coder.
Il decoder all'altro capo del filo adotta la medesima strategia: si aspetta "raffiche" di bit in fila indiana e provvede a riformare i gruppi di 16, 24, 32 o altra quantità prevista, pronti per entrare in un DSP o direttamente nello stadio DAC.
Ovviamente, per non rallentare il flusso e quindi "sporcare" o "singhiozzare" l'audio, i bit che passano in fila indiana devono correre ad una velocità molto maggiore di quella delle badilate, e soprattutto devono viaggiare osservando una cadenza precisa che sia ben nota ad entrambi i partecipanti allo scambio.
Per fare in modo che i bit entrino ed escano dal filo rispettando la giusta cadenza, si è pensato di aggiungere un segnale di clock: ogni volta che il clock cambia stato, un bit entra o esce dal filo, che a questo punto possiamo chiamare a ragione "linea dati".
E per serializzare un segnale audio stereo? Nessun problema: aggiungiamo un terzo filo che serve per indicare quando la linea dati trasporta i numeri del canale sinistro, ad esempio con un livello 0, e di conseguenza i dati del destro, in questo caso con un livello 1.
Il terzetto di fili appena descritto viene in genere "incastrato" nei circuiti dei codec, affinché i numeri possano entrare e uscire senza occupare decine e decine di piste.
Quanto sopra dovrebbe far emergere l'idea che il flusso dei numeri per l'audio digitale sia in natura continuo e rapido, quindi poco adatto ad essere gestito con un protocollo del tipo "chiedi e ti sarà dato".
Non credo che il codec abbia bisogno di un segnale che lo autorizzi ad emettere i singoli campioni, semplicemente perché i campioni fanno parte di un flusso in tempo reale agganciato al clock.
E' però probabile che il codec abbia un registro di configurazione dove uno o più bit fungano da interruttori per bloccare o consentire i flussi in arrivo e in partenza: se questi non sono nello stato giusto, il codec può apparire fermo e quindi non svolgere alcuna funzione visibile, o meglio, ascoltabile dall'esterno.
Gio55 ringraziano
Avatar utente
da Gio55
#4110
Grazie molte per le spiegazioni.
Il codec l'ho impostato seguendo il manuale e ho poi verificato la configurazione che gli ho impsoto su esempi disponibili dala TI. E' nella modalità master (può lavorare anche come slave). In pratica a quanto ho letto il clock dovrebbe essere così fornito dal DSP.

La cosa strana infatti (a conferma di quello che hai scritto nel post) è che impostando la interrupt di ricezione seriale non "scatta" mai. Veramente strano mi sare aspettato che l'evento si verificasse ad ogni campione emesso dal CODEC.
L'evento di ricezione si verifica solo se richiamo la funzione delle librerie DSK6713_AIC23_read (funziona anche con quella della McBSP : modulo seriale del DPS). Per questo pensavo che la funzione delle librerie avesse all'interno la trasmissione di un comando del tipo "manda nuovo campione". Evidentemente non è così come pensavo, ma ovviamente non avendo possibilità di leggere come hanno scritto la funzione non so come procedere.

Vorrei infatti svincolare la ricezione dei dati dal polling, inserendo un while nel main che richiami la funzione di lettura (potrei perdere dati).

Tu che mi consigli?
da zioelp
#4111
Gio55 ha scritto:La cosa strana infatti (a conferma di quello che hai scritto nel post) è che impostando la interrupt di ricezione seriale non "scatta" mai. Veramente strano mi sare aspettato che l'evento si verificasse ad ogni campione emesso dal CODEC.

Hai modo di stabilire se il CODEC emette almeno un campione?
E' probabile che il meccanismo sia concepito così: il CODEC emette un campione, e questo produce un interrupt che, per qualche motivo, invece di essere accettato (acknowledged) dal firmware, rimane in sospeso, impedendo di fatto il riconoscimento dell'arrivo di ulteriori campioni.
La funzione DSK6713_AIC23_read che chiami "manualmente" sembrerebbe più efficace se chiamata in automatico dall'interrupt stesso, o comunque attivata in diretta relazione con esso, ad esempio con un flag.
A spanne, il difetto sembrerebbe imputabile all'assenza di un init: per caso, esiste una DSK6713_AIC23_init, o similare, predisposta per essere chiamata una-tantum in testa al programma?
Gio55 ringraziano
Avatar utente
da Gio55
#4112
Hai modo di stabilire se il CODEC emette almeno un campione?

Si ho pogrammato il timer1 che periodicamente richiama la funzione DSK6713_AIC23_write per emettere campioni di segnale (alla gìfrequenza che voglio) tipo 1kHz.

Poi ho impostato la interrupt seriale di ricezione, ma non viene mai attivata ovvero sembrerebbe ai verificarsi l'evento.
Per prova allora ho inserito nella routine del timer la funzione DSK6713_AIC23_read appena dopo aver emesso il campione. A questo punto scatta subito la interrupt seriale di ricezione :shock:

Se ho capito quello che mi dici forse dovrei programmare ed attivare anche la interrupt di trasmissione seriale? (del campione da emettere).

Riporto la lista delle funzioni disponibili delle librerie:

Codice: Seleziona tutto/* Set codec register regnum to value regval */
void DSK6713_AIC23_rset(DSK6713_AIC23_CodecHandle hCodec, Uint16 regnum, Uint16 regval);

/* Return value of codec register regnum */
Uint16 DSK6713_AIC23_rget(DSK6713_AIC23_CodecHandle hCodec, Uint16 regnum);

/* Open the codec with id and return handle */
DSK6713_AIC23_CodecHandle DSK6713_AIC23_openCodec(int id, DSK6713_AIC23_Config *Config);

/* Close the codec */
void DSK6713_AIC23_closeCodec(DSK6713_AIC23_CodecHandle hCodec);

/* Configure the codec register values */
void DSK6713_AIC23_config(DSK6713_AIC23_CodecHandle hCodec, DSK6713_AIC23_Config *Config);

/* Write a 32-bit value to the codec */
Int16 DSK6713_AIC23_write(DSK6713_AIC23_CodecHandle hCodec, Uint32 val);

/* Read a 32-bit value from the codec */
Int16 DSK6713_AIC23_read(DSK6713_AIC23_CodecHandle hCodec, Uint32 *val);

/* Set the codec output gain */
void DSK6713_AIC23_outGain(DSK6713_AIC23_CodecHandle hCodec, Uint16 outGain);

/* Set the codec loopback mode */
void DSK6713_AIC23_loopback(DSK6713_AIC23_CodecHandle hCodec, Int16 mode);

/* Enable/disable codec mute mode */
void DSK6713_AIC23_mute(DSK6713_AIC23_CodecHandle hCodec, Int16 mode);

/* Enable/disable codec powerdown modes for DAC, ADC */
void DSK6713_AIC23_powerDown(DSK6713_AIC23_CodecHandle hCodec, Uint16 sect);

/* Set the codec sample rate frequency */
void DSK6713_AIC23_setFreq(DSK6713_AIC23_CodecHandle hCodec, Uint32 freq);


Le interrupt invece le ho impostate con le librerie di base BSL della TI (comuni anche ad altri DSP e micro della casa) del tipo "IRQ_map" etc.. In particolare IRQ_map prende come parametro un intero che rappresenta l'handle dell'evento mappato per la ricezione seriale (piuttosto che eventuale trasmissione seriale, timer, GPIO etc..)
da zioelp
#4113
Gio55 ha scritto:Si ho pogrammato il timer1 che periodicamente richiama la funzione DSK6713_AIC23_write per emettere campioni di segnale (alla gìfrequenza che voglio) tipo 1kHz.

La funzione write, a mio parere, serve per inviare una word di 32 bit alla sezione DEC del CODEC, affinché i numeri che entrano diventino via hardware un segnale analogico disponibile su una presa o su un pin di un connettore fisico.
Gio55 ha scritto:Poi ho impostato la interrupt seriale di ricezione, ma non viene mai attivata ovvero sembrerebbe ai verificarsi l'evento.

In teoria, se non immagino male lo schema elettrico che non vedo, l'interrupt di ricezione dovrebbe scattare quando la parte CO del CODEC ha pronta una word di 32 bit derivante dalla conversione in digitale di un segnale analogico esterno.
Sempre in teoria, non vedrei alcun legame fra l'azione write che agisce sul decoder, e l'azione read che reagisce al coder. Il codec somiglia molto alla classica UART: c'è una parte che trasmette e genera un interrupt per avvisare il DSP che il buffer di trasmissione è vuoto e quindi pronto ad accettare un nuovo dato da spedire, e c'è una parte che riceve e genera un interrupt per avvisare il DSP che è arrivato un nuovo dato dall'esterno.
Nel caso della UART, la parte che trasmette è completamente slegata e separata dalla parte che riceve, e di solito è previsto che entrambe lavorino in simultanea condividendo solo l'accesso ai bus interni del microcontroller.
Nel caso del codec, dovresti leggere il data sheet e vedere se il chip è concepito per funzionare simultaneamente come coder e come decoder, o invece prevede la scelta esclusiva di solo una delle due modalità.
Gio55 ha scritto:Per prova allora ho inserito nella routine del timer la funzione DSK6713_AIC23_read appena dopo aver emesso il campione. A questo punto scatta subito la interrupt seriale di ricezione :shock:

Tale apparente stranezza potrebbe essere legata alla funzione DSK6713_AIC23_loopback, che immagino presente per testare il chip senza dover collegare segnali esterni. Se, per default, il chip operasse collegando internamente le sezioni analogiche, questo spiegherebbe perché il tuo ordine di trasmettere produca subito un evento di ricezione. Dai un'occhiata ai bit gestiti da DSK6713_AIC23_loopback; magari ne trovi uno che devi spostare dal default prima di lanciare il resto.
Gio55 ha scritto:Se ho capito quello che mi dici forse dovrei programmare ed attivare anche la interrupt di trasmissione seriale? (del campione da emettere).

Per rispondere alla domanda dovrei conoscere qualche dettaglio in più circa il circuito e l'applicazione: stai realizzando un lettore MP3? Stai provando un filtro audio? Stai pensando a un riconoscitore vocale?
Gio55 ringraziano
Avatar utente
da Gio55
#4122
In questi giorni stavo provando un programma che mi hanno passato, per provare una soluzione al problema che dicevo precedentemente, da prendere come spunto.
Il programma l'ho importato dalla versione 3 (con cui lo avevano sviluppato) e l'ho portato alla versione che utilizzo io la 5, grazie alla funzione Import di Code Composer Studio.

Mi succede una cosa stranissima che non riesco a spiegarmi, Ho inserito e verificato che le librerie fossero correttamente definite (con relativi path dalle impostazioni di progetto). Il programma viene correttamente compilato.

Qunado provo ad eseguirolo (nella modalità debug) se inserisco 2 breack point, raggiunto il primo all'inizio del porgamma dopo aver inizializzato le variabili non riesce a raggiungere il secondo. Ho provato a spostare il secondo per identificare dove il programma sembra incepparsi, mi sembra sia causato da una istruzione che richiama funzioni della libreria math .h (in cui sono presneti variabili double).

Da cosa può dipendere? Visto anche il precedente problema sulla seriale nel programma da me sviluppato, comincio a sposettare che ci sia qualche problema sulle librerie ma non so che fare e come procedere, Aspetto tuoi consigli :)
da zioelp
#4123
Il software è l'arte di perder tempo dietro gli svarioni altrui. :) Le cosiddette "librerie" sono il classico esempio di arma a doppio taglio: da un lato promettono un ipotetico risparmio di tempo quando funzionano, ma dall'altro mantengono una sicura perdita di tempo quando non funzionano. Henry Ford (quello delle automobili) diceva che le anatre depongono le uova in silenzio, mentre le galline fanno un sacco di baccano, col risultato che tutto il mondo mangia uova di gallina. Nel mio lavoro di consulente in elettronica e informatica ho maturato la convinzione che il software debba svolgere solo quattro operazioni di base: apri, chiudi, leggi, scrivi. Dal semplice timer per un tostapane, al meno semplice controllo di guida per un missile intercontinentale, il software deve sempre aprire, chiudere, leggere, scrivere. Quando scrivevo in assembler sul DEC PDP-11 (una roba vecchia che ormai è preistoria) potevo aprire e chiudere con quattro istruzioni che, eseguite da un processore con clock di pochi megahertz, apparivano precise e velocissime su tutte le possibili varianti in catalogo. Oggi, chi scrive in linguaggi "blasonati-web-cluod-net" ad alto livello su processori con clock di gigahertz, occupa (involontariamente) mezzo megabyte di codice per aprire, un altro mezzo per chiudere, eppure ottiene un'esecuzione "a singhiozzo" che risulta affidabile solo fra un aggioramento e l'altro, ovvero, in media, dal caffé delle 9 alla pausa pranzo delle 13. E' un cane che si morde la coda: se ti dico che potresti aprire e chiudere con quattro righe leggendo il manuale per dieci minuti, tu non compri la mia libreria che ho scritto in dieci minuti leggendo il manuale al posto tuo. Ora, se ti facessi vedere che la mia libreria occupa quattro righe, tu penseresti di scriverla da solo e non la compreresti, danneggiando di fatto il mio business. Per evitare il danno al mio business, devo solo "mascherare" le quattro righe utili in mezzo a quattro milioni di righe inutili, e devo indurti a pensare che, per scrivere quattro milioni di righe, io abbia lavorato sei mesi. A questo punto potresti obiettare che moltissime librerie son gratuite, e anche gli stessi IDE dal nome fantasioso, con termini accattivanti quali Composer, Warrior, Studio, Lab e via dicendo, sono ad apparente costo zero pur facendo scena e sembrando più che validi. E' vero che tali software non li paghi direttamente, ma solo perché l'industria paga indirettamente i chip sul quale gireranno i programmi che scrivi. Un nuovo processore può essere bellissimo e validissimo, ma se il pubblico lo percepisce come "difficile da programmare", verrà subito scavalcato da un altro oggetto proposto con tecniche di marketing più scaltre e raffinate.
Esempio tipico l'onnipresente "Arduino": a mio parere è un'idea bellissima, utile, ben concepita, ma se si chiamasse "K28" o "Z97/100", probabilmente si venderebbe molto meno, perché in fondo non è altro che una scheda con sopra un comune microcontroller e dentro una "libreria" con un semplice interprete. Il successo commerciale di Arduino dipende da un paio di ragionamenti che, a prima vista, sembrano logici e legati fra loro: 1) l'utente medio non è in grado di assemblare una scheda hardware con sopra un microcontroller, e quindi la compra già pronta ad un costo ragionevole; 2) l'utente medio non è in grado si scrivere un interprete e una libreria, e quindi prende tutto già pronto a costo zero perché compreso nell'hardware di cui sopra. Il discorso non fa una grinza, ma purtroppo maschera un problema di fondo che invece dovrebbe far pensare: che cosa diavolo me ne faccio di un interprete e di una libreria, se devo solo far lampeggiare un LED o far girare un motorino alimentato da una pila? E soprattutto: che cosa farò quando invece di uno dovrò far lampeggiare due, tre, quattro LED? Arduino mi dà un pesce, non la canna da pesca, e soprattutto mi insegna a recarmi al supermercato per comprare un flacone di due litri di detersivo liquido invece di mostrarmi come preparare al volo dieci grammi di "bicarbonato di sodio" da diluire in due litri d'acqua presa dal mio rubinetto.
In conclusione: è mooolto probabile che i problemi nel tuo software derivino da incompatibilità fra l'IDE, le librerie, le versioni, gli aggiornamenti, i service-pack e tutti gli altri nomi commerciali onerosi e/o gratuiti coinvolti nel processo. :)
Se stai scrivendo per lavoro e ricevi uno stipendio, probabilmente ti conviene uniformarti e cercare una combinazione "libreria - hardware" più favorevole. Se stai scrivendo per hobby o per imparare, allora il mio suggerimento si sposta sul datasheet e sugli altri documenti: di certo farai più fatica, ma vuoi mettere la soddisfazione?
Gio55 ringraziano
Dimmer su aspirazione

Ciao a tutti ho una ventola di aspirazione in came[…]

Visita il nostro canale telegram