De l'Arduino au langage C standard avec AVR Studio

[invitedca01a58]

Hello Mourad

Whaou ! Déjà 2 Arduino MEGA 2560.
Petite question : la MEGA 2560 a-t-elle une prise ICSP ?

Intéressante, ta récupération du LCD. Avec un 2560, les pins I/O sont nombreuses. Donc on peut en consacrer un certain nombre au LCD. Avec un 328, les pins sont beaucoup moins nombreuses.
Il y a quelque temps, j'ai fabriqué une petite platine à base de ATtiny2313 avec un LCD de 2 x 16 caractères. Cette platine communique avec tout autre µC par la liaison UART (Rx/Tx). Elle sert de moniteur. Ce qui lui est envoyé s'affiche sur la deuxième ligne, alors que ce qui était écrit en deuxième ligne passe à la première ligne. J'ai écrit le programme en assembleur, d'abord parce que c'est le langage que j'utilisais jusqu'ici, mais aussi parce que la mémoire de l'ATtiny est réduite à 2k. Ce serait un beau challenge de réécrire ce programme en C.
-----

[invitedca01a58]

@ Jean-Marie:
pour tes messages d'erreur, ils sont du a des exceptions logiciels liées à l'exécutable de AVR Studio ou de ces DLLs qui les appelle.
essai de rinstaller tout avrstudio et Atmel studio et leurs plugins qui vont avec.

J'ai réinstallé Studio4 et Studio6. Studio4, je l'ai réinstallé dans un répertoire différent
Studio6 fonctionne de manière impeccable mais pour Studio4, c'est toujours la même chose.
Si je charge un programme en assembleur dans Studio4, tout fonctionne normalement, y compris en simulation. Par contre, c'est l'appel à la simulation pour les programmes C qui déclenche l'erreur.

Je viens de commander ces adaptateurs sur eBay. Cela pourrait servir si on optait pour un 128 ou un 2560.

[mkh.mourad]

@jack & Jean-Marie45 :
dans le C99 il existe ce qui est équivalent a un byte, et 2 et 4 et 8 byte:
uint8_t, int8_t sont des types BYTE (8bits).
uint16_t, int16_t sont des types WORD (16bits).
uint32_t, int32_t sont des types DWORD (32bits).
uint64_t, int64_t sont des types DDWORD (64bits).
le préfix "u" désigne des types non signés ( Unsigned).

pour l'Arduino Mega 2560, elle a deux ICSP à ce que je pense!! une pour l'ATmega2560-16AU ( le microcontrôleur principale)

icsp1.jpg

