Conversion float to string

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,

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

Bonjour

Citation:

---

Envoyé par boboss123

=> 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

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.

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

Citation:

---

Envoyé par dalfab

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).

Citation:

---

Envoyé par dalfab

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.

Citation:

---

Envoyé par boboss123

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.

Citation:

---

Envoyé par boboss123

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.

Citation:

---

Envoyé par boboss123

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.

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

Citation:

---

Envoyé par dalfab

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.

Citation:

---

Envoyé par dalfab

- 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...

Citation:

---

Envoyé par Bktero

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

---

Sauf si une fonction de la lib standard appelle ces fonctions et que ces fonctions sont appelées dans des thread FreeRTOS... mais a priori ça ne semble pas le cas.

Pourquoi une fonction de la stdlib qui appelle malloc() serait différente d'une fonction custom qui appelle malloc() ?

https://www.freertos.org/a00111.html

Citation:

---

To get around this problem, FreeRTOS keeps the memory allocation API in its portable layer. The portable layer is outside of the source files that implement the core RTOS functionality, allowing an application specific implementation appropriate for the real time system being developed to be provided. When the RTOS kernel requires RAM, instead of calling malloc(), it instead calls pvPortMalloc(). When RAM is being freed, instead of calling free(), the RTOS kernel calls vPortFree()

---

Sauf si tu choisis le mode heap_3, les 2 mécanismes d'allocation sont séparés :

Citation:

---

heap_3 - simply wraps the standard malloc() and free() for thread safety

---

A noter que quand tu utilises FreeRTOS, tout ton code hors interruptions s'exécute dans un thread. Tu es presque toujours dans le contexte d'un thread. La pile utilisée par l'OS lui-même (quand le scheduler prend la main) est la même celle utilisée pour les interruptions a priori. C'est en tout cas comme ça sur Cortex-M : https://gradot.wordpress.com/2018/06...-arm-cortex-m/

Citation:

---

Envoyé par Bktero

Pourquoi une fonction de la stdlib qui appelle malloc() serait différente d'une fonction custom qui appelle malloc() ?

---

Aucune différence, le problème sera le même... mais le problème de la stdlib, c'est que je n'ai pas accès au code source et je ne sais donc pas ce qu'elle fait... ce qui n'est pas le code de mon code dont je sais qu'il n'utilise que les fonction malloc de FreeRTOS.

Je vais essayer de créer un nouveau projet avec uniquement quelques taches qui font des printf pour voir si le problème vient de là afin d'être certain que ce ne soit pas autre chose qui cause le problème.

Citation:

---

Envoyé par boboss123

Aucune différence, le problème sera le même... mais le problème de la stdlib, c'est que je n'ai pas accès au code source et je ne sais donc pas ce qu'elle fait...

---

Exact.

Citation:

---

Envoyé par boboss123

ce qui n'est pas le code de mon code dont je sais qu'il n'utilise que les fonction malloc de FreeRTOS..

---

Et donc si tu n'utilises pas heap_3 comme allocateur, alors la bibliothèque standard n'utilise pas le tas de FreeRTOS.