optimisation gestion BP et LCD

Bonjour,

J'ai réalisé un projet d'incubateur d’œuf de reptile (d’ailleurs, je pense faire un topic dans la rubrique "Réalisations et Projets Finis").

Le temps de cycle est assez long, car il y a la gestion de 2 DHT22, un ds18b20, ethernet...

J'ai un afficheur LCD 4x20 et 5 boutons sur une entrée analogique (type shield LCD keypad).

Le problème est les menus du LCD sont longs à réagir, environ 1 seconde.

Comment faire pour améliorer la réactivité ?

Je pensais le gérer par une interruption, mais comment faire sur une entrée analogique ?

Merci de votre aide.

Bonjour

Le mieux serait de revoir ton programme en supprimant tous les delay

Et bien, justement, il n'y a aucun delay !

Les DHT22 et ds18b20 sont des capteurs qui sont long, du coup, la perte de temps se fait lorsqu'on attends la réponse à l'interrogation du capteur. La page web est aussi chronophage.

J'ai des tempos pour ma regul, mais j'utilise la fonction millis.

Edit. Enfin, si, j'ai des delay, mais seulement pour l'anti-rebond.

Désolé d'insister, mais de mon point de vue la chasse aux delay doit aussi inclure les bibliothèques utilisées.

Je connais très bien le ds18b20 et peux te garantir que son usage est tout à fait possible sans aucune perte de temps. En mode 12 bits, il y a un délai minimum de 750 ms à respecter entre le début de prise de mesure et la lecture du scratchpad. Mais entre ces deux événements, le programme peut très bien faire autre chose. Peut-être utilises tu une bibliothèque qui lie les deux événements avec un gros delay entre les deux.

Le DHT22 je connais moins donc je te laisse voir. Je serais quand même très surpris qu'il monopolise le microcontroleur pendant longtemps sans aucun delay.

L'anti-rebond software des boutons peut aussi être géré avec la fonction millis()

Pour info, sur un automate similaire que j'ai réalisé, la seule portion de code qui prend du temps est un serveur HTTP. Sur la page la plus riche en informations, le programme peut mouliner jusqu'à 300 ms. C'est le seul moment où la gestion des autres parties peut être légèrement saccadée. Mais le serveur HTTP est loin d'être sollicité en permanence. Son usage est occasionnel, et quand il l'est, c'est que je suis en train de pianoter sur un clavier ou une tablette donc le manque de réactivité des boutons ne me pénalise pas à ce moment là.

Après, si vraiment tu veux utiliser des interruptions, il te reste celles du timer, pour aller lire régulièrement l'état de tes boutons, le stocker en RAM et le traiter en temps différé hors interruption.

Mais je persiste à pronostiquer que c'est dommage car ton interruption se déclenchera très majoritairement pendant que le programme est occupé à dormir dans un delay.

+1 avec bricoleau pour les ds18b20, il faut découper l'acquisition en deux phases - déclenchement de la mesure - lecture de la mesure La lecture de la mesure doit être faite 800mS (environ) plus tard, mais entre temps tu peux faire tous les autres traitements.

Je trouve ce sujet intéressant, car nous sommes dans le cas très classique de programme qui doit faire "plusieurs choses à la fois".

Face à ce type de besoin, si on veut pouvoir exploiter toutes les possibilités offertes par un arduino, il me semble nécessaire de structurer son programme de manière à pouvoir gérer "où passe le temps".

Cela passe par l'identification de toutes les portions de code qui sont des séquences d'instructions continues. Et pour chacune d'elles, connaître leur durée d'exécution et maîtriser leur fréquence.

Par exemple, une lecture de température ou d'humidité a rarement besoin d'être déclenchée plus d'une fois par minute. Donc typiquement à ne pas mettre en exécution systématique depuis le loop(). Un écran LCD n'a pas besoin d'être rafraîchi trop souvent. Un RTC ne doit être lu qu'une fois par seconde. Un serveur HTTP submergé de requetes ne doit pas bloquer les autres fonctionnalités etc.

C'est justement pour arriver à gérer tout ça a mieux que je me suis développé un ordonnanceur, que j'ai fini par mettre en ligne ici

En effet, je n’ai pas regardé les bibliotheques, et la gestion des temps d’attente entre la demande d’acquistion et la lecture.

Je regarde ça ce soir, et j’essaierai d’optimiser tout ça.

Bon, j'ai vérifié mon code, et c'est bien le DS18B20 qui me prenait tout le temps machine. J'avais pas fait attention du delay dans la librairie "DallasTemperature.h" que j'utilisais (750ms !!!).

Pour l'instant, j'ai supprimé la lecture car il n'a un rôle que secondaire dans mon appli, et je retrouve tout la réactivité de mon LCD.

Je vais le réintégrer mais sans utiliser les delay ni cette librairie.

Merci pour votre aide !

tartiflette: Je vais le réintégrer mais sans utiliser les delay ni cette librairie.

tu peux aussi réduire la résolution