Esec comanda PCM1795 de catre Arduino Nano

[merck]

Folosesc un Arduino Nano pentru a comanda prin SPI un DAC PCM1795. 

Liniile de cod sunt simple:

const int slaveSelectPin = 10;



void setup() {

pinMode(slaveSelectPin, OUTPUT);
SPI.begin();

SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE2)); //sau SPI_MODE0

}



void loop() {
    readRegister(18|0x80,0);

}



void readRegister(byte thisRegister, byte bytesToRead) {

digitalWrite(slaveSelectPin, LOW);

delayMicroseconds(1);

SPI.transfer(thisRegister);

SPI.transfer(bytesToRead);

digitalWrite(slaveSelectPin, HIGH);
delayMicroseconds(1);

}

 

Problema este ca nu reusesc sa citesc.

 

Forma de unda a clock-ului mi se pare bizara (nu inteleg de ce timp 625ns clock-ul ramane in High, dupa ce s-a trimis primul octet):

Si pe date am acel nivel de 1 logic intre cei doi octeti (trasa rosie). 

Daca scad frecventa pana acele 625ns devin nesemnificative, tot nu reusesc sa citesc.

 

Dupa cum se observa, acel nivel de 1 logic foarte ingust apare (trasa rosie) si daca am micsorat frecventa la 125kHz.

 

Am incercat toate cele 4 moduri de clock:

 

in cele de mai jos nu mai apare acel nivel 1 logic foarte ingust 

 

 

In documentatia lui PCM 1975 doar atat arata la formele de unda:

 

https://www.ti.com/lit/ds/sles248a/sles248a.pdf?ts=1643545241911&ref_url=https%3A%2F%2Fwww.google.com%2F

 

Ce gresesc?

Editat Februarie 13, 2022 de merck

[Vizitator]

15 minutes ago, merck said:

readRegister(18|0x80,0);

Trebuia sa ai 0x98 pe oscilograma. Tu ai 0x92. De ce ?

LE: Scuze, acum a vazut. 18 este in decimal. Este ok. 0x92

 

Editat Februarie 13, 2022 de Vizitator

[Vizitator]

Din grafic pare ca acea microsecunda intarziere dintre slavepin=LOW si inceput transfer pare foarte asemanatoare cu durata de 625ns dintre octeti.
Nu cumva este ceva gresit la clock/delay ?

 

[informer]

As incerca sa te ajut dar eu nu prea inteleg ce vrei sa faci: sa citesti registrul cu adresa 18 adica 0x12?

 

[merck]

Da, doresc sa citesc registrul 18.

 

P.S. DAC-ul audio PCM1795 merge pe 24 de biti by default si vreau sa il setez pe 32 de biti. Si daca modific (rescriu) valoarea registrului 18 trebuie sa il citesc sa ma conving ca am reusit sa il setez pe 32 de biti. 

Editat Februarie 13, 2022 de merck

[Bandi Szasz]

SPI trimite 8 biti ( 1 byte) si tu ai apelat de 2 ori  "SPI.transfer" consecutiv, in spate acele functii incarca niste registrii in modulul SPI care necesita timp,  de acolo si acel delay de 625ns. Se apeleaza primul SPI.transfer si se trimite primul octet iar dupa ai acel delay de 625ns care nu este altceva decat timpii necesari apelarii urmatorului SPI.transfer.

Pe tine treaba asta nu te intereseaza, datele se trimit si se citesc file pe "falling edge" fie pe "rising edge" adica in momentul in care se face tranzitia HIGH-LOW sau LOW-HIGH, cat timp ramane clock-ul LOW sau HIGH nu are nici o importanta.

 

Nu cunosc acel DAC insa cu siguranta lipseste ceva, probabil trebuie trimis inca ceva sau in alta forma ca sa intre in modul de citire, nu ai gasit vro librarie gata facuta pentru DAC-ul asta sa nu iti mai bati capu ?

 

 

Editat Februarie 13, 2022 de Bandi Szasz

[informer]

Atunci scrie ceva de genul:

result = SPI.transfer(bytesToRead);

