Malloc plutot qu'une variable locale [Forums - Langage C]
Malloc plutot qu'une variable locale [Forums - Langage C]
Pseudo Pass se souvenir de moi     Créer un compte
ARTICLES et TELECHARGEMENTS ~ FORUMS ~ LIENS  
 
             
 
Recherche
 
   
 

Parcourir ce sujet :   1 Utilisateur(s) anonymes



(1) 2 »


Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Bonjour

Dans du code du SDK de NXP je vois des fonctions qui ont besoin d'un buffer pour travailler et qui le prennent via un Malloc
par exemple 1024octets pour lire un fichier de FAT et le copier dans un autre.
A chaque fois il y a libération de la mémoire quelques ligne en dessous avant de quitter la fonction.

Quel est l’intérêt d'utiliser Malloc plutôt qu'une variable locale qui selon moi serait de la même manière chargée en mémoire au lancement de la fonction puis libérée en quittant la fonction ?

Merci pour vos lumières

Posté le : 10/08/2017 13:46
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
27/09/2005 18:07
De Metz
Messages: 1354
Hors Ligne
Peut-être parce qu'une variable locale est prise dans la pile et que sa taille est limitée, alors que les variables dynamiques sont prises dans le tas.

Posté le : 10/08/2017 14:34
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Pour me répondre il sera peut être plus simple de se baser sur un exemple concret d'espace mémoire...

Je suis sur un K64 qui a 2 banque de RAM pour un total de 256 KB
SRAM_L ORIGIN = 0x1FFF0000, LENGTH = 0x00010000 (64 KB)
et SRAM_U ORIGIN = 0x20000000, LENGTH = 0x00030000 (192 KB)