et une autre pour le ATMEGA16U2 ( microcontrôleur d'interface USB<->RS232).

icsp2.jpg

[invitee2def47b]

Je ne connais ni avr studio, ni les produits atmel, mais dans tout bon débogueur, on ne peut suivre la valeur d'une variable locale (déclarée dans une fonction) que lorsque la fonction est en cours d'exécution (en mode pas à pas) [...]
Quant aux variables statiques, elles combinent les avantages des variables globales et locales: ce sont donc des variables locales qui ne perdent pas leurs valeurs entre 2 appels de la fonction dans laquelle elles ont été déclarées.

Justement, si une variable locale est statique, on devrait logiquement pouvoir la suivre, mais tu semble indiquer que non. Ai-je bien compris?

Sinon, je commence à comprendre l'importance cruciale des variables de type volatile: cela permet d'indiquer au compilateur de ne pas réaliser des optimisations de code (qui pourraient mener à des résultats non conformes à ceux attendus). En plus de l'exemple de Jack, nous avions rencontré un cas lors du MOOC: http://pyr.ch/dokuwiki/lib/exe/fetch...temp2indoc.pdf pages1 § "Attente active"

Mais d'après ce que je lis ailleurs, il se pose aussi le problème suivant:
Les compilateurs peuvent mettre la valeur d'une variable dans un registre (comme un cache en quelque sorte) durant l’exécution d'une fonction ou routine, or si cette variable peut être modifiée entre temps dans son emplacement originel (en RAM par exemple) par une interruption (ou un autre thread le cas échéant), la valeur contenue dans le registre est obsolète ce qui peut générer des problèmes. Déclarer ce type de variable comme volatile empêche que sa valeur soit mis en cache dans un registre, ou bien si elle est quand même mise en registre sa valeur sera lue dans son emplacement d'origine (RAM par exemple) à chaque fois qu'une opération sera effectué à partir de celle-ci. (C'est l'idée principale parce que personne n'a la même explication ni la même interprétation de l'effet sur le compilateur. Ce serait intéressant de pouvoir suivre pas à pas le cheminement réel de la variable avec une sonde, mais je en suis pas sur qu'on ait besoin de ce niveau de détail à ce stade).

Les variables partagées entre le programme principal et les interruptions doivent donc être déclarées "volatile".
Je pense que cette règle doit être appliqué si une variable est stockée dans une mémoire externe accessible et modifiable un par un périphérique par exemple.

[mkh.mourad]

voici le projet LCD que j'ai fais sur mon module LCD. j'ai traduit la librairie LiquideCristal d'Arduino du c++ au c.

[hary]

voici le projet LCD que j'ai fais sur mon module LCD. j'ai traduit la librairie LiquideCristal d'Arduino du c++ au c.

Pourquoi y a t-il du C++ dans les bibliothèques Arduino ?

Je me suis fait taper sur les doigts sur un autre post pour avoir parlé de C++ pour les uC ! On m'a dit qu'il fallait s'en tenir à l'écart.
Tout celà est très déroutant.

D'ailleurs, tu l'a modifié de C++ à C ! Pour quelle raison ?

C'est désespérant tous ces outils intervenants dans la chaine et tous ces langages.
Comment voulez vous qu'un débutant arrive à gérer et faire fonctionner tout cela ensemble chez lui ?

[bobflux]

Justement, si une variable locale est statique

Si elle est statique, ce n'est plus vraiment une variable locale... son scope est local (elle est inaccessible en dehors de la fonction) mais sa valeur est globale. Et ta fonction peut ne plus être réentrante...

> on devrait logiquement pouvoir la suivre, mais tu semble indiquer que non. Ai-je bien compris?

On peut toujours suivre une variable static (même "locale" dans une fonction) car elle a un emplacement mémoire fixe. Si elle est "locale" c'est un peu plus compliqué de le trouver (mais le debugger sait le faire).

Les variables partagées entre le programme principal et les interruptions doivent donc être déclarées "volatile".
Je pense que cette règle doit être appliqué si une variable est stockée dans une mémoire externe accessible et modifiable un par un périphérique par exemple.

En gros oui, et ça comprend aussi tous les registres hard.

Mettons que tu aies un registre de timer qui s'incrémente tout seul, et tu fais :

uint32_t *ptimer = 0xblablabla;
while( *timer < valeur ) { attendre }

Si tu oublies le volatile, le compilateur va se dire que ça sert à rien de checker *timer à chaque itération de la boucle, et il va "optimiser" comme ceci :

if( *timer < valeur ) { attendre à l'infini }

Ce qui est nettement moins utile...

Ou encore, si tu essaies de bitbang une broche :

*registre_de_pin = 1;
*registre_de_pin = 0;
*registre_de_pin = 1;
*registre_de_pin = 0;

Si tu n'as pas déclaré le pointeur en volatile*, le compilateur va penser "c'est idiot de se fatiguer à écrire 4 fois de suite à la même adresse, je vais dégager les 3 premières lignes"...

[bobflux]

Je continue sur le volatile :

C'est pas juste une question de registre. Le compilateur (et le processeur si il est évolué) peuvent réordonner les instructions et les lectures/écritures mémoire à leur convenance pour optimiser la performance, tout en respectant certaines contraintes (notion de point de séquence en C). Ils peuvent aussi éliminer les écritures redondantes, par exemple une boucle qui écrit plusieurs fois à la même adresse, éliminer une écriture suivie d'une lecture de la même adresse, fusionner plusieurs opérations mémoire à des adresses qui se suivent en une seule opération pour faire un accès séquentiel plus rapide, etc.

Dans un système multicore ou multi-cpu, comme un PC ou un LPC43xx, l'autre cpu peut modifier ta mémoire dans ton dos...

Toutes ces optimisations respectent une contrainte assez simple : il ne faut pas que ça change le résultat, mais en faisant l'hypothèse que le code en cours d'exécution est le seul à pouvoir modifier la mémoire qu'il accède. Si cette hypothèse est fausse, on ne peut plus réordonner, éliminer, etc.

Le mot-clé volatile informe simplement le compilateur du fait que la variable n'appartient pas vraiment au code en cours d'exécution.

Sur un cpu basique (genre AVR), le compilateur se contentera de ne pas éliminer ni réordonner les accès mémoire sur la variable en question.

Pour un cpu évolué (genre ARM, ppc, x86, etc), le compilateur va aussi utiliser des instructions spéciales, par exemple :

- barrière mémoire qui indique au processeur qu'il doit finir les accès mémoire précédents la barrière avant d'entamer les accès mémoire suivant la barrière
- instructions spéciales IO, qui ne sont pas réordonnées et ne passent pas par la mémoire cache
- etc.

[bobflux]

Pourquoi y a t-il du C++ dans les bibliothèques Arduino ?

Parce que c'est plus pratique.

> Je me suis fait taper sur les doigts sur un autre post pour avoir parlé de C++ pour les uC ! On m'a dit qu'il fallait s'en tenir à l'écart.

Tu as rencontré un idiot.

> Tout celà est très déroutant.

C'est très simple.

Si on utilise toutes les features évoluées du C++, qui sont nombreuses et extrêmement complexes, on peut faire un code monstrueux, laid, et plus lent que si on l'avait fait en python.

Par contre, même pour un uC tout basique comme un AVR, on peut utiliser certaines features bien pratiques du C++ ne serait-ce que pour avoir un code plus propre, des check à la compilation, etc. Par exemple, des petits templates, du RAII si on a du nettoyage à faire, des classes pour organiser le code, etc. C'est bien pratique.

Le C++ est juste un outil. Il faut l'utiliser pour ce qu'il fait bien, et pas pour ce qu'il fait mal (tout ce qui a le mot "runtime" ou "dynamique" dedans).

[invitedca01a58]

@ Mourad
Merci pour ton code LCD.
J'ai fait un essai de compilation avec Studio6. J'ai des erreurs sur "cli" et "sei" (undefined reference). Mais c'est pas grave. Le code est encore beaucoup trop compliqué pour que j'arrive à m'y retrouver.

@ hary
Tu n'es pas le seul à ramer.
Lorsque j'ai commencé l'assembleur, il me semble que les choses ont été bien plus faciles. En assembleur, on ne fait que tester des bits ou des octets et modifier des bits ou des octets. La programmation consiste simplement à organiser et à savoir ce qu'on fait de ces bits et de ces octets.
En langage C, il existe des bouquins mais il s'agit d'un C mal adapté aux microcontrôleurs. On trouve des bouquins pour Arduino mais je n'ai pas trouvé de bouquin ou de site consacré au C de AVR-GCC et AVR-LibC. Tout ce qu'on trouve ce sont des pages isolées de sites Internet.
HULK28 avait commencé une superbe initiation (C party). Malheureusement, il a fallut qu'un inconscient vienne se plaindre que cela n'allait pas assez vite. Du coup, claquage de porte !

[mkh.mourad]

@Jean-Marie45: sur mon code dans le fichier main.c j'ai effacé un include sans faire attention.
#include <avr/interrupt.h> // pas sur de l'ortographe
@hary: le langage le plus proche du processeur est l'assembleur. C'est un langage bas niveau, dificile a lire un code de plusieurs ligne pour un debutant, et il manipule dirrectement les ressources du microcontroleur comme les registes généraux et le registre d'état, le registre du poiteur de stack ...etc. il a acces a tous les instructions élémentaire s du processeur.
Le langage C est plus évolué et plus proche du langage humain que celui des processeurs. Mais reste plus adapter a la programation système et la programation du materielle que le C++.
Un code en C++ est presque du C s'il n'utilise pas les classes orientées objet. Parmis Les avantages du c++ sont les classes, elles simplifie la programmation et rendent le code plus portable. Ces avantages sont au détriment des ressources du système cible. Un microcontroleur c'est pas un pc.
Si tu ecris un code de blink en arduino qui utilise des fobctions et des classes ecritent en c++, et tu le compares à un code ecris en pur C, tu verras la simplicité du c++. Mais apres la compilation: le code écrit en c est plus petit que celui en c++.
D'ailleurs beaucoup de compilateurs support que l'assembleur et le c. Si le c++ est present, il n'est supporté que partiellement.
La librairie d'AVR est ecrite en c et non en c++, par contre Arduino, parce qu'il cible la simplicité du code et évite la complexité côté hardware, il est codé en c++.
Avr Studio ne suporte que le c, pas de c++. Par contre l'atmel studio le peut.
Pour nous arduino etait le premier pas de débutant. Ce threads a comme but de passer de arduino (c++) à avr_libc (que du c).

[invitedca01a58]

@ Mourad
J'ai ajouté #include <avr/interrupt.h> à ton programme. Il compile maintenant sans problème. Merci, Mourad.

----------------------------------------

Par ailleurs, pour Studio4, j'ai essayé de réinstaller WinAVR-20100110-install.exe. Je n'ai plus d'erreur en lançant Debug.

Mais je ne dois pas encore crier trop vite victoire. En effet, après 10 minutes d'essai, Studio4 s'est fermé sans crier gare.
Je l'ai relancé, mais la commande Debug provoque à nouveau l'erreur et une nouvelle réinstallation de WinAVR n'y change rien !

[mkh.mourad]

Merci Jean-Marie.
Chez moi je travaille avec AtStudio 6.2. Je vais essayer avec AVR STUDIO 4.18 pour voir quand je serai chez moi le soir.

[invite03481543]

HULK28 avait commencé une superbe initiation (C party). Malheureusement, il a fallut qu'un inconscient vienne se plaindre que cela n'allait pas assez vite. Du coup, claquage de porte !

Bonjour Jean-Marie,

en fait je n'ai pas abandonné cette initiation, mais cela réclame un temps dont je ne dispose plus vraiment depuis quelques mois, là je suis présent encore quelques jours mais ensuite je ne sais pas quand je reviendrai.
J'ai avancé pas mal malgré tout, mais je posterai d'un coup la globalité, pour éviter ce qui s'est passé avec les premières pages éditées...
La notion de temps est quelque chose de difficile à accepter sur les forums, où la plupart oublie trop souvent que tout ce que nous faisons, comme dans la rubrique des projets, est pris sur note temps libre, autrement dit sur le temps que nous souhaitons aussi passer avec nos familles prioritairement.

Voilà pourquoi j'ai décidé de faire une pause avec ce sujet pour le moment, mais temporairement.

@+

[Jack]

@jack & Jean-Marie45 :
dans le C99 il existe ce qui est équivalent a un byte, et 2 et 4 et 8 byte:
uint8_t, int8_t sont des types BYTE (8bits).
uint16_t, int16_t sont des types WORD (16bits).
uint32_t, int32_t sont des types DWORD (32bits).
uint64_t, int64_t sont des types DDWORD (64bits).
le préfix "u" désigne des types non signés ( Unsigned).

Ok, mais ce ne sont pas des types de base, ce sont simplement des types redéfinis par typedef dans le fichier d'entête stdint.h

[Jack]

Justement, si une variable locale est statique, on devrait logiquement pouvoir la suivre, mais tu semble indiquer que non. Ai-je bien compris?

Non, si elle est locale, elle ne peut être accédée qu'au cours de la fonction dans laquelle elle a été définie. La variable a le même comportement qu'une variable globale, mais ça reste avant tout une variable locale.

Les variables partagées entre le programme principal et les interruptions doivent donc être déclarées "volatile".
Je pense que cette règle doit être appliqué si une variable est stockée dans une mémoire externe accessible et modifiable un par un périphérique par exemple.

Il faut bien veiller à ce qu'un programme d'interruption ne modifie pas le contexte du code qui était exécuté lors de l'arrivée de l'interruption. Certains processeurs sauvent automatiquement un certain nombre de registres, mais si on ne maîtrise pas les zones de code qui peuvent être interrompus, il vaut mieux sauver tous les registres de travail.
Plus délicat: si programme principal et programme d'interruption peuvent écrire dans le même registre ou le même emplacement mémoire, on se retrouve avec les problèmes de sections critiques liées au multithreading, impliquant l'utilisation de mutex ou de sémaphores. Depuis un moment déjà, les µcontrôleurs possèdent les instructions "atomiques" qui vont bien du genre "test and set" qui permettent de résoudre ces problèmes.

PS: pour les variables statiques, comme le dit bobfuck, on peut en effet indirectement la suivre car elle n'est pas stockée dans la pile. En jetant un oeil sur l'adresse de cette variable, il est en effet possible de la suivre à tout moment. Reste que tous les IDE ne permettent pas le décodage de la mémoire: je pense à une vraible float par exemple: on connait la valeur des 4 octets, mais ce qui nous intéresse, c'est la valeur finale

[invitedca01a58]

j'ai décidé de faire une pause avec ce sujet pour le moment, mais temporairement.

Je me rends très bien compte du temps que ça prend de faire une présentation claire et bien structurée d'un sujet. Je me réjouis que ta pause soit temporaire. Je pense que tu as raison d'attendre de poster l'ensemble d'un coup. Cela évitera d'exciter l'impatience des gens. Merci en tout cas pour le beau travail que tu as déjà posté.

[invitedca01a58]

A propos de "volatile" et d'optimisation du code, voici un intéressant article sur AVRfreaks.

A propos de l'utilisation du simulateur, voici un autre article intéressant. Il est basé sur Studio5 mais c'est la même chose pour Studio6 (et pas très différent de Studio4).

[invitee2def47b]

Un GRAND merci à bobfuck et à Jack pour leurs réponses. Comprendre la qualification volatile est fondamentale parce qu'il me parait difficile de remonter aux causes des effets indésirables générés en cas d'oubli. La diversité de vos exemples permet de mieux cerner quand il faut déclarer une variable ou un registre volatile.

Cependant, vos réponses semblent contraires sur certains points: Sur le fait de pouvoir suivre la valeur d'une variable locale statique (en pas à pas ou lors d'un point d’arrêt) en simulation (ou pourquoi pas en debugging sur puce (OCD)):

On peut toujours suivre une variable static (même "locale" dans une fonction) car elle a un emplacement mémoire fixe. Si elle est "locale" c'est un peu plus compliqué de le trouver (mais le debugger sait le faire)

Non, si elle est locale, elle ne peut être accédée qu'au cours de la fonction dans laquelle elle a été définie. La variable a le même comportement qu'une variable globale, mais ça reste avant tout une variable locale....

PS: pour les variables statiques, comme le dit bobfuck, on peut en effet indirectement la suivre car elle n'est pas stockée dans la pile. En jetant un oeil sur l'adresse de cette variable, il est en effet possible de la suivre à tout moment. Reste que tous les IDE ne permettent pas le décodage de la mémoire: je pense à une vraible float par exemple: on connait la valeur des 4 octets, mais ce qui nous intéresse, c'est la valeur finale

Comme tu me cite juste avant, je suppose que tu parle bien de simulation mais avec ce que tu rajoute à la fin, j'ai du mal à percevoir la cohérence. Est ce que tu peux m’éclairer?
Accessoirement, est ce qu'il faut comprendre que certains IDE munis d'un debugger ne permettent pas de suivre une variable située en RAM?

Sinon, pour bobfuck une variable locale statique n'est plus vraiment locale alors que pour Jack "La variable a le même comportement qu'une variable globale, mais ça reste avant tout une variable locale." Je pense que vous dite la même chose mais que vous n'êtes pas d'accord sur la terminologie, ça peut embrouiller les débutants que nous sommes. Pour ma part, la portée (scope) d'une variable est indépendante de sa qualification (qualifier: static par exemple) -d'ailleurs on peut avoir des variables globales statique pour restreindre son accès au fichier dans lequel elle est déclarée (sources)- je suppose donc qu'il faut continuer à parler de variable locale même si elle est statique?

ça comprend aussi tous les registres hard.

(ie il faut déclarer les registres harware avec volatile aussi)
Pourrais tu préciser de quels registres il s'agit? Est ce qu'il y a des cas où nous devrons le faire ou cela est déjà fait dans les fichier d'en-tête (.h) du modèle de processeur utilisé qui associent les noms des registres à leurs adresses?


Au final, j'aimerai arriver à pouvoir résumer ce qu'il faut retenir en règles simples pour nous tous mais j'aurais besoin de vous pour vérifier compléter:

1) Attribut static:
Il permet de conserver une variable locale après la fin de l’exécution de la fonction dans laquelle est est déclarée. Elle reste une variable locale, c.a.d non accessible par le programme principal et les autres fonctions.
De manière plus marginale, il permet pour une variable globale de restreindre son accès au fichier dans lequel elle est déclarée.

2) Attribut volatile: Permet d'interdire au compilateur (et à certains processeurs si j'ai bien compris) d'optimiser le code pour les instructions qui accèdent à cette variable afin d'éviter des effets non-souhaités. Doivent être déclarées comme volatile:
* les variables qui sont susceptibles d'être utilisées par d'autres éléments en plus du programme (interruption, périphérique, matériel, processus, autres core et/ou thread,...)
* les registres matériels (A préciser???)
* les variables qui pourraient sembler inutiles au compilateur (exemple: boucle dans laquelle on ne fait rien "for (i=0; i<Seuil; i++){ }" => i doit être volatile)
* autres cas ???? (Merci pour vos contributions)

