Tous les capteurs reliés au RPI par Wifi avec module ESP8266

[Jean-Marie]

Hello SMBA38

Je ne sais vraiment pas pourquoi ton OSF reste à 1. Tu as bien fait de recommander des DS1337 car ta puce est peut-être défectueuse ou endommagée.

Comment à la mise sous tension avoir un niveau bas sur INT1 (Ou sur INT2) pour alimenter le montage?

Une électronique est sans doute possible, mais au prix d'une consommation et d'une complication supplémentaire.
Pourquoi ne pas prévoir un petit bouton poussoir. Lorsqu'on remplace la batterie, il suffit d'une pression d'une ou deux secondes pour amener la gate du transistor switch à zéro. Le µC démarre et constate que la date de l'horloge est à zéro. Le µC maintient alors la gate à zéro avec une pin dédiée (le bouton poussoir peut être relâché), le temps d'entrer en contact wifi avec le poste central qui lui transmettra la date, l'heure et la fréquence de l'alarme. Ces données seront injectées dans l'horloge. Le µC remettra la pin dédiée à 1, ce qui coupera l'alimentation du µC et de l'ESP.

Je patauge lamentablement dans la programmation de la DS1337. Je vais probablement m'inspirer de l'exemple que tu donnes mais celui-ci utilise soit un langage C différent de AVR-GCC ou bien il ne s'adresse pas aux AVR car il y a des appels à des fonctions que je ne connais pas (par exemple: "disable_interrupts(GLOBAL); ").

[smba38]

Coucou Jean-Marie,

Désolé pour l'exemple en C, je pense que c'est pour un microcontrôleur PIC.
Je t'ai donné cet exemple juste pour que tu t'inspire du code, en particulier des structures.

J'ai vu qu'il existe sur Arduino des librairies pour le DS1337.
par exemple:

https://github.com/etrombly/DS1337RTC
http://forum.arduino.cc/index.php?topic=38077.0


Pour l'électronique de commande à partir d'un signal carré l'avantage est de ne pas utiliser un GPIO d'un ESP8266 utilisé en autonome.(ils sont pas nombreux).

Une solution avec un condensateur n'est t'elle pas envisageable ?.

A+

SMBA38.

[Jean-Marie]

Hello SMBA38

Je t'ai donné cet exemple juste pour que tu t'inspire du code, en particulier des structures.

