syntaxe en C

[cubitus_54]

Bonsoir,

j'ai assez peu d'expérience en C.
Je me casse la tête pour comprendre un programme en C pour Arduino qui a pour but de gérer un lecteur RFID
Je poste ici, car c'est un problème se syntaxe et pas d'électronique.

J'ai la variable "SendData" qui me pose problème.

elle est déclarée dans la fonction MFRC522_ToCard :

uchar MFRC522_ToCard(uchar command, uchar *sendData, uchar sendLen, uchar *backData, uint *backLen)

elle est utilisée comme paramètre pour appeler une autre fonction :

		Write_MFRC522(FIFODataReg, sendData[i]);

Cette valeur va être envoyée à la carte à l'adresse FIFODataReg ...

Ce que je ne comprends pas c'est que cette variable qui semble être un tableau "sendData[i]" n'est pas initialisée et nulle part dans le programme elle prend de valeurs.
Or elle doit bien avoir une valeur définie pour paramétrer la carte...

Ce la que je ne comprends plus rien...

Je pense que j’interprète mal quelque chose...

Merci
-----

[bisou10]

Ben si:

	//Writing data to the FIFO
    for (i=0; i<sendLen; i++)
    {   
		Write_MFRC522(FIFODataReg, sendData[i]);    
	}

[Jack]

Ben si:

    //Writing data to the FIFO
    for (i=0; i<sendLen; i++)
    {   
        Write_MFRC522(FIFODataReg, sendData[i]);    
    }

Tu te trompes de sens bisou10, puisque sendData est lu dans les lignes que tu cites.

Pour répondre à cubitus, le tableau est initialisé ici par exemple:

    for (i=0; i<4; i++)
    {    
		buff[i+8] = *(serNum+i);   
	}
    status = MFRC522_ToCard(PCD_AUTHENT, buff, 12, buff, &recvBits);

Le tableau est bien initialisé et c'est son adresse qui est passée par l'intermédiare de "buff".
Cette adresse est récupérée dans la fonction par l'intermédiaire de sendData qui pointe en fait sur le même tableau que buf.

A+

[acx01b]

[/code]Le tableau est bien initialisé et c'est son adresse qui est passée par l'intermédiare de "buff".
Cette adresse est récupérée dans la fonction par l'intermédiaire de sendData qui pointe en fait sur le même tableau que buf.

salut, le contenu pointé au final par sendData est initialisé là, mais ça ne dit pas quand le pointeur sendData est initialisé

[A voir en vidéo sur Futura]

[Jack]

Je rappelle que le passage de paramètre se fait uniquement par valeur en C. C'est donc là que sendData reçoit sa valeur à partir de buff

[cubitus_54]

Bonjour,

Merci pour vos réponses,

Je crois que mon vrai problème est que je ne comprends pas bien les histoires de pointeurs...
Les passages de paramètres OK

Mais les pointeurs, je me représente que vaguement le fonctionnement...

Je vais essayer de creuser la question.

[Jack]

Le fait d'avoir fait pas mal d'assembleur m'a bien servi. Lorsqu'on a bien assimilé les notions d'adressage, et en particulier l'indirect et l'indexé, la notion de pointeur semble presque naturelle puisqu'il s'agit sensiblement du même mécanisme: on n'accède pas directement à la donnée, mais indirectement par une autre donnée possédant son adresse.

On peut observer tous ces mécanismes, notamment lors du passage de paramètres, avec un bon debugger permettant la visualisation des variables.

A+

[luc_1049]

Bonjour

Vous vous attaquez à du costaud pour un début !

Si vous avez possibilité de debugger sur cible ou simuler le code mettez une fenêtre de visualisation sur sendata le pointeur qui renvoie une adresse .
A défaut d'initialisation il est à NULL.

Il serait bien que vous puissiez voir en simulation ou avec un crayon et du papier , les séquences d'appel pour suivre et comprendre comment est initialisé ce pointeur(sendata) qui pointe sur un tableau, sachant que ce tableau contient un certain nombre de valeurs dont la première est (sendata[0]) ou *(sendata+0).
Si le pointeur ne pointe sur rien c'est à dire NULL, ce qui arrive quand il n'est pas initialisé, récupérer par soft l'objet pointé *(sendata+x) donnera n'importe quelle valeur. Pour qu'il soit initialisé il faut par exemple affecté au pointeur l'adresse d'un autre tableau, (sendata =&tableau_primaire[0] ou sendata =tableau_primaire). Bien entendu comme il s'agit d'une variable de type pointeur il faut déclarer quelque part (uchar * sendata) tout comme vous le feriez pour une autre variable.
Enfin dans l'exemple il faut aussi s'assurer de l'espace mémoire pour l'objet pointé. Un pointeur est réservé lors de sa déclaration. Mais même s'il est initialisé par exemple (sendata = 0xabcdef10) rien ne dit qu'à cette adresse on pourra y écrire un certain nombre d'octets correspondant au N valeur d'un tableau. Car l'éditeur de lien peut y placer aussitôt après une variable puis une autre qui seraient écrasées alors par un bug soft. Par contre si on déclare un tableau (uchar tableau_primaire[10]) puis que l'on fait (sendata =&tableau_primaire[0]) là on est sur d'avoir 10 cases mémoire pouvant chacune contenir un octet c'est à dire un UCHAR, obtenu par *(sendata+x) pour X variant de 0 à 9. Toute tentative d'écriture avec X> 9 génèrera vraisemblablement à un moment donné un BUG. S'il n'y a pas de BUG c'est un coup de chance , c'est parce qu'il n'y a pas de variable située après la 10ème valeur de tableau_primaire.
Il FAUT DONC TOUJOURS initialiser le pointeur et S'ASSURER qu'il pointera sur une zone de mémoire disponible sinon c'est comme si vous utilisiez un paquet de graine semant des graines à la volée sur différents sillons sans vous être assuré que les sillons d'a coté vous appartienne, alors un autre jardinier passera après soit du déserbant ou une autre semence et rien ne poussera comme attendu en quelque sorte un bug de jardinage.

http://fr.wikibooks.org/wiki/Program..._effet_de_bord
cdlt

[Jack]

A défaut d'initialisation il est à NULL.

Non, toutes les variables locales, donc y compris les paramètres des fonctions, sont créées sur la pile et ne sont pas initialisées.
Seules les variables globales sont mises à 0 au lancement du programme.
Pour les paramètres, le problème d'initialisation ne se pose pas étant donné le mécanisme de passage des paramètres de le fonction appelante à la fonction appelée.

Il FAUT DONC TOUJOURS initialiser le pointeur

Absolument!

A+

[cubitus_54]

J'ai lu la description sur Wikipédia.

Je comprends mieux, c'est puissant comme système, mais c'est drôlement subtil...

J'avoue être assez d'accords avec la citation :

L'arithmétique associée aux pointeurs est sans doute ce qui a valu au C sa réputation « d'assembleur plus compliqué et plus lent que l'assembleur »

[Jack]

Je ne vois pas ce qu'il y a de compliqué dans l'arithmétique des pointeurs, si un pointeur pointe sur un entier, le fait d'incrémenter ce pointeur fait qu'il pointe sur l'entier suivant. C'est magique non? Et infiniment plus logique que se déplacer d'octet en octet.

[luc_1049]

Bonjour

Au sujet de l'initialisation du pointeur par défaut à NULL.
Une variable globale est sans intervention du codeur initialisée généralement à 0 dans le startup.ini qui est exécuté avant le main. Un pointeur global dans ce cas n'est pas alors au moins dans ce cas initialisé à NULL ?
cdlt

[Jack]

Bonjour

Au sujet de l'initialisation du pointeur par défaut à NULL.
Une variable globale est sans intervention du codeur initialisée généralement à 0 dans le startup.ini qui est exécuté avant le main. Un pointeur global dans ce cas n'est pas alors au moins dans ce cas initialisé à NULL ?
cdlt

C'est exact, au startup.ini près qui dépend des compilateurs. Le code d'initialisation des données n'est donc pas forcément accessible.
Mais si je reprends tes mots:

Si vous avez possibilité de debugger sur cible ou simuler le code mettez une fenêtre de visualisation sur sendata le pointeur qui renvoie une adresse .
A défaut d'initialisation il est à NULL.

dans ce cas sendData n'est pas globale, d'où mon intervention.

[invite936c567e]

J'ai lu la description sur Wikipédia.

Je comprends mieux, c'est puissant comme système, mais c'est drôlement subtil...

J'avoue être assez d'accords avec la citation :

L'arithmétique associée aux pointeurs est sans doute ce qui a valu au C sa réputation « d'assembleur plus compliqué et plus lent que l'assembleur »

Wikipédia n'est pas vraiment une référence objective (ni même toujours fiable), et les avis personnels y trouvent malheureusement quelquefois une meilleure place que l'exposé des faits.

La citation provient certainement d'une personne qui ne maîtrisait pas le langage C et n'en percevait pas tout l'intérêt, et qui devait peut-être se trouver dans une situation similaire vis-à-vis de l'assembleur.

Le C est plus lisible, plus simple et plus rapide à coder que l'assembleur, et continue néanmoins d'autoriser un certain nombre de manipulations de niveau "machine" inaccessibles dans les autres langages de haut niveau (Fortran, Pascal, Cobol...). Et avec un bon compilateur et/ou de bonnes pratiques d'optimisation, la vitesse d'exécution des programmes écrits en C ne doit pas être notablement inférieure à celle des programmes écrits en assembleur, tant qu'on ne touche pas au domaine réservé de ce dernier, qui concerne les particularités de fonctionnement matériel.

Bref, ce qui est énoncé dans la citation est très certainement injustifiée. D'ailleurs, par chez moi et dans les milieux professionnels que j'ai fréquentés, le C n'avait pas cette réputation, bien au contraire.


Quand on débute, comprendre et manipuler les pointeurs n'est pas une évidence pour tout le monde, loin s'en faut. Mais comme dans tous les domaines, il convient de bien maîtriser la question avant de pouvoir se risquer à donner un avis un tant soit peu pertinent.

[invite936c567e]

Concernant les pointeurs, les principales difficultés sont à mon sens :
- la compréhension des principes de l'adressage mémoire, indépendamment de sa programmation et donc du langage utilisé (cette partie est certainement la plus importante, en intérêt comme en taille, et nécessite de connaître certains principes de base du fonctionnement des ordinateurs) ;
- le point de vue et les règles particulières retenues dans le langage C, comme le comportement des opérations affecté par le typage des éléments pointées ;
- la syntaxe particulière du langage C qui peut parfois prêter à confusion, notamment l'utilisation de l'astérisque (*) pour (re-)déclarer un type « pointeur » ou pour désigner l'élément pointé, et son absence dans la désignation d'éléments traités comme des adresses (tableaux, chaînes de caractères).

Il n'y a rien d'insurmontable dans l'apprentissage des pointeurs. Mais encore faut-il ne pas rater le premier point, pour lequel la seule lecture du manuel de référence du langage reste malheureusement insuffisante.

[acx01b]

Je rappelle que le passage de paramètre se fait uniquement par valeur en C. C'est donc là que sendData reçoit sa valeur à partir de buff

???

on veut soit :

Type SendData[N];

soit :

SendData = ...

ou encore :

UneFonction(&SenData); // à suivre dans la fonction

[acx01b]

ou encore SendData est un pointeur paramètre d'une fonction, et donc il faut voir où la fonction est appelée

c'est le cas ici

et la fonction MFRC522_ToCard est appelée à plusieurs endroits, il faut donc essayer de suivre d'où vienne le 2ème param qu'on lui passe

uchar MFRC522_ToCard(uchar command, uchar *sendData, uchar sendLen, uchar *backData, uint *backLen)

appelé par exemple comme ceci :
status = MFRC522_ToCard(PCD_TRANSCEIVE, TagType, 1, TagType, &backBits);
mais aussi à 4-5 autres endroits avec d'autrs params,

en gros c'est un programme pas trivial

il fait quoi au fait ?

[Jack]

Je ne comprends pas ce que tu veux dire.

Il me semble pourtant que ma réponse était claire: le paramètre sendData est initialisé lors du passage de paramètre. Qu'est-ce qui te pose problème exactement?

PS: j'éditais mon message et je n'ai pas vu que tu venais d'en reposter un. Ne pas tenir compte de cett réponse du coup

[cubitus_54]

il fait quoi au fait ?

C'est un programme qui permet de gérer un lecteur RFID.

Dans les grandes lignes.
Il initialise le lecteur,
Il détecte le type de carte (MFRC522_Request)
Il lit le N° de série de la carte (MFRC522_Anticoll)
La fonction MFRC522_ToCard récupère les données demandées.

Merci à tous pour les explications et les remarques