[Jack]

Accessoirement, est ce qu'il faut comprendre que certains IDE munis d'un debugger ne permettent pas de suivre une variable située en RAM?

Chaque IDE ayant des possibilités différentes, et ne connaissant pas le monde atmel, je ne me prononcerai pas. En tout cas, rien n'empêche le debogueur d'inspecter sa ram et d'afficher son contenu comme bon nous semble.
En tout cas, il faut savoir ce qu'il y a dans la RAM. S'il s'agit d'une variable locale, ce n'est pas la peine d'aller voir sa valeur en dehors de son scope puisqu'elle est située dans la RAM (enfin, avec un processeur normal, pas comme les pic16f par exemple). En effet, la pile évolue et son contenu évolue en permanence. C'est comme lorsqu'on efface un fichier, tant qu'on n'écrit pas sur le disque dans les secteurs de ce fichier, on peut toujours le récupérer, mais rien ne le garantit.

Sinon, pour bobfuck une variable locale statique n'est plus vraiment locale alors que pour Jack "La variable a le même comportement qu'une variable globale, mais ça reste avant tout une variable locale

Dans tous les cas, on ne peut accéder àune variable locale que dans la fonction où elle a été déclarée. Si elle est statique, sa valeur est PERSISTANTE, ce qui lui donne un comportement qui pourrait s'apparenter à une variable globale, mais il s'agit bien d'une variable LOCALE.

