taille dispo pour la stack sur kinetis [Forums - Kinetis]
taille dispo pour la stack sur kinetis [Forums - Kinetis]
Pseudo Pass se souvenir de moi     Créer un compte
ARTICLES et TELECHARGEMENTS ~ FORUMS ~ LIENS  
 
             
 
Recherche
 
   
 

Parcourir ce sujet :   1 Utilisateur(s) anonymes





taille dispo pour la stack sur kinetis
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Bonjour

Sur les S08, on avait le fichier PRM qui permettait de régler la taille de la stack, par défaut ridiculement faible avec 0x50.

Je cherche à savoir si par hasard sur les kinetis, ils auraient optimisé ça pour que CW calcule la taille de stack disponible tout seul en fonction des var globales déclarées dans le projet. A défaut je cherche à savoir où déclarer cette taille de stack.
Yvan me dit que c'est un fichier .lcf sur les K60 mais il n'y en a pas trace sur mon pc (je suis sur un K15)...

Merci

Posté le : 06/11/2013 16:44
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: taille dispo pour la stack sur kinetis
Pilier de la communauté
Inscrit:
27/09/2005 18:26
Messages: 794
Hors Ligne
Salut Charly,

C'est dans le fichier .ld qui est dispo sous "Project_Settings\Linker_Files" dans l'arbo de CW.

Joël

Posté le : 06/11/2013 19:59
En Savoie, on a pas de pétrole, mais on a des Diots !
Transférer la contribution vers d'autres applications Transférer


Re: taille dispo pour la stack sur kinetis
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
donc si je comprends bien 0x50 du S08 est devenu 0x400 sur le KL

crebindiou ça fait pas lourd 0x400; 1/16ieme de la RAM !

Ca m’amène à la question qui me turlupinait déjà avec les S08
Si dans la ram on a les var globale puis la stack ou s'empilent les var locales et les registres des fonctions ouvertes, pourquoi CW ne calcule pas bêtement la taille de la stack comme étant TailleRam - Volume des vars globales ?


Posté le : 06/11/2013 21:30
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: taille dispo pour la stack sur kinetis
Pilier de la communauté
Inscrit:
27/09/2005 18:26
Messages: 794
Hors Ligne
J'ai peu de billes sur le sujet, je suis pas du tout expert, mais l'espace restant n'est surement pas inutilisé. Sans avoir vérifié, que ce passe t-il si on fait un malloc ?! Ce n'est surement pas localisé dans la stack ! Et ce ne sont pas des variables globales bien sur. Pour moi il y a les variables globales, la stack, et le reste ! Suite à un malloc la mémoire allouée sera dans "le reste". Un dimensionnement correct - c'est à dire non excessif - de la stack permettra de faire plus d'allocation de mémoire dynamique. Le terme se suffit à lui même d'ailleurs, si c'est dynamique, CodeWarrior ne peut pas anticiper sur les tailles de telle ou telle zone.

Il y a peut être d'autre exemples... je laisse les pros s'exprimer et/ou corriger...

Joël

Posté le : 07/11/2013 22:18
En Savoie, on a pas de pétrole, mais on a des Diots !
Transférer la contribution vers d'autres applications Transférer


Re: taille dispo pour la stack sur kinetis
Pilier de la communauté
Inscrit:
23/10/2005 11:40
De Aix les Bains (73)
Messages: 1943
Hors Ligne
Yvan a pensé au malloc aussi

Ca fait au moins une bonne raison, même si le compilo aurait toujours la possibilité d'optimiser la stack s'il n'y a pas usage de malloc

Maintenant, s'il y a un moyen de voir quelle place on occupe en RAM avec nos variables globales on peut calculer cette valeur de stack nous même. C’était dans le fichier map qu'on pouvait voir ca me semble il.

Posté le : 07/11/2013 22:34
Mieux vaut marcher dans la bonne direction que courir dans la mauvaise
Transférer la contribution vers d'autres applications Transférer


Re: taille dispo pour la stack sur kinetis
Pilier de la communauté
Inscrit:
13/10/2005 10:06
De haute-savoie (74)
Messages: 1164
Hors Ligne
La pile est une forme d'allocation dynamique de la RAM. Un variable poussée dans la pile a une durée de vie limitée et peut être réaffectée à une autre variable à un autre moment.
Cela signifie que le seul moyen d'évaluer la taille de la pile à un moment donné serait soit de pouvoir détecter toutes les combinaisons de fonctions qui à un moment donné vont utiliser la pile, soit calculer la taille max.
Généralement on calcule la taille max qui est facile à faire et que le compilo pourrait faire. Cela correspond à l'arborescence la plus longue dans les appels de fonction (tree) x 2 octets (vecteur de retour) + la taille des variables locales.
Sur un programme lourd cela devient finalement assez compliqué à calculer car il y a beaucoup de branches et il faut toutes les évaluer !

Bien sûr en pratique la valeur max peut ne pas être atteinte. Si par exemple une fonction 1 utilise la pile pour traiter un tableau de 100 octets dont il n'a plus besoin en sortant de la fonction, et qu'une autre fonction utilise elle aussi 100 octets dans la pile mais n'en a plus besoin en sortant de la fonction, et si on est capable de garantir que la fonction 1 ne peut pas appeler la fonction 2 alors la taille de la pile ne dépassera pas 100 octets alors que l'on a deux variables de 100 octets.
Cela signifie que le seul moyen d'évaluer alors automatiquement cette taille serait une couverture dynamique du code... couverture qui finalement est faite quand on déroule le code ! Donc en pratique, j'embarque toujours un système d'évaluation de la taille max consommée en pile en initialisant toute la pile avec une valeur remarquable (0xAA) puis en regardant après avoir fait tourner un long moment pour être sur que le soft est allé dans toutes les routines, la dernière valeur qui n'est plus 0xAA ! Ca donne la taille consommée réellement par l'application. C'est empirique et approximatif car on n'est finalement pas sûr d'avoir couvert tous les cas, en particulier dans les systèmes temps réels durant lesquel on ne maîtrise pas les branches d'appel


Je rappelle que le malloc est en principe proscrit en embarqué ! Certains le tolèrent à l’initialisation du programme, à condition de ne jamais libérer la mémoire avec 'free' ni de refaire de malloc en cours d'application, l'objectif étant d'éviter des 'fuites mémoires'. La plupart des normes en vigueur dans l'embarqué interdisent tout simplement l'allocation dynamique.

On peut contourner le problème en réécrivant soit même sa routine d'allocation mémoire. J'en ai fais une qui fonctionne très proche du malloc, qui ne gère que des blocs contigus (contrairement au malloc qui peut morceler l'allocation) et que je ne libère jamais.
Cela me permet de faire de l'allocation dynamique à l'initialisation de mon programme, sans avoir à utiliser malloc ! J'ai embarqué ces routines dans la révision de mon noyau round robin quand j'ai ajouté la gestion des queues... A toutes fins utiles

Concernant le malloc, l'allocation se fait dans le segment HEAP et non pas dans la stack. Si on utilise pas le heap, on peut réduire ce segment qui par défaut sur les coldfire par exemple est déjà de 400 octets je crois !

Stéphane

Posté le : 08/11/2013 11:51
Transférer la contribution vers d'autres applications Transférer



 Haut   Précédent   Suivant



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

taille dispo pour la stack sur kinetis [Forums - Kinetis]