gestion memoire PIC18F26K20

[Eki27]

Bon, de toute évidence je n'ai pas compris l'entièreté des finesses du modèle mémoire de mon PIC!
Mais heureusement que vous êtes là (surtout RISC ) pour m'aider à éclaircir tout ca!

Jusqu'ici, lorsque j'avais besoin de créer zones de stockages contigus en mémoire (par exemple pour créer un gros tableau de plus de 256 KB) je manipulais le fichier .lkr du pic pour regrouper plusieurs databank. Ca, ca fonctionne Ok.

Cependant en regardant de plus près le fichier lkr original du PIC18F26K20 (en attachement), je constate qu'il n'y a que 14 databank déclarés, soit 1MB de RAM défini? Mais le 18F26K20 possède pourtant 4MB! Ou sont définis les 3 autres?

A cause de cette incompréhension, je bloque actuellement sur la création d'un "2-méga-groupe" pour l'utiliser en tant que "super-buffer" (j'adore inventer des mots...) afin de pouvoir stocker quand mon PIC ne peut plus communiquer avec son hôte.

En précisant que je travaille avec le compilateur C18 sous MPLAB.
D'avance merci pour vos conseils.
-----

[Seb.26]

Tu as un petit souci d'unités on dirait

Ton PIC a 3936 OCTETS de RAM donc tu risque pas de pouvoir faire des buffers de 256KB ...

[Eki27]

ouillllllle, la honte ! A force de travailler avec des véritables ordinateurs, je perds l'habitude de m'exprimer avec des dimensions si petites

Revoici ma demande en bonne et due forme :

Jusqu'ici, lorsque j'avais besoin de créer zones de stockages contigus en mémoire (par exemple pour créer un gros tableau de plus de 256 B) je manipulais le fichier .lkr du pic pour regrouper plusieurs databank. Ca, ca fonctionne Ok.

Cependant en regardant de plus près le fichier lkr original du PIC18F26K20 (en attachement), je constate qu'il n'y a que 14 databank déclarés, soit 1KB de RAM défini? Mais le 18F26K20 possède pourtant 4KB! Ou sont définis les 3 autres?

A cause de cette incompréhension, je bloque actuellement sur la création d'un "2-Kilo-groupe" pour l'utiliser en tant que "super-buffer" (j'adore inventer des mots...) afin de pouvoir stocker quand mon PIC ne peut plus communiquer avec son hôte.

En précisant que je travaille avec le compilateur C18 sous MPLAB.
D'avance merci pour vos conseils.

[Eki27]

Bon, je continue à me corriger (je me mets une baffe à chaque post, rassurez-vous)

J'ai bien 16 BANKS de 256 bytes, soit 4096 bytes au total, tout va bien mieux.

j'ai donc regroupé les BANKS 7 à 12 (256 * 6 = 1536 bytes) pour pouvoir contenir un tableau de 50 structures comme ci-dessous.

Si je comptes bien chaque structure pèse 24 bytes (5 int (10 bytes) + 6 char (6 bytes) + 2 long (8 bytes)) * 50 unités = 1200 bytes
Je suppose qu'une structure ne peut pas chevaucher 2 BANKS!? Donc je perds 16 bytes sur les 5 premières = 80 bytes

1280 bytes devraient pouvoir tenir dans 1563. J'ai pourtant une erreur du linker de MPLAB qui requiert 1912 bytes pour contenir mon tableau de structure, après avoir essayé je ne peux en mettre que maximum 34, moi pas comprendre!

struct StrBuffer {
int t;
int i1;
int i2;
int i3;
int i4;
char s[6];
long r;
long v;
};

[A voir en vidéo sur Futura]

[paulfjujo]

bonsoir,


Ton raisonnement devrait tenir , en raisonnant sur la granularité des bank à 256 bytes, mais
au niveau langage assembleur,
mais il faut penser que le compilateur C18 se sert d'abord ! et doit grapiller par ci par là
de la place necessaire à gerer ses pointeurs et autres..
et il faudra aussi de la RAM dispo pour le reste de ton programme..

[RISC]

Salut,

Il faudrait avoir ton programme pour examiner cela de plus près...
Je pense que le problème que tu as es déjà lié à l'alignement des données (le char au milieu c'est pas bon...).
Si tu as la possibilité de réorganiser ta structure, je te conseille de procéder comme suit (à titre de test) :

[/code]
struct StrBuffer {
long r;
long v;
int t;
int i1;
int i2;
int i3;
int i4;
char s[6];
};
[/code]

Utilises-tu la version optimisée ou non du compilateur C18 ?

a+

[Eki27]

J'utilise le "biessss" compilateur de base C18 livré avec MPLAB, un tel gaspillage me fait peur! Ou bien c'est voulu pour forcer l'achat!?

De plus si la fonction stroul était inclue dans les librairie de C18, je pourrais transformer le tableau de char en long (techniquement gagner deux bytes, peut être plus?)

Vous me conseillez de changer de compilo? Si oui par quoi?

J'ai tenté la réorganisation tel que tu l'as proposée mon cher RISC, malheureusment aucun changement, toujours limité à 34 structures maximum pour les 6 BANKS.

Autres questions en rapport avec MPLAB et :
- la data memory gauge est-elle fiable (je ne crois pas du tout)?
- Dans le menu VIEW, je peux accéder à l'affichage du program memory, mais pas à memory, je ne peux donc pas voir ou il place mes variables en RAM! (est-ce du à mon outil de debug? qui n'est autre que le simple picKit 3 en direct)
- je ne comprends pas l'utilité de l'option single-bank / multi-bank de stack model dans les options du projet (et je ne sais pas si cela influence mon problème actuel)

Encore merci

[Seb.26]

Demande au compilo la taille de ta stucture : sizeof(...)
http://en.wikipedia.org/wiki/Sizeof

[Edit] Et pourquoi pas splitter ton tableau de structures en x tableaux ( un tableau par structure) ... au moins pour le stockage, ensuite tu fais une fonction qui reconstitue ta structure ...

[Eki27]

ha ben oui , je pourrais faire un sizeof de chaque élément, majoré de de la récupération de la position en mémoire et puis faire tous des petits tableaux... Mais, mais, ca revient à faire de l'assembleur avec le langage C!! Je crois que tu viens d'inventer un nouveau concept

Non sans blague, j'aimerais réaliser quelque chose de propre.

A bientôt,
Eki

[paulfjujo]

bonsoir,


Ayant un doute, j'ai fait la manip suivante pour tester une Grosse BANK : (bank 6 à C)
bizarre il ya des lettres maintenant sur les declaration de bank , on n'est plus en decimal ?
test fait avec un 18F46K22

voir images
il s'avere que la jauge donne bien un ecart de 1718-518=1200 !!!
mais mon programme , dans lequel j'ai inséré la declaration est tres court ...
ce qui peut expliquer que quand il y a de la place libre dans les banks que l'on s'accapare là ... c'est OK !!!

ou ai-je mal fait la declaration ?

nota: j'ai la version C18 V3.37.01 lmitee 60j , qui a du repassé depuis longtemps en mode NON Optimisée.

[RISC]

Salut,

Je n'ai pas trop confiance dans les jauges...Je préferre regarder la mémoire RAM.
Dans MPLAB : View > File Registers tu devrais trouver tes structures.

Autre chose, génère un fichier .map : Project > Build Options > Project > onglet Mplink Linker > cochde la boite "Generate Map File"

Après compilation tu trouveras un fichier MAP qui te donne un rapport extrêmement précis de l'utilisation de la RAM et de la FLASH et de tout ce qui se trouve dedans..

a+

[Eki27]

Merci pour ces infos, qui m'ont bien aidé à y voir plus clair!

Je pense avoir solutionné mon problème via ces trois principes :
1) optimisation de l'organistation de banks; en partant de la bank1 0X100 pour mes grandes sections et en les ajustant au mieux.
2) utilisation correcte de la directive #pragma udata/idata; le fait de placer des variables initialisées dans une section udata était incohérent et ne donnait pas le résulat attendu (problème principal)
3) utilisation du mot clé PROTECTED pour les banks réservées dans le fichier du linker afin d'éviter que le compilateur y place d'autres données

Avec ces corrections, la jauge mémoire de MPLAB redevient fiable (elle l'a probablement toujours été, le problème était entre la chaise et le clavier )

Bonne journée et à bientôt!