Probleme de chaine de caractere

[invitee13c535c]

Bonjour,

J'ai un problème avec mes chaines de caractère,
Je programme un PIC18F2620 avec mplab, mcc18, icd3,

Suivant comment j’écris mes chaines de caractère, j'ai des problèmes,

Si j'écris:
const char INTRO_PROG[] = "test";
Lorsque le micro travaille avec cette chaine les valeurs de cette chaine sont aléatoires,
Alors que en mode debug, si je vais voire la valeur de la chaine elle n'a pas changé...

Et si j’écris
const char INTRO_PROG[] = {'t','e','s','t','\0'}
Tous fonctionne correctement,

Comment expliquer cela?
Quelle est la différence entre les deux notations?
Est ce que ça peut provenir d'un problème de pointeur?

Merci
-----

[Jack]

Lorsque le micro travaille avec cette chaine les valeurs de cette chaine sont aléatoires

Comment constates-tu cela?

A+

[invitee13c535c]

J'envoie ces chaines sur la liaison série rs232, mon hyper terminal les réceptionne et affiche a l’écran.

const char INTRO_PROG[] = "test"; // comme ça j'ai des caractères hexa sans sens; ni longueur fixe,

const char INTRO_PROG[] = {'t','e','s','t','\0'} // comme ça, ca marche, j'ai a l’écran le texte voulu;

[invite653ac363]

Salut,
Et si tu enleves le '\0' de ta deuxieme solution, est ce que tu n'a pas le même probleme ?

Ca pourrait être la detection de fin de chaine qui se passe mal sur la premiere solution.

A+

Cédric

[A voir en vidéo sur Futura]

[invitee13c535c]

Presque,
le début est bon, mais j'ai une chaine de 32 caractères a l’écran,
je travaille en tableau de caractère, mon '\0' permet de connaitre la fin,
mon programme ne marche plus du tous,

[invitee13c535c]

Le PIC18F2420 me fait la même chose,
Le problème n'est pas hard.

Merci

[Jack]

Tu n'as pas de possibilité de debugger le programme du PIC et de visualiser l'état des variables afin de voir ce qui est contenu dans le tableau?

J'avoue que le fait de retirer le 0 final permet de faire apparaitre les premiers caractères n'a aucun sens, ou alors c'est tordu.

A+

[invitee13c535c]

lorsque je debug, a un moment (aléatoire) la variable passe plus en paramètre,

{
blablabla
ma_fonction ( chaine);
blablabla
}

void ma_fonction (char * buff){
buff n'est pas bon, il ne pointe plus sur chaine,
}

[invitee13c535c]

J'ai fait un test
Si je programme que la liaison série, ( 1/10 du programme) tout marche normalement,
dans les deux cas.
quand je rajoute des fichiers, a un moment ca ne remarche plus, mais je n'arrive pas a le remettre dans un état qui marche.

Est ce de la magie?

[Jack]

tu n'as pas un warning des fois? Parce que tu déclares un tableau de caractères constants et dans ta fonction, tu passes un pointeur qui pointe sur ces caractères, ce qui pourrait permettre de les modifier et ça, le compilateur, il n'aime peut-être pas.
Essaie avec