Si pune analizorul pe MISO daca vrei sa vezi rezultatu` sau tipareste variabila result.
Validarea valorii se face pr fronturile determinate de MODEx.

 

Al doilea transfer genereaza cela 8 clock-uri pt. citirea rezultatului....

Editat Februarie 13, 2022 de informer

[merck]

Da, SPI trimite un octet si DAC-ul cere 2 octeti pentru o comanda de scriere/citire. Delay-ul de 625ns dintre doua apelari ale functiei SPI.transer banuiesc ca este asa cum zici tu necesar incarcarii registrilor dar de ce imi modifica si iesirea in 1 logic? Nu-mi dau seama daca nu cumva DAC-ul este deranjat de acel 1 logic parazit. 

 

 

6 minutes ago, informer said:

Atunci scrie ceva de genul:

result = SPI.transfer(bytesToRead);

Am incercat asa la inceput si rezultatul afisat a fost 0 sau 255 (am pus afisare in binar si era 11111111) dupa cum ii tuna lui.Deci aveam carnati de 0 pe coloana, apoi 14-19 valori de 11111111 si tot asa aleator. Asta ma determinat sa pun analizorul sa vad poate nu-s formele de unda corecte. 

6 minutes ago, informer said:

Si pune analizorul pe MISO daca vrei sa vezi rezultatu

Este pus si este 0xFF 0xFF (este trasa galbena)

Editat Februarie 13, 2022 de merck

[informer]

OK... si in mod sigur acel registru 0X12 sau 18 contine altceva decat0XFF?

 

[Vizitator]

13 minutes ago, Bandi Szasz said:

"SPI.transfer" consecutiv

Pare ok conform pdf.
Primul octet este adresa care trebuie citita, iar urmatorul byte este 0x00 pentru a genera clock-ul pentru citire valoare de la slave.
 

[merck]

Acum vad ca dupa 7 afisari se blocheaza si tipareste doar R (din Read si se opreste). 

 

 

Am mai reincarcat odata codul si acum tipareste 0 la infinit (macar ruleaza programul).

 

 

Editat Februarie 13, 2022 de merck

[Vizitator]

Ciudat este ca din oscilogramele lui @merck pare ca slave trimite date pe perioada (primul octet) cand trebuia sa astepte sa primeasca adresa.
Trebua ca abia apoi , pe timpul cand master trimite clock prin octetul 0x00, sa trimita si slave data.

 

 

Editat Februarie 13, 2022 de Vizitator

[informer]

Acum 12 minute, Liviu.Mihaiu a spus:

Ciudat este ca din oscilogramele lui @merck pare ca slave trimite date pe perioada (primul octet) cand trebuia sa astepte sa primeasca adresa.

Eu nu vad sa trimita date... daca ultima tresa este legata la MISO vad ca pastreaza acelasi nivel.

 

Pe de alta parte comportamentul este ca si cand cei 8 biti trimisi cand se transfera 0x00 ar fi pe 1.
Eu as incerca sa scriu intai ceva, sa fiu sigur ca am ceva diferit de 0xFF si dupa sa incerc sa citesc....

 

L.E. M-am uitat si eu in datasheet... dupa mine valoarea returnata de a doua apelare a lui transfer() ar trebui sa fie continutul registrului... si ala, cel putin default n-ar trebui sa fie pe 0xFF. Slave-ul asta SPI ii ca si cand n-ar fi acolo... 
 

Editat Februarie 13, 2022 de informer

[merck]

7 minutes ago, informer said:

Eu as incerca sa scriu intai ceva, sa fiu sigur ca am ceva diferit de 0xFF si dupa sa incerc sa citesc....

Incerc acum, insa ori pun din doua capturi ori una mai inghesuita ca sa incapa si scrierea si citirea.

Hm, am cuplat analizorul si nu mai citeste 0 ci 0xFF:

 

 

scot analizorul si iar tipareste 0.

Revin imediat cu scrierea si citirea consecutiva.

[informer]

Pai e nasol daca analizorul modifica starea unei linii digitale... inseamna ca aia-i in ceva high Z dupa mintea mea....

MSEL ii pus pe 0 pt. SPI? Ca daca ar fi in mod I2C fara rezistente de pull-up s-ar explica....

Editat Februarie 13, 2022 de informer