Horloge et table de commutation
Dans l’implémentation du code nécessaire au projet « barrette écologique », j’ai quelque peu séché sur le problème du suivi de la table de commutation. Celle-ci contient des données non-triée de temps, de jour(s) de la semaine et de la commutation à appliquer.
Comment trouver à coup sûr la dernière commutation et la prochaine à venir? Une fonction de différence de temps est nécessaire et rend un delta:
delta = ((int) prtc_line->hour - (int) DB_SystemClock.Time.hh) * 60 +
(int) prtc_line->minute - (int) DB_SystemClock.Time.mm;
Petit piège en langage C, les bytes à transformer en int, sinon-> écrêtage à 255. Ensuite, nous parcourons régulièrement toutes les lignes du tableau de commutation. Ainsi la valeur obsolète sera mise à jour. Celle-ci sera remplacée au fil des scan, si une ligne plus proche existe dans la table, parcourue de 0 à n.
Pour résoudre ce problème, je me suis contenté d’une fonction qui ne traite que 24 heures, laissant à plus tard son complément pour traiter des semaines. Le tableau ci-dessous montre la simplicité du raisonnement pour 24H:
- Le plus grand delta négatif est celui de la dernière commutation à 11h – l2;
- Le plus petit delta positif, la prochaine commutation 13h – l3.
Sur une semaine, ça ne fonctionne plus! En effet, admettons que nous sommes lundi (jour=1) et que les commutations sont seulement sur dimanche, jour=7? En admettant que notre fonction « delta » ajoute 24*60 par jour, il apparaît que la prochaine commutation est la première de dimanche, et la commutation en cours est la dernière de dimanche!! Tous des nombres positifs!! Notre fonction va donc trouver
- Le plus grand delta (mais pas négatif) sera celui de la dernière commutation à 14h – l4;
- Le plus petit delta positif, la prochaine commutation 10h – l1.
Faut-il une logique « intraday », travaillant avec +/- et une autre pour les jours à distance?
|
Commutation |
l1 |
l2 |
time |
l3 |
l4 |
|---|---|---|---|---|---|
|
heure |
10h00 |
11h00 |
’12:10 |
13h00 |
14h00 |
|
Delta |
-130 |
-70 |
delta |
+50 |
+110 |
|
Delta corrigé 1 semaine |
+9950 |
+10010 |
– |
+50 |
+110 |
La solution est la suivante: lors de la recherche et comparaison, pour éviter les problèmes des jours répartis sur une semaine, on ajoute une correction de 7 jours * 24 heures * 60 minutes au temps de commutation de la ligne lue s’il est inférieur a 0. ce calcul tient compte du fait que les écarts sont cycliques sur une semaine de 7 jours. De ce fait, le test de comparaison de temps se fait toujours sur des nombres strictement positifs, et fonctionne pour le jour courant et … les autres de la semaine.
Grâce à Code::Blocks, j’ai pu tester et valider mes fonctions efficacement, car modifier + charger le binaire dans le module PIC est bien long… voir: https://microclub.ch/2009/11/23/barrette-ecologique-suivi
Yves Masur
Intéressant, j’ai rencontré le même problème sur un projet de gestion d’horaire de trains.
Je l’ai résolu de la manière suivante :
Je place les dates (et les heures) de commutations dans un tableau.
Lorsque j’insére une nouvelle commutation, je trie mon tableau dans l’ordre croissant et ajuste l’index de la prochaine commutation.
Ainsi la présentation des diverses dates de commutations sont oordonnées dans l’ordre croissant, plus faciles à lire, et l’index de la prochaine commutation s’incrémente en fonction du temps écoulé.
Si une commutation est indépendante de la date, par exemple tous les mardi à 7h45, mon tableau contient un flag « AutoRepete »; lors du traitement du tableau (lors d’une commutation effectuée) une fonction rajoute la date répétitive.
Par cette méthode, je me suis beaucoup simplifé le traitement des commutations.
En effet c’est la meilleure technique… Si la mémoire RAM à disposition est suffisante. Ce qui n’est pas le cas dans ce projet: les informations de commutation sont placées dans une structure en EEPROM. Il n’y en a que 3 en mémoire: celle en travail (édition), l’actuelle et la future.
Les algorithmes de tri sont donc plus complexes. L’article ci-dessus ne rend pas non plus toute la problématique.
Par exemple, avec la solution ci-dessus et les paramètres suivants:
Tables avec commutations à
– 00.15 et 16:00 Lu-Sa
– 00:30 Dimanche
Le mercredi à 23:50, le recalcul trouve Last=00:30 et Next=00:15, alors qu’on s’attendait à 00:15.
Le BUG n°4 de la présentation – c’est lui! Fait mal à la tête. Il faut le voir sur papier. Je mettrai les slides sur le site quand j’aurai trouvé la technique.