1) Attribut static:
Il permet de conserver une variable locale après la fin de l’exécution de la fonction dans laquelle est est déclarée. Elle reste une variable locale, c.a.d non accessible par le programme principal et les autres fonctions.
De manière plus marginale, il permet pour une variable globale de restreindre son accès au fichier dans lequel elle est déclarée.

Ca me va.

2) Attribut volatile: Permet d'interdire au compilateur (et à certains processeurs si j'ai bien compris) d'optimiser le code pour les instructions qui accèdent à cette variable afin d'éviter des effets non-souhaités. Doivent être déclarées comme volatile:

Un processeur n'optimise pas le code. C'est bien le rôle du compilateur.

* les variables qui sont susceptibles d'être utilisées par d'autres éléments en plus du programme (interruption, périphérique, matériel, processus, autres core et/ou thread,...)

Ca me va

* les registres matériels (A préciser???)

Attention, il y a registre et registre. Il ne faut pas confondre les registres de l'unité centrale, donc du microprocesseur, et les registres des périphériques qui ont été greffés pour former un microcontrôleur.
Les registres du CPU n'ont pas d'adresse. Il existe d'ailleurs le qualificatif register" qui permet de forcer certaines variables à être stockées dans les registres du CPU. Ca peut permettre par exemple d'accélérer le passage des paramètres à l'appel d'une fonction. Cependant, "register" n'est plus utilisé tant les compilateur savent optimiser tout seuls aujourd'hui et choisir si ces paramètres seront passés par la pile ou par des registre CPU.

