Discussion :

[boboss123]

Bonjour,

Je suis en train de créer un programme qui tourne sur microcontrôleur PIC32MZ avec FreeRTOS.

Le microcontrôleur redémarre de manière aléatoire : le reboot est effectué après une exception levée sur un pointeur ayant une mauvaise adresse dans du code appartenant aux libraries standards fournis avec le compilateur (je ne sais donc pas quelle fonction plante).
=> L’hypothèse qui me semble la plus probable est que les fonctions sprintf/snprintf ne sont pas "thread safety" et/ou qu'elles utilisent les fonctions malloc/free des libraries standard, ce qui interfère avec l'utilisation de FreeRTOS.

Je suis donc partie dans l'idée de créer mes fonctions de conversion pour être certain de leur comportement.

Actuellement, j'ai déjà fait mes fonctions de conversion entier vers string et maintenant j'aimerai faire ma fonction de conversion float to string (et double to string).
J'aimerai pouvoir passer en paramètre le nombre de chiffre après la virgule et la taille minimale de la chaine afin d'insérer des caractères espace ou '0' (paramètre configurable) en début de chaine si celle-ci est trop petite

PS : j'ai compris comment était codé en binaire un float... c'est déja un début.

Quelle méthode me conseillez-vous d’utiliser ?

Merci d'avance,

[Bousk]

Et (sn)printf ne fait pas l'affaire ? printf("%0.*f", nbDecimals, floatValue); ?
http://www.cplusplus.com/reference/cstdio/printf/

[Sve@r]

Bonjour

=> L’hypothèse qui me semble la plus probable est que les fonctions sprintf/snprintf ... et/ou qu'elles utilisent les fonctions malloc/free des libraries standard

Garanti que non

[dalfab]

Bonjour,

C'est en effet très peu probable un problème de réentrance dans de genre de code. Par contre ces bibliothèques sont consommatrices de données sur la pile. N'es-tu pas dans un cas de débordement de pile?
Quand à coder soit même une conversion flottante, c'est loin d'être simple. C'est d'ailleurs dans ces traitements qu'il peut y avoir des erreurs (erreur sur les dernières décimales, mauvaise gestion des nombres dénormés)
Regarde si ta bibliothèque dispose de ftoa() ou de fcvt() qui sont capables d'effectuer la conversion.

[boboss123]

Merci pour vos réponses.

Ce que je remarque, c'est que depuis que j'ai implémenté mes fonctions custom pour remplacer (sn)print, mon µControleur reboot beaucoup moins souvent. Je n'ai pas encore fait la modification de partout dans mon code (seulement dans les endroits ou (sn)print sont appelés le plus souvant), ce qui expliquerait les reboots restants.

J'avais aussi des problèmes sur la gestion des float (des variables de type float avait leur valeur modifiée de manière aléatoire) qui a été résolu avec cette méthode : https://www.microchip.com/forums/m1066871.aspx

Par contre ces bibliothèques sont consommatrices de données sur la pile. N'es-tu pas dans un cas de débordement de pile?

J'ai configuré le "minium stack size" du compilo à 10000, ce qui semble largement suffisant pour initialiser FreeRTOS (dans freeRTOS, j'utilise heap_1.c : https://docs.aws.amazon.com/fr_fr/fr...anagement.html). Je n'ai pas détecté d'erreur avec les fonctions de debug FreeRTOS : vApplicationStackOverflowHook(), xPortGetFreeHeapSize() et uxTaskGetStackHighWaterMark().
En configurant à 0 la heap du compilateur (pas celle de FreeRTOS), les fonctions (sn)printf fonctionnent encore même avant appel de osStartKernel() : ce qui laisse supposer qu'elles utilisent uniquement la stack (et pas de heap).

Regarde si ta bibliothèque dispose de ftoa() ou de fcvt() qui sont capables d'effectuer la conversion.

Je veux bien mais qu'est-ce qui me garanti que ces fonctions sont thread safety ? je n'arrive pas à trouver l'information... et je n'ai pas d'autres pistes d'où pourrait venir le problème.

[dalfab]

J'ai configuré le "minium stack size" du compilo à 10000, ce qui semble largement suffisant pour initialiser FreeRTOS (dans freeRTOS, j'utilise heap_1.c : https://docs.aws.amazon.com/fr_fr/fr...anagement.html). Je n'ai pas détecté d'erreur avec les fonctions de debug FreeRTOS : vApplicationStackOverflowHook(), xPortGetFreeHeapSize() et uxTaskGetStackHighWaterMark().

Je ne sais pas à quoi correspond la 'minimum stacke size' du compilo. Mais ici il y a un noyau temps réel embarqué, et chaque thread doit avoir une pile, et chaque pile foit avoir une taille attribuée. Et ce qui est important c'est le maximum accessible.

En configurant à 0 la heap du compilateur (pas celle de FreeRTOS), les fonctions (sn)printf fonctionnent encore même avant appel de osStartKernel() : ce qui laisse supposer qu'elles utilisent uniquement la stack (et pas de heap).

Heureusement qu'il n'y a pas heap utilisée. C'est justement pourquoi il peut pas y avoir de problème de data race dans ce genre de fonction.

Je veux bien mais qu'est-ce qui me garanti que ces fonctions sont thread safety ? je n'arrive pas à trouver l'information... et je n'ai pas d'autres pistes d'où pourrait venir le problème.

Il faudrait voir comment créer une fonction qui ne serait pas 'thread safe': seule cause : mauvaise gestion d'une ressource partagée, mais quel type de ressource :
- la heap est une ressource partagée, aucune raison de faire une allocation dynamique ici un buffer en dur gère tous les flottants, et tu as toi même fourni la preuve qu'aucune allocation dynamique n'est effectuée.
- sinon quelle ressource système pourrait être nécessaire ? un coprocesseur pour les calcul flottant ? Ça serait un conflit entre les interruptions et les threads, mais l"erreur sera sur toutes les fonctions utilisant du calcul flottant. Je ne vois rien d'autre et je crois peu à cela.
Sincèrement comment une fonction purement calculatoire pourrait être suffisamment mal écrite pour avoir un conflit de ressource?(il y a bien un moyen simple mais aucun débutant ne ferait cette erreur!) La probabilité d'avoir un 'data race' dans ton code me parait infiniment plus probable.

[Bktero]

Pour info, malloc() et free() n'ont aucun effet sur FreeRTOS qui a son propre tas avec son propre allocateur.

[boboss123]

Je ne sais pas à quoi correspond la 'minimum stacke size' du compilo. Mais ici il y a un noyau temps réel embarqué, et chaque thread doit avoir une pile, et chaque pile foit avoir une taille attribuée. Et ce qui est important c'est le maximum accessible.

Oui j'ai bien défini une taille de pile pour chaque tache, le 'minimum stacke size', c'est la taille mémoire minimale que est alloué aux fonctions appelée en dehors des taches FreeRTOS.

- sinon quelle ressource système pourrait être nécessaire ? un coprocesseur pour les calcul flottant ?

Je n'ai pas l'impression que le problème vienne de là car mes calculs sont bons


... Je continue de chercher...