Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : Jérémy
Mystere avec MikroC (encore)
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonsoir,
Voulant recuperer d'autres info sur mon capteur OWS DS18B20
( ID code sur 48bits, valeur thermostat MSB et LSB ..)
des que je rajoute l'init d'un Byte .. TH1=0 MSB du thermostat
mon programme reste planté apres les lignes de presentation affichées ...
si je commente l'init de cette variable .. c'est OK
la RAM est à 92% d'apres les STATS ( mais qui sont fausses ,car ne tiennent pas compte de la RAM utilisée par le compilo lui meme )
Déja signalé à MikroE .. mais c'est comme ça.
La RAM reste au meme niveau avec ou sans l'init du seuil TH1.
J'ai donc ouvert un post surmikroC forum à ce sujet ..
avec le projet MikroC zipé.
DONC PRUDENCE lorsqu'on programme avec des resoosurces RAM ( ou ROM) pres des limites maxi
à suivre ...
Voulant recuperer d'autres info sur mon capteur OWS DS18B20
( ID code sur 48bits, valeur thermostat MSB et LSB ..)
des que je rajoute l'init d'un Byte .. TH1=0 MSB du thermostat
mon programme reste planté apres les lignes de presentation affichées ...
si je commente l'init de cette variable .. c'est OK
la RAM est à 92% d'apres les STATS ( mais qui sont fausses ,car ne tiennent pas compte de la RAM utilisée par le compilo lui meme )
Déja signalé à MikroE .. mais c'est comme ça.
La RAM reste au meme niveau avec ou sans l'init du seuil TH1.
J'ai donc ouvert un post surmikroC forum à ce sujet ..
avec le projet MikroC zipé.
DONC PRUDENCE lorsqu'on programme avec des resoosurces RAM ( ou ROM) pres des limites maxi
à suivre ...
Mystere avec MikroC (encore)
Hello,
il faut vérifier si ton nom de variable TH1 ne masque pas une autre variable système ou constante pré-définie
pour en être sûr, tu peux renommer ta variable avec un autre nom, par exemple myTH1
il faut vérifier si ton nom de variable TH1 ne masque pas une autre variable système ou constante pré-définie
pour en être sûr, tu peux renommer ta variable avec un autre nom, par exemple myTH1
Mystere avec MikroC (encore)
Mystere avec MikroC (encore)
ça peut ne pas être l'affectation qui plante, mais l'allocation d'une variable. le simple fait de déclarer une variable n'est pas suffisant pour l'allouer, la déclaration est éliminée par l'optimiseur si la variable n'est pas utilisée.
il peut se produire un débordement à l'exécution si la mémoire disponible n'est pas suffisante, en particulier en cas d'appels imbriqués, mais ceci c'est au développeur de l'anticiper : le compilateur ne simule pas l'exécution du programme, même sur de plus gros systèmes.
est-ce que tu peux poster le code minimum compilable qui fait sortir le problème ?
il est même possible que tu trouves l'origine du problème en réduisant le code dans cette optique.
il peut se produire un débordement à l'exécution si la mémoire disponible n'est pas suffisante, en particulier en cas d'appels imbriqués, mais ceci c'est au développeur de l'anticiper : le compilateur ne simule pas l'exécution du programme, même sur de plus gros systèmes.
est-ce que tu peux poster le code minimum compilable qui fait sortir le problème ?
il est même possible que tu trouves l'origine du problème en réduisant le code dans cette optique.
Mystere avec MikroC (encore)
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
brunog a écrit :ça peut ne pas être l'affectation qui plante, mais l'allocation d'une variable. le simple fait de déclarer une variable n'est pas suffisant pour l'allouer, la déclaration est éliminée par l'optimiseur si la variable n'est pas utilisée. .
Sans declaration de variable TH1 et TL1 .. programme OK RAM utilisée 219 bytes
Declaration de variable ..sans l'initialiser ... programme OK RAM utilisée 219 bytes
Initialisation de TH1=0 dans le main programme .. programme se plante RAM utilisée 219 bytes .. inchangée ??
Aucune error ou warning ...dans les messages de compil.
initialisation de TL1=0 dans le main programme .. programme se plante RAM utilisée 221 bytes .. modifiée ! ?
Aucune error ou warning ...dans les messages de compil.
l' init de TH1=0; n'augmente pas la taille RAM occupée ?
l'init de TL1=0; augmente la taille ram occupée de 2 bytes ?
c'est quoi ce bins !
avec MAXLEN1 =70 pour declaration char TEXTE[MAXLEN1]; (TEXTE utilisé!) .. programme OK sans usage de TH1=0;
il faut que je descende à MAXLEN1=56 pour que le programme soit OK apres l'init TH1=0; Taille RAM occupée 205 bytes
il y a un probleme de Bank page quelques part !
mon projet mikroC
nota : resultat Statistiques douteuses ! surtout avec la notion de WORD pour la RAM ?
WORD pour la ROM ..OK
Compilo Optimisation levem Four (4)
Test SANS optimisation ..idem
Ma conclusion :
Prendre des PIC 18F evolues avec beaucoup de RAM (et ROM)
avec gestion lineaire (des acces) RAM
.. c'est nettement plus confortable d'utiliser un 18F87J50 ou 18F47J53 avec bootloader HID.
pour ne pas perdre du temps sur ce genre de problematique ..
J'attends un retour de MikroE !
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Mystere avec MikroC (encore)
sur le pic12f1840, le maximum de mémoire consécutive dans une banque est de 80 mots : en déclarant une chaîne de 70 caractères, tu es très près de la limite
après un rapide examen du code C :
la fonction Raz_Buffer1() provoque un débordement car buffer1 est dimensionné à 40 alors que MAXLEN1 est égal à 64 :
....
de plus dans interrupt(void) rien ne garantit que le compteur i1 ne dépasse pas la taille maxi de buffer1 :
et il existe une autre déclaration locale de i1 qui masque la déclaration globale :
...
après un rapide examen du code C :
la fonction Raz_Buffer1() provoque un débordement car buffer1 est dimensionné à 40 alors que MAXLEN1 est égal à 64 :
Code : Tout sélectionner
#define MAXLEN1 64
volatile unsigned char buffer1[40];
volatile unsigned char * p1;
char TEXTE[MAXLEN1];
....
Code : Tout sélectionner
void Raz_Buffer1()
{
buffer1[0]=0;
Index1=0;
Flag_Buffer1 =0;
// nettoye le buffer
for(Index1=0;Index1<MAXLEN1;Index1++)buffer1[Index1]=0;
c1=RCREG;
i1=0;
Index1=0;
c1=0;
RCIE_bit = 1;
p=0;
}
de plus dans interrupt(void) rien ne garantit que le compteur i1 ne dépasse pas la taille maxi de buffer1 :
Code : Tout sélectionner
buffer1[i1]=c1;
Index1=i1;
i1++;
et il existe une autre déclaration locale de i1 qui masque la déclaration globale :
Code : Tout sélectionner
volatile unsigned int i1;
...
Code : Tout sélectionner
void Write_Msg_Eeprom(unsigned char Adr,const char * d1)
{ int i1 ,i;
Mystere avec MikroC (encore)
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Bravo,
le bug etait bien sur le debordement lors du RAZ buffer1 ..
j'avais reduit cette taille voyant que j'approchais de 92% de RAM utilisé , en oubliant cette init commune avec le define MAXLEN1..
J'ai remis mon MAXLEN1 à 50 bytes pour TEXTE te Buffer1 .. c'est OK
la taille rRAM utilisée reste inchangée puis que 60+40 => passé à 2x50
0 1144 Used RAM (bytes): 219 (91%) Free RAM (bytes): 21 (9%) Used RAM (bytes): 219 (91%) Free RAM (bytes): 21 (9%)
La variable i1 dans void Write_Msg_Eeprom(unsigned char Adr,const char * d1)
est en local , puisque definie dans la fonction. et ne devrait pas interferer avec celle utilisée dans l'interuption
je vais quand meme la renommer i2 .. ça mange pas de pain..
merci encore de ton aide .
le bug etait bien sur le debordement lors du RAZ buffer1 ..
j'avais reduit cette taille voyant que j'approchais de 92% de RAM utilisé , en oubliant cette init commune avec le define MAXLEN1..
J'ai remis mon MAXLEN1 à 50 bytes pour TEXTE te Buffer1 .. c'est OK
la taille rRAM utilisée reste inchangée puis que 60+40 => passé à 2x50
0 1144 Used RAM (bytes): 219 (91%) Free RAM (bytes): 21 (9%) Used RAM (bytes): 219 (91%) Free RAM (bytes): 21 (9%)
La variable i1 dans void Write_Msg_Eeprom(unsigned char Adr,const char * d1)
est en local , puisque definie dans la fonction. et ne devrait pas interferer avec celle utilisée dans l'interuption
je vais quand meme la renommer i2 .. ça mange pas de pain..
merci encore de ton aide .
Mystere avec MikroC (encore)
Mystere avec MikroC (encore)
Mystere avec MikroC (encore)
content que ton problème soit résolu !
j'utilise MikroC depuis sa naissance en 2005, il a fait rapidement des progrès considérables grâce à la qualité de ses concepteurs et également grâce à la participation de ses utilisateurs, c'est un produit très stable de très bonne qualité, je pense que mon dernier rapport de bug remonte autour de 2010...
j'utilise MikroC depuis sa naissance en 2005, il a fait rapidement des progrès considérables grâce à la qualité de ses concepteurs et également grâce à la participation de ses utilisateurs, c'est un produit très stable de très bonne qualité, je pense que mon dernier rapport de bug remonte autour de 2010...
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 37 invités