Oui, les structures et l'organisation du code vont probablement m'aider. Mais pour le moment, je crois que je tourne en boucle dans une fonction (que je n'ai pas écrit moi-même) car j'ai une led témoin qui devrait s'allumer après le retour de la fonction et qui reste opiniâtrement éteinte. Donc, je suis en train de décortiquer chaque bit pour comprendre pourquoi je reste coincé. Travail de patience !

Merci pour tes liens des librairies Arduinos. J'y aurai peut-être recours si je n'arrive pas à comprendre comment me servir des registres de la communication I2C de l'Atmega (qui, entre nous, est beaucoup plus complexe que la communication UART).

Pour creuser un peu plus la question de la mise sous tension du système clock+µC+ESP, par exemple lors du remplacement des batteries, j'ai relevé dans la datasheet de la DS1337 tout ce qu'on raconte sur la position des bits au démarrage de l'alimentation.

53.jpg (266.54 Kio) Vu 7422 fois

En rouge, les conséquences sur INTB.
Pour le bit A2IE, j'ai des doutes sur l'interprétation du texte anglais et donc l'effet du bit. Ce bit à zéro signifie-t-il l'absence de square wave ?
En tout cas, il semble que si une square wave est produite, sa fréquence sera de 32,768KHz en raison des bits RS1 et RS2.
Afin de se faire une idée plus précise, j'ai laissé la DS1337 plusieurs minutes non alimentée, puis je l'ai alimenté en 5V et j'ai mesuré la tension de la pin INTB: 4,94V.
Normalement, si elle avait une square wave de 32KHz avec rapport cyclique de 50%, je devrais mesurer 2,5V.

[smba38]

Coucou Jean-Marie.

Pour être sur du signal carré sur INTB, il faut regarder à l'oscillo la forme du signal.
J'ai un Oscillo numérique que j'ai récupéré dans une déchèterie je regarde ce soir.

Dans ta mesure de INTB ty parles de 4,94v ton circuit n'est pas alimenté en 3,3V ?.

A l'initialisation le code de contrôle en 0x0E est à 0x18 ce qui correspond à RS2+RS1=1 et INTCN=0.
A1IE et A2IE sont à également = 0 à l'initialisation.

C'est sous ces conditions que le signal carré est émis.

Parfois le registre des statuts 0x0F est 0x81 ou 0x82 ou 0x83 (Dans mon cas le 8 indique le bit 0SF).
Les valeurs A1F et A2F ne sont pas pris en compte si A1IE ou A2IE ne sont pas à 1 INTCN doit également être = 1.

INTCN=0 -> signal carré avec la fréquence gérée par les bits RS1 et RS1 (si RS1 et RS2 =1 -> 32,768KHZ= valeurs par défaut).
INTCN=1 -> gestion des interruptions INTA (si A1IE=1) et INTB (si A2IE =1).

En fait les bits A1F et A2F du registre 0x0F son positionnés si une condition d'alarme se présente.(sur la comparaison des registres)
Mais l'alarme n'est effective que si A1IE ou A2IE sont à 1 avec en plus INTCN=1.

Les bits A1F et A2F peuvent seulement être remis à 0, c'est bizarre sur un registre de Statuts.
A la remise à 0 de A1F ou A2F, le niveau de INTA ou INTB change, il passe de l'état bas à l'état haut.
INTA et INTB repasseront à 0 à la prochaine interruption.

Même le bit OSF peut être remis à 0 mais il est repositionné à 1 automatiquement si il y a un problème sur l'oscillateur.
Dans mon cas le comportement est le même que je câble un Quartz ou ne je ne câble pas de quartz.
Sans quartz un seconde est incrémentée à chaque minute environ, c'est pas rapide mais ça va pour faire des tests. (et en plus on gagne un Quartz).

A+
SMBA38.


A+
Michel.

[Jean-Marie]

Hello SMBA38

Pour être sur du signal carré sur INTB, il faut regarder à l'oscillo la forme du signal

Tout à fait ! Mais mon PCscope n'accepte que des variations de 1 Volt autour du zéro à cause de l'entrée Ligne de la carte son. J'ai été un peu trop fainéant pour installer un pont de résistances 100k-10k à la sortie INTB.

54.jpg (120.21 Kio) Vu 7414 fois

Voilà qui est fait.
L'écran montre un total de 4,5 secondes. La pulse visible correspond à la connexion de la pin INTB à l'oscillo.
En 1/10ème de seconde, la pulse revient à zéro non pas parce que j'ai coupé la connexion mais parce que le condensateur d'entrée de la carte son est chargé. Voilà pourquoi ce système ne peut servir à mesurer des tensions continues. D'ailleurs, l'extrême limite inférieure de fréquence du son est de 20 Hz. La même pulse mais inversée est visible au moment où on débranche la connexion.
Conclusion: pas de square wave mais seulement une tension continue sur la pin INTB de ma DS1337 à la mise sous tension.
La seule chose que j'ai du mal à comprendre est que je m'attendais à une pulse positive à la connexion et à une pulse négative à la déconnexion.

J'ai un Oscillo numérique que j'ai récupéré dans une déchèterie

J'aimerais beaucoup que tu me files l'adresse de ta déchetterie. J'irais y planter ma tente pour quelques jours !

Dans ta mesure de INTB ty parles de 4,94v ton circuit n'est pas alimenté en 3,3V ?

Pour le moment, j'ai enlevé l'ESP de la breadboard et mon programmateur reste branché en permanence sur l'Atmega. L'alimentation de 5V est fournie par l'USB en passant par le programmateur car cela convient aussi bien à l'Atmega qu'à la DS1337. Je repasserai en 3.3V quand je serai obligé de rebrancher l'ESP.

[Jean-Marie]

Voici un meilleur test. Cette fois, la pin INTB reste connectée à l'oscillo et la photo est prise au moment du branchement de l'alimentation de la DS1337.

55.jpg (122.58 Kio) Vu 7413 fois

Ici on voit que la tension de INTB passe brusquement de 0V à une valeur positive, même si rapidement, elle semble revenir à zéro à cause de l'effet condensateur.
Ceci confirme l'absence d'ondes carrées

[Jean-Marie]

Il y a peut-être une autre solution que de reprogrammer la DS1337 quand on change les batteries principales. C'est que la DS1337 ait sa propre alimentation avec une pile bouton CR2032. La DS1337 consomme très peu de courant (+- 450 nA à 3.3V si la square wave est OFF) et peut donc tenir très longtemps avec une pile bouton. A la première mise en service et lors du remplacement de la CR2032, il faut reprogrammer la DS1337 avec un petit programmateur home made.

OU BIEN ...

Au lieu d'une CR2032, on utilise une LIR2032 qui est une batterie de même taille et même tension mais rechargeable. Cette batterie est maintenue chargée par l'alimentation du reste (µC et ESP) et permet de maintenir l'heure et la date de la DS1337 pendant qu'on remplace ou qu'on recharge les batteries principales.

OU BIEN ...

Un super-condensateur peut aussi remplacer la LIR2032 et maintenir le fonctionnement de la DS1337 pendant le remplacement des batteries principales.

[smba38]

Coucou jean Marie,

Voici ma mesure à l'oscilloscope de l'état initial du DS1337 entre la masse et INTB.

DS1337 SQW.JPG (126.77 Kio) Vu 7389 fois

L'image n'est pas terrible, l'oscilloscope dispose d'uns sortie RS232 (25 broches) pour envoyer des hard copies.
Il faut que je retrouve un convertisseur 25 broches -> vers 9 broches puis un convertisseur RS232 9 broches -> USB.

A l'état initial il semble bien y avoir un signal carré.
J'ai le même signal si je force le registre contrôle à 0x18 (Signal carré de 32KHZ).

La sortie INTB passe à 0 à l'écriture de registre de contrôle (0x06) pour demander un interruption sur INTB.
Elle passe à 2V à l'écriture de 0x00 dans le registre de statuts.
Elle repasse à 0 suite à une interruption sur INTB.

J'ai une résistance de rappel de 10K entre INTB et le + .
Le montage est alimenté en 3,3V.

A+
SMBA38.

[Jean-Marie]

Sacrebleu !
Je me demande maintenant si ce n'est pas moi qui ai grillé ma DS1337 !

D'autant plus que j'essaye de traquer un problème dans une fonction (i2c_start_wait) que je n'ai pas écrite moi-même. Le plus souvent, le programme reste coincé dans cette fonction, mais parfois il en sort et reste bloqué plus loin. De même, à l'intérieur de la fonction il est impossible de déterminer quelle instruction bloque car je ne reste pas bloqué au même endroit à chaque fois.

En fait, j'ai écrit un petit programme de lecture des registres et jusqu'ici, le programme n'a pu aller jusqu'au bout qu'une seule fois et je doute de l'exactitude des valeurs données au moniteur. Voici les valeurs obtenues:

• Registre 0x00 : 0x00
• Registre 0x01 : 0x7F
• Registre 0x02 : 0xFF
• Registre 0x03 : 0xFF
• Registre 0x04 : 0xFF
• Registre 0x05 : 0xFF
• Registre 0x06 : 0xFF
• Registre 0x07 : 0xFF
• Registre 0x08 : 0xFF
• Registre 0x09 : 0xFF
• Registre 0x0A : 0xFF
• Registre 0x0B : 0xFF
• Registre 0x0C : 0xFF
• Registre 0x0D : 0xFF
• Registre 0x0E : 0xFF
• Registre 0x0F : 0xFF

Pour te faire une idée, voici la boucle principale du programme.

Code : Tout sélectionner

int main(void)
{
	byte Reg;
	AVR_init();
	UART_init();
   stdout = &UART_output;
   stdin  = &UART_input;
	printf("Lecture des registres de DS1337\n");
	i2c_init();
   i2c_start_wait(DS1337_W);     // set device address and write mode
	i2c_write(0x00);
	i2c_rep_start(DS1337_R);       // set device address and read mode
	
	for (Reg = 0x00; Reg < 0x0F ; Reg++)
	{
		printf("Reg %X : %X \n", Reg, i2c_readAck());
	}
	printf("Reg %X : %X \n", Reg, i2c_readNak());
	i2c_stop();
	
	while(1)
	{
		FlashLED();
	}
}

[Jean-Marie]

Hello SMBA38
Ta square wave continue à me travailler.
Je pense de plus en plus que j'ai foutu ma puce en l'air.
En effet, chaque fois que je voulais être sûr de remettre la DS1337 à zéro (Reset), je débranchais son alimentation pendant quelques minutes mais les pins SDA et SCL restaient connectées au µC toujours alimenté. Donc je pense que SCL continuait à osciller à 100 KHz et probablement que la DS1337 n'aime pas d'être traitée de la sorte.

Je vais de ce pas préparer une nouvelle mini-platine DS1337 et refaire les tests avec une attention particulière à l'alimentation.