Discussion :

[f-leb]

Si vous êtes férus d'Arduino et que vous souhaitez vous mettre au langage C, ce tutoriel est peut-être fait pour vous :

Programmer l'Arduino en langage C

ou comment apprendre la programmation du microcontrôleur Atmel AVR de l'Arduino en véritable langage C, au cœur des registres de la puce, sans passer par l'EDI standard, et sans utiliser le fameux « langage Arduino ».

J'adore jouer avec ma carte Arduino UNO et son environnement de développement graphique. C'est un outil qui facilite grandement la programmation en dissimulant une foule de détails. D'un autre côté, je ne peux m'empêcher d'observer dans les coulisses de l'EDI, et j'ai senti le besoin de me rapprocher des aspects matériels, de m'écarter des bibliothèques fournies par défaut et de l'EDI Java pour compiler directement mes programmes à partir de la ligne de commandes.

Francesco Balducci

Du code source en langage C jusqu'au téléversement dans la carte Arduino avec la chaîne de compilation avr-gcc.

Bonne lecture, et bon développement, en vrai langage C...

Retrouvez la série de tutoriels Apprendre à programmer l'Arduino en langage C par Francesco Balducci
Les meilleurs cours et tutoriels pour apprendre à utiliser la carte Arduino
Retrouvez les meilleurs cours et tutoriels pour apprendre les systèmes embarqués

[Vincent PETIT]

Merci pour ce tuto Fabien !
Voilà qui pourrait intéresser les copains du forum C qui n'ont qu'un petit pas à franchir pour jouer sur un microcontrôleur.

Sur le rôle de la macro _BV

En C, on a l'habitude d'utiliser les opérateurs d'affectation bit à bit |= et &= pour lire ou écrire dans une variable, mais le compilateur reconnaît ce genre d'accès et produit un code d'assemblage optimisé dans le cas d'opérations bit par bit, sans opération de lecture supplémentaire.

Tu es entrain de me faire peur car je n'avais jamais constaté de différence entre :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRB |= _BV(DDB5);

et

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRB |= 0x20;

Je vais regarder ça de prés et surtout les options d'optimisation de mon compilateur car si la lecture ne se fait pas dans le cas de :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRB = DDRB | 0x20;

J'espère bien que DDRB soit lu puis aille dans un registre de travail pour se voir appliqué le OU 0x20 et enfin être remis dans DDRB

A bientôt,

[f-leb]

Salut Vincent

Tu es entrain de me faire peur car je n'avais jamais constaté de différence entre :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRB |= _BV(DDB5);

et

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRB |= 0x20;

Je ne te suis pas, finalement cela revient au même, non ?

http://www.nongnu.org/avr-libc/user-...5a93800b3d9546

#define _BV(bit ) (1 << (bit))

#include <avr/io.h>

Converts a bit number into a byte value.

Note
The bit shift is performed by the compiler which then inserts the result into the code. Thus, there is no run-time overhead when using _BV().

[Vincent PETIT]

Je ne te suis pas, finalement cela revient au même, non ?

Oui oui mais lorsque j'ai lu cette phrase, qui introduit _BV dans le tuto :

En C, on a l'habitude d'utiliser les opérateurs d'affectation bit à bit |= et &= pour lire ou écrire dans une variable,

Jusque là pas de soucis nous sommes d'accord.

Mais a partir du mais justement :

mais le compilateur reconnaît ce genre d'accès et produit un code d'assemblage optimisé dans le cas d'opérations bit par bit, sans opération de lecture supplémentaire.

Ça laisse penser qu'il y a un problème et que _BV est né de ça !

Je me suis donc interrogé sur ce point.
Je sais que sur GCC, et même d'autre compilateur, les options de compilations peuvent avoir un effet désastreux en programmation embarqué car des variables en attentes du matériel ou d'un registre peuvent être éliminées du source car le compilateur pense qu'elles ne servent a rien. Certain flag dans des registres se mettent a 0 après une simple lecture et là aussi certain compilateur, voyant dans le code un simple lecture, vont essayer d'optimiser et malheureusement ça fini en "comme la variable ne fait que lire une adresse et ne fait rien de cette valeur, pas de calcul ni d'opération" bah c'est qu'elle ne sert pas au final !

A+

[f-leb]

bon, je ne suis pas assez calé

je n'ai pas compris ce "mais" comme ca, mais c'est peut-être un souci dans la traduction :

In C we use the bitwise “|=” and “&=” assignment operators, which usually read and write a variable, but the compiler recognizes those kind of accesses generating optimized assembly in case of bit-wise operations, and there is no read operation involved.

[neuneutrinos]

Dans ma tête quand je vois ça :
une voix me dit "mais pourquoi il n'utilise pas un xor ?"
A part ce détails des plus utile...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

_BV(bit) 1<<(bit)

DDB5 est une constante
1<<(DDB5) peut être déterminé lors de la compilation comme une constante, et donc ne pas d'opération superflue lors de l’exécution.( pas d'opération de décalage inutile lors de l’exécution )

Je l'ai compris comme ça.

[Vincent PETIT]

c'est peut-être un souci dans la traduction :

Non non pas du tout !

C'est que j'ai pensé a un problème très sournois du genre :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
int i;
 
interrupt (TIMERA0_VECTOR) irq_routine(void) // a chaque débordement du TIMERA
{
    i = 42;
}
 
void func(void) // fonction attendre
{
    i = 0;
    while (i == 0); 
}

1. Lorsque la fonction "func" sera appelée, "i" va être mis dans un registre de travail pour manipulation, donc ce registre sera mis à 0 puis testé avec la valeur 0 dans une boucle.
   
   
2. Puis le TIMERA va déborder et la routine d'interruption va s'exécuter en stoppant tout (on empile), l'emplacement mémoire de "i" va valoir 42.
   
   
3. Enfin, on sort de l'interruption, on retourne dans le code de la fonction "func" (on dépile) et le registre qui valait 0, avant, et qui est testé avec la valeur 0 n'a aucune raison de se mettre à jour avec la nouvelle valeur de "i", soit 42 !

Et c'est la boucle infinie.

Pire encore, si jamais les options d'optimisation sont activées alors GCC va voir tout de suite une comparaison avec la valeur 0 et un registre qui est mis a 0 .... et il risque de retirer la condition qui pour lui ne sert strictement a rien et c'est vrai puisqu'on teste 0 avec 0. Ce problème se règle facilement avec le mot clé volatile qui va forcer le compilateur a aller voir l'emplacement mémoire de la variable "i" à chaque vérification ou manipulation.

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

volatile int i;

D'où la frousse que j'ai eu en voyant ce _BV(bit) que je ne connaissais pas et la phrase :

En C, on a l'habitude d'utiliser [...], mais le compilateur reconnaît ce genre d'accès et produit un code d'assemblage optimisé dans le cas d'opérations bit par bit, sans opération de lecture supplémentaire.

J'ai pris le "mais" dans le sens attention alors que ce n'est pas ça... bref c'est rien, c'était juste un peu de paranoïa mais je me soigne C'est rien Vincent, ce n'est qu'une macro, ça va aller