Bonjour,

En ASM, je faisais ceci :



J'enregistrais les 64bits de mon capteur en les stockant dans "rom_code1".
Et grâce aux "EQU", je déclarais renommais les 2 octets dont j'avais besoin.

Même si je n'oublie pas la remarque de Stéphane au sujet de la fonction ci-dessous avec les pointeurs, je voudrais pouvoir déclarer ces 2 octets afin de pouvoir les lire ensuite :



Hier j'ai essayé en ajoutant ceci dans le .h :



Le compilo l'a pris, mais rien de plus en mode débug.

Et là, je viens de trouver ceci sur un site :

Citation :

Et en l'adaptant dans ma logique :



ça vous parait correct ?

oula ça mélange pleins de trucs, tu me mets en limite de compétence C là...
ca je suis étonné que le compilo le prenne (je découvre des choses) mais je doute que ce soit ce que tu voulais ecrire

Si tu voulais dire var3 c'est la même chose que au8page_data[3] alors il faut écrire
(sans le =, sans le ; et sans les espaces qui délimites les paramètres du define

tu peux alors ecrire dans ton code des choses comme
qui est la même chose que


mais la notion de tableau étant importante dans ton code il semble plus lisible/pratique de faire ceci
l'indice du tableau devient plus parlant (tu remplaces un nombre par un nom qui représente quelquechose) tout en gardant avant le nom du tableau qui lui aussi est utile à la compréhension (sinon tu ne sais plus que c'est dans un tableau)

Aprés autre sujet avec l'initialisation d'un tableau
ne signifie pas "voici le nom à donner aux 8 cases de mon tableau"
cela est équivalent à

Aïe pardon !

J'ai réécris ce code de mémoire. En effet, le compilo l'a pris comme ceci :



Le compilo m'aurait surement envoyé bouler avec le "=" et le ";".

Bon là pour le coup, je trouve cela plus simple avec l'ASM

Les valeurs de chaque élément du tableau, ce n'est pas moi qui vais les choisir. Ce sont les 8 octets rom_code que le capteur va me renvoyer. Et je devrais m'en servir régulièrement afin de l'interroger (adressage quoi).

Je reprend mon exemple concret et réel :



Si je te suis bien, je peux arriver à faire la même chose en faisant :



Ce qui pourrait me permettre de vérifier le CRC par la suite en faisant un truc du style :



Tu crois que je comprend le truc ?

Je viens de trouver ceci :



Ces 2 lignes sont équivalentes, sauf que pour la 2ème, puisqu'il s'agit d'un pointeur visant la 1ère case, je peux peut-être faire :



Si ça ça marche, je trouve le truc un peu bizarre dans la mesure ou j'ai l'impression que c'est une nouvelle variable ...

Beaucoup de notions dans tout ce que tu nous montre dans ce post...

Pour dire vrai je ne comprends pas trop le besoin donc j'ai du mal à te dire quoi faire exactement, je me contente de corriger tes erreurs et de rebondir dessus pour expliquer ce que tu as écrit.

là avec le * tu nous parles de "pointeurs".
J'ai mis très longtemps à comprendre perso, ma formation mécano devait être allergique . C'est Maverick dans son superbe article ici qui m'a enfin permis de comprendre ; peut être ce que tu cherches... (explique nous en français sans code ce que tu veux faire sinon)
http://www.68hc08.net/articles.item.1 ... teurs-meme-plus-peur.html

En gros tu manipules non pas des valeurs mais l'adresse où se trouve les valeurs.

Je comprend la notion de pointeur en C (et d'ailleurs, je crois que c'est inévitable quand à leur utilisation).

J'ai déjà lu cet article, très intéressant, dommage qu'il n'y est pas la deuxième partie...

Je vais essayer d'être plus explicite ;

1°) Je reçois mes 8 octets rom code issu du capteur dans un tableau de 8 cases déclaré comme ceci : "U8 au8page_data [8]".
Je ne modifierai jamais ces valeurs.

2°) La valeur de l'octet contenant le CRC se range automatiquement dans "au8page_data [7]", soit la 8ème case.

3°) Maintenant, afin de vérifier que les 7 octets contenus dans les case "au8page_data [0 à 6]" ne comportent pas d'erreurs, je dois calculer moi même le CRC de ces 7 octets et de le comparer avec l'octet du CRC reçu.

4°) Il n'est pas confortable, à chaque fois que cela est nécessaire, d'appeler une fonction effectuant ce calcul en faisant :


Mais plutôt :


D'où l'intérêt de renommer "au8page_data [7]" en "crc_ROM"

De même, dans la suite de la transition, je devrais lire et interpréter 9 octets.


En asm, c'est un truc vraiment tout con, une histoire de labels souviens toi :

Ben là c'est tout con pareil

Pas d'espace entre le nom du tableau et le [

Mais pour ce que tu veux faire ce n'est pas la bonne méthode, il y a bien mieux en C.

La fonction CalculCRC tu lui donnes l'adresse de début des données et le nombre d'octets à prendre en compte dans le calcul


Que ce soit pour le tableau ROM ou pour chacune des mesures par la suite tu utilises la même fonction en lui passant l'adresse du tableau et le nombre d’octets à prendre en compte

ensuite tu fais
Pour tester le CRC

Après pour manipuler les octets de la trame lu périodiquement tu as bien mieux qu'un define qui donne un nom à chaque octet

C'est soit un define qui reprend la syntaxe a rallonge nécessaire pour avoir le unsigned short formé par 2 octets du tableau


Soit carrément une union de structure (on en a parlé l'autre jour) qui te permettra de manipuler tes 8 octets
- soit comme un tableau de 8 octets (dans ta fonction de lecture)
- soit comme une structure qui contient un U16 u16temperature, un U16 u16machin un U8 u8conf, 2 octets qui servent à rien et un octet U8 u8CRC. Tu peux manipuler la température comme un u16 directement après, sans calcul ni rien.

Ça ça dépend des goûts et des couleurs. Perso je préfère la solution union de structure pour simplifier les syntaxes après, Yvan se sert jamais d'unions de structures...

En tous cas ce qui est certain c'est que si tu penses à quelquechose de plus ergonomique en ASM, c'est soit que t'as pas pigé un truc, soit que tu ne sais pas encore que ça existe !

... ou soit que je suis un génie ! lol j'aime bien ton mot de la fin ... je rentrerai pas dans ce débat ASM vs C. Tout ce que je sais, c'est que pour l'instant le C m'emm....e !

Bon donc la réponse à :


Serait :



Je prend note des fonctions que tu viens d'écrire.


Et tu sais David, je ne vois pas trop de différence d'érgo entre l'ASM et le C, si l'on admet le code ci-dessus

Pour le moment tu en es à faire ne C ce que tu faisais en ASM...tu comprendra mieux quand les premiers trucs marcheront et que tu passera aux fonctionnalités d’après...

Salut,

meme si je suis silencieux et je ne vais pas vous faire avancer mais depuis le debut je suis les deboires et les avancées de notre ami Dinastar et j'avouer que je suis avec interré par toute cette lecture car j'apprends des tonnes de choses meme si en ce moment je ne peu pas les appliquer

alors merci pour toutes ces notions de C qui j'espere servirons aussi a d'autres !

Pat