De l'Arduino au langage C standard avec AVR Studio

[sylvainmahe]

Peut être il veut faire ça comme nous c'est à dire en C avec AVR et sans bibliothèques supplémentaire?

Auquel cas pour ma part j'ai presque fini une bibliothèque objet ultra minimaliste qui utilise seulement AVR, donc plus facile à décortiquer j'imagine que des bibliothèques arduino plus grosses et multifonctions, ça pourrait peut être l'aider?


C'est vrai que le sujet est un peu en standby mais je suis sûr que chacun avance dans son coin et on va arriver à montrer des choses pas mal à un moment.

Y a un truc dont je voulais vous parler, sur internet on peut lire que les interruptions par exemple ne fonctionnent pas en C++, d’ailleurs le fichier interrupt d'arduino est un fichier C, donc je pensais vraiment que ce n'était pas possible en objet... Effectivement c'était pas évident de trouver les bonnes macros AVR, mais à force de passer du temps on trouve, et ça fonctionne parfaitement bien en langage objet pour le coup
Sa détecte même les rebonds si ont ne met pas un condensateur dans le circuit des interruptions pour lisser un peu le courant, c'est quand même précis.

Pour mon cas j'aurais besoin plus tard des interruptions pour mon détecteur de radioactivité, en plus de prendre en compte le temps mort du tube geiger ce qui complique un peu les choses d’ailleurs car ces tubes fonctionnent en saturation à cause des avalanches d'électrons, c'est le temps mort, et ce temps mort est variable certainement suivant les trajectoires des particules dans le gaz, des niveaux d'énergie, de la probabilité d'ionisation, de collisions, etc...
La chose un peu bébête c'est que cette situation fait que l'augmentation de l'exposition à la radioactivité augmente le nombre d'interruptions en un temps donné, ça d’accord, mais à un moment si on continue dans cette courbe d'augmentation, le nombre d’interruptions passe à zéro parce que le tube est en saturation, c'est arrêté sur le dernier front montant juste avant la saturation et basta.
Ou bien sinon la solution, il faut que je détecte sur une même pin les interruptions en front montant, et la tension à tout instant, et faire un test, si la tension est toujours de 5v au delà d'un délai, cela signifie que le tube est en saturation.

Ou sinon j'ai pensé un système avec 2 tubes
Bon après je me complique sans doute pour rien car la saturation d'un tube comme le SBM20 ne doit s'obtenir peut être que proche d'une source de radioactivité assez intense...

Bref, que de projets

J'ai une question, pendant une interruption mon programme il fait quoi? L'interruption exécute la fonction que je souhaite, ça d’accord, mais une fois cette fonction exécutée il reprend la ou il en était dans le reste du programme? Ou bien on perd ce qu'on était en train de faire? Bref, est ce qu'une interruption déglingue le reste?


La semaine prochaine je vais programmer quelques fonctions pwm pour faire fonctionner des servos pour ceux qui aiment les robots et le modélisme. Et pourquoi pas ensuite coder une fonction I2C pour recevoir les valeurs de gyro comme le MPU6050 utilisé un peu partout.

Je vous tiens informé de l'avancement de tout ça.

Personnellement vous pensez que je fais erreur à programmer un AVR en C++ ou bien ça ne change pas grand chose à part le fait que ce soit peut être un peu plus lourd?
-----

[invitedca01a58]

Hello Sylvain,

Pour la programmation en C++ ou pour le fonctionnement de tubes Geiger, je ne suis pas capable de t'aider mais pour les interruptions, la réponse est simple.

Le programme ordinaire est une boucle sans fin qui s'exécute toujours dans l'ordre qui a été prévu. Une interruption est un petit morceau de code qui est exécuté lorsque la condition de l'interruption se produit. Ce petit morceau de code vient s'insérer dans la boucle principale du programme juste après l'instruction en cours au moment de l'interruption. Le cours du programme principal est donc détourné pour exécuter l'interruption puis retourne au programme principal là où il l'a quitté. Donc la boucle principale se poursuit comme s'il n'y avait pas eu d'interruption.

