De l'Arduino au langage C standard avec AVR Studio

[adrien4607]

Suite aux remarques de Fred_du_92, j'ai tenté d'installer AVR Studio 6.2, mais hélas c'est bien trop lourd pour ma machine qui fonctionne sous Windows XP !

La gratuité de l'utilisation de cet outils en version 6.2 devient donc toute relative s'il est nécessaire d'investir dans une machine neuve pour le faire tourner.

Il faudra donc soit bidouiller, soit casser sa tirelire ! A moins d'être déjà équipé d'un PC moderne !
Enfin, tout cela à déjà été dit je crois !

A l'école, nous avons des vieux Pentium4 avec 1Go de RAM et encore ... , discrètement, j'ai installé atmel studio 6 et il fonctionne parfaitement, certes un peut lent lors de la compilation de gros projet ... Mais ... Si il y a des mise à jours c'est qu'il y a une raison ... !

Et je pense que vous devriez écouter Fred_du_92, comme je l'ais dis, les mise à jours c'est pas pour rien qu'il les font ... !
Et les toolchain .... Je n'avais encore jamais entendu se bazars , je me doutais que ça devais exister se genre de truc, mais je découvre aujourd'hui se que c'est ... et ça ne ma pas empêcher de coder un beau projet que j'ai fait de A à Z (coder en AVR-C sous Atmel studio 6) http://forums.futura-sciences.com/el...ttendue-3.html et ça sans connaitre les fameuse toolchain .... !!


De plus, il y a même pas un ans, j'ai acheter mon premier USBASP (et unique) pour pouvoir programmer mes bestioles alors que je n'y connaissait pas grand chose en AVR-C, je connaissait le C/C++ et l'arduino. J'ai juste lus les tutos en #5 et fait qu'elle que recherche, le reste, ça à été de la lecture de datasheet, de la patience, de la motivation, de la reflection , ... Avent de vouloir conquérir le monde, commencé déjà par vous conquérir vous même. Le débogueur, les toolchain, ... c'est inutile ! Commencer par apprendre les base, faite vos dent sur des petit projet sans vous cassez le c** avec les toolchain, les débogueurs, ... contentez vous d'un USBASP et de studio, c'est comme ça que vous apprendrez le mieux !
Vous rallez pour mettre a jours Studio car sois disant votre PC n'est pas une bête de course et que vous ne voulez pas en acheter un autre (se que je comprend totalement) mais vous voulez déjà investir dans un Atmel-ICE alors que vous ne savez même pas si vous allez accrochez ou pas .... Il y a un problème ... vous voulez investir dans une bête de course (Atmel-ICE) pour programmer vos µC MAIS vous ne voulez pas installer une bête de course pour coder (Atmel Studio 6) ....


PS1: Je n’ai pas lus tous les post ...
PS2: Je n'est pas beaucoup d'expérience en programmation et je suis trèèèèèss loins de coder comme un pro, mais se que je sais, c'est que ceux qui veule, ils peuvent et il se démerde pour réussir !
PS3: Je suis toujours sur mon bon vieux USBASP, je pense seulement à peut-être acheter une AVR-Dragon que j'ai découvert grâce à skywodd et j'ai un gros doute que je vais l'acheter car aillant un petit budget, je trouve que le jeux n'en vaut pas la chandelle !
PS4: C'est ma façon de voir les choses, a vous de l’interpréter comme vous le voulez ...


Sur se bonne soirée
-----

[invitef0c79320]

salut tout le monde.
connaître des choses c'est mieux de les ignorer. toolchain, comipler, linker, assembler, avrdude, deboger...etc font partie du monde de la programmation. si l'ide nous facilite la vie c'est formidable, mais connaître ce qui fais a notre place c'est super. il ne faut pas voir l'ide comme une boite noir. connaître c'est outils certes n'est pas indispensable pour faire de beau programme complexe et pro, mais ca reste préférable de les survoler pour savoir ce qu'ils font en arrière plans sur un IDE.
je travaille sur la librairie de Arduino des afficheur a cristaux liquide LCD de type Hitachi HD44780. je suis en train de les traduire du C++ Arduino au standard C avr-gcc. j'ai trouver des petites bugs dans les sources originaux.
cordialement.