[invitee2def47b]

Il faut bien veiller à ce qu'un programme d'interruption ne modifie pas le contexte du code qui était exécuté lors de l'arrivée de l'interruption. Certains processeurs sauvent automatiquement un certain nombre de registres, mais si on ne maîtrise pas les zones de code qui peuvent être interrompus, il vaut mieux sauver tous les registres de travail.
Plus délicat: si programme principal et programme d'interruption peuvent écrire dans le même registre ou le même emplacement mémoire, on se retrouve avec les problèmes de sections critiques liées au multithreading, impliquant l'utilisation de mutex ou de sémaphores. Depuis un moment déjà, les µcontrôleurs possèdent les instructions "atomiques" qui vont bien du genre "test and set" qui permettent de résoudre ces problèmes.

Quand tu parle du contexte du code, tu évoque les registres qui vont être empilés avant l’exécutions du programme d'interruption (ISR)?
Pour le reste, je comprend bien l’enjeu et les concepts mais il va me falloir un peu de temps pour m'approprier tous ça. Je ne pense pas qu'on en ai besoin tout de suite, mais pour ceux que que ça intéresse, c'est décrit assez simplement ici:

atomicité

Section critique

Mutex

test-and-set

[invitee2def47b]

Un processeur n'optimise pas le code. C'est bien le rôle du compilateur.

Certains processeurs multi-core et/ou supportant l'hyperthreading peuvent réordonner l’exécution des instructions (peut être pas des micro-controleurs), ce qui pose le même type de problème que l'optimisation:

Le compilateur (et le processeur si il est évolué) peuvent réordonner les instructions et les lectures/écritures mémoire à leur convenance pour optimiser la performance, tout en respectant certaines contraintes (notion de point de séquence en C).

Merci beaucoup pour ces précisions (ainsi que pour les réponses à mes interrogations):

Attention, il y a registre et registre. Il ne faut pas confondre les registres de l'unité centrale, donc du microprocesseur, et les registres des périphériques qui ont été greffés pour former un microcontrôleur.
Les registres du CPU n'ont pas d'adresse. Il existe d'ailleurs le qualificatif register" qui permet de forcer certaines variables à être stockées dans les registres du CPU. Ca peut permettre par exemple d'accélérer le passage des paramètres à l'appel d'une fonction. Cependant, "register" n'est plus utilisé tant les compilateur savent optimiser tout seuls aujourd'hui et choisir si ces paramètres seront passés par la pile ou par des registre CPU.

[invitee2def47b]

A propos de "volatile" et d'optimisation du code, voici un intéressant article sur AVRfreaks.

A propos de l'utilisation du simulateur, voici un autre article intéressant. Il est basé sur Studio5 mais c'est la même chose pour Studio6 (et pas très différent de Studio4).

