Bit de controle en attente : Logique et Physique

[huasca]

@ J-M-L : ok , merci ! Pour & : je cherchais un angle de vue sur le fameux BIT 0 mais mon hypothese n'a pas tenue longtemps

@ trimarco232 : Et oui , en plus d'etre une partie importante du processus , ce petit bout de code est une epreuve pour un neophyte

La possibilité de voir le bas niveau est juste essentielle , il faut que je trouve comment faire !

[J-M-L]

quant au non moins fameux << , qui ressemble à s'y méprendre à une instruction, est plutôt une directive destinée au préprocesseur (la preuve par l'assembleur)

oui et non << est une instruction à part entière pour le compilateur. Dans ce cas particulier, comme le résultat est calculable lors de la compilation puisque tout est constant, le préprocesseur remplace l'expression par un littéral qui est ensuite utilisé par le compilateur pour générer un code optimisé.

si vous aviez mis PLOCK dans une variable de type volatile, le compilateur n'aurait pas pu faire l'optimisation mais le code aurait été tout aussi fonctionnel

[huasca]

Bonsoir , je reviens sur le sujet après avoir trouvé une explication dans un .pdf orienté robotique.

La voici :

" Comment faire pour passer le n`eme bit du registre x à 1 sans modifier les autres bits?

Le registre x est de la forme (y,y,y,n`eme bit,y,y,y,y) où y=0 ou 1.

Il suffit de savoir que (y OU 0)=y et que (y OU 1)=1.
Il suffit donc de faire x OU(0,0,0,1au n`eme bit,0,0,0 , 0 ) pour obtenir le registre x identique sauf le n`eme bit qui est passé a 1.
Ceci se fait en C par l'instruction :

x|=(1<<n) "

source : http://les-electroniciens.com/sites/default/files/cours/programmationavr.pdf

[trimarco232]

Bonjour,
exact,
et pour faire passer à 0 le bit n c'est :

x&= ~(1<<n);

[J-M-L]

Bravo vous avez compris

Maintenant pour raccrocher cela à votre sujet il suffit de remplacer n par PLOCK qui est le nom d'une constante prédéfinie donnant le "petit nom" du bit en question

Attention - histoire d'ajouter à la confusion - bien que cette approche soit correcte dans 99,9999% des cas - le fonctionnement n'est pas toujours identique : certains registres ATMEL au niveau matériel sont traités comme des bascules en écriture  - c'est le cas de PIND par exemple qui par le simple fait d'écrire un 1 sur un bit bascule la valeur de ce bit (donc ne met pas un 1 dedans mais inverse la valeur qui était dedans)

c'est un cas très spécial - la doc arduino dit que ce registre est en lecture seule mais la doc ATMEL explique un peu plus son comportement

[huasca]

Je la croise dans tout les setups que je lis ça et là , c'est en fait une syntaxe ultra courante !

Je cherche maintenant un moyen de sortir les fonctions en assembleur pour pouvoir les lires à l'ancienne.

Est-ce que l'IDE Arduino dispose de l'option ?

[_pepe_]

Supprimé

[huasca]

Je fais partager des fois que..


ok , donc je sauve mon croquis , j'ouvre un term ( OSX ) et j'invoque GCC avec ce qu'il faut d'options pour avoir mes dump ?

Apres essai , gcc m'indique qu'il ne connait pas l'extension .ino donc impossible d'obtenir les chemins des fichiers temporaires par ce biais...
(nb : le .ino , mystère à résoudre plus tard )

Direction les préférences de l'IDE et je demande les détails durant la compilation.
A la fin , dans la console , j'obtiens l'adresse du fichier ELF ( sous OSX et en 1.0.5 : /var/folders/... )

Je rejoins le répertoire avec un terminal et lance avr-objdump :

avr-objdump -d HelloWorld.cpp.elf

Et là , miracle !!!     >> j'ai mal aux yeux !

J'en profite pour tenter de désassembler la fonction qui me posait problème : il me faut compiler main.cpp et obtenir les infos.
Petite deception : man gcc : pas de man... je croyais que c'était obligatoire ?

>> https://c.developpez.com/cours/mode-emploi-gcc/

En fait c'est gcc --help

Vu le nombre d'options le manuel doit faire 3 gigas !!! je comprends pourquoi personne ne veut y mettre les doigts !

Je trouve cpp... 
.
.
.
.
.
.
.
.
( whaou , y'a du monde la dessous )

> merci pour le coup de pouce !