[sylvainmahe]

Ah d'accord merci pour les infos Jean-Marie

Donc finalement cela signifie que les interruptions fonctionnent de façon très saines, ce que je ne comprend pas c'est que sur internet on peut lire qu'il faut désactiver les interruptions pendant une interruption, désactiver ceci, ou cela?
De toute façon quand notre fonction liée à l'interruption s’exécute, j'imagine que l'interruption elle même est terminée?

Enfin si vous avez des infos la dessus je suis preneur, je vais de mon coté revérifier sur internet ce qu'il en est.


Sinon pour en revenir au C++, j'ai conscience que sur ce sujet vous êtes surtout axé Assembleur et C, mais pour ma part, allumer une Led avec:
maLed.on();
et l'éteindre avec:
maLed.off();
...me fait beaucoup plaisir

Mais j'ai cru comprendre que certains ici ne connaissaient pas bien le C++, et évidement je suis prêt à passer du temps et répondre aux questions à ce sujet la spécifiquement pour que les gens puissent commencer à démarrer des projets en C/C++.

Le truc qui se passe, comme il a déjà été dit, c'est que apprendre le C ou le C++ en faisant de l'AVR n'est pas forcément d'une part chose facile, et d'autre part ne fait pas découvrir toutes les possibilités du C et du C++. Moi c'est bien parce que je suis passé avant par du C/C++ sur ordinateur classique à cpu, 32/64bits, que je trouve cela facile ces mêmes langages mais avec AVR, car évidement il y a beaucoup mois d'instructions à programmer pour travailler avec une ou quelques pins d'un microcontrôleur, que d'afficher des choses en 2D à l'écran ou voir même en 3D...

Donc je ne sais pas, la meilleur chose à faire est peut être de passer par le circuit auquel on est pratiquement tous passé, c'est à dire apprendre les choses dans l'ordre? Ou bien bidouiller au départ avec de l'arduino, puis comprendre tout seul qu'il faut évoluer au delà de ça? Ou bien faire un mix des deux, bidouillage et apprentissage via les manuels de référence et divers tutos/articles, chose que je fait souvent.
C'est aussi par la bidouille qu'on apprends, je pense qu'on est tous passé par des choses prémâchées au départ, pas tout à fait exactes dans leur fonctionnement, que ce soit dans le domaine de l'informatique que dans d'autre domaines, puis ensuite on a voulu en savoir plus et faire les choses comme il faut et par nous même.

Dans d'autres domaines, par exemple l'alimentaire, au départ on achète un gâteau, on trouve qu'il est bon, on regarde la recette au dos, si on est un peu plus curieux que ça on va voir sur internet des recettes un peu plus sympa, avec un peu moins de saloperies artificielles, puis on le fait nous même. Au départ on échoue puis à force d'essayer on fini par y arriver.
La c'est peut être pareil avec les AVR, on achète une carte arduino, on la fait fonctionner avec l'ide, ensuite on s’affranchit de l'ide, puis on regarde comment est faite la carte pour finalement la concevoir nous même, et si on a envie de rajouter un +5v et un gnd à coté des pins de signal, pourquoi pas, on le fait, comme ça un servo-moteur standard on le branche direct sur notre carte avec les trois fils (c'est vrai que de ce coté la arduino il on loupé leur truc je trouve).

Enfin bref je balance des idées comme ça, à vous de me dire si tout ça correspond à votre vision de comment on aborde le monde des AVR

[sylvainmahe]

J'ai une petite question, pourquoi dans les bibliothèques arduino dans pas mal de fonctions on peut voir au début:
uint8_t oldSREG = SREG;

puis à la fin de la fonction:
SREG = oldSREG;

Pourquoi le statut du registre pourrait changer entre temps, et de****t être remis comme il était après l’exécution de certaines macros avr? Je vous pose la question car j'y connais pas grand chose en assembleur et en gros, je n'utilise pas ça dans ma bibliothèque et tout fonctionne très bien, si jamais vous avez la réponse...

[PA5CAL]

J'ai une petite question, pourquoi dans les bibliothèques arduino dans pas mal de fonctions on peut voir au début:
uint8_t oldSREG = SREG;

puis à la fin de la fonction:
SREG = oldSREG;

Les fonctions dans lesquelles on trouve ces lignes sont bien souvent les routines d'interruption. Cette façon de faire permet de sauvegarder tous les flags avant d'entreprendre les opérations susceptibles de les modifier, puis de restituer leur état initial juste avant de quitter la routine.

On les utilise aussi souvent pour remettre le flag d'interruption I dans un état initial inconnu. Par exemple, pour réaliser la lecture ou l'écriture atomique d'une structure occupant plusieurs octets, on sauvegarde SREG puis on force le flag I à 0 pour interdire la survenue d'une interruption, et après l'opération on restaure le flag en récupérant SREG, sans avoir à s'inquiéter de savoir si auparavant les interruptions étaient autorisées ou non.

[sylvainmahe]

Ok d'accord merci. Ça explique les endroits ou ils ont utilisé cela, bon même si il y a des subtilités encore qui m'échappent car je ne connais pas l'assembleur, mais en tout cas je vois mieux le principe et à quoi ça sert.

[invitedca01a58]

Hello Sylvain

Pour être concret, dans ma datasheet de l'Atmega 328 (page 9), on trouve ceci:

7.3 Status Register
The Status Register contains information about the result of the most recently executed arithmetic instruction. This
information can be used for altering program flow in order to perform conditional operations. Note that the Status
Register is updated after all ALU operations, as specified in the Instruction Set Reference. This will in many cases
remove the need for using the dedicated compare instructions, resulting in faster and more compact code.
The Status Register is not automatically stored when entering an interrupt routine and restored when returning
from an interrupt. This must be handled by software.

Ensuite sont détaillés les 8 bits du registre SREG (Status Register) qui sont tous des flags positionnés selon le résultat des opérations arithmétiques et logiques précédentes.
Donc si tu as un morceau de programme comme ceci:

if X < Y

{ faire quelque chose; ]

la comparaison entre X et Y positionne certains flags de SREG. Si une interruption se produit entre le 'if' et le 'faire quelque chose', le code de l'interruption pourrait modifier les flags de SREG. Du coup, lorsque le programme reprend sont cours ordinaire, le "faire quelque chose" pourrait passer aux oubliettes si SREG n'est pas restauré à la sortie de l'interruption à la valeur qu'il avait à son entrée.

[5_cylindres]

salut à tous

UNIQUEMENT DANS LE CAS DES INTERRUPTIONS :

SREG n'a besoin d'être sauvegardé "à la main" que si on bosse en assembleur.

dans le cas d'une programmation en C avec GCC comme compilateur, c'est GCC lui-même qui s'occupe de programmer les sauvegardes et restaurations de tout ce qui doit l'être : entre autre SREG, à l'adresse 0x3F sur un 2560, est sauvegardé juste après les registres de calcul nécessaires, puis restauré juste avant (on peut voir ça dans les fichiers ".lss").

>>> c'est bien ce que je disais quelques (nombreuses) pages plus avant : Ar...no, c'est de la m...e, c'est codé avec les pieds ! j'espère que GCC est suffisamment bien verrouillé pour ne pas sauvegarder deux fois SREG sinon bonjour les dégâts !

bye

[invitedca01a58]

SREG n'a besoin d'être sauvegardé "à la main" que si on bosse en assembleur.

dans le cas d'une programmation en C avec GCC comme compilateur, c'est GCC lui-même qui s'occupe de programmer les sauvegardes et restaurations de tout ce qui doit l'être : entre autre SREG, à l'adresse 0x3F sur un 2560

