Avec un esp8266 (wemos mini) l'utilisation de chacune des bibliothèques en mode séparé fonctionne mais l'écran devient bloqué dès qu'une action sur la SD intervient.
Je soupçonne que dans une bibliothèque l'affectation d'une pin ne soit pas effectuée correctement au changement de bibliothèque.
Faudrait-il fermer une instance avant d'en ouvrir une autre ?
Je suis bien incapable de résoudre ce genre de pb
L'usage des bibliothèques U8G et Sd sur un ATmega 2560 ne posait aucune difficulté semblable en SPI mais ce n'était pas le même écran.
Pour éviter les soucis avec plusieurs périphériques SPI, je passe toutes les pins CS en output HIGH avant tout appel aux périphériques.
Cela permet d’eviter des réponses parasites de ceux qui n’auraient pas encore été initialisés par leur bibliothèque respective.
À tenter au début du setup:
Edit:
Je crois savoir que certains modules SD ne relâchent pas correctement certaines pins du bus SPI, du coup ils ne fonctionnent pas correctement sur un bus partagé. D’autres intervenants sur le forum auront plus d’infos sur le sujet je pense.
J'ai un esp8266 branché avec un adaptateur microSD ET un écran lcd UC1701X
Je charge un programme pour lire écrire sur la SD : pas de pb
je charge un programme pour afficher sur le lcd : pas de problème
Donc les connections des matériels n'entrent pas en conflit
Je lance le programme de mon premier post
l'affichage "ecran ok s'affiche sur le lcd
le programme ensuite interroge le lecteur sd, constate bien qu'il n'y a pas de sd dans le lecteur MAIS si les messages en console série sont bien affichés, le texte "ecran ok" devrait s'effacer et être remplacé par "pas de Sd"
Il n'en est rien
Donc les commandes de l'écran ne sont plus reconnues.
Les ordres pour MISO, MOSI, SCLK qui ne devraient être pris en compte que s'ils sont validés par leur CS respectif doivent passer sur l'écran quand sd est concerné et le bloquer ou ne plus passer après usage de SD...
Est-ce parce que Wire ne fait pas correctement son boulot ? ou bien ???
Après réflexions et essais il semble que l'ajout de U8G2.begin(); avant chaque appel de l'affichage corrige
Il faut que je teste plus précisément si un SD.begin(D1) est aussi nécessaire mais il semble que non
j'avais eu un pb assez similaire, avec un autre écran mais exactement les mêmes symptômes. Résolu en utilisant des pin miso mosi sck différents par periphérique: