Quelle mémoire pour enregistrer des mots dans un PIC ?

[AmigaOS]

Bonjour

Habituellement je ne fais pas trop attention à la taille des mémoires contenu dans les µC parce que mes programmes ne sont pas trop grands et parce que par magie le programme se sert de la mémoire là ou il faut.
Mais cette fois ci je risque d’avoir besoin d’un peu plus d’espace et je ne sais pas exactement quelle taille de mémoire choisir. Et en plus il y a des mémoires différentes contenus dans les µC Flash, EEPROM, RAM...

J’ai besoin d’un PIC dans lequel je peux rentrer :
- un menu composé d’une 60taine de mots (~300 caractères)
- un tableau qui contient 60 cases pour caractériser des lettres, des chiffres, et des symboles pour des afficheurs 14-segments. (2 octets par caractère)
- une vingtaine de variables max en int et char (je ne sais pas encore exactement combiens)
- Et un programme de entre 150 et 600 lignes de C.
Il me manque donc la taille du programme que je ne connais pas encore.

Quelles tailles pour quels types de mémoires choisirais vous dans cette situation ?

Merci
-----

[antek]

La doc dit pourtant tout !

- taille des mots
- temps d'accès
- taille de programmation de l'accès
- durée de vie en nombre d'écriture

Pour la flash il faut savoir aussi si tes mots rentrent dedans, et pour le reste transposer les int char etc en octets.

[AmigaOS]

Oui je sais comment trouver un µC qui à telle ou telle taille de mémoire, mais avant de faire ça j'aimerais connaitre la taille que mon programme va prendre dans la mémoire. C'était ça ma question.

[vincent66]

Bonsoir,

Ben tu rédiges un premier jet de ton programme, tu compiles et alors tu sauras...

[A voir en vidéo sur Futura]

[AmigaOS]

Si je déclare (par rapport à mon exemple) :

short int caracteres[60] = {0b0111001001110010, 0b0000000000001100, ..., 0b1000001000001110} ;   //Mes caractères pour afficheur 14 seg
char mots[60][20] = {("MENU"), ("SELECT"), ..., ("RESET")} ;   // Les mots du menu
int a1, a2, a3, a4, a5, a6, a7, a8, a9, a10 ;   // Des variables pour le reste du programme
char b1, b2, b3, b4, b5, b6, b7, b8, b9, b10 ;

Uniquement pour ce bout de code, est-ce que j'ai besoin de 60x2 + 60x20 + 10x2 + 10x1 = 1350 octets dans la RAM et dans la Flash ? Ou il y a des choses qui se rajoutent et dont j'ai pas tenu compte ?

Ben tu rédiges un premier jet de ton programme, tu compiles et alors tu sauras...

Ce sera un gros code que je vais devoir faire étape par étape en validant chaque partie avant de passer à la suivante. Du coup ça va être compliqué de faire un code vite fait pour tester.

[jiherve]

bonsoir
a priori c'est bon au "padding" prés car bien souvent le compilo peut allouer sur d'autres frontière que l'octet il peut donc y avoir un peu de pertes collatérales.
Cela peut se vérifier en modifiant l'ordre de déclaration mais en general commencer par les long(int,32bits) puis les short(word,16bits) et enfin octets(char ou byte).
Ceci dit tout çà ne tombe pas dans la même mémoire les deux premiers items finiront en flash (ce sont des constantes) et le reste en RAM (ce sont des variables) ,ceci étant vrai pour la plupart des processeurs utilisés par les amateurs.
JR

[AmigaOS]

il peut donc y avoir un peu de pertes collatérales

Ok c'est de ça que je parlais alors. Mais tant que c'est pas 50% du programme c'est pas trop grave. Pour l’instant j'ai seulement besoin d'une grosse approximation sur laquelle je rajoute de la marge pour acheter le µC.

