Go Down

Topic: SPI : comment faire cohabiter 2 modules ? (Read 5882 times) previous topic - next topic

Artouste

#15
Feb 16, 2015, 09:43 pm Last Edit: Feb 16, 2015, 09:43 pm by Artouste
non ...
bon
alors il va falloir y aller à tatons :smiley-mr-green:
si tu deconnecte ton ecran , tu obtient des valurs OK en serial du 5541 ?
si tu deconnecte ton 5541 , ton ecran est OK ?


hatoupix

bon
alors il va falloir y aller à tatons :smiley-mr-green:
si tu deconnecte ton ecran , tu obtient des valurs OK en serial du 5541 ?
si tu deconnecte ton 5541 , ton ecran est OK ?


Oui et oui

idem si ils restent tous les 2 connectés MAIS si je n'en déclare qu'un dans le code

Artouste

Oui et oui

idem si ils restent tous les 2 connectés MAIS si je n'en déclare qu'un dans le code
alors 2eme phase 8)
tu declare les 2
tu alimente les 2
et tu regarde a partir de quelle connection de  ligne SPI ajoutée/retranchée ça coince/repart

il faut considerer les 2 dispositifs , donc papier crayon pour faire un "joli tableau"  :smiley-mr-green: 

hatoupix

alors 2eme phase 8)
tu declare les 2
tu alimente les 2
et tu regarde a partir de quelle connection de  ligne SPI ajoutée/retranchée ça coince/repart

il faut considerer les 2 dispositifs , donc papier crayon pour faire un "joli tableau"  :smiley-mr-green: 

bon pô facile ... mais rien de tip top : si les 2 sont déclarés et si je débranche l'un (j'ai déjà essayé un par un ) ... eh bien ca ne fonctionne toujours pas ...

c'est donc très certainement un problème soft ...

Artouste

bon pô facile ... mais rien de tip top : si les 2 sont déclarés et si je débranche l'un (j'ai déjà essayé un par un ) ... eh bien ca ne fonctionne toujours pas ...

c'est donc très certainement un problème soft ...
la probalité non nulle est grande :smiley-mr-green:
ton code et les libs utilisées

hatoupix

la probalité non nulle est grande :smiley-mr-green:
ton code et les libs utilisées

#include <ILI9341_due_gText.h>
#include <ILI9341_due.h>
#include <MS5541.h>

pour le code, rien de spécial :
#define TFT_CS 10
#define TFT_DC 9
#define TFT_RST 8

//Ecran TFT 2.2"
ILI9341_due tft(TFT_CS, TFT_DC, TFT_RST);
ILI9341_due_gText txt(&tft);

// Capteur de pression
MS5541 PressSensor;



  tft.begin();
  tft.fillScreen(COULEUR_FOND);
PressSensor.update();
airPressure = PressSensor.getPressureBar();




hatoupix

J'ai pensé à une solution qui devrait fonctionner mais je ne sais pas comment la coder :

comment à l'instar de la création de l'instance PressSensor(MS5541 PressSensor; ), je pourrais la détruire ? ... et ce "proprement" car ces méthodes sont dans de le loop, et si je peux éviter d'etre en overflow ...

mais comment faire ? :smiley-confuse:



derder9161

Deux solutions

La lib contient un constructeur donc tu peux ecrire le destructeur

Seconde solution et cela semble être la meilleur pour répondre strictement a Ta question : tu fais un appel de fonction qui te retourne la valeur de ton capteur et tu instance l'objet uniquement dedans (donc en local) ce qui sous entend qu'il sera détruit a la fin de la fonction)

hatoupix

Deux solutions

La lib contient un constructeur donc tu peux ecrire le destructeur

Seconde solution et cela semble être la meilleur pour répondre strictement a Ta question : tu fais un appel de fonction qui te retourne la valeur de ton capteur et tu instance l'objet uniquement dedans (donc en local) ce qui sous entend qu'il sera détruit a la fin de la fonction)
j'ai essayé la seconde solution ... ca marchotte : au premier passage ca semble plutot ok, mais à partir du 2e l'effet "avant instanciation locale" recommence ... a croire que la destruction ne détruit pas tout ou bien que l'autre composant SPI "garde en mémoire" des données qu'il ne devrait pas !

