De nombreux participants à ce forum-ci n'ont pas suivi le cours MOOC. Donc ils n'y comprendront rien aux devoirs qu'on a dû remettre. Ce serait peut-être plus adapté d'utiliser plutôt le forum propre du MOOC (en demandant aux instructeurs s'ils sont d'accord qu'on publie nos solutions).
Vous en faites pas pour nous, y'a déjà un bon moment qu'on est larguéEnvoyé par Jean-Marie45
Je suis Charlie
@Jean-Marie
j'avais fait un fil sur le forum du MOOC, en donnant le principe.
pour ceux de ce forum qui n'ont pas l'énoncé, le voici
****************
Serrure codée
Pour allumer la Led L1, il faut successivement :
- appuyer sur P1
- relâcher P1
- appuyer à nouveau sur P1
- appuyer sur P2 (sans relâcher P1)
- relâcher P2
- relâcher P1. C'est alors que L1 doit s'allumer durant trois seconde.
La vitesse d'exécution de la séquence n'est pas importante. Toute autre manipulation est considérée comme fausse. Elle doit être suivie :
- de l'attente jusqu'à ce que plus aucune touche ne soit pressée
- d'une attente supplémentaire d'une seconde.
Ensuite, le programme doit reprendre sa détection.
****************************** *************
je m'aperçois d'ailleurs que j'avais zappé la fin du problème (délais d'attente), mais apparemment ça a marché quand même
Je rejoins tout à fait l'avis Jean-Marie.
Si j'avais passé du temps à concevoir des exercices et à mettre au point un correcteur automatique, je suppose que je n’apprécierais pas qu'on publie les énoncés sur un forum public et que cela mette en péril les prochaines cessions.
Même si le risque est faible, je pense qu'il faudrait demander l'accord des formateurs ne serait-ce que pour le principe, et ce même si le forum du MOOC était utilisé.
Dernière modification par Adam_D ; 01/07/2014 à 19h53.
D'ailleurs le code de l'honneur du MOOC précise bien:
3. I will not make solutions to homework, quizzes or exams available to anyone else.
et ne précise pas de limitation de durée.
Dernière modification par Adam_D ; 01/07/2014 à 19h59.
Bonjour Jean-Marie,
(En réponse au post #143)
En fait je l'ignorais autant que toi, j'ai juste exploré un des liens que tu as donné et fais quelques recherches. L'intérêt de ces fonctionnalités m'a immédiatement interpellé.
J'en profite au passage pour indiquer que contrairement à ce que j'avais dit, ces fonctions existent déjà dans AVR Studio 4.18.
Dernière modification par Adam_D ; 01/07/2014 à 20h17.
@ bobfuck et @ Jack Encore une fois merci beaucoup pour vos contributions, elles m’apprennent beaucoup et/ou me forcent à revisiter des notions que je n'avais plus utilisé depuis + de 15 ans.
Juste une (toute) dernière précision et après je reviendrai à des préoccupations moins complexes pour nous:
Concernant les variables partagées entre le programme principal et les interruptions qui doivent donc être déclarées "volatile", quand tu dis:
Desquels parles tu exactement? J'en profite pour tenter une classification (grossière) des registres:
A) ceux qui sont relatifs au µC (unité centrale s'entend)
B) ceux qui sont relatifs aux périphériques intégrées au µC (TIMER, EEPROM, ADC,...) et qui sont qualifiés d' I/O Register (Attention: il ne comprennent pas les registres d'E/S comme PORTB, PINB par exemple qui appartiennent à la 1re catégorie).
Pour chacune des ces 2 catégories:1) certains ont déjà un rôle assigné (SREG, DDRB,...).Parles-tu des GPI/OR, de tous les registres à usage général, ou d'autres encore? C'est important pour pouvoir achever le résumé simple sur l’attribut volatile.
2) d'autres sont disponibles pour un usage général (par exemple comme cache) et sont qualifiés de GPR "General Purpose Register".
Bien sur, volatile n'aura d'effet que sur le compilateur (et peut être certains processeurs multi-core ou multi thread), et ne protégera pas contre une programmation qui permettra à une interruption ou à une fonction de modifier une variable au mauvais moment, au mauvais endroit ou plus généralement d'une manière qui ne convient pas (d'où les mises en garde de Jack et de bobfuck sur la responsabilité du programmeur dans la sauvegarde du contexte, et sur les problèmes généraux liés aux variables partagées), mais c'est indépendant de volatile.
ATTENTION: Il y a une petite erreur dans mon post précédent:
PORTB, DDRB, PINB... font bien sur partie de la seconde catégorie (I/O Register).
Avec toutes mes excuses! Quel dommage qu'on ne puisse pas modifier ses propres posts!
bonjour,
à propos de mon précédent post et des commentaires suscités
je ne voyais pas les choses ainsi, mais bon.
C'est vrai qu'il y a la charte signée.
C'est une erreur de ma part.
gégé62
Le mot anglais "register" désigne en gros une bascule D, autrement dit en francais, un flop avec un clock enable.
C'est juste un élément de mémoire statique synchrone dans lequel on peut stocker 1 bit. Si on ne fait rien, le bit reste stocké et on peut le voir sur la sortie du flop. Si on présente un nouveau bit sur l'entrée et qu'on active l'action d'écriture (le clock enable) alors le nouveau bit est stocké à la place de l'ancien. Si tu en as 32, ça donne un registre 32 bits...
Comme les "registres" du CPU et à peu près tous les "registres" des périphériques sont implémentés avec ce genre de machin, on les appelle des "registers" (en anglais) et puis en français c'est devenu des "registres", pis voilà...
Les registres du cpu c'est ceux que tu utilises dans les instructions. Ils n'ont pas d'adresse, on y accède par leur nom genre "add r1,r2", ils peuvent avoir des noms (A,B,EAX,SP,status,etc) ou des numéros (d0-d7, etc).
Les registres de périphérique, eux, ils ont une adresse. On les appelle des registres mais la méthode d'accès est complètement différente de celle des registres du cpu, c'est une simple opération mémoire...
Sur certaines architectures, on accède à ces registres de périphériques exactement comme au reste de la mémoire (genre avec une instruction mov) ; sur d'autres il y a des instructions spéciales pour y accéder, genre IN/OUT. Le but est d'informer le cpu que c'est pas une mémoire "basique", par exemple elle peut avoir plus de latence, ou le périphérique utilise un accès asynchrone, etc.
De nos jours dans les uC on a plutôt tendance à utiliser des instructions mémoire standard et à rajouter un MMU simple qui a une liste de zones d'adresses et de méthodes d'accès correspondantes, par exemple il sait que dans telle zone il y a une SRAM qui répond en 1 cycle, telle autre zone c'est une DRAM, telle autre zone c'est tel ou tel périphérique, etc.
Pour ajouter à la confusion, dans un uC il y a sur le même chip le processeur (avec ses registres) et les périphériques (avec ses registres aussi).
> (Attention: il ne comprennent pas les registres d'E/S comme PORTB, PINB par exemple qui appartiennent à la 1re catégorie).
Tout ça, c'est des registres de périphériques, pas des registres de cpu, si tu regardes dans les .h tu trouveras des #define avec des adresses...
Bonjour Gégé,
Ça ne reste que mon sentiment. Dans tous les cas, ton idée de comparer nos solutions reste bonne, pourquoi ne pas nous lancer dans un nouvel exercice (sur une autre thread pour ne pas tout mélanger)? Si tu tiens à rester sur les exercices du MOOC, peut être que c'est possible sur son forum avec l'accord des formateurs comme l'a suggéré Jean-Marie ?
#gégé62
Tu ouvres un nouveau thread on le nome par exemple "exercices et solutions", où on pose des exercices genre ceux du MOOC, et on laisse le temps au participants pour poster leurs solutions. Et on discute après les methodes et les astuces des bons codes.
Bonjour Bob,
Merci pour ta réponse toujours très complète.
En fait, ma question était plutôt "pour quels registre faut-il employer volatile? (tu disais les registres hard, d'où mon interrogation)"
Je suppose qu'il ne s'agit pas des registres dédiés ou spéciaux vu que ce ne sont pas des variables à déclarer. Peut être parlais-tu alors des variables ou pointeurs auxquels sont allouées des registres à usage général (GPR et/ou GPIOR)?
Exact, j'avais déjà corrigé dans le post.
( Pour qu'on s'y retrouve tous, Bob parle ici des registre (de CPU par opposition à d'I/O= de périphériques) à usage général et non des registres (de CPU) dédié ou spéciaux comme le registre d'instruction par exemple).
Ça doit dépendre des processeurs parce que pour l'Atmega 328P comme pour le Pic 16F84, ces registres ont bien une adresse même s'ils sont appelés r1,...rn dans le code assembleur mais bon c'est vraiment un point de détail.
Une curiosité sur l'Atmega 328P, pour un même registre, l'adresse à utiliser peut être différente selon l'instruction utilisée (IN/OUT ou LD/ST, voir datasheet p.625 note 4 en fin de page).
Toujours pour illustrer ce dont Bob nous informe, l'accès aux 32 GPR du CPU est effectué en 1 seul cycle d'horloge car ils ne sont pas physiquement situés dans la RAM (même s'ils ont une adresse comme si c'était le cas) contre 2 cycles pour les autres registres qui sont implantés dans la RAM, d'où l’intérêt de les utiliser comme cache (ou comme espace de stockage).
D'où ma question sur volatile que je repose au tout début de ce message. bob?
Dernière modification par Adam_D ; 02/07/2014 à 16h47.
@Adam, Mourad, Jean-Marie...
et tous
non je ne suis pas fixé sur les exercices du MOOC, et pas assez sûr de moi pour lancer un thread . J'en suis encore à essayer de mettre bout à bout tout ce que nous avons appris, l'air de rien c'était copieux
Je voulais seulement soumettre pour ce problème particulier une solution qui (je crois) détournait un peu la difficulté programmistique () avec une astuce sous forme d'un algorithme.
Cependant le problème de confidentialité et respect de la charte pourrait se reproduire dans ce thread. Il me semble plus simple effectivement de demander l'autorisation aux deux profs de discuter ici librement des exercices et de leur(s) solution(s).
Je me permets de le faire sur le forum du MOOC dès maintenant.
Bonne soirée
c'est pareil sur tous les AVRs, les 32 registres généraux (General Purpos Registers = GPRs) sont placés au début de la RAM (virtuelle) a l'adresse 0x0000 (R0) jusqu'au 0x001F (R31).Bonjour Bob,
Une curiosité sur l'Atmega 328P, pour un même registre, l'adresse à utiliser peut être différente selon l'instruction utilisée (IN/OUT ou LD/ST, voir datasheet p.625 note 4 en fin de page).
Toujours pour illustrer ce dont Bob nous informe, l'accès aux 32 GPR du CPU est effectué en 1 seul cycle d'horloge car ils ne sont pas physiquement situés dans la RAM (même s'ils ont une adresse comme si c'était le cas) contre 2 cycles pour les autres registres qui sont implantés dans la RAM, d'où l’intérêt de les utiliser comme cache (ou comme espace de stockage).
D'où ma question sur volatile que je repose au tout début de ce message. bob?
l'adressage des registre de périphériques d'entrées sorties (SFRs = Special Function Registers) commence juste après les 32 registres GPRs depuis 0x0020 jusqu'au 0x005F.
puis commence la vrai RAM interne SRAM (reel) à partir de 0x0060.
les deux instructions assembleur LDS et STS peuvent accéder a toutes la plage de la mémoire RAM (virtuelle). mais la particularité des instructions IN/OUT c'est qu'elles ne voit que la plage des SFRs seulement, indexés depuis 0x00 et non de 0x0020.
Hello Mourad
Super, cette explication.
On dirait que Adam et toi avez de bonnes notions d'assembleur.
A propos, de quel document tires-tu ce paragraphe de "IN versus LDS" ?
Bonsoir Mourad,
Je n'ai pas dis le contraire, simplement je ne l'ai vérifié que pour l'Atmega 328P (ainsi que tous les µC indiqué sur le datasheet).
Par contre, il est vrai que je n'avais pas vu que les 64 registres de périphérique (I/O Registers) ne sont pas dans la RAM (sauf les 160 suivant) et sont donc accessibles eux aussi en 1 seul cycle d'horloge (contre 2 pour la RAM).
Ce ne sont pas que des SFR parce que cette plage comprend 3 registres à usage général pour les périphériques (GPIOR).
@Jean-Marie45: Bonsoir
ce paragraphe est tiré d'un super livre ecrit principalement par Muhammad Ali Mazidi:
The AVR Microcontroller and Embedded Systems: Using Assembly and C
@ADAM:
tu parles de quels registres GPIOR? GPIOR0,1 et 2. sincèrement je ne sais pas à quoi sert ces registres. en tous cas je ne pensepas qu'ils sont pas parmis les GPRs.Ce ne sont pas que des SFR parce que cette plage comprend 3 registres à usage général pour les périphériques (GPIOR)
les SFR sont touts les registres a part ceux GPRs (les registres R0 à R31).
les SFRs par defaut inclut tous les registres de périphériques: les registres de ports d'entrées/sorties (PORTB, PINB, DDRB) , ceux des timers, des registre d'etat ( le SREG) et de Stack (SPh et SPL), USART, SPI, WDog, etc...
Justement, ce sont des registres à usage général (GPIOR), pour moi ça ne peux pas être des registres spéciaux (ou dédiés), mais si on a une définition différente ce n'est pas grave.
Pour leur utilité, il sont utiles en particulier pour stocker des variables globales et des fanions (Flag), notamment GPIOR0 qui, comme tous les 32 premiers registres I/O sont accessibles par bit.
Hello Mourad
Le bouquin que tu as renseigné semble très bien fait et bien adapté à ce que nous voulons faire. Il est accessible aux débutants et commence avec les notions de base de la logique digitale. Il se concentre ensuite sur les AVR d'Atmel en utilisant Studio. Afin de faire comprendre les entrailles du µC, il utilise à la fois l'assembleur et le langage C de AVR-GCC. Il a choisi l'ATmega32 comme µC d'expérimentation.
Son seul inconvénient est sont prix extrêmement élevé ( 162 $ ). Heureusement pour des hobbyistes comme nous, il n'est pas très difficile de le télécharger en pdf.
Ce serait un bon support pour progresser ensemble. Ceci relance la question que j'avais déjà posé il y a un petit temps et qui n'a guère reçu de réponse : ne serait-ce pas un bonne idée de se choisir un µC commun (sur un platine commune, et avec un support de cours commun)? Il y a déjà 2 semaines que le thread a débuté. Beaucoup d'informations intéressantes ont circulé mais aucune direction précise n'a été suivie, de sorte que nous en sommes toujours au "blink".
Bonjour Jean-Marie,
Ok pour choisir un µC commun, ou une platine. Pourquoi ne pas conserver le 328p pour rester dans le simple et pouvoir utiliser l'USBasp? Son datasheet reste lisible, sa structure compréhensible, et rien n'interdit d'évoluer par la suite.
Ce n'est qu'une proposition, comme je n'ai pas de projet concret à court terme, je ne suis pas fixé sur un modèle particulier.
Pourquoi ne pas plutôt opter pour un AVRISP MKII. Il est un peu plus cher mais permet d'évoluer ensuite vers les ATXmega et le mode de programmation PDI.
Apparemment il est possible de transformer l'USBasp en AVRISP MKII, qui est quand même 10 à 15x plus cher (en version officielle du moins). Pour le prix, autant passer à l'Atmel-ICE à- de 50€. Mais pourquoi pas?
Sinon le PDI à des avantages sur le SPI?
Dernière modification par Adam_D ; 04/07/2014 à 18h48.
Oui, c'est vrai qu'il est cher (27€), mais c'est du pur Atmel, et il n'y a pas de surprise.
Mais je ne savais pas que l'USBasp pouvait assurer le même service. Dans ce cas il ne faut bien sûr pas changer.
Depuis que je suis passé à l'ATXmega, je remarque que la programmation PDI (qui ne nécessite que 3 fils +VCC) est beaucoup plus rapide.
Bon, ce n'est pas un argument-massue, mais c'est surtout que l'ATXmega n'accepte pas le mode ISP.
Dernière modification par lpt1com2 ; 04/07/2014 à 18h59.
Bonsoir,
pour ma part je suivrai l'orientation générale, n'ayant pas d'avis technique et acceptant d'y mettre les quelques euros ou dizaines d'euros nécessaires.
@Jean-Marie, pour mon info
quand tu dis " un uc commun sur une platine commune", qu'entends-tu par "platine", un circuit imprimé sur lequel nous soudons un support "DIL", ou qque chose prêt à raccorder comme Arduino ?
A part cela, j'ai bien envie d'essayer quand même, pour ma culture, la programmation via USBAsp dont tu parles plus haut, mais je n'ai pas bien compris comment on procède. J'ai compris qu'il faut deux USBAsp dont l'un est à modifier pour une question de bootloader, mais ça s'arrête là.
Comme tu as prévu de décrire plus en détail ces points j'attends la suite avec intérêt
-mais il faut du temps...toujours du temps, et je pense que tu en passes déja beaucoup sur le forum-
bonne soirée
Je suis de l'avis de ADAM, il ne faut pas inventer la roue. Une ARDUINO UNO est tres bonne platine, avec son ATMEGA328P de forme de boitier DIL. simple à progmmer et le demonter pour le placer sur carte PCB finale ou sur une plaquette d'essai.
En plus le 328p reste universel dans le milieu de la game des Avr 8bits, tres répondu(moin de 5euro) et aisément accessible.
Je me demmande si on peut modifier un USBASP EN avrISP MKII, par un arduino, sans faire recours a un autre USBASP.
Je n'ai pas été très bavard sur le forum car je voulais choisir un nouveau laptop à ma fille cadette (qui vient d'être diplômée).
Afin d'aider à choisir un µC, j'ai fait un petit tableau de comparaison entre un ATmega32, un 328, un 128 et un 2560.(voir image).
Dans ce tableau, je ne mentionne que les points où il y a des différences, par exemple, la mémoire, le nombre de pins I/O, etc. Je passe sous silence toutes les caractéristiques qui sont communes aux 4 µC, par exemple, il peuvent tous tourner à la fréquence maximum de 16 MHz.
J'ai ajouté les platines les moins chères que j'ai trouvées sur eBay pour mettre en oeuvre ces µC.
Bien sûr, il est toujours possible de se contenter d'un µC DIP sur une breadboard (mais les contacts des pins ne sont pas fameux) ou de construire soi-même la platine à l'aide d'une plaque de type veroboard ou d'un vrai circuit imprimé homemade, mais les platines de eBay ne sont vraiment pas chères.
A noter que l'ATmega328 existe en version DIP mais la platine où il est monté sur socket coûte un peu plus cher (7,24€)que la version SMD reprise dans le tableau. Par contre, elle offre l'avantage (comme le signale Mourad) de pouvoir transférer le µC une fois programmé dans son circuit définitif et de mettre un nouvel ATmega328 sur l'Arduino pour le prochain projet.
Je confirme qu'on peut transformer un USBasp en AVRisp mkII.
Je n'ai pas encore fait de dossier d'explication mais le principe est simple. Il faut d'une part l'USBasp qu'on veut transformer (Un modèle chinois convient très bien. Je viens de commander celui-ci, non pas pour le transformer en AVRisp mkII mais pour l'utiliser comme USBasp). D'autre part, il faut un programmateur pour le transformer. Je sais qu'on peut utiliser un Arduino comme programmateur. Le site Arduino explique comment faire mais je ne l'ai jamais pratiqué moi-même. Donc, en principe, un Arduino est capable de transformer l'USBasp en AVRisp mkII (à condition que l'Arduino soit capable de modifier les fuses de la cible, ce que j'ignore).
La transformation consiste à remplacer le programme inscrit dans l'USBasp par un fichier hex imitant le comportement de l'AVRisp mkII. Il faut également écrire un fichier hex dans l'EEPROM et adapter les Fuses. A ceux qui voudront tenter l'expérience, je tiendrai les fichiers hex nécessaires à leur disposition (en privé).
P.S. J'ai déjà 3 USBasp transformés en AVRisp mkII de cette manière.
A ceux qui se sentiraient un peu perdus par la transformation, je peux commander pour eux un USBasp chinois, le transformer (gratuitement) en AVRisp mkII et leur envoyer le programmateur transformé, mais je pense que l'envoi à partir de la Belgique coûtera plus cher que l'USBasp lui-même !
La modification de l’USBasp est-elle totalement compatible avec l’AVRisp MKII ?
Si oui, ça m’intéresse (je vais aussi chercher de ce côté).
Je dis ça car le MKII bénéficie des mises à jour gratuites du firmware par Atmel (j’en ai déjà eu 2).
Hello lpt1com2
C'est la troisième fois que je t'écris une réponse. J'ai perdu les 2 premières réponses en passant en mode avancé. Le forum semble avoir des problèmes.
Je ne pense pas que l'AVRisp mkII cloné puisse bénéficier des mises-à-jour d'Atmel car le hardware est probablement fort différent du vrai appareil.
Toute l'histoire du clonage a commencé en mars 2010 lorsque j'ai acheté mon clone ICI.
Je me suis demandé si je ne pouvais pas cloner moi-même un USBasp chinois. J'ai donc copié le firmware, l'EEPROM et les fuses du clone et c'ai réinjecté ces données dans un USBasp. Miracle ! L'USBasp a été reconnu par Studio4 comme un AVRisp mkII. Plus tard, j'ai essayé de l'utiliser avec Studio5 mais ça ne marchait pas. Il y a quelques semaines, j'ai installé Studio6.2 et mes clones sont à nouveau reconnus. Peut-être un bug de Studio5 ?
Que ceux qui ont envie d'essayer le clonage me contactent par message privé.
