Interruption sur une liaison ESP-01

Bonjour,

J'ai découvert il n'y a pas très longtemps les interruption donc ce n'est pas un sujet que je maîtrise bien.

Alors voilà mon objectif est de faire une interruption sur la liaison série surtout sur la réception de données (RX).

Pour le coup j'aurais vraiment besoin d'une interruption car mon ESP-01 sera en mode DeepSleep.

Dans sa datasheet il est écrit que esp8266 peux faire une interruption sur la liaison série et j'ai vu que sur ESP-01 possède une carte ESP8266 je me suis dit que cela était possible.

Merci d'avance

Bonjour

Pour le coup j'aurais vraiment besoin d'une interruption car mon ESP-01 sera en mode DeepSleep.

Deepsleep = sommeil profond, les interruptions n'y sont pas actives, idem pour l'UART

-> ESP8266 : pas de réveil de deepsleep par réception série

-> Dans le cas particulier du module ESP-01 seule une brève mise à la masse de RESET peut faire sortir du deepsleep

Alors voilà mon objectif est de faire une interruption sur la liaison série surtout sur la réception de données (RX).

Oublier alors le deepsleep

OK merci pour ces précisions.

Mais il y a pas un mode intermédiaire qui n'éteint pas le périphérique UART ?

et si possible auriez-vous un lien à me passer pour trouver comment faire une interruption sur la liaison série si je ne me sers pas du deepsleep ?

chercher des infos sur le modemsleep des ESP8266 : fonctionnalités ? utilisation sous IDE Arduino ?
(je ne sais rien à son sujet … a part son existence)

La réception série fonctionne de fait sous interruption.

Both transmit and receive is interrupt-driven.

source : Reference — ESP8266 Arduino Core 2.7.2-10-g2843a5ac documentation

Comment ‘soulever le capot’ et prendre la main, en particulier sous IDE Arduino ? aucune idée

D’autre part il faut tenir compte du fait qu’un changement d’état (en particulier le revéil d’un sommeil profond !) prends un temps non négligeable, Le risque est grand de perdre le début d’une trame arrivant sur le port série si l’arrivée de cette trame doit ‘réveiller’ l’ESP8266

Des infos sur les modes de sleep sur le forum de Nick Gammon , mais rien sur l’ESP8266. Par contre il explique comment réveiller par l’uart.

L’ESP8266 est-il indispensable ? Un arduino nano ne convient pas ?

Merci pour vos réponses

Pour répondre à votre question l'ESP8266 est indispensable, car il faut une connectivité wifi.
Le problème que je rencontre est la consommation trop importante de l'ESP01 (montage sur batterie)
Un autre µC envoie une trame par UART à l'ESP je peux donc renvoyer la trame si je ne l'ai pas reçu entièrement.

De plus, l'action demandée à l'ESP doit être "rapide" donc je n'ai pas le temps de la reset et de la reconnecter au WiFi

N'existe-t'il pas un mode basse consommation capable de maintenir le périphérique UART actif ?
Si oui, est il possible de générer une interruption à la réception d'un caractère. D'après la datasheet l'ESP8266 possède cette option.

al1fch oui j'utilise l'IDE Arduino pour la programmer.

Merci d'avance pour le temps que vous m'accorderez.

al1fch:
La réception série fonctionne de fait sous interruption.

oui, l'UART est géré par interruptions ... mais uniquement si le µC est éveillé !

N'existe-t'il pas un mode basse consommation capable de maintenir le périphérique UART actif ?

Que dit la datasheet des ESP8266 au sujet des modes lightsleep et modemsleep ?

Si oui, est il possible de générer une interruption à la réception d'un caractère. D'après la datasheet l'ESP8266 possède cette option.

Toute réception d'un caractère par un ESP8266 actif produit une interruption , c'est comme cela que la librairie Serial fonctionne sans que l'utilisateur s'en rende compte.

De plus, l'action demandée à l'ESP doit être "rapide" donc je n'ai pas le temps de la reset et de la reconnecter au WiFi

ça exclut toute baisse radicale de la consomation d'énergie
Avis perso : seul le deepsleep présente un intérêt manifeste pour un montage sur batterie

Un peu de lecture sur les divers modes de fonctionnement des ESP8266 (hors IDE Arduino)

al1fch:
Que dit la datasheet des ESP8266 au sujet des modes lightsleep et modemsleep ?

mode light-sleep : réveil possible uniquement si action sur GPIO
mode modem-sleep : réveil à intervalles réguliers (DTIM Beacon intervals) par timer

la réception en soi n'a rien à voir, ou alors je ne sais pas (plus?) lire

On pourrait imaginer diverses solutions à ce problème :

Le plus simple : un ESP32, qui peut se réveiller du mode light sleep via l'UART

Un nano qui est réveillé par l'UART, qui réveille l'ESP8266 par une impulsion sur le RST

Il serait peut-être possible de s'inspirer de cet exemple. Si on communique avec l'ESP8266 non pas sur l'UART mais sur d'autres pins en Software Serial, on peut utiliser le premier front montant d'une de ces pins pour créer l'impulsion sur la pin RST qui va réveiller l'ESP8266.

Dans ce cas, il faudrait un circuit spécifique à côté de l'ESP qui capte l'arrivée des signaux et génère cette impulsion, une seule fois a priori (j'imagine que des impulsions sur RST lorsque l'ESP est réveillé risquent de le restart...?). L'ESP devrait aussi "resetter" ce circuit juste avant de s'endormir afin que le circuit sache qu'il devra agir la prochaine fois qu'il recevra un signal.

