Temporisation : Choix entre 2 principes de programmation

Bonjour,

Pour situer le contexte de ma requette je automaticien et cela fait longtemps que je n'ai pas touché a un contrôleur embarqué.

Je souhaite gérer des temporisation dans un programme. J'envisage 2 architectures pour mon programme.

Solution 1: - Créer une fonction callback sur interruption - Avec la classe timer , créer une classe temporisation retard a la montée avec comme variables publiques une entrée d'activation, une valeur réelle de délai, une sortie booléenne délai passé , une fonction qui vérifie le temps passé et incrémente la variable delai. - Créer un objet tempo pour chaque tempo a gérer et appeler la fonction de vérification à chaque appel de la fonction callback. Et appeler l'entrée activation et la sortie en fonction des besoins du programme.

Solution 2 : - Utiliser plusieurs fonctions callback pour chaque temporisation et jongler avec plusieurs interruptions suivant le besoins du programme.

Quelle méthode vous semble la plus propre et la plus adaptée à la carte arduino uno?

Les interruptions sont liées aux ressources hardware. Donc une seule routine interruption par Timer hard.

Ce que tu décrit existe déjà, il y a plein de lib de gestion de timers dispo dans le playground. J'ai moi même écrit une lib soft sans interruption et dispo ici : http://arduino.cc/forum/index.php/topic,101814.0.html Sinon il y a TimerOne et TimerThree qui utilisent respectivement les timers 1 et 3.

J'aime bien l'idée d'une classe de base que tu dérives pour surcharger le callback. Dans ma lib, les callback sont appellées depuis la fonction statique manage() mais dans ton cas elles seraient depuis la routine d'interruption.

Sinon je n'ai pas bien compris ce que tu sous entends pour chaque cas 1 et 2.

Ce que je sous entend , c'est qu'avec mes habitudes de programmation , je serais plutôt tenté d'utiliser la solution 1. En effet ayant l'habitude de programmer des PLC , je préférerais une structure programme qui s'en rapproche avec un cycle unique cadencé et une lecture/écriture des sorties en continu dans ce même cycle. Je précise par rapport a mon dernier message que dans la fonction d'actualisation de la tempo j'aurais mis a jour la sortie en faisant un traitement de comparaison entre 2 appels successifs de la fonction millis() Je m'attendais éventuellement a ce qu'on me contredise sur cette solution qui pour moi est plus claire a mettre en œuvre que la solution 2. La solution 2 se rapprocherai plus d'une programmation événementielle et je n'ai pas l'habitude de programmer comme ça pour piloter des systèmes physiques. De plus le arduino n'est pas temps réel (il peut y avoir des effets non désirés )et tu ma donné l'argument qu'il faut une interruption par timer hard, donc en gros pour gérer plusieurs tempos, mieux se baser sur une seule interruption.

PS : J'étudie ta lib ce soir.

Je ne cherche à contredire personne, je suis très conciliant :D C'est juste qu'on vient de monde différent et qu'on a -a priori- un vocabulaire un peu différent. Je ne connais rien aux automates industriels et je viens de la programmation embarquée C/C++/Assembleur dans les domaines telecom et traitement du signal... ;)

Ma lib est sans timer hard ni interruption. Uniquement soft donc pas pour du temps réel dur. Mais suffisant pour bricoler sur Arduino, gérer des timeouts, etc ... La lib TimerOne est plus temps-réel car elle utilise l'interruption Timer.