Merci 5_cylindres. J'ignorais cette info.

[sylvainmahe]

J'avais oublié le datasheet pour le coup, j'aurais du aller voir, Merci encore pour toutes ses infos, comme ça je peux avancer comme il faut dans ma programmation

[PA5CAL]

salut à tous

UNIQUEMENT DANS LE CAS DES INTERRUPTIONS :

SREG n'a besoin d'être sauvegardé "à la main" que si on bosse en assembleur.

dans le cas d'une programmation en C avec GCC comme compilateur, c'est GCC lui-même qui s'occupe de programmer les sauvegardes et restaurations de tout ce qui doit l'être : entre autre SREG, à l'adresse 0x3F sur un 2560, est sauvegardé juste après les registres de calcul nécessaires, puis restauré juste avant (on peut voir ça dans les fichiers ".lss").

>>> c'est bien ce que je disais quelques (nombreuses) pages plus avant : Ar...no, c'est de la m...e, c'est codé avec les pieds ! j'espère que GCC est suffisamment bien verrouillé pour ne pas sauvegarder deux fois SREG sinon bonjour les dégâts !

bye

S'agissant des interruptions, GCC ne s'occupe pas systématiquement de la sauvegarde et de la restauration des registres. Lorsqu'il est nécessaire de gérer le prologue et l'épilogue des routines d'une manière particulière, par exemple pour gagner en vitesse ou en espace mémoire, il suffit de le lui demander en utilisant la syntaxe qui va bien.

On peut donc parfaitement faire des routines d'interruption avec une sauvegarde du contexte totalement prise en charge par le programme du développeur écrit en C, sans une seule ligne d'assembleur.

Soit dit en passant, je ne vois pas en quoi la double sauvegarde de SREG poserait problème dans la façon dont elle est utilisée dans le code Arduino.


Je ne vois pas d'inconvénient à prétendre que « Ar...no, c'est de la m...e, c'est codé avec les pieds ». Encore faut-il en apporter des preuves, ou tout au moins des indices, au travers d'arguments valables qui ne résultent pas simplement d'une mauvaise connaissance de la question.

[sylvainmahe]

Ok. Donc alors cela signifie que dans ce cas de figure ça permet juste de gagner en mémoire et en vitesse, mais ne pas le faire ne créé pas de problème particulier si j'ai bien compris?

C'est vrai que pour arduino, pour ma part à mon arrivé ici j'ai été surpris de la façon dont s'est codé, au final c'est pas si mal codé que cela, il y a eu un boulo assez important de fait, mais je trouve qu'il y a beaucoup trop de rappels à des méthodes ou des defines dans tous les sens. Des fois on en arrive à devoir examiner 3 ou 4 .c ou .cpp en remontant par les include parce que machin appel truc, qui appel ensuite bidule, puis machin, etc...
Ça aurait pus être mieux organisé.

[PA5CAL]

Ok. Donc alors cela signifie que dans ce cas de figure ça permet juste de gagner en mémoire et en vitesse, mais ne pas le faire ne créé pas de problème particulier si j'ai bien compris?

Heu... Mis à part que manquer de mémoire ou ne pas réagir assez vite crée en règle général des problèmes rédhibitoires ... ? Non, ne pas le faire ne crée pas d'autres problèmes particuliers, si au bout du compte on fait ce qu'il faut, autrement.

[sylvainmahe]

Le truc c'est que je ne sais pas trop ou et quand le faire.
Faudrait que je vous montre mon code pour me dire ou ce serait le plus intéressant de mettre ces instruction la.

[PA5CAL]

Le truc c'est que je ne sais pas trop ou et quand le faire.
Faudrait que je vous montre mon code pour me dire ou ce serait le plus intéressant de mettre ces instruction la.

J'ai l'impression que tu mets la charrue avant les bœufs.