[adrien4607]

salut tout le monde.
connaître des choses c'est mieux de les ignorer. toolchain, comipler, linker, assembler, avrdude, deboger...etc font partie du monde de la programmation. si l'ide nous facilite la vie c'est formidable, mais connaître ce qui fais a notre place c'est super. il ne faut pas voir l'ide comme une boite noir. connaître c'est outils certes n'est pas indispensable pour faire de beau programme complexe et pro, mais ca reste préférable de les survoler pour savoir ce qu'ils font en arrière plans sur un IDE.
je travaille sur la librairie de Arduino des afficheur a cristaux liquide LCD de type Hitachi HD44780. je suis en train de les traduire du C++ Arduino au standard C avr-gcc. j'ai trouver des petites bugs dans les sources originaux.
cordialement.

C'est claire, plus on connais les choses, mieux on sais s'en servir, mais il faut savoir se qui est indispensable ou non. Programmer en AVR-C sans connaitre le C/C++, c'est pas possible, mais programmer en AVR-C sans connaitre les toolchain, sans avoir de deboger, ... c'est possibles, oui ça peut-être utile de savoir se que c'est, mais je pense que les débutants devrais commencer avec atmel studio (récent) et un programmateur de base sans s'encombrer de chose qui risque de les handicapé et de les dégouté ... Et après quand ils auront bien fait leur dents sur cette petite base commencer à approfondir les deboger, toolchain, ...

[laveplusblanc]