je vais donc continuer à chercher sur 2 plans : un destructeur "correct" ET/OU mettre en "disable" mon écran TFT

si vous avez d'autres idées ....

fdufnews

#24
Feb 18, 2015, 04:51 pm Last Edit: Feb 18, 2015, 04:52 pm by fdufnews
Je pense que tu ne peux pas faire cohabiter sur un bus SPI le MS5541 et un composant SPI.
Le MS5541 n'est pas compatible SPI dans la mesure ou il n'a pas de Chip Select. Le pattern qui active sa sortie peut apparaître n'importe quand lorsque tu dialogues avec ton afficheur et cela crée un conflit sur DOUT.

Je vois 2 solutions:
1) gérer ce capteur par SPI logiciel comme abordé précédemment. Ainsi il sera sur d'autres broche et il n'y aura plus de conflit.
2) utiliser un buffer sur DOUT que serait en haute impédance lorsque tu ne veux pas lire le MS5541. Cette solution évite d'utiliser des broches supplémentaires par contre elle oblige à ajouter un composant dans ton système. De plus même si le DOUT est déconnecté cela n'empêcherait pas le MS5541 de détecter un START dans le flux de données sur le SPI qui ne lui est pas destiné. Il faudrait donc débuter tous les transferts par un RESET tel qu'indiqué dans la doc du composant.

hatoupix

Je pense que tu ne peux pas faire cohabiter sur un bus SPI le MS5541 et un composant SPI.
Le MS5541 n'est pas compatible SPI dans la mesure ou il n'a pas de Chip Select. Le pattern qui active sa sortie peut apparaître n'importe quand lorsque tu dialogues avec ton afficheur et cela crée un conflit sur DOUT.

Je vois 2 solutions:
1) gérer ce capteur par SPI logiciel comme abordé précédemment. Ainsi il sera sur d'autres broche et il n'y aura plus de conflit.
2) utiliser un buffer sur DOUT que serait en haute impédance lorsque tu ne veux pas lire le MS5541. Cette solution évite d'utiliser des broches supplémentaires par contre elle oblige à ajouter un composant dans ton système. De plus même si le DOUT est déconnecté cela n'empêcherait pas le MS5541 de détecter un START dans le flux de données sur le SPI qui ne lui est pas destiné. Il faudrait donc débuter tous les transferts par un RESET tel qu'indiqué dans la doc du composant.
je ne vois pas comment gérer mon capteur en SPI logiciel ...  (si c'est mettre un destructeur, c'est fait mais ca donne rien ...)

Merci

fdufnews

Non c'est émuler le fonctionnement du SPI avec des IO classiques. Je me demande s'il n'y a pas déjà une librairie qui fait ça.

hatoupix

Non c'est émuler le fonctionnement du SPI avec des IO classiques. Je me demande s'il n'y a pas déjà une librairie qui fait ça.
oula, en voila une solution qui m'irait bien ! je vais chercher ... si jamais tu as le lien, n'hésites pas  ;D

fdufnews

#28
Feb 18, 2015, 09:37 pm Last Edit: Feb 18, 2015, 09:43 pm by fdufnews
Je pense qu'on doit pouvoir le faire tout simplement en utilisant shiftIn et shiftOut Par contre cela implique des transferts modulo 8 bits il faudra peut être bricoler un peu. Au pire il suffira de récupérer le code de shiftIn et shiftOut pour l'adapter.

hatoupix

Je pense qu'on doit pouvoir le faire tout simplement en utilisant shiftIn et shiftOut Par contre cela implique des transferts modulo 8 bits il faudra peut être bricoler un peu. Au pire il suffira de récupérer le code de shiftIn et shiftOut pour l'adapter.
j'aime beaucoup le "tout simplement"  :P ...je vais me plonger dans ces transformations ... bon ca fait longtemps que j'ai pas fait de vrai dev ... mais je vais tenter !

Merci pour toutes ces infos !

Go Up