Je viens de faire des tests avec un vieux PIC et MPLAB X qui donne l'état des mémoires.
Et pour la RAM mon calcul correspond bien.
Pour la flash ça marche dès que j'initialise les variables. Ça a l'air logique du coup.
J'ai fait ensuite des tests en répétant des boucles for 2, 10, 20, 30 fois et j'ai pu voir comment ça remplit la mémoire.
30 boucles for avec une instruction dedans ça remplit 1146 words (je suppose que un word sur un µC 8bit c'est 8bit?)
Du coup ça réponds à peu près à ma question.

Merci en tout cas

[jiherve]

re
non la taille d'une instruction c'est en général plus que 8bits sur un AVR c'est 16bits min sur un PIC aussi sans doutes et une ligne de C génère le plus souvent plusieurs instructions assembleur.
JR

[AmigaOS]

Ok, merci pour l'information!

Je me demande, si on déclare :

const char mots[60][20] = {{"MENU"}, {"SELECT"}, ..., {"RESET"}} ;

au lieux de :

char mots[60][20] = {{"MENU"}, {"SELECT"}, ..., {"RESET"}} ;

alors les 1200 cases du tableau n'iront jamais en RAM et on les économise donc ?
Ou est ce que je dis des conneries là ?

[jiherve]

re
en effet de plus de la RAM initialisée cela demande d'abord de stocker les valeur en ROM et un bout de code pour l'initialisation donc une double peine mais le compilo peut être malin et faire uniquement un stockage en ROM tout le reste n’étant que jeu d'adresse!
Pour suivre tout çà il faut un utilitaire, souvent présent dans l'IDE , qui permette de visualiser le contenu de la ROM/FLASH.
JR

[antek]

en effet de plus de la RAM initialisée cela demande d'abord de stocker les valeur en ROM . . .

C'est quoi la ROM dans un PIC 8 bits ? . . .

[AmigaOS]

Super! J'ai fait le test. En mettant "const" devant le tableau la RAM est vidé

[jiherve]

bonjour,

C'est quoi la ROM dans un PIC 8 bits ?

c'est la Flash donc une mémoire non volatile, ne jouons pas stérilement sur les mots ,grande spécialité française!
JR

[antek]

c'est la Flash donc une mémoire non volatile, ne jouons pas stérilement sur les mots ,grande spécialité française !

Oui, vaut mieux dire ROM plutôt que flash, et pourquoi pas ROM pour EEPROM.
Utiliser le mot juste évite les jeux stériles.

[PA5CAL]

Les termes peuvent désigner le type du circuit ou sa fonction.

Une ROM (Read Only Memory) désigne autant une mémoire qu'il est seulement possible de lire (parce que son contenu a été fixé par le masque de fabrication de la puce qui la contient) qu'une mémoire qu'on ne destine qu'à être lue (et dont le contenu a pu être fixé a posteriori à l'aide d'un procédé quelconque, éventuellement réversible).

Le fait de préciser qu'on a affaire à une PROM, une EPROM, une UVPROM, une mémoire Flash ou une EEPROM apporte des informations supplémentaires quant à ses caractéristiques et aux façons de l'utiliser.

En particulier, une EEPROM (Electrically Erasable Programmable ROM) est en principe destinée à conserver des données non volatiles susceptibles d'être modifiées « au vol » par le système qui l'utilise, lequel la lit et l'écrit généralement indirectement au travers d'un périphérique d'interface spécifique.

À l'inverse, la mémoire Flash d'un micro-contrôleur, destinée notamment à contenir le code exécutable, est lue directement et beaucoup plus rapidement. Lorsque le système prévoit la possibilité de s'auto-programmer, son écriture reste indirecte et lente, et a priori beaucoup plus limitée en nombre de cycles qu'une mémoire EEPROM. Toutefois, la fonction d'auto-programmation de la mémoire Flash autorise parfois l'émulation d'une EEPROM sur certains micro-contrôleurs qui n'en possèdent pas.


En résumé, sur les micro-contrôleurs disposant d'une mémoire Flash, d'une mémoire RAM et d'une EEPROM, on s'attend en principe à trouver :
- une mémoire Flash, pour le programme, les constantes et les valeurs des variables initialisées ;
- une mémoire vive, constituée d'une RAM et de registres spécifiques, pour les variables du programme et plus généralement pour l'espace de stockage temporaire du langage (dont la pile et le tas, en C, par exemple) ;
- éventuellement une mémoire EEPROM, pour les données non volatiles, modifiables, généralement accessibles de façon indirecte par le programme.

On peut connaître immédiatement la taille d'un programme en mémoire Flash après compilation, de même que la taille de ses variables globales en mémoire RAM.

Mais on ne peut pas trouver de façon aussi directe la taille maximale de l'espace occupé en mémoire vive par les variables locales, par les paramètres d'appel de fonctions, par les contextes sauvegardés et par les allocations dynamiques. Pour évaluer la quantité de RAM nécessaire au fonctionnement du programme, il faut déterminer la situation la plus défavorable, de façon empirique ou par le calcul après analyse du code généré.

[jiherve]

Bonsoir
Merci Pa5cal en effet il existe ROM,UVPROM,FLASHPROM,EEPROM qui toutes partagent fonction et suffixe, au final la seule inutile est la WOM.
JR