Bonjour,

J’ai des plantages plus ou moins régulier de ma montre Twatch : c’est uniquement lorsqu’elle doit sortir du mode sommeil et que je fais pas mal de mouvements (courir, bricolage, taille de la haie …) mais pas lorsque je suis statique.
Je pense qu’il s’agit d’une mauvaise gestion des IRQ, peut-être (ce n’est qu’une supposition) qu’une seconde IRQ arrive alors que la montre n’est pas encore totalement reveillée, ou alors qu’il y a un dépassement de la pile d’évennement.

J’utilise la boucle d’évennement de SimpleWatch, qui est celle décrite sur ce site.

Suis-je le seul ? Des idées pour corriger ce pb ?

Mon code est là si qq’un le souhaite.

Merci

Bonjour Lolo, comme vous suivez mes tweets en ce moment vous savez que je suis un peu dans la même galère que vous sur le sujet Je n’ai pas été jusqu’à séparer les deux fonctions mise en sommeil / réveil comme vous l’avez fait. C’est une très bonne idée.
Je trouve d’ailleurs que l’exemple SimpleWatch est clairement destiné à des développeurs professionnels. C’est la raison pour laquelle j’ai essayé de le simplifier au maximum pour le rendre plus accessible.

Je pense comme vous, c’est un peu le même système que les events listener en javascript. L’émetteur envoie plusieurs signaux pour être certain qu’au moins 1 soit lu dans la loop. Du coup la fonction wakeup est probablement exécutée plusieurs fois (un serial.print nous le confirmera la théorie). Si tel est le cas, pourquoi pas tester que l’écran soit bien éteint avant d’exécuter le code ?

Coucou,

On se tutoie, ca sera plus cool

Je crois que j’ai trouvé : j’ai augmenté la queue des messages à 64 éléments … et j’ai pu faire une rando entière sans problème YEEAAAAHHHHHH ! Mieux, elle n’a même pas rebooté depuis que j’ai gravé le code hier soir alors que je l’ai porté sans arrête depuis (dodo, rando, et tout le reste) : une première.

Il faut que je vois sur ce 2 ou 3 jours. Mais si c’est le cas, j’ouvrirai un ticket auprès de Lewis pour qu’il upgrade FreeRTOS (pas testé de le faire par moi-même) en espérant qu’ils aient corrigé les problèmes d’overflow non maitrisé.

En fait, comme je le disais sur 1 autre forum, mon gros problème est surtout un manque totale de commentaires dans les sources (ce qui me fait perdre un temps pas possible car il me faut décrypter ce qui est fourni pour un oui ou un non), et une doc franchement perfectible pour la Lvgl …
Mais bon, ca va déjà mieux

A+

Oui avec plaisir, c’est sera plus simple
C’est une bonne solution de contournement, d’ailleurs j’ai oublié de regarder si les messages étaient purgés dans ton code.

Pour LVGL, je suis d’accord avec toi, c’est pour ça que j’ai entrepris une série d’articles. LVGL est une aussi une solution pro, il faut bien payer les développements en vendant du consulting.

Si vous voulez on pourrait se partager le travail et publier des articles en commun sur nos deux blogs ?

C’est une bonne solution de contournement, d’ailleurs j’ai oublié de regarder si les messages étaient purgés dans ton code.

Pour le moment, je ne me suis pas encore pencher sérieusement sur la boucle du « ino » : c’est un copier coller de ce qu’a fait Lewis. Mais ce pense qu’ils sont purgés par le