Merci pour le lien sur l'optimisation de code (et volatile), je n'ai pas encore eu le temps de tout lire mais ça a l'air très riche.


Sinon, j'ai vu dans ton second lien qu'il est possible en simulation (depuis Studio 5) de créer des stimuli qui vont simuler le comportement des entrées qu'on pourrait connecter au µC. Un exemple simple est présenté ici.

Un petit logiciel permet de créer un fichier de stimuli en modifiant chronogramme avec la souris

Cette fonctionnalité m'a l'air très intéressante pour les programmes qui interagissent avec l’extérieur de manière non simple.

[invitedca01a58]

Hello Adam
Je savais qu'on pouvait modifier des ports, des registres ou des variables pendant la simulation mais j'ignorais entièrement que ces modification pouvaient provenir d'un fichier de stimuli et qu'il était également possible d'enregistrer les résultats dans un fichier log qui peut à son tour resservir d'entrée de stimuli. Cela ouvre des possibilités très larges. Tu as l'air d'en connaître un sacré bout !

[Jack]

Quand tu parle du contexte du code, tu évoque les registres qui vont être empilés avant l’exécutions du programme d'interruption (ISR)?
Pour le reste, je comprend bien l’enjeu et les concepts mais il va me falloir un peu de temps pour m'approprier tous ça. Je ne pense pas qu'on en ai besoin tout de suite, mais pour ceux que que ça intéresse, c'est décrit assez simplement ici:

atomicité

Section critique

Mutex

test-and-set

Oui, c'est bien ça. Il faut quand même avoir ce problème dans le coin de la tête quand ça ne marche pas et qu'on n'a plus de solution.

[gegel62]

hello bonjour à tous

en allant sur le lien donné par Jean-Marie et rappelé par Adam, je trouve celui ci qui est pour Studio 6. Je n'ai pas lu mais ça semble intéressant.
http://maxembedded.com/2012/06/25/using-atmel-studio-6/

A part ça, je mets ici le programme que j'ai fait pour la serrure codée en semaine 4. C'est sans intérêt pour la programmation, mais justement j'avais trouvé cette méthode car je ne parvenais pas à utiliser la forme switch case.
C'est un détournement, je ne pense pas que ça puisse servir à d'autres types de problèmes, mais tellement simple à utiliser dans ce cas-là, que je n'y résiste pas...
Pour changer le code, il suffit de mettre à jour les valeurs "nombre de fronts" et "target" qui est le résultat à obtenir.
Bien sûr s'il y avait 20 fronts, ça deviendrait un peu lourd...!!
/*serrure codee
2 BP, il faut realiser une sequence precise
pour allumer la led
on compte les fronts montants (A) et descendants (B), si frontA on fait (count++), si frontB on fait count=(count*2)+3.
Après le nombre maxi de fronts on teste la variable "resultat" qui ne peut prendre la valeur "target" que si la sequence
est correcte.
Si le code est faux (On attend d'avoir les deux Pous à LOW),
on remet count et nombre_fronts à zéro.

 */
#define Pous1 2    
#define Pous2 3
#define Pous1_On !digitalRead (Pous1)  //actif à LOW
#define Pous2_On !digitalRead (Pous2)
#define Led 4
#define Led_On digitalWrite(Led,HIGH) 
#define Led_Off digitalWrite(Led,LOW) 

int valeur1 = 0 ;
int ancienvaleur1 = 0;
int valeur2 = 0 ;
int ancienvaleur2 = 0;
int nombre_fronts = 0;
const int Max_nombre_fronts = 6;
int count = 0;
const int target =  22;

void setup()  {
  Serial.begin(9600);
  pinMode(Pous1,INPUT_PULLUP);
  pinMode(Pous2,INPUT_PULLUP);
  pinMode(Led,OUTPUT);
  Led_Off;
}
void loop() {
  valeur1 = Pous1_On;
  valeur2 = Pous2_On;
  
  if(ancienvaleur1 != valeur1) //front 1
  { count++; nombre_fronts++;
  ancienvaleur1=valeur1;
  delay(20);
  }
 
  if(ancienvaleur2 != valeur2) //front 2
  { count = (count*2)+3 ; nombre_fronts++;
  ancienvaleur2=valeur2;
  delay(20);
  }
  if(nombre_fronts == Max_nombre_fronts)  {
          if(count == target) {
          Led_On;       
          while(1);
          }
  }
}

bonne journée

[mkh.mourad]