comme GCC ne sait pas passer de l'une à l'autre et que j'utilise FreeRTOS
J'ai la heap de FreeRTOS qui est affectée à la deuxième banque, la plus grande pour 190kB; Il reste donc 2KB sur cette deuxième banque mais je ne comprends pas à quoi elle sert. Si je rentre
#define configTOTAL_HEAP_SIZE   ((size_t)(192 * 1024))
dans FreeRTOs j'obtiens une erreur
Description Resource Path Location Type
Citation :
region `m_data_2' overflowed by 2048 bytes
, il manquerait pile 2KB, étrange...

sur la première banque SRAM_L j'ai défini une heap_size à 0x0400 et une stack_size à 0x0400

du coup pour moi j'ai
Dans SRAM_L (64KB) :
-0X0400 de heap (pour les éventuels malloc de librairies externes utilisées en dehors de FreeRTOS)
-0x0400 de stack (pour les paramètres de fonctions et variables locales) (Que les fonctions utilisées en dehors de FREERTOS ???)
-Il reste donc 0x10000 -0x400 -0x400 = 0xF800 de RAM libre utilisée pour les variables globales (ou STATIC ce qui est presque pareil)

Dans SRAM_U (192KB)
-190KB utilisées par la heap de FreeRTOS (pour moi ça sert à affectée de la heap à chaque taches de Freertos et chaque tâche utilise ensuite cette heap pour TOUT (var locales, appels de fonctions, malloc etc...)
-2KB qui servent à je ne sais pas quoi


Pour en revenir à ma question, il me semble que tout ce qui est appelé depuis freertos part dans la heap de la tache concernée, que ce soit du malloc ou une var locale.
Mais vu qu'il me reste des incompréhensions sur le map mémoire la réponse se trouve sans doute dans ces zones d'ombre !

Merci

Posté le : 10/08/2017 14:37
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Bonjour Jacques

Merci pour ta réponse. De tout ce que j'ai lu ce matin j'ai compris qu'il y avait un soucis sur pc avec la pile qui est par défaut tés petite mais il me semble que sur nos petits microcontrôleurs on fait un peu comme on veut puisque on dit au compilateur ce que l'on veut dans le détail.

J'espère que le détail de mon cas que je viens de poster aidera à faire avancer mon schmilblick.

Outre le fait que j'aimerais bien enfin comprendre en détail ces histoires de RAM qui sont au cœur de nos problèmes, je suis confronté au codage d'une fonction où je suis partis sur 2 malloc (sur le modèle de fonctions NXP) avec la gestion des erreurs qui devient très complexe à coder pour gérer le free() en fonction des sorties sur erreur de la fonction. Avec des var locales je n'aurais pas tous ces risques de fuite de mémoire associés

Merci

Posté le : 10/08/2017 14:45
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
et je confirme que FreeRTOS met tout dans sa heap (var local, malloc etc)

freeRTOS a 190kB de heap en SRAM_U (ORIGIN = 0x20000000, LENGTH = 0x00030000)

or dans une fonction appelée par une tache de FreeRTOS
une variable locale se trouve à l'adresse 0x20014150 donc dans la heap de FreeRTOS
une var allouée avec Malloc est placée en 0x2001b90 donc aussi dans la hap de FReeRTOS

en terme d'espace mémoire j'en déduis que var local ou malloc ce serait pareil, je me trompe où ?

Et les 2kB de SRAM_U que je ne peux pas affecter à la heap de freertos, elle est occupée par quoi ? comment puis-je le savoir ?



Posté le : 10/08/2017 15:25
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Bon

J'ai fini par comprendre (je crois)

L’intérêt du malloc est qu'il va en heap et pas en stack, que ce soit avec ou pas freertos.
Avec Freertos on défini la stack de chaque tache à la création de celle ci. Du coup si toutes les taches devaient exécuter une fonction nécessitant ces grosses variables il faudrait que toutes les taches soient lancées avec une grosse stack
Si les functions utilisent malloc alors toutes les taches peuvent être crées avec une task minuscule ; les fonctions appelées prendront la RAM dans la heap de freertos.

Mais mon esprit tordu de mécano n'est pas encore comblé !
Si on a 3 taches qui appellent chacune une fonction avec une var local de 10ko alors il faut que chacune de ces taches dispose d'une stack de ces 10ko ; si la fonction utilise malloc alors les stack des 3 taches peuvent être petites, les fonctions prendront dans la heap. Genial mais au final si les 3 fonctions appellent en MÊME temps la fonction, le problème se retrouvera sur la heap, non ?
ça revient au même au final sauf que la stack insuffisante on la voit à la compilation alors que la heap insuffisante on la verra (peut être) en test, non ?

J'ai raté un truc ?

Merci

Posté le : 10/08/2017 19:35
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Accro
Inscrit:
06/07/2007 09:17
Messages: 697
Hors Ligne
Salut.
Pour moi, tu as raison sur le test du HEAP. On ne verra les problème que lors de l'execution.
Je ne connais pas FreeRTOs, mais si la taille de HEAP est défini, n'y a-t-il pas une mécanisme de protection sur le dépassement?

Posté le : 16/08/2017 08:17
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Salut

Si il y a puisque quand on fait un malloc on peut (et doit évident) tester si l'objet en question a bien été alloué. Si ce n'est pas le cas c'est qu'il n'y a pas assez de heap disponible.
malloc c'est donc royal tout est sensé se faire en douceur mais c'est super compliqué à gérer dans le code !!! Dans un code normal il est rare de partir en erreur là ca devient normal et doit déclencher la relance d'un processus qui pourra s'exécuter une fois que la tache voisine aura libéré de la heap.

Sur cette histoire de malloc et de heap je ne pense pas que freertos ait un comportement différent.

Stéphane nous expliquait un jour que sur les applications critiques niveau sécurité on n'avait pas le droit de faire du malloc, j'imagine donc que dans ces applis là chaque processus a en permanence à disposition 100% de la RAM qu'il est susceptible d'avoir besoin.

Ou alors je n'ai rien compris...

Posté le : 16/08/2017 09:41
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Accro
Inscrit:
06/07/2007 09:17
Messages: 697
Hors Ligne
c'est vrais que je n'utilise jamais malloc() et free() car je souhaite avec un system stable et prédictif.
Si j'ai besoin d'un tableau, je le définit avant. j'anticipe...
Gente un msg CAN qui ne contient que 2 octets de data sera quand même copier dans une structure avec 8 octets de data disponible (max can frame data size).

Pour freeRTOS, tu devrais regarder ceci:
http://www.freertos.org/a00111.html

Cela explique assez bien 5 différentes implémentation possible.

Posté le : 16/08/2017 14:05
Transférer la contribution vers d'autres applications Transférer


Re: Malloc plutot qu'une variable locale
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
j'ai passé des heures sur ce doc de freertos

En utilisant les SDK de compétition de NXP il est bien difficile de se passer de malloc, il y en a de partout !

Posté le : 16/08/2017 14:14
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer



 Haut   Précédent   Suivant
(1) 2 »



Vous pouvez voir les sujets.
Vous ne pouvez pas débuter de nouveaux sujets.
Vous ne pouvez pas répondre aux contributions.
Vous ne pouvez pas éditer vos contributions.
Vous ne pouvez pas effacez vos contributions.
Vous ne pouvez pas ajouter de nouveaux sondages.
Vous ne pouvez pas voter en sondage.
Vous ne pouvez pas attacher des fichiers à vos contributions.
Vous ne pouvez pas poster sans approbation.

[Recherche avancée]


Powered by XOOPS© The XOOPS Project
Contacter les administrateurs

Malloc plutot qu'une variable locale [Forums - Langage C]