J'utilise un atmega2560 que j'ai bootladé avec un arduino uno.
Pour ce faire j'utilise les pin SPI pour bootloder le µP tel que décrit dans le tuto de référence de ce site (https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard), puis le protocole UART (Tx et Rx) pour charger mon programme.
Tout fonctionne parfaitement, mais j'ai un problème avec le pin 50 (MISO), que j'utilise dans mon programme pour une sortie digitale classique, la sortie reste toujours à "high".
Je me demande si cette sortie n'est pas "définitivement" inutilisable en sortie classique du fait de l'utiliser aussi lors de la gravure de la séquence d'initialisation?
Pour être plus précis j'utilise cet atmega2560 dans un ampli audio, il gère un certain nombre de fonctions (sélection des entrées audio, décodage d'une télécommande infra rouge, afficheur OLED... et surtout un potentiomètre actif numérique (puce PGA2311).
Cette puce à une fonction "mute", c'est à dire lorsque son entrée est à 1 la puce est active, à 0 elle est silencieuse.
J'assure cette commande à l'aide du pin 50 (MISO), via la télécommande. J'ai plusieurs fois modifié mes cartes électroniques et mon programme, et jusqu'ici tout fonctionnait bien (en tous cas pour ce qui concerne les fonctions du µP).
En poursuivant mes tests, je me suis aperçu que cette fonction "mute", qui était instantannée autrefois, n'est pas inactive comme je l'ai mentionné plus haut,mais s'applique au bout de quelques secondes, avec un comportement anormal: le son se coupe progressivement, avec un tremblement curieux, en dent de scie.
A votre avis est-ce un problème de "hard" ou une mauvaise utilisation de cette sortie?
Ce que tu appelles "programmer par "SPI" est en fait le mode ISP (In Situ Programming).
Le SPI correspond à une fonction secondaire de certaines I/O, d'où la confusion facile entre ISP et SPI puisqu'ils utilisent les mêmes pins, mais pas au même moment le mode ISP n'étant accesssible qu'au démarage du micro.
Ce mode ISP est le PREMIER mode de programmation des micros avr, en conséquence "il est étudié pour" et ne peux pas détériorer le micro.
Le mode "par bootloader" n'est pas le mode initial : il faut bien charger le bootloader dans le micro, et cela se fait en ISP.
Je pense plutôt à un problème matériel.
La première explication qui vient est une charge/décharge de circuit RC.
Quels changement entre le moment où cela fonctionnait vite et maintenant ?
Il y a-t-il des résistances supplémentaires dans ton circuit ?
Et encore plus raz les paquerettes : as-tu testé avec une autre sortie, histoire de vérifier que la pin 40 n'a pas été endommagée par quelques fausses manip, involontaires et donc passées inaperçues ?
Idem pour le potentiomètre.
Merci pour ta réponse.
En effet il s'agit bien d'un mode "ISP" et non SPI.
D'après ce que je comprends, il n'y a pas d'interdiction d'utiliser ce pin pour une fonction traditionnelle.
Il n'y a pas vraiment eu de changements dans le circuit, sauf l'ajout d'un connecteur en parallèle pour pouvoir programmer la puce. (pas de circuit RC autres que ceux destinés à découpler l'alimentation de la puce)
Je penche donc pour un problème matériel. Il est possible que ce soit un simple problème de soudure (pas facile de souder cette minuscules puce!).
je vais re-contrôler tout çà et reviendrai donner le résultat
Après vérification, il ne s'agit pas du problème énoncé: le pin fonctionne bien, il sort 0 ou 1 correctement.
Je ne pense pas qu'il s'agisse d'un problème de hard, mais plutôt de programme.
En fait, lorsque la fonction "mute" est active (low), le signal de sortie est amputé d'une partie du signal, pendant un laps de temps très court.Je poste une capture de lecture à l'oscillo du signal de sortie (1kHz en entrée, mute active).
Le code que j'utilise est très simple (C/C d'un extrait qui me semble lié au transfert SPI car il y a plus de 500 lignes en tout je ne voudrai pas que vous passiez 1 h à déchiffrer tout mon charabia
Je ne sais pas si la description de mon problème vous semble clair? En tout cas merci de vous y pencher!
#include <SPI.h>
const int slaveSelectPin = 53;
const int POT = 51; // assignation pin SPI potar
const int MUTE = 50; //assignation pin commande MUTE PGA
const int ZCEN = 12; //assignation pin commande ZCEN PGA
int niveau=0;
pinMode (slaveSelectPin, OUTPUT);
pinMode(POT, OUTPUT); // assigne pin de commande du potar
......
digitalPotWrite(niveau);
}
void digitalPotWrite( int niveau) {
peut être que je ne décris pas suffisamment mon problème, voici quelques précisions. je précise qu'au départ je présumais un problème de sortie du pin MISO, mais il n'en est rien (d'ou l'edit du titre de mon post)
Le PGA2311 est une puce qui intègre un potentiomètre actif deux voies. Actif car il permet un gain >0.
Il est cadencé à 6,25Mhz max et communique via le port SPI.
Une fonction "zero crossing" permet de détecter le moment ou le signal s'annule pour modifier le gain, afin de réduire les bruits de transition. Au bout de 16ms, le gain est modifié quoiqu'il arrive.
Un fonction MUTE est integrée, en mettant la pin dédiée à la masse (que je commande via le pin MISO de mon atmega2560). Cette commande doit déconnecter le buffer interne de PGA, et mets les sorties G et D à la masse via une résistance interne de 10k.
C'est là oû le bât blesse car dans mon cas celà ne fonctionne pas. Comme vous pouvez le constater à la mesure à l'oscillo, seul quelques cycles du signal est annulé.
Bref j'imagine qu'il y a un problème dans mon programme, dont je vous ai mis un extrait qui correspond à ce qui concerne cette puce PGA, le reste du programme étant dédié aux autres fonctions, qui fonctionnent par ailleurs très bien.
Merci pour vos lumières, car j'ai essayé un tas de trucs qui n'ont eu aucun effet.
