Barrette écologique – suivi
Comme ce projet avance par étapes, je me propose d’en relater les avancées ici. Eh oui, c’est finalement assez complexe, et ça mérite quelques éclaircissements. Il ya :
- Le hard
- le logiciel bas niveau
- les processus LAN
- du temps réel
- l’interface WEB
- de la compression
- des stockages et transmission de données
Actuellement (novembre 2009), le hard est posé dans les grandes lignes; mais pas complètement arrêté. La clock RTC sera matérialisé par un DS1307, une pile, un quartz. La commande de triacs sera fortement inspirée d’une interface de Franic (merci Laurent!).
Les couches logicielles assez bien définies; toutefois, c’est la partie qui risque de subir les plus grand changements – même si le hard est terminé! Chacun pour
ra peaufinner son interface WEB. Pour cela, il faudra une bibliothèque bien établie de tags, et de modules en Javascript. Et de modules en C, bien sûr.
Le tout est téléchargeable ici: http://yves.masur.microclub.ch/articles/
Ce n’est pas vraiment un article, mais il y a: le code source, les pages WEB, et deux documents au format pdf. « MXBOARD_decouverte » présente les différentes facette de cette plateforme, alors que « barette » est le cahier des charges – qui se transforme en cahier de réalisation petit à petit.
Yves Masur
Et l’image représente l’envoi en série dans un 74HC595 d’un byte qui allumera des LEDs…
Pour la comparaison des temps de commutation, j’ai fait une fonction qui rend un indice basé sur HH * 100 + MM. Pas facile: il faut indiquer au compilateur que chaque élément est un entier signé, sinon résultats farfelus! De plus, lorsque l’indice compare:
23:30 – 22:59 = 71, la minute après c’est:
23:30 – 23:00 = 30. Surprenant, mais utilisable pour tri et comparaisons.
La fonction de comparaison de temps et de « tracking » est désormais OK. Voir https://microclub.ch/2010/03/06/horloge-et-table-de-commutation/
Ping : Horloge et table de commutation « Microclub
La documentation est partagé ici:
http://docs.google.com/View?id=dd2z4nh9_1fbx246hr
Laissé un peu de côté, j’ai repris l’affaire en main. Maintenant, l’horloge fait correctement la sélection de la dernière commutation, et de la prochaine. En fait, le problème venait de calculs de la fonction de comparaison – toujours le même bug du compilateur.
Lorsque le temps doit être ajusté, le calcul est:
if (dt1 < 0) dt1 += 7 * 24 * 60;
Hormis un comportement aberrant de la sélection des lignes de commutation, j'avais des delta négatifs sur le module SBC, alors que la simulation avec CodeBloks donnait des résultats corrects (v. mon message du 6 mars 2010).
Le calcul est modifié par une macro ainsi:
#define M_WEEK ((int) 7 * 24 * 60)
if (dt1 < 0) dt1 += M_WEEK;
Le truc, c'est bien sûr le (int) pour forcer le compilateur à calculer sur 16 bits!!
La partie WEB offre aussi ses surprises. Plein d’entrain, je profite de corriger un aspect esthétique de la DialogBox permettant d’ajuster l’horloge.
Rien que pour voir, j’utilise Adobe DreamWeaver CS5 (version d’essais 30 jours). Ce finaud m’a mis en forme le code, mais aussi l’a « corrigé » en changeant:
… par:
…
Évidemment, le script sert à manipuler les données pour les transmettre en GET. Pas étonnant que ma DialogBox soit plus belle, mais… aussi inopérante!!
Nom d’une pipe: le code n’est pas affiché: évidemment c’est un peu difficile de suivre ma prose 🙁
Maintenant, il s’agit de détecter le courant consommé dans 2 prises. Je vais essayer avec un opto et un pont + 1 ohm en série. A ce stade, je ne sais pas s’il faut faire une moyenne soft – étant donné que le courant sera pulsé à 100 Hz – ou filtrer par hard. Et a quoi ressemblera la dérive en température? Pas trop important, vu que le seuil à détecter est du genre 120W -> 15 W.
Piégé par le hard et le temps réel!!
Après de heures de recherche, je constate que je me suis fait avoir par le hard qui lit les 8 boutons et allume 8 LEDs. Les deux chips partagent le même fil de DATA, de CLOCK et de LATCH. Pour le data, il faut programmer la patte de lecteur en entrée pour lire les switch, en sortie pour les LEDs.
Cependant, dans mon design de code, je lis les switchs à 50 ms, tandis que les LEDs sont mise à jour à 250 ms, histoire de faire des clignotements avec une phase de 1/4 ou 3/4 de seconde.
Mais voilà… chaque fois que je lis les switchs, j’envoie leur config sur les LEDs!! Je suis donc obligé de les mettre au même rythme.
version 08d utilisable!
Après un long travail de mise au point, les modules suivants sont opérationnels:
– commutation par table
– commutation par page WEB
– commutation par bouton-poussoir
– état des LEDs
– transitions (partiellement)
De plus, des parties de code sont rendues compatible avec CodeBlocks. Grâce à ceci, il est possible de modifier et tester ses modules avec rapidité sous Windows. Une fois au point, on peut le compiler sous l’IDE de MPLAB et le charger sur le MXBOARD. Les fichiers concernés ont une inclusion conditionnelle d’entête:
#if defined(__GNUC__)
#include "_gnu_.h"
#else
Bien entendu, ce qui est relatif au hard est remplacé par un printf() exprimant où l’on en est…
A dispo sous: http://yves.masur.microclub.ch/articles/index.php et choisi [Mxboard].
Voici une image du prototype:
http://yves.masur.microclub.ch/articles/Mxboard/barette_prises_2.jpg, ajoutée dans l’article initial.
Ping : Barrette écologique – suivi 2 « Microclub