On n'écrit pas des instructions à un endroit du code parce que c'est « intéressant », mais parce que ça correspond à ce qu'on doit faire pour réaliser ce qu'on souhaite.

Il est tout-à-fait pertinent de se demander quelle solution permet de répondre à un besoin particulier. En revanche, disposer d'un élément de solution et se demander comment l'insérer dans sa réalisation est le signe que l'adéquation de cet élément est douteuse, et plus généralement qu'on ne maîtrise pas sa démarche de conception et qu'on court au-devant des ennuis.

Si tu « ne sais pas trop où et quand le faire », c'est parce que ce n'est pas une solution que tu comprends assez pour couler de source dans ta problématique. Je te suggère plutôt de prendre le problème par le bon bout (i.e. définition du besoin, conception, puis réalisation ; d'abord fonctionnellement, puis techniquement), et d'étudier séparément l'intérêt et les implications de ces instructions, dans le cas où tu viendrais à les mettre effectivement en œuvre, de façon pleinement justifiée.

[sylvainmahe]

Ok donc je ne vais pas mettre ces instructions, parce que mon programme fonctionne parfaitement bien sans, le résultat souhaité est la, donc au final pourquoi se casser les bonbons.

J'ai fini avec les interruptions, je continues la suite.

[sylvainmahe]

D'après vous le plus rapide c'est de faire une égalité avec du binaire ou de l'exa?

OCR0A = 0b11111001;

ou:

OCR0A = 0xF9;

Merci d'avance.

[Jack]

Il n'y a aucune différence, dans la mémoire, quelle que soit la base, il y aura toujours la même valeur.

[sylvainmahe]

Tout à fait mais je parlais juste en terme de rapidité, enfin tu me dira on s'en fou tellement c'est minime mais j'étais curieux de savoir

[Jack]

Tout à fait mais je parlais juste en terme de rapidité, enfin tu me dira on s'en fou tellement c'est minime mais j'étais curieux de savoir

Je crois que tu n'as pas compris. Je répète que ça ne changera rien car le code généré par le compilateur sera strictement identique vu qu'il s'agit de la même valeur.
0b11111001 ou 0xF9, c'est du TEXTE que le compilateur va convertir en un code numérique correspondant à cette valeur.

Lorsque le µcontrôleur exécutera le programme le code sera donc strictement identique, que la valeur ait été exprimée en hexadécimal ou en binaire dans le code source.

[sylvainmahe]

Ok d'accord, parce que si tu veux ce que je ne pige pas c'est qu'avec avrdude je semble envoyer de l'exa:

truc bidule... -P /dev/ttyUSB0 -U flash:w:main.hex:i

Alors ce fichier .hex contient de l'exa qui sera converti en binaire par le programmateur?
Ou c'est déja du binaire dedans? Pourtant ce n'est pas ce que j'ai vue dedans quand j'ai ouvert le fichier.

Merci d'avance pour les explications

[Jack]

Un fichier .hex est un fichier texte (donc codé en ASCII) qui contient les données exprimées en hexa. Ces données contiennent le code machine qui est issu de la compilation de ton code source. La base dans laquelle tu exprimes tes nombres dans le code source n'a donc aucune influence sur le code machine et par conséquent sur le contenu de ton fichier .hex

[sylvainmahe]

Merci pour l'explication.
Donc on peut mettre des entiers pour plus de lisibilité en programmation si on le souhaite, sans que ça influe sur la rapidité à l’exécution, c'est vrai qu'il y avait une ambiguïté dans ma tête vis à vis du processus exact, mais la c'est très clair maintenant.

[Jack]

Donc on peut mettre des entiers pour plus de lisibilité en programmation si on le souhaite, sans que ça influe sur la rapidité à l’exécution

Ca c'est un autre problème. La taille des données manipulées influe sur la rapidité du traitement. Du point de vue rapidité, l'idéal est d'adopter une taille des donnée égale à celle traitée par l'unité de traitement du processeur.

[freepicbasic]

Tu devrais étudier les types en programmation;
http://fr.wikibooks.org/wiki/Program.../Types_de_base

Ce qui compte en programmation ce sont les limites des datas
Autrement dit le nombre de bits et la façon de coder les chiffres

Plus le type est complexe plus il prend de place en mémoire et plus les calculs sont lents, mais plus la précision sera grande.

La précision se fait donc au dépend de la vitesse et de l'espace RAM.

Il faut donc utiliser les types les plus adéquat selon le besoin.

Mais ce n'est pas toujours vrai;

Mais aussi selon le genre de µc , un µc 8 bits aura plus de facilité pour des opérations 8 bits.
Si le µc est un 16 bits, le fait de faire une opération 8 bits peut le pénaliser en vitesse.
Pour les opérations qui concerne un seul bit, si le µc n'a pas d'instructions qui manipulent le bit , il lui faudra plusieurs instructions pour manipuler un bit.
(généralement les µc en ont , mais souvent les µp plus puissant n'en ont pas)

[Jack]

Tu devrais étudier les types en programmation;
http://fr.wikibooks.org/wiki/Program.../Types_de_base

Ce qui compte en programmation ce sont les limites des datas
Autrement dit le nombre de bits et la façon de coder les chiffres

Plus le type est complexe plus il prend de place en mémoire et plus les calculs sont lents, mais plus la précision sera grande.

La précision se fait donc au dépend de la vitesse et de l'espace RAM.

Il faut donc utiliser les types les plus adéquat selon le besoin.

Mais ce n'est pas toujours vrai;

Mais aussi selon le genre de µc , un µc 8 bits aura plus de facilité pour des opérations 8 bits.
Si le µc est un 16 bits, le fait de faire une opération 8 bits peut le pénaliser en vitesse.
Pour les opérations qui concerne un seul bit, si le µc n'a pas d'instructions qui manipulent le bit , il lui faudra plusieurs instructions pour manipuler un bit.
(généralement les µc en ont , mais souvent les µp plus puissant n'en ont pas)

Tu réponds à qui exactement?

[freepicbasic]

je répondais à sylvain en particulier, (sur un forum les réponses ne s'adressent pas qu'à une seule personnes), je pense que jack tu connais déjà, c était des précisions en plus, car vu les questions , sylvain manque des connaissances de bases, et des réponses incomplètes risquent de le perturber encore plus,
Mais tout commentaires ou autres sont bienvenus.

[Jack]

ok, pas de problème

[sylvainmahe]

Ok merci pour les réponses, mais.... ... *freepicbasic, euh, comment te dire
Les types heureusement que je connais ça, et j'utilise toujours les plus adéquats et surtout ceux qui rentrent dans les limites max des données à rentrer dedans, j'ai toujours fais comme ça, même à l'époque ou je voyais en masse sur le site du zéro entre autre des gens coder comme des porcs, en disant c'est bon, on a 2go de ram, arrête de nous les péter... Bref, pour un microcontrolleur encore plus, je ne vais pas utiliser un int32_t pour mettre un bit

Ce que je disais c'est, est ce qu'il y a une différence de vitesse d’exécution entre ça et ça sachant que l’égalité n'est pas issue d'une variable, mais de texte qu'on mais en direct:

OCR0A = 0b11111001;

OCR0A = 0xF9;

On me répond que non, et voyant l'explication, effectivement c'est logique puisque tout fini en hexa.

*freepicbasic, mais je suis content de manquer de connaissances de base, comme ça ca me fait une bonne marge pour progresser, d’ailleurs Pascal aussi l'a bien remarqué si vous relisez tout ce qu'il explique, c'est vrai que je n'ai qu'un bac pro mécanique, je suis pas très intelligent à vrai dire, je ne sort pas de grosses universités.

[zibuth27]

Tiens, un mot moins censuré que "vrai"

Ça fait du bien, on est en Gaule, quoi !