bonjour,
normalement avec un liaison I²C si SDA est bloqué à un alors il ne peut y avoir d’échange donc ou la routine read_reg est foireuse ou le capteur ne s'initialise pas bien, j'ai souvent çà sur celui que j'utilise le POR (power on reset) ne se faisant pas bien, il faut que la tension d'alimentation passe vraiment à zéro.
JR
l'électronique c'est pas du vaudou!
J'ai cru aussi que c'était à cause du bouton reset mais quand je regarde le signal à l'oscillo il est bon, pour ce qui est de la routine du read_reg je ne l'ai pas changé donc je pense pas que ça vienne de ça, pareil pour l'initialisation je n'ai pas changé la config des registres et j'ai essayé de mettre le code qui marchait avant. Est ce que selon toi ces symptômes peuvent être ceux d'un capteur défectueux ou je cherche sur une autre piste ? Dans tous ls cas j'ai commandé un nouveau capteur que je reçoit dans 3 jours.
re
dans mon cas j'utilise çà sur un robot à chenilles et il arrive que le capteur ne démarre pas , au mieux je coupe simplement l'alimentation du robot au pire il faut, qu'alimentation primaire coupée, je court circuite les pins d'alimentation du capteur, je pense que le POR à un seuil très faible et qu'un chouilla de tension résiduelle suffit à le rendre inopérant, j'avais déjà vu çà sur un processeur il y a bien longtemps.
JR
l'électronique c'est pas du vaudou!
Ce serait peut-être mieux de déplacer la discussion en Électronique maintenant ?
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
re
je pense aussi car son probleme est mi hard/mi soft.
il faudrait regarder à l'oscillo ce qui se balade sur SCL et SDA car s'il n'y a rien alors la routine read_reg serait bien foireuse. L'I²C c'est plein de pièges.
JR
l'électronique c'est pas du vaudou!
Discussion déplacée en Électronique.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
J'ai regardé à l'oscilloscope et les deux signaux sont à l'état haut il me semble. En revanche j'en ai pas parlé plus tôt mais cela fait maintenant 2 fois que je grille le micro que j'utilise sans aucune raison et je me demande si cela serait lié. La carte, comme je l'ai précisé précédemment, a été faites par des étudiants l'an dernier et les soudures ainsi que le routage sont plus que douteux, je n'ai pas trouvé de court-circuit pour l'instant mais je vais tester le régulateur demain pour être sûr qu'il delivre bien du 5v au micro. Sauf que j'ai effectivement du 5v sur la pin d'alimentation du capteur donc logiquement le régulateur est bon non? À moins qu'il y ait un filtre à l'intérieur du micro.
Re
pour observer SDA et SCL il faut utiliser un mode de déclenchement front descendant sur SDA en normal ou single shot s'il n'y a pas de trafic permanent.
Si ceci fait il n'y a pas de déclenchement et que la routine retourne quelque chose alors soit il existe un code d'erreur à lire quelque part soit c'est du soft de très mauvaise qualité .
Si le µC grille c'est qu'il y a une grosse bêtise!
Photos du malade stp.
JR
l'électronique c'est pas du vaudou!
Je t'envoie la photo demain quand je retourne travailler mais je te préviens tu vas avoir peur
Pour le code j'essaierai de regarder un peu mieux mais comme je t'ai dis le soft marchait très bien depuis le debut même si les valeurs n'etaient pas cohérentes par ma faute je recevais bien des données, en plus il est vraiment très simple, il s'agit de la routine basique pour lire sur i2c avec le compilateur ccs il n'y a que 5 ou 6 instructions assez basiques.
Bonjour,Envoyé par AKA TENDO
une bonne habitude consiste à faire clignoter une led sur un port pour s'assurer que le programme "tourne".
Fais une photo de ta carte pour voir comment tout ça est câblé et poste aussi ton schéma.
Bonjour effectivement j'allumais des leds pour vérifier que le programme tourne. Mais au bout d'un moment les leds se mettent à clignoter faiblement puis à ne pas clignoter du tout (après plusieurs programmation, quelques jours généralement) et le capteur ne s'alliment pas non plus quand les leds s'éteignent. C'est pour ça que je dis que le micro est mort.. on l'a changé 2 fois et ça a fait la même chose. Hors je ne pense pas avoir touché quoi que ce soit, c'est pour ça que je suis inquiet. Je vous envoie les photos dans quelques minutes. Le schéma je l'ai demandé mais je ne l'ai pas pour l'instant dsl..
IMG_20230120_082948.jpgIMG_20230120_082945.jpg
Voici les photos.
Mon problème de micro vient d'être résolu, pour l'instant... (cause : piste de 12V et gnd foireuse). J'ai donc remis le code que JR m'a proposé mais j'obtiens des valeurs qui changent alors que le capteur ne bouge pas et je pense qu'elles ne sont pas cohérentes voici une capture (je précise que je ne fais pas encore la division je veux voir les données brutes) :
Dernière modification par AKA TENDO ; 20/01/2023 à 10h50.
bonjour
relève le z aussi!
JR
l'électronique c'est pas du vaudou!
Bonjour JR. D'après mon professeur il n'y a pas besoin de relever le Z dans notre cas, c'est pour ça que je ne l'ai pas mis.
Re
ben si car comme déjà écrit si les axes X,Y sont horizontaux alors c'est l'axe z(perpendiculaire au plan du chip) qui porte l'information de la gravité.
JR
l'électronique c'est pas du vaudou!
Pourtant il a bien des valeurs cohérentes c'est ça qui m'étonne, à moins qu'il n'affiche pas les valeurs de z et qu'il ne fasse que les lire. Est ce que tu veux dire que les 2 valeurs dépendent de la lecture de l'axe z et qu'il faut obligatoirement au moins lire le registre?
re
non ce que je veux dire c'est que ton capteur, immobile, n'est soumis qu'à la gravité et celle ci se manifestera sur les 3 axes avec des niveaux dépendants de la position spatiale du capteur.
Avec un capteur parfait placé à l'horizontale on devrait avoir x = 0, Y=>0 ,Z = -1g.
Il faut donc toujours lire les 3 axes pour pouvoir exploiter leurs valeurs.
JR
l'électronique c'est pas du vaudou!
D'accord, dans ce cas j'essaierai de rajouter une ligne pour lire Z et je te tiens au courant en fin d'après-midi je pense. Merci.
re
prends le temps de refaire les brasures car là c'est vraiment crade!
JR
l'électronique c'est pas du vaudou!
J'y ai pensé mais malheureusement je ne préfère plus trop y toucher étant donné qu'on m'a dis que les étudiants avaient soudés et désoudés plusieurs fois pas mal de choses, il y a des endroits où il y a des brûlures et d'autres où les pastilles se décollent voire des pistes! Nous avons donc repris certaines choses avec le prof mais je pense qu'à ce niveau là il faudrait carrément refaire une carte.
J'ai donc réessayé de modifier le code pour lire l'axe z, malheureusement j'ai toujours le même problème avec mes valeurs, j'ai essayé de déclarer les variables pour mes axes avec différents types mais ça ne change pas vraiment mon problème. Bien evidemment ça doit être de ma faute je vous mets donc le code ci-dessous :
Pièce jointe 474013
Je vous remets le code, la pièce jointe ne fonctionne pas.
CODE:
Code:#include <16F877A.h> #fuses HS,NOWDT,NOPROTECT,NOLVP #use delay(clock=20000000) #use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) #use i2c(MASTER, sda=PIN_C4, scl=PIN_C3) #define READ_ADDR 0xD1 #define WRITE_ADDR 0xD0 #define REG_GYRO_X1 0X43 #define REG_GYRO_X2 0X44 #define REG_GYRO_Y1 0X45 #define REG_GYRO_Y2 0X46 #define REG_GYRO_Z1 0X47 #define REG_GYRO_Z2 0X48 #define GYRO_CONFIG 0x1B #define ACCEL_CONFIG 0x1C #define PWR_MGMT_1 0x6B #define POWER_MNGMNT 0x6B #define CONFIG 0x1A #define SAMPLE_DRATE 0x19 #define INT_ENABLE 0x38 #define REG_ACCEL_X1 0x3B #define REG_ACCEL_X2 0x3C #define REG_ACCEL_Y1 0x3D #define REG_ACCEL_Y2 0x3E #define REG_ACCEL_Z1 0x3F #define REG_ACCEL_Z2 0x40 #define WHO_AM_I 0x75 int TestRS = 0; void write_reg(int Reg, int val) { i2c_start(); i2c_write(0xD0); i2c_write(Reg); i2c_write(val); i2c_stop(); } int read_reg(int Reg) { //unsigned int data = 0; int buffer; i2c_start(); i2c_write(0xD0); i2c_write(Reg); i2c_start(); i2c_write(0xD1); //start with the address in read mode buffer = i2c_read(0); // read and store the data in a variable i2c_stop(); return buffer; } /*int16 lecture_cap(int reg) { // i2c_write(0xD0) aresse de base pour module // int data; i2c_start(); i2c_write(0xD0); // i2c_write(reg); // i2c_start(); i2c_write(0xD1); // pour recevoir la data " LSB(esclave)= 1 data=i2c_read(0); i2c_stop(); return data; } */ void MPU6050_Init() { write_reg(PWR_MGMT_1, 0x01); delay_ms(100); write_reg(CONFIG, 0x00); delay_ms(10); write_reg(GYRO_CONFIG, 0x18); // Pourquoi configurer Gyro et pas Accé delay_ms(10); write_reg(ACCEL_CONFIG, 0x00); // test 24/11 delay_ms(10); write_reg(SAMPLE_DRATE, 0x07); delay_ms(10); write_reg(INT_ENABLE, 0x01); delay_ms(10); } /*int check_addr (int reg_addr) //check if the slave's address is right { //read_reg(0xD0,buffer_Receive); //0x75 is the REG: WHO_I_AM if (buffer_Receive == 0x68) { return (1); } else { return (0); } } */ void main (void) { int TestRS = 0; int axeY ; int axeX ; int axeZ ; MPU6050_Init(); do { /* write_reg(0x1C,0x28); data = read_reg(0x1C); printf("\n\r valeur: %2u",data); output_d(testRS); delay_ms(500); TestRS=TestRS+1; */ //axeX= read_reg(REG_ACCEL_X1) << 8 | read_reg(REG_ACCEL_X2); //axeY= read_reg(REG_ACCEL_Y1) << 8 | read_reg(REG_ACCEL_Y2); axeX= (int)((read_reg(REG_ACCEL_X1) << 8) | read_reg(REG_ACCEL_X2)); axeY= (int)((read_reg(REG_ACCEL_Y1) << 8) | read_reg(REG_ACCEL_Y2)); axeZ= (int)((read_reg(REG_ACCEL_Z1) << 8) | read_reg(REG_ACCEL_Z2)); //axeX= (float)axeX/16384.0; //axeY= (float)axeY/16384.0; printf("\n\r axe Y: %d",axeY); printf("\n\r axe X: %d",axeX); output_d(testRS); delay_ms(500); TestRS=TestRS+1; delay_ms(500); } while(true);
Dernière modification par gienas ; 24/01/2023 à 12h50. Motif: Ajouté les balises code obligatoires pour les programmes
Bonjour,
j'eplucherais plus tard mais en premier lieu
Pour accéder aux mesures il vaut mieux passer par la FIFO.The data within the accelerometer sensors’ internal register set is always updated at the Sample Rate. Meanwhile, the user-facing read register set duplicates the internal register set’s data values whenever the serial interface is idle. This guarantees that a burst read of sensor registers will read
measurements from the same sampling instant. Note that if burst reads are not used, the user is responsible for ensuring a set of single byte reads correspond to a single sampling instant by checking the Data Ready interrup
JR
l'électronique c'est pas du vaudou!
Bonjour JR, effectivement je voulais te parler de ça plus tard mais puisque tu amène le sujet.. ^^. J'ai vu qu'apparemment il fallait utiliser la FIFO. Je comprends le principe de fonctionnement de la FIFO mais je ne vois pas pourquoi il faut l'utiliser, je n'ai jamais eu à le faire sur d'autres projets. D'autre part, j'ai réussi à avoir des valeurs à peu près potables en utilisant la fonction "make16" mais je ne comprends pas pourquoi ta façon de faire avec le décalage de bit me donne des valeurs aléatoires.
re
c'est lié à ce que j'ai mit en citation, la lectures des registres individuels doit être faite de façon rapide et synchrone avec leur mise à jour sinon on peut lire des valeurs appartenant à deux cycles de mesures différents , elle seront donc non consistantes, la FIFO évite ce désagrément puisque les données y sont mises à jour en bloc de façon synchrone .
JR
l'électronique c'est pas du vaudou!
D'accord, donc au final il faut que j'utilise la fonction make16 et le fifo c'est ça?
Les valeurs que j'ai reçu avec la fonction make16 ne sont pas au dessus de 3000 (sans la divison) mais je pense que je peux les utiliser comme ceci pour faire des tests non? (étant donné qu'elles sont précises pour l'inclinaison).
En fait j'ai envie d'utiliser le code comme ça pour les tests et en parallèle j'essayerai de faire quelque chose de plus correct, mon projet doit être quasiment finit à la fin de la semaine ^^'
Voici les valeurs que j'obtiens à plat sans mouvement :
En revanche, lorsque je rajoute dans le code la division par 16384.0, je n'obtiens que 3 ou 0 sur chaque axe je ne sais pas trop pourquoi.
Je vais continuer de creuser et de voir comment utiliser la FIFO.
bonsoir
faut il lire X,Y,Z ?
si oui et que l'accelero est configure +-2g c'est pas idiot.
JR
l'électronique c'est pas du vaudou!
Bonsoir, désolé sur la capture des données il y a marqué 2 fois axe X mais en réalité le deuxième c'est l'axe Z ( erreur de frappe dans le printf). Maiq effectivement je lis les 3 axes là. Car j'ai vu dans un exemple sur Internet que le Z doit se rapprocher le plus possible de 16384 et effectivement il s'en rapproche donc mes valeurs sont à peu près cohérentes. Par contre je n'ai rien trouvé par rapport au FIFO, j'ai compris qu'il y avait un buffer associé mais je ne comprends pas comment on le lit.
