Je souhaite lire une valeur sur mon DSP, un ADAU1466 de Analog Device qui est contenue dans un "ReadBack" à l'adresse 0x004C. Voici le code que j’ai fait :
#include <SPI.h>
//The pins I use
#define PIN_MOSI 11
#define PIN_MISO 13
#define PIN_SCLK 12
#define PIN_CS 10
void setup() {
Serial.begin(115200);
delay(100);
Serial.println("Démarrage ESP32-S3...");
//Define the PIN_CS as an output
pinMode(PIN_CS, OUTPUT);
//To be sure put CS in High level
digitalWrite(PIN_CS, HIGH);
delayMicroseconds(10);
//Placed ADAU1466 into SPI control mode by pulling SS/ADDR0 low three times
for (uint8_t i=0; i<3;i++){
digitalWrite(PIN_CS,LOW);
delayMicroseconds(10);
digitalWrite(PIN_CS,HIGH);
delayMicroseconds(2);
}
SPI.begin(PIN_SCLK, PIN_MISO, PIN_MOSI, PIN_CS);
delay(100);
digitalWrite(PIN_CS, HIGH);
Serial.println("Démarrage Connection SPI avec DSP...");
}
void loop() {
//1MHz to be sure it's not the source of the problem
//MSB first and Spi mode 3 as it says in the datasheet
SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE3));
//Put PIN_CS as LOW for the beginning of the transaction
digitalWrite(PIN_CS, LOW);
//Chip address : 0x00 and read : 1
SPI.transfer(0x01);
// Address MSB : 0x00
SPI.transfer(0x00);
// Addresse LSB : 0x4C
SPI.transfer(0x4C);
// Read and print the 4 byte I'm waiting for
uint8_t Data_Byte[4];
Data_Byte[0] = SPI.transfer(0x00);
Serial.println(Data_Byte[0]);
Data_Byte[1] = SPI.transfer(0x00);
Serial.println(Data_Byte[1]);
Data_Byte[2] = SPI.transfer(0x00);
Serial.println(Data_Byte[2]);
Data_Byte[3] = SPI.transfer(0x00);
Serial.println(Data_Byte[3]);
//Put PIN_CS as HIGH for the ending of the transaction
digitalWrite(PIN_CS, HIGH);
SPI.endTransaction();
delay(1000);
}
Cependant pour l’instant je n’obtiens que la valeur 0
Voici la partie de la datasheet sur laquelle je me suis basée :
Vous demandez les données juste après avoir envoyé la sub address
Les données ne sont pas immédiatement disponibles après l'envoi de la dernière commande sans doute ?
Cependant même si la lecture de Data_Byte[0] pourrait correspondre à l'envoi d'un dummy byte permettant l'alignement des données, voire Data_Byte[1] aussi, vous devriez voir quand même des données dans les Data_Byte restant.
La datasheet parle aussi d'une configuration du DSP avec SigmaStudio. Qu'avez vous fait de ce côté là ? Si je me souviens bien, il faut configurer une cellule ReadBack dans SigmaStudio, la connecter au paramètre actif que vous voulez lire, et utiliser l’adresse SPI correspondante pour obtenir des données valides.
Merci pour ta réponse, j’ai bien tenté un delayMicroseconds(10);entre chaque envoi, mais ça n’a rien changé.
La partie SigmaStudio fonctionne, j’obtiens bien ma valeur à l’adresse indiquée lorsque mon DSP est connecté à mon PC via l’USBi. Ci-joint le montage simple sous SigmaStudio :
C’est le SPI qu’il faut titiller pour qu’il mette ces bytes à disposition. Généralement on envoie au moins un 0x00 (dummy byte) et ensuite une n fait la lecture
Sinon votre code SPI a l’air correct. Vérifiez juste que l’adresse est la bonne
Ça c’est pour récupérer les 4 octets en réponse, mais il peut y avoir besoin d’envoyer au moins un dummy byte avant, qui va faire un tick d’horloge sur l’esclave et ça va permettre de démarrer le cycle d’envoi de données.
Mais comme je disais plus haut, ce n’est sans doute pas le problème car après une ou deux de vos lectures, les autres octets devraient contenir quelque chose (a moins que vous ne mesuriez un zéro).
oui , mais en même temps le datasheet montre le signal SCLK en idle au niveau LOW , et actif sur front montant : pour moi , c’est (comme généralement) du mode 0 …
Qui peut dire?
Dans la mesure où les données ne sortent pas sur le bon front on ne peut pas être certain qu'elles sont correctement interprétées dans le DSP.
La datasheet est relativement ambiguë concernant le SPI
Si on compare la figure 8 et la série des figure 37-39 la phase de l'horloge est inversée.
Je pense que cela vaudrait le coup d'essayer de changer les paramètres du SPI.
Il y a aussi un truc qui m'interroge,
N'y aurait-il pas une embrouille entre n° de brche et n° de GPIO?
Il n'y a en principe pas de mauvais choix dans la mesure ou on peut router les périphériques à travers la GPIO_MATRIX, en acceptant éventuellement une baisse de performance dans les débit les plus élevés. Je ne peux pas aller plus en détail car je n'utilise plus beaucoup les ESP32 en C mais dans la doc espressif il y a ceci
EDIT: je me réponds à moi même.
Si j'ai bien compris, la librairie SPI du package ESP32 crée par défaut une instance de cette manière SPIClass(uint8_t spi_bus = HSPI); donc elle utilise le périphérique hspi et lorsqu'on passe des valeurs aux arguments sck, miso, mosi ils sont connectés au périphérique. S'il y a une erreur sur l'usage du périphérique ou sur la connexion aux IOs il y a un appel de ce genre
err:
log_e("Attaching pins to SPI failed.");
return false;
donc il devrait y avoir un message en cas de problème il me semble.
De ce que je retiens, il ne semble pas y avoir d’erreur dans le code. Je vais ressortir mon oscilloscope pour tenter de mieux comprendre les fonctionnement
et tu entoures sur le dessin GPIO11, 12, 13 et 14.
Dans le code c'est le n° des GPIO qu'il faut indiquer pas le n° de la broche. Il faut bien comprendre que les librairies sont écrites pour fonctionner avec toutes les cartes. Le n° des GPIO est invariant quelque soit la carte alors que les GPIO qui arrivent sur les broches peuvent varier d'une carte à l'autre.
Agit-il comme un filtre? (si oui, si le signal d’entrée n’a pas de composante à 1000 Hz, la sortie RMS après le filtre pourrait aussi être proche de 0)
C’est de ma faute, c’est bien les GPIO 10,11,12 et 13 qui sont connectés. Et sur cette carte, ils correspondent bien aux broches 10,11,12 et 13, même si sur le schéma on a l’impression qu’ils sont décalés.
Il s’agit bien d’un filtre, mais justement un passe-bande centré sur le 1000Hz. En plus, j’obtiens bien un résultat lorsque je connecte mon DSP à sigma studio.