void ma_fonction (const char * buff){

C'est un compilateur C ou C++?

A+

[invitee13c535c]

J'utilise déjà const, quand je peut le mettre je ne me prive pas (garde fou) ;
je ne l'avais pas écrie , je m'en excuse.
J'utilise un compilateur C.
il y a t'il une différence entre ces deux déclaration.
const char INTRO_PROG[] = {'t','e','s','t','\0'}
const char INTRO_PROG[] ="test";
Le micro travaille t-il de la meme façon avec ces deux déclarations?
Le const ne sert qu'a empêcher de le modifier? non? je n'ai plus le programme sous les yeux mais je regarderai le const plus sérieusement demain.

Merci A++

[Jack]

il y a t'il une différence entre ces deux déclaration.
const char INTRO_PROG[] = {'t','e','s','t','\0'}
const char INTRO_PROG[] ="test";

Non, le résultat doit être strictement le même.

A+

[invitee13c535c]

J'ai ajouté des const partout, et ca a l'aire de marcher.
Je n'arrive pas a mettre en évidence le problème, ca reste un mystère!!
Je vous tiens au courant si je trouve quelque chose.
Merci A++

[invitee13c535c]

Bonjour,

J'ai de nouveau problème,
j'ai mis mes chaines dans la ROM, maintenant plus de problème, tous s'affiche correctement.
Mais nouveau problème:
Le pic redémarre suivant les instructions que je lui demande.
// Question simple, tel que numéro de version du prog, ca fonctionne
// Question plus complexe, faisant appelle a du traitement de chaine... il redémarre.
J'ai vu qu'il y avais le registre RCON qui pourrai m'aider, mais je ne sais pas comment?
pouvez vous m'aider a comprendre ce registre?
avez vous une idée pour m'aider a trouver d'ou proviens le problème?

Merci A++

[invitef86a6203]

Le pic redémarre suivant les instructions que je lui demande.

ça ressemble a un crash de la pile ...

[invitee13c535c]

merci
comment faire pour corriger ce problème?
ce crash peut il également être a l'origine du problème des chaine de caractère?
A+

[invitef86a6203]

il faut consulter la doc pour savoir combien de niveaux sont acceptables , par exemple 8 , puis regarder combien de call sont empilés, si ça dépasse on est crashé.
Avec un compilateur c est pas toujours évident de savoir , il faut voir le code asm généré, parfois certains compilateurs ont un sytème de contrôle (stack overflow) de la pile mais c est plutôt sur des sytèmes plus gros comme un PC.
Sur le système avec des grosses piles , les données sont parfois aussi empilées lors d'un call avec un tableau en paramètre, cela dépend du microprocesseur et du compilateur, il est préférable alors de passer un simple pointeur pour économiser la pile.

[invitef86a6203]

je de jeter un oeil a la doc du 18F2620 , il a 31 niveaux de pile et un système de stack overflow qui reset le µC.
Donc ça peut être ça la source du problème.

[invitee13c535c]

Merci
est ce que 31 ca veut dire que je peux appeler 31 fonctions?
ou 31 est une taille mémoire ou est enregistré la fonction est les variables?
J'ai vu que le registre STKPTR pourrai m'aider.
par curiosité, comment la pile est géré lors d'une interruption?
Merci A++

[invitef86a6203]

Une fonction peut en appeler d'autres donc ce n' est pas évident de savoir combien en fait sont empilées.
Surtout que certaines fonctions peuvent être très gourmandes.
le registre STKPTR peut permettre de vérifier ou il en est avec un debug ou en envoyant la valeur sur un port de controle par exemple pour un débuggage non ICD, mais bon pour le stack pas evident d 'appeler une fonction qui risque de prendre du stack aussi...,

On devrait pouvoir apparement rallonger le stack puisque la doc dit qu'il est a l'adresse 0 et donc on doit pouvoir étendre la pile plus loin, puisque c est de la Ram après , à vérifier ... Je n'ai jamais utilisé ce µp..., et dans ce cas il faudrait enlever l'option de reset après over flow des 31 de base constructeur, en espérant que le STKPTR ne soit pas limité a 5 bits , LOL.
Sur les processeurs plus gros le stack est programmable , peut être que le compilateur sait le faire, avec une instruction du genre STKLEN=xx

Il semble que le stack ne puisse pas empiler de data , comme Microchip en a l'habitude d'ailleurs, bref, je n'ai pas vu de push ou pop instructions.

[invitef86a6203]

page 56 le stack est une mémoire spécifique, et donc ne doit pas être modifiable.
il disent que l'on peut empiler des datas aussi grace au registre,
Alors si le compilo empile les datas on est vite crashé, il faudrait envoyé des messages court pas plus de 16 char...voir moins, en plusieurs fois.

[invitee13c535c]

Je ne sais pas si le stack est a l'origine de mon problème, mais je met le nez dans quelque chose qui m'est inconnu,
Mplab X ide possède une doc dans "help" détaillé, je vais chercher si je trouve un moyen de résoudre mon problème;
Grand merci, A++