Je ne vais pas renter dans ce débat d'AVR studio 4 ou 6, que je n'utilise personnellement pas ou plutôt plus (j'utilise maintenant uniquement Eclipse), mais fort de mon expérience de presque 10 ans de microcontrôleurs en tant qu'amateur, je me permets d'affirmer que l'utilisation d'un debugger in circuit (qui permettent tous d’ailleurs aussi la programmation) est incomparablement plus simple et efficace qu'un programmateur du type "je programme et puis j'oublie"
LVPBL

[invitef0c79320]

c'est sur que le débogage in simulation ne vaux rien devant le débogage in situ at runtime.
avr studio c'est pour des pc anciens génération, alors que Atmel studio c'est puissant plein d'option et plus performant coté éditeur (au moins), mais reste pour des PC actuelles.
pour éclipse je n'ai pas eu l'occasion de tester avr-gcc sur cet IDE.

[invitee2def47b]

@ laveplusblanc

Juste pour en savoir un peu plus, quelles sont les raisons qui t'ont orienté vers Eclipse?

[invite5637435c]

A l'école, nous avons des vieux Pentium4 avec 1Go de RAM et encore ...

Bonjour,

petit veinard, toi au moins tu avais un PC
Nous nous avions des profs de génie et des livres.
C'est peut-être ce qui fait que nous ne voyons pas les choses de la même façon, notre génération à appris à se servir d'abord de sa tête avant de choisir un outil adapté au boulot à faire, le cas échéant de créer l'outil si besoin.

Quand je lis tout ce jargon débile de toolchain et Cie, il y en a qui manque vraiment d'élégance pour pas dire de culture.
Tout ce pseudo langage à la sauce Arduino le démontre: une vulgarisation de plus, de l'intelligence en moins!
Apprenez le C Adrien, perfectionnez vous dans ce langage et vous ne perdrez pas votre temps comme certains dans cette discussion, et le français pour d'autres aussi par la même occasion ça évitera de devoir subir ce baragouinage débile pseudo technique et totalement inutile, sauf à montrer son ignorance...

[Jack]

Salut Hulk,

d'accord sur le fond avec toi, mais en revanche, pourquoi parler de jargon débile en évoquant la "toolchain". Il me semble que c'est un élément indispensable pour développer aujourd'hui. Certes, certains IDE masquent cettent chaine, mais dès qu'on veut quelque chose d'un peu particulier, il faut maitriser son fonctionnement.

sans compter que certains de ces IDE sont hors de prix pour les amateurs qui fréquentent ce forum. gcc mermet de cibler à peu près tous les processeurs et microcontrôleur. Reste à mettre en place tout le reste, d'où cette notion de toolchain qui me semble plus qu'importante aujourd'hui.

A+

[invite5637435c]

Salut Jack,

Désolé mais quand je lis ça:

c'est sur que le débogage in simulation ne vaux rien devant le débogage in situ at runtime.

Ca me fait un peu bondir...

Il y a des anglicismes incontournables tels que linker par exemple et bien d'autres encore mais ce n'est pas une raison pour généraliser tous les termes dont la plupart ont des équivalents français bien définis.
Toolchain se traduit aisément par chaîne d'outils ou ensemble d'outils, tout comme runtime avec durée d'exécution.
Soit on s'exprime totalement en anglais si on en est capable, soit on fait un petit effort.
On retrouve cette paresse dans l'esprit Arduino, mélanger du C à la sauce C++ pour s'interfacer avec des bibliothèques obscures non publiques.
Le principe du C est de rendre portable une application d'une plate-forme à une autre, ici rien de tout ça, vraiment aucun intérêt.
Flowcode, Arduino, même combat: du gloubi-boulga d'électronique!

[invitef0c79320]

Salut Jack,

Désolé mais quand je lis ça:



Ca me fait un peu bondir...

Il y a des anglicismes incontournables tels que linker par exemple et bien d'autres encore mais ce n'est pas une raison pour généraliser tous les termes dont la plupart ont des équivalents français bien définis.
Toolchain se traduit aisément par chaîne d'outils ou ensemble d'outils, tout comme runtime avec durée d'exécution.
Soit on s'exprime totalement en anglais si on en est capable, soit on fait un petit effort.
On retrouve cette paresse dans l'esprit Arduino, mélanger du C à la sauce C++ pour s'interfacer avec des bibliothèques obscures non publiques.
Le principe du C est de rendre portable une application d'une plate-forme à une autre, ici rien de tout ça, vraiment aucun intérêt.
Flowcode, Arduino, même combat: du gloubi-boulga d'électronique!

merci HULK pour tes remarques, je vais les prendre en considération la prochaine fois.
je ne suis qu'un débutant en programmation, je ne maitrise ni l'électronique ni la langue française. le Français n'est pas ma langue maternel, l'anglais non plus, mais j'essai d'écrire en Français propre.
le jargon technique est plein de mots anglais même si la traduction existe.
un IDE c'est en anglais, le mot français équivalent c'est EDI.
LED c'est pas Français, DEL l'ai.

je m'excuse une autre fois si j'ai utilisé toolchain a la place de chaîne d'outils ou ensemble d'outils, de même pour runtime par durée d'exécution.
on apprend tout les jours

[invite5637435c]

Y a pas de mal, j'ai cité ta phrase mais sans vouloir te stigmatiser personnellement, cette façon d'écrire est particulièrement envahissante surtout sur les forums et même pour des gens chez qui pourtant le français est la langue maternelle, un peu comme une mode facile et surtout de mauvais goût qui pique les yeux.
Il faut juste en être conscient et ta réaction est la bonne, je t'en remercie.

[hary]

Je rajouterai, qu'en plus, la plupart des informations sont en Anglais.

Et quand on débute et qu'on lit cette information en Anglais, et bien on en assimile les anglicismes !

Certes, on peut certainement passer pour des nazes, mais si on se retrouve ici, c'est qu'on cherche à "s'érudir."

C'est quoi la suite du programme ?

[Jack]

on cherche à "s'érudir."

hem! hem! La langue française est suffisamment riche pour éviter de devoir inventer un nouveau verbe.

[f6exb]

Ce nouveau verbe est du 2è ou 3è groupe ?

[hary]

@ HULH28, Il faut bien taquiner un peu !

Tu voudrais pas nous relancer ton cours de C autour d'un environnement simple et accessible ?

Genre autour des AVRs puisqu'on s'est lancé avec ça.

Ou bien MSP430, certains possèdent une Launchpad MSP430.

On a compris que tu n'est pas très amis avec Arduino, mais pour nous, débutant, ça permet vraiment de s'y mettre sans trop de déboire.
Et pour pas trop cher ! Et on arrive quasiment tout de suite à faire clignoter des LEDs.

On cherche qu'à apprendre !

[invitedca01a58]

A propos de ce forum, nous n'arriverons pas à travailler ensemble sans un minimum de tolérance, de modération et d'humilité. Il est possible de donner son avis sans avoir recours à des jugements à l'emporte-pièce, sans nuance. Les propos agressifs ou offensants ne déclenchent que des réponses véhémentes ou des claquages de porte malheureux. Chacun a droit au respect et a un devoir de respect envers les autres.

---

Ceci dit, la question principale a été posée par hary : "C'est quoi la suite du programme ? "

Si nous quittons l'IDE Arduino pour aborder Studio, c'est bien parce que nous désirons entrer plus en profondeur dans la compréhension des microcontrôleurs et de leur langage de commande.
Finalement, le choix entre Studio4 et Studio6 n'est pas très important car ces deux environnements font fondamentalement la même chose: le programme C est le même et la simulation virtuelle est la même. C'est ce dont nous avons besoin pour démarrer.

Il faut donc que chacun soit en mesure de programmer son microcontrôleur. Encore faut-il choisir le microcontrôleur. Le principe de programmation est le même pour tous les AVR 8bit mais le nombre de pins et de fonctions hardware diffère.

Nous n'avons pas fait le recensement du matériel dont nous disposons. Ceux qui viennent du cours MOOC ont vraisemblablement soit un Arduino (mais il y a beaucoup de modèles), soit un Launchpad MSP430. Ces deux-là ne sont que superficiellement comparables car l'organisations des registres internes est différente. Donc, je pense que ceux qui désireraient poursuivre avec le MSP430 ouvrent un nouveau thread spécifique à cette platine.

Nous poursuivons donc ce thread avec ceux qui continuent sur AVR.
Sur une platine Arduino ? Sur une platine plus proche de la machine (voir messages #86 et #87) ? Sur une breadboard ?

Recensons d'abord le matériel dont on dispose.

Pour ma part, j'ai :

• une platine Arduino Uno R3 (µC : ATmega328P)
• quelques ATmega8 et 328P en réserve
• trois programmateurs USBasp clonés en AVRispmkII
• plusieurs breadboards
• le matériel pour souder et fabriquer des circuits imprimés (mais ce n'est pas nécessaire pour un apprentissage du C)

De quoi disposez-vous ?

[hary]

Moi, c'est MEGA2560 et une poignée de composants génériques (LEDs, résistances, potentiomètres, transistors, MOSFET etc...)

Mais pour le moment, je suis toujours coincé avec AVR Studio 6.2 qui ne veut pas fonctionner correctement ! Soit il est mal installé, soit je ne sais pas l'utiliser correctement.

[invitee2def47b]

Je suis vraiment choqué par certaines interventions récentes. Alors quoi la liberté n'a pas cours ici? Quel est le sens des ces interventions que les américain qualifieraient de "passive agressive"? Au prétexte que nous serions débutants nous devrions faire comme ci et surtout pas comme ça sans discuter sous peine d'être dénigrés ouvertement?
Donner des conseils est fort différent de sortir de nul part et de vouloir imposer des diktats. Il me semble qu'il est possible d'exprimer ce qui ne reste qu'un point de vue de manière moins péremptoire. Mais comme souvent, moins on a de légitimité et plus on a recours à la force, je dis cela sans vouloir "stigmatiser personnellement" bien entendu... Or quand je vois que Mourad, qui a aidé de nombreuses personnes sur un autre forum dans une langue qui n'est pas la sienne se fait sommer d'apprendre le français et interdire l'emploi d’anglicisme, je trouve que c'est un comble d'indélicatesse qui aurait pu être évité en relevant quelques indices évidents. Le pire c'est que quand Mourad, dans un geste d'une incroyable élégance s'excuse à la place de l'agresseur, il se voit retourner un genre de "c'est bien petit, tu as bien compris ma leçon".
Et avec la même grâce pachydermique:

Le principe du C est de rendre portable une application d'une plate-forme à une autre, ici rien de tout ça vraiment aucun intérêt.

Ne pensez vous pas que la moindre des choses avant de se rependre en critique aurait été de lire (et de comprendre) le titre du thread? (Zut un anglicisme!)

Ceci est ma dernière intervention sur un sujet qui ne concerne pas directement la raison d'être de cette discussion. Je ne m'attend à aucun résultat, mais je ne peux qu’espérer un peu moins d'autoritarisme sur la forme des interventions, parce qu'être débutant n'implique ni bizutage ni allégeance.

[invite3c199cf9]

Sans vouloir prendre particulièrement la défense de HULK28, il a quand même répondu avec respect au post #101.

[invitee2def47b]

@Jean-Marie,

Je te prie de m'excuser, nos messages se sont croisés je n'avais pas vu que tu étais déjà intervenu.

@ tous
Pour le recensement, Je n'ai pas de carte pour l'instant. On m'avais prêté un coffret Arduino Uno au tout début du MOOC mais je n'y ai plus accès. Je possède une plaque d'essai, une alimentation, un fer à souder. Je peux accéder à un labo pour faire des tests.
Je compte commander 2 programmateurs USBasp (pour en convertir 1 en AVRispmkII), 2 ou 3 ATmega328P nus, très probablement la platine de développement avec connecteur ZIF dont tu as parlé pour la liberté qu'elle offre et à termes d'autres µC mais je ne me suis pas encore penché sur la question de savoir lesquels.

Pour ceux que ça intéresse, il est possible de commander des coffrets complets comprenant la carte Arduino Uno, plaquette d'essai, fils, afficheurs, servo moteur et même des badges + récepteur RFID pour 36€ ici

[invitedca01a58]

Hello hary,
Quand tu dis "MEGA2560", je suppose qu'il s'agit de la platine Arduino MEGA2560.
Comme je le disais ci-dessus, les principes de programmation seront les même que pour un ATmega8 mais la plupart des registres porteront un nom différent. Par exemple, l'ATmega8 a un seul port de communication SPI alors que l'ATmega2560 en a 5. Donc, les registres SPI seront numérotés. L'adaptation logicielle n'est pas importante mais cela veut dire qu'on ne peut pas se contenter de copier le programme d'un 328 pour le faire tourner sur un 2560.
Il y a certaines choses plus subtiles. Par exemple, on a vu que le fait d'écrire sur le port PIN provoque un toggle de la pin. Cela marche sur un 328 par exemple. Par contre, un ATmega8, 16 ou 32 ne comprend pas cette commande.
-------------------------------

pour le moment, je suis toujours coincé avec AVR Studio 6.2 qui ne veut pas fonctionner correctement ! Soit il est mal installé, soit je ne sais pas l'utiliser correctement.

Tu devrais expliquer ici ce qui ne marche pas. Peut-être que certains seront en mesure de te dépanner.

Pour le moment, j'ai également un problème avec Studio4.
Dans mon petit programme de clignotement de led, j'ai placé "char Led = 0" avant la fonction "main" pour voir si je peux suivre la valeur "Led" pendant la simulation. Mais dès que je demande "debug" je reçois le message de la photo 1. En cliquant sur OK, Studio se ferme. En cliquant sur Annuler, je reçois un second message (voir photo 2).
J'ai essayé de réinstaller Studio4 mais cela reste pareil.

[invitee2def47b]

Pour visualiser la valeur de "Led", je te propose de la déclarer avec static pour voir si ça fonctionne. Le cas échéant, tu peux aussi essayer avec volatile.

[invitedca01a58]

Hello Adam,

Je n'avais moi-même pas vu les interventions après celle de Hary.
En incitant à la tolérance, je ne visais personne en particulier, mais je sens bien que l'atmosphère est électrique et que l'orage peut éclater à tout moment.

@ Mourad, tu as fait preuve d'une très belle maîtrise et d'une fameuse dose d'humilité.
Pour le français, ne t'inquiète pas. D'autres semblent maîtriser moins bien la langue, même si c'est leur langue maternelle.
-----------------------------

Pour ceux qui voudraient continuer le travail avec une platine arduino, ils doivent parvenir :

• soit à utiliser AVRdude pour programmer le µC par l'entrée USB de la platine (comme le fait l'IDE Arduino)
• soit utiliser un programmateur reconnu par Studio pour programmer par la prise ICSP

J'ai déjà montré que la deuxième solution fonctionne. Je vais essayer de faire marcher la première.

[invitedca01a58]

J'ai oublié de joindre les image au message #111.
Les voici.

[hary]

Sinon, j'ai ce type de truc pour programmer un ProMini qui n'a pas d'USB intégré.

http://www.ebay.fr/itm/6Pin-USB-2-0-...item5d4397cc60

Je l'utilise avec l'IDE Arduino. Ça fonctionne mais il faut appuyer sur le Reset au moment du Upload car le signal DTR est en 3.3V alors que mon ProMini est en 5V. Le signal DTR en 3.3V n'est pas assez prononcé pour être détecté. Je fait donc le reste à la main.

Je ne sais pas ce que ça vaut par rapport à un USBasp ?

[invitee2def47b]

@ Jean-Marie,

J'avais répondu par rapport à tes messages d’erreur précédents. Si je comprends bien, tu as juste placé la déclaration de Led avant le main() depuis? Dans ce cas tu peux le replacer après et essayer de les déclarer comme dans mon post #112 si tu le veux. Il y a bien sur une hypothèse derrière ma proposition.
Pour les 2 nouveaux messages d’erreur, il semblerait comme tu le sais déjà qu'AVR Studio ne sache pas quel debugger utiliser. As tu essayer de cocher "Manually choose the debugging engines"? Je ne peux pas essayer moi même parce que je n'ai pas encore reçu mon nouveau disque dur et celui-ci est plein.
Sinon, ça ne porte sans doute pas à conséquence mais pourquoi utiliser un char et non pas un byte?

@ hary
Je suppose qu'un bootloader est nécessaire dans le µC? Si oui alors ça crée une limitation par rapport à l'USBasp qui n'en a pas besoin. Ou je dis une bêtise? Pour le ProMini ça n'as pas d'importance vu que le µC est soudé mais sur une carte avec support de CI, il est intéressant de pouvoir acheter un µC vide et de pouvoir le programmer directement.

[invitef0c79320]

merci tout le monde pour leurs interventions.
nous sommes tous ici pour apprendre ou à aider qui veut apprendre. personne ne peut prétendre qu'il est le seul source d'information. le principe des forum c'est d'essayer de partager pour progresser, qu'on sois donneur ou preneur, on est ainsi tous gagnants.

moi j'ai une Arduino MEGA 2560 rev3. j'ai Atmel studio 6.2 sous un pc i7 4770 win8.1, je teste aussi l'AVR Studio 4.18 +sp3 + la dernière toolchain AVR 8bits-GCC v3.4.4.1229 d'Atmel.
je suis un technicien ascensoriste donc j'ai un petit peu d'outils électrique (fer à souder, un multimètre) et des cartes électroniques défectueuses pleines de composants électroniques.
j'ai récupéré une petite pupitre qui contient un afficheur LCD 20x4 de type Hitachi et 6 boutons poussoirs. je l'ai modifié pour l'adapter comme une "shield Arduino", je lui ai ajouté un buzer et une led.

lcd.jpg

j'ai finis d'adapter la librairie "LiquideCristal.cpp /.h" d'Arduino écrite en C++ en C standard. j'aménagerai le code et je le partagerai avec vous après.

pour ceux qui ont une ARDUINO Mega 2560, j'ai fais modifié une image téléchargée du net pour mettre en évidence les vrai pin du microcontrôleur que Arduino assigne a ses Pins de sa carte.

ArduinoMega2560Maping.jpg

ce que j'aime avoir c'est un ASPUSB, inchallah dans un future proche.

[invitedca01a58]

@ hary
Le lien que tu donnes montre un convertisseur USB --> liaison série TTL.
J'en ai aussi deux, que j'avais oublié de mentionner dans mon matériel.
Comme le dit Adam, ce convertisseur permet d'entrer en communication avec le µC par les lignes Rx/Tx à condition que le µC ait un bootloader pour établir la communication. Beaucoup de cartes Arduino actuelles se branchent directement sur l'USB car elle comportent déjà leur propre convertisseur USB --> série. Le convertisseur que tu présentes peut servir à programmer soit un Arduino sans convertisseur intégré (comme le Pro Mini), soit un ATmega sur Breadboard comportant un bootloader.
En ce qui concerne l'USBasp, sa sortie est destinée à la programmation de n'importe quel ATmega par le port SPI (ou ISP ou ICSP, c'est la même chose). Cette voie de programmation se fait sans bootloader, par communication hardware directe. Elle sert donc principalement à programmer les µC nus, mais peut aussi servir à programmer le µC d'une platine Arduino en accédant aux pins MISO, MOSI, SCK, RESET et GND. (Dans ce cas, la programmation efface le bootloader préexistant, mais il peut être rechargé au besoin).
L'USBasp fonctionne avec le logiciel AVRdude.
Le firmware de l'USBasp peut être remplacé (à l'aide d'un autre programmateur ISP) par un firmware clonant l'USBisp mkII. L'USBisp mkII est un programmateur de Atmel est est donc reconnu directement par Studio, que ce soit la version 4.18 ou la version 6.2
Le chargement d'un programme dans la mémoire du µC est beaucoup plus rapide avec l'USBisp mkII qu'avec l'USBasp.

@ Adam
Dans Studio6, je peux suivre la valeur de la variable Led en simulation à condition de la déclarer en-dehors de la fonction main. Avec ou sans "static" ne change rien. Par contre, la variable Led n'est plus accessible si je la déclare "volatile". Il va falloir que j'approfondisse ces notions de static et volatile.
Si je remets la déclaration de la variable dans la fonction main, aucune déclaration ne permet de suivre la variable: ni static, ni volatile, ni nue.
J'ai déclaré la variable comme "char" car le type "byte" ne semble pas exister en C.

Dans Studio4, pour le moment, je ne peux plus rien simuler car dès que je clique Debug, je provoque l'erreur.

[invitef0c79320]

@ 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.
pour une variable dite locale, le compilateur peut ne pas lui réserver de place dans la RAM interne du processeur lors de ses optimisations du code, mais la stock dans les registres généraux. pour forcer le compilateur à utiliser une case mémoire a la place des registres on déclare la variable avec un modificateur de type "volatile".

[Jack]

Dans Studio6, je peux suivre la valeur de la variable Led en simulation à condition de la déclarer en-dehors de la fonction main. Avec ou sans "static" ne change rien. Par contre, la variable Led n'est plus accessible si je la déclare "volatile". Il va falloir que j'approfondisse ces notions de static et volatile.
Si je remets la déclaration de la variable dans la fonction main, aucune déclaration ne permet de suivre la variable: ni static, ni volatile, ni nue.
J'ai déclaré la variable comme "char" car le type "byte" ne semble pas exister en C.

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)

Le type byte n'existe pas en effet dans la norme du langage C
Il est très facile de l'ajouter:
#define byte unsigned char

pour forcer le compilateur à utiliser une case mémoire a la place des registres on déclare la variable avec un modificateur de type "volatile"

Ca n'est pas tout à fait ça: certaines variables peuvent être modifiées par autre chose que le code du processus que l'on est en train d'exécuter C'est le cas lorsqu'un autre thread vient modifier une variable commune, mais aussi avec les registres. Le compilateur serait tenté de faire des optimisations en pensant certaines lignes de code inutiles. C'est le cas lorsqu'il suffit de lire un registre pour réarmer un flag par exemple.
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.
C'est très utiles dans les fonctions de traitement d'interruption par exemple.