bonjour,
Je suis en train de developper pour le boulot un appareil qui est sensé enregistrer 300 valeurs ( 1 par sec pendant mini 5min, soit 300 valeurs). Ces valeurs sont comprises entre 0-255 donc je prends la variable int.
Je definie un tableau int tab[300];
mais la horreur, le compilateur me dit qu'il n'y a pas assez de place... pourtant d'apres mes calculs c'est bon... ou est l'erreur :
300*int(8bit) = 2400bit = 2.4Kbits = 300bytes
flask memory du pic 16f877 = 8K
la flash memory est destinée a stocker le programme, pas les variables.
cependant on peut quand même écrire dedans et y stocker des données si besoin, mais les stocker dans l'eprom est généralement une meilleure solution.
oki j'aî compris mais alors d'apres toujours la data sheet, la taille de ram dispo est de 368bytes.
donc un tableau de 200 valeurs de int doit passé a l'aise (200bytes).. mais non...
J'ai fait un test :
int tab[96] donne RAM=28%
int tab[97] donne RAM complete....
Au secours !
Salut,
Attention la RAM du PIC16F877 est composée de 4 pages. les 368 octets ne sont pas contigues. Donc chaque page peut contenir environ 90 valeurs. C'est surement pour ça que le compilateur ne peut pas allouer des tableaux aussi gros. La solution serait de creer 4 tableaux et de gérer l'écriture des 300 valeurs dans le programme.
Bonjour!
Un char non signé pourrait suffire (et prendrai moins de place!)Envoyé par joseph4008
1) Ne pas écrire en EEPROM, le nombre de cycle d'écriture est "limité" (par rapport au nombres de cycles possibles en RAM ou FLASH)
2) Tu peux écrire en FLASH, mais les cycles d'écritures sont très long (cependant moins long qu'en EEPROM)
3) Le mieux est d'écrire en RAM s'il te reste suffisamment d'octets libres, cependant, la mémoire est divisée en 4 bank, tu passes de l'une a l'autre en modifiant les bits RP0 RP1 (en direct) ou IRP (en indirect):
* 80 octets en banque 0, adresses 0x20 à 0x6F
* 80 octets en banque 1, adresses 0xA0 à 0XEF
* 96 octets en banque 2, adresses 0x110 à 0x16F
* 96 octets en banque 3, adresses 0x190 à 0x1EF
* 16 octets communs aux 4 banques, soit 0x70 à 0x7F = 0xF0 à 0xFF = 0x170 à 0x17F = 0x1F0 à 0x1FF
Les octets communs signifient simplement que si tu accèdes au registre (adresse mémoire RAM) 0x70 ou au registre 0XF0, et bien tu accèdes en réalité au même emplacement. Ceci à l’avantage de permettre d’utiliser ces emplacements sans devoir
connaître l’état de RP0,RP1, et IRP.
Pour les autres cases mémoires, en adressage direct:
RP0 = 0, RP1 = 0 ==> BANK 0
RP0 = 1, RP1 = 0 ==> BANK 1
RP0 = 0, RP1 = 1 ==> BANK 2
RP0 = 1, RP1 = 1 ==> BANK 3
En indirect:
IRP = 0 => BANK 0 ET BANK 1
IRP = 1 => BANK 2 et BANK 3
A toi de te faire une petite fonction de gestion mémoire, qui te permettra automatiquement de sauter d'une banque a l'autre au fur et a mesure de la progression de ton tableau.
Et comme le conseil maximilien, des "unsigned char" (taille 1 octet) suffisent, car tes "int" occupent 2 octets par valeur !!!
A+
Bonjour à tous,
Je relance un peu ce topic car je suis dans le même cas de figure. J'ai une erreur à la compilation car j'utilise toute la capacité de la bank. J'ai bien compris qu'il fallait changer de bank, mais à quel moment? à la déclaration du tableau? Lorsque je veux lire une valeur?
Je programme en C et je trouve peu d'informations...
Merci de votre aide!
Je n'ai pas testé , c est juste pour donner le principe
Une routine lecture identique est aussi nécessaire.
Pour les déclarations genre RAM2[64] reste à voir ce que fait le compilateur...
Code:// On crée 4 banks de 64 octets soit 256 octets au total unsigned char Ram1[64]; unsigned char Ram2[64]; unsigned char Ram3[64]; unsigned char Ram4[64]; // Data = donnée a sauvé // adr = adresse de 0 à 255 pour considérer les 4 buffers comme 1 seul void SaveDat(unsigned char data, unsigned char adr) { unsigned char MyBank; // Mybank sera les 2 bits de poids forts (2^6 = 256) transformé en (0-3) MyBank = adr >> 6; // aiguiller vers la bonne bank switch (Mybank) { case 0: MyBank &= 0x3F; // MyBank qui maintenant ne sert plus // est utilisé pour l'adresse 0-63 Ram1[MyBank] = data; // la bonne bank break; case 1: MyBank &= 0x3F; Ram2[MyBank] = data; break; case 2: MyBank &= 0x3F; Ram3[MyBank] = data; break; case 3: MyBank &= 0x3F; Ram4[MyBank] = data; break; } }
Finalement j'ai trouvé. En C c'est très simple il suffit de déclarer comme suit:
#pragma rambank 0
T1[50];
#pragma rambank 1
T2[50];
après les tableaux sont accessible sans changer de bank. Ceci dit en passant je suis a la société générale et c'est vraiment de la M****
j'ai un autre problème :s
Sous CC5X je pouvais déclarer une variable global pour pouvoir l'utiliser dans une méthode sans la redeclarer mais sous hi-tech ce n'est pas possible j'ai une erreur :/
Une solution? Utiliser des pointeurs?
Bonjour
Ce que dit Dralaf est incorrect, le nombre de cycle ecriture/effacement, sur un 16F87XA, est de 1 000 000 pour l'EEprom interne, contre 100 000 pour la flash, de plus la flash des 16F87XA (les plus recents) exige une ecriture par groupe de 4 mots ce qui n'est pas le cas avec un 16F87X.
Un pic dont l'EEprom est morte peut encore être utilisé, ce n'est pas le cas si la flash est morte.
Personnellement, j'ai utilisé une EEprom externe, une 24LC512 pour stocker plus de 65 000 octets, avec la methode ecriture par page c'est tres simple et rapide.
Gilles
Code:sizeof(int)= ???
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