/* other activities */
        if(xQueueReceive(g_event_queue_handle, &data, 5 / portTICK_RATE_MS) == pdPASS){
                switch(data){
...

Mais si FreeRTOS est franchement mieux documenté, je tombe à nouveau sur des trucs « bizard ». Par exemple, if(mvtWakeup){ gpio_wakeup_enable( (gpio_num_t)BMA423_INT1, GPIO_INTR_HIGH_LEVEL ); Serial.println(« BMA allowed »); } else { gpio_wakeup_disable( (gpio_num_t)BMA423_INT1 ); Serial.println(« BMA disabled »);

}

devrait faire que la montre ne se réveille pas si je mets le flag mvtWakeup … et ben, bien que gpio_wakeup_disable() soit appelé, c’est toujours le cas
(en fait, c’est super malin d’allumer la montre si on tourne le poignet … sauf quant tu conduit et où chaque virage à droite la réveile )

Ensuite, je vais m’attaquer à la gestion du réseau, …

Pour LVGL, je suis d’accord avec toi, c’est pour ça que j’ai entrepris une série d’articles. LVGL est une aussi une solution pro, il faut bien payer les développements en vendant du consulting.

C’est clair
Bon après avoir bien galérer, je commence a « maitriser » la chose … enfin, du moins, je comprend comment marche les trucs que j’utilise. A l’exception des styles où on repart dans le brouillard le plus complet des qu’il s’agit d’objets composites tels que les sliders.

Si vous voulez on pourrait se partager le travail et publier des articles en commun sur nos deux blogs ?

Si tu veux bien sur. Pour Lvgl, ca va être difficile de faire qq chose de compréhensible pour les débutants car c’est du bas niveau : c’est pourquoi sur mon projet, j’ai crée des classes C++ pour en simplifier l’utilisation.

Je vais les mettre dans une librairie externe pour les réutiliser avec mon LilyPI.

A+

Bel avancement. Si vous voulez discuter plus facilement, je suis en train de mettre en route un serveur discord avec d’autres membres du blog. Pour le moment, j’envoie au compte goutte les invitations, le temps que tout soit sécurisé.

Ben, il a fallu que j’envoie ce message pour que ca replante à nouveau.
2 Plantages en moins de 24h … alors que je bosse donc planté devant mon PC toute la journée
La seule planche de salue (vu qu’il va être vraiment difficile d’en trouver la cause) : je vais essayé de remplacé le light_sleep par un deep_sleep. Comme ca le fait rebooter, au moins la mémoire sera nettoyer.
Mais il va falloir que je fasse le ménage dans la proc de démarrage qui est beaucoup trop longue.

Well, je me remet à la montre (et son copain LilyPI) après avoir fait un break pour d’autres projets plus urgents.

Je commence a me pencher sur le coté RTOS … et là, je m’interroge : est-ce vraiment normal que tout passe par loop() ???
J’ai commencer à regarder les docs de RTOS (qui elles sont vraiment bien foutues ) et ca ressemble vraiment à ce qu’on trouve sur un Amiga au niveau du scheduler et de la gestion des messages : et si je prend la même logique, utiliser loop() pourrait bypasser simplement tout le multi tasking de l’OS et les sécurités associées … a moins que loop() ne soit une tache comme une autre.

Dans le même gène, SimpleWatch qui m’a servit de base, lance des taches de fond par exemple pour mettre à jour l’heure. Sauf que … est-ce que c’est vraiment safe après un light_sleep() ???

Bref, je pense que je vais refaire entièrement cette partie … en fonction de se que j’apprends des docs de l’OS.

Une idée ?

A+

Bon, réponse sur le forum Arduino : loop() est une tâche comme une autre et de priorité 1 (donc basse).
Autre bonne nouvelle de mes pérégrinations webesques : d’après sa docs RTOS, prend en compte directement le multi-core. Du coup, c’est cool, on n’a pas a se soucier de lancer les tâches sur le 2nd coeurs si nécessaires ce qui ouvrent des opportunités interessantes pour accélérer le démarage de la montre.

Bon, j’ai totalement refait la gestion des IRQ (donc la boucle principale) et ca « semble » avoir résolu les pb de stabilité. Attendons quand même qq jours pour en être sur …
Go maintenant sur la gestion du deepsleep et l’accelération du démarrage.

3 jours, pas un seul plantage et pourtant je ne l’ai pas ménagé : rando a pied + ski de rando + bricolage. Avec le code original, elle plante pour moins que ça. Cooooolllllllll

C’est donc sur mon github : https://github.com/destroyedlolo/DomoWatch

Je vais donc pouvoir de focaliser sur de nouvelles fonctionalités