C'est tres interessant ce sujet de volatile et static. Ca me fait plaisir de vous lire. MERCI
une petite remarque à propos des AVR.
Ce que j'ai bien compris en plus de ce que Adam a cité si dessus, pour les static le compilateur reserve un emplacement en mémoire une seule fois durant l'exécution du programme. Même si la variable a une portée restreint. Donc il est non initialisée a chaque nouvel appel de fonction, et elle conserve sa valeur antécédente.
Le qualificateur volatil est pour indiquer au compilateur que au cours de l'exécution du programme la variable peut être modifiée ou lu par un acteur extérieur comme une interuption ou un thread.. donc il doit toujours apres une modification de sa valeur la metre a jour tout de suite.

Attention, il y a registre et registre. Il ne faut pas confondre les registres de l'unité centrale, donc du microprocesseur, et les registres des périphériques qui ont été greffés pour former un microcontrôleur.
Les registres du CPU n'ont pas d'adresse. Il existe d'ailleurs le qualificatif register" qui permet de forcer certaines variables à être stockées dans les registres du CPU. Ca peut permettre par exemple d'accélérer le passage des paramètres à l'appel d'une fonction. Cependant, "register" n'est plus utilisé tant les compilateur savent optimiser tout seuls aujourd'hui et choisir si ces paramètres seront passés par la pile ou par des registre CPU.

Pour les processeurs Atmel AVR, les registres ont tous des adresses memoires en Ram interne. Et ils sont déclarés par des #define dans les fichiers d'entêtes.

[bobflux]

Un processeur n'optimise pas le code. C'est bien le rôle du compilateur.

Ben... un microcontrôleur en général non, mais un monstre comme un proc de PC, on pourrait dire qu'il optimise le code, puisque les instructions x86 sont traduites à la volée en un genre de micro-instructions, qui sont ensuite réordonnées, fusionnées, voire éliminées complètement (par exemple les store redondants) ; il y a la prédiction sur les branchements ; les accès mémoire sont passés à la moulinette (prefetch, réordonnancement, écritures différées, etc) ; le tout est assez chiadé et il est bien difficile de prédire la performance d'un code à l'oeil nu, mis à part l'habituel "si ça dépasse du cache, la performance se prend un parpaing dans la gueule".

> Quand tu parle du contexte du code

Le contexte c'est tout ce qui représente l'état du processeur à un moment donné alors qu'il est en train de faire un certain truc. Ça comprend un certain nombre de registres, dont le PC et le stack pointer, et sur un cpu évolué il y a aussi l'état du MMU, etc. Passer d'un contexte à un autre c'est un "context switch".

Il faut voir aussi que si une instruction est en cours et qu'elle va durer plusieurs cycles, soit on l'abandonne pour la refaire après l'ISR, soit on la termine, mais on ne peut pas interrompre une instruction en plein milieu et la reprendre.

Sur un micro c'est assez simple (il faut juste que l'ISR sauvegarde et restaure les registres qu'il va modifier), et en général les instructions prennent 1 ou 2 cycles.

Par contre sur un PC il faut abandonner les 10 instructions qui étaient dans le pipeline, sauver tout un tas de merdier, le MMU, le FPU, une montagne de registres, et puis à la sortie de l'IRQ quand on reprend la tâche en cours, le cache a été chamboulé, etc, ce qui fait qu'un processeur desktop de la mort à 3 GHz sera mis à genoux par un débit d'irq/s qui fait mourir de rire un bon micro rapide genre Cortex-M0 ou M4, qui vont facilement dans les centaines de kIRQ/s... C'est pourquoi les PC sont dotés de périphériques intelligents (genre une carte réseau qui va stocker les paquets reçus en RAM et envoyer un IRQ seulement de temps en temps, pas à chaque paquet).

Aussi, à la fin de l'ISR, on restaure le contexte et on revient là où on était avant. Certains micros ont un "interrupt tail chaining" : avant de restaurer le contexte, on regarde si il y a un autre IRQ en attente, et si oui, on l'exécute immédiatement, sans restaurer et re-sauver le contexte.

[mkh.mourad]

@gegel62
Vu que les delais de remise des devoirs du MOOC sont passés, est qu'on peut mettre nos solutions pour les comparer et voir nos fautes de codage même si on a eu 10/10.

[gegel62]

@Mourad

ben, moi je pense qu'on a le droit, et même cela montre qu'on a été intéressé par les cours
de toutes façons ce n'est pas le forum du MOOC, mais j'imagine que les profs seraient ravis de savoir qu'on continue de bosser après sur leurs exos....!
Oui ça m'intéresse qu'on voie nos diverses solutions.
J'avais eu 10/10 pour cet exercice, bien que sans doute il était donné pour s'entrainer aux switch/case (mais peut-être que je me trompe)