si on a une liaison filaire (UART) à quoi sert l'ESP ?

je pense qu'il faudrait plus de billes pour pouvoir répondre ...

d'accord avec 5_cylindres

Un autre µC envoie une trame par UART à l'ESP je peux donc renvoyer la trame si je ne l'ai pas reçu entièrement.

Si vous avez la main sur cet autre µC pourrait activer une pin pour réveiller l'ESP (reset) sur interruption externe, lui laisser le temps de se réveiller avant de balancer la trame.

Une autre approche si le timing n'est pas important, vous réveillez l'ESP tous les ∆t (avec une interruption RTC ou autre) et l'ESP contacte votre autre µC pour lui demander s'il a un message à émettre (car je suppose que c'est pour cela que vous avez besoin du WiFi)

le cahier des charges peut guider la solution retenue

Le but de mon projet est de récupérer les informations via un µC (dsPIC33) et de transmettre ces infos par WiFi.
D'ou l'utilisation de l'ESP01 et de la liasion UART.

Au vu des différentes réponses et du peu de choix que permet l'ESP01, je pense que je vais faire un RESET.
J'espère juste que l'ESP ne mettra pas trop de temps à se reconnecter au WiFi.

avez vous vraiment besoin du dsPIC33 ? est-ce qu'un ESP12 ou un ESP32 ne seraient pas capable de faire l'acquisition ET l'émission ?

dspic + wifi ça veut dire encore un module supplémentaire, esp + réveil externe, etc ...
ça commence à faire beaucoup de monde à mettre en œuvre, alimenter, mettre en veille avec des protocoles de réveil non compatibles ...
du coup, construis ta propre centrale nucléaire, hydraulique, à charbon ...

Je suis d'accord qu'il aurait été plus simple de faire tout sur une seule et même carte mais le problème c'est que c'est sur un PCB déjà existant

Au réveil de deepsleep l'ESP8266 reboote avant de se reconnecter au Wifi, durée dépendante de la box... Compter 1seconde en tout, souvent plus

Bonjour, merci pour vos réponses

5_cylindre ta réponse n'est absolument pas fondée, si tu t'étais renseigné un minimum sur l'utilisation d'un dsPIC tu apprendrais qu'ils ont une très bonne gestion de la consommation d'energie, bien plus simple et plus complète qu'une ESP32 (sous IDE Arduino).
Si j'ai choisi un tel µC c'est que j'ai mes raisons, et si je demande de l'aide aujourd'hui c'est pas pour justifier mes choix de composants ou le fonctionnement de mon système mais pour trouver de l'aide sur le fonctionnement d'une ESP8266 que je ne comprends pas entièrement.

Un dsPIC en mode Idle consomme quelques mA, je crois que se chiffre est dérisoire devant la consommation d'une ESP01.

Pour en revenir au sujet PRINCIPAL

J'ai bien compris qu'il n'était pas possible dans l'IDE Arduino de déclencher une interruption sur réception UART. Je vais donc utiliser la broche Reset ou une interruption par front montant.

Je remercie toutes les personnes qui ont contribué a m'aider sur ce problème.

Cordialement

re_b:
J'ai bien compris qu'il n'était pas possible dans l'IDE Arduino de déclencher une interruption sur réception UART. Je vais donc utiliser la broche Reset ou une interruption par front montant.

Rien à voir avec l'IDE, ça reste un outil de dev et des bibliothèques. Le souci c'est que l'ESP-01 dont vous parlez n'offre pas cette possibilité de réveil sur interruption UART (lorsqu'il est en mode sommeil). C'est matériel.

PS: Un ESP32 en mode 'hibernation' consomme 5µA, 10-µA en deep sleep, 0.8mA en 'light sleep'.

En light sleep vous pouvez capturer les interruptions sur l'UART qui contient une fonction qui permet de réveiller la puce lorsqu'un certain nombre de fronts positifs sur la broche RX sont reçus. Ce nombre de fronts positifs peut être défini en utilisant la fonction uart_set_wakeup_threshold(). Notez que le caractère qui déclenche le réveil (et tous les caractères avant) ne seront pas reçus par l'UART après le réveil. Cela signifie que le périphérique externe doit généralement envoyer un caractère supplémentaire à l'ESP32 pour déclencher le réveil, avant d'envoyer les données

Si vous n'éteignez que le modem (Modem Sleep Mode) il consommera que 2mA à faible vitesse (et jusqu'à 50mA si vous le faites pédaler à fond)

(bien sûr le merdier qu'ils mettent autour consomme aussi donc tout dépend de l'ESP32)

re_b:
5_cylindres ta réponse n'est absolument pas fondée, si tu t'étais renseigné un minimum ...

quand on commence à multiplier les composants, qui doivent se réveiller mutuellement, transmettre en HF sans être équipés, etc... si, ma remarque est justifiée.

re_b:
Si j'ai choisi un tel µC c'est que j'ai mes raisons, et si je demande de l'aide aujourd'hui c'est pas pour justifier mes choix de composants ...

puisque tu as si bien su choisir ta solution, fais avec (toutes) les réponses qui t'ont été faites.

re_b:
Je remercie toutes les personnes qui ont contribué a m'aider sur ce problème.

je ne me sens pas concerné, je ne considère pas t'avoir aidé(e), j'ai juste donné mon avis sur des points qui me semblaient nébuleux ... mais que tu sembles ne pas admettre.