Hello Slan85 et Mourad
Merci pour vos précisions. Je les ai prises en compte et tout fonctionne de manière super.
Ma ligne d'argument est maintenant celle-ci:
Selon qu'on choisit "debug" ou "release" dans la barre des tâches, c'est l'un ou l'autre des fichiers hex qui est flashé. Magnifique !Code:-C"C:\Program Files\Arduino\hardware\tools\avr\etc\avrdude.conf" -patmega328p -carduino -P COM5 -b115200 -Uflash:w:"$(TargetDir)\$(TargetName).hex":i
Merci pour l'astuceEnvoyé par Slan85
Hello tout le monde
Envoyer des messages au terminal du PC par UART, c'est pratique pour faire du debugging pendant le développement d'un projet. Par contre, une fois que le projet est au point et monté sur sa propre platine, il y a beaucoup de chance que la liaison série avec le PC ne serve plus à rien. Par exemple, si le projet est une horloge, un thermomètre, un régulateur de chauffage, un capacimètre, un luxmètre, ou autre, le projet s’accommoderait fort bien d'un petit afficheur LCD (du genre 2 lignes de 16 caractères) pour permettre de choisir les paramètres et d'afficher les valeurs mesurées. Ce type d'afficheur est très bon marché sur eBay.
16x2 LCD Display.jpg
Il y a quelque temps, j'ai monté un tel afficheur sur une petite platine de ma fabrication fonctionnant avec un ATtiny2313 que j'ai programmé en assembleur. Cette platine se connecte au µC principal par liaison série UART. Il suffit donc de débrancher la liaison PC et de mettre le LCD à la place. Lorsque le µC envoie quelque chose par UART, la ligne 2 du LCD scroll à la ligne 1 et le nouvel envoi s'affiche en ligne 2.
P1070182.JPG P1070177.JPG
Pour certains d'entre nous, l'obstacle principal d'une telle réalisation est la fabrication du circuit imprimé.
Sur eBay, on trouve des petits modules de commande d'afficheur LCD très bon marché, communiquant avec le µC selon le protocole série I2C.
I2C Interface for LCD1602.jpg
Il y a quelques jours, j'avais déjà trouvé un article expliquant comment rediriger le stdIn/Out vers l'UART. Voici un autre article du web selon lequel il est simple de rediriger le flux In/Out vers le "stream" de son choix. Petit extrait de l'article:
En même temps, cet article explique pourquoi nos essais d'affichage de "float" ne marchent pas.Setting up an O/I streams
So far we have set up an environment ready to support streams. Now we need to set up streams where we want our data to be send and received. You can set up any number of streams like for LCD, USART, ports, I2C, SPI, ADC and so on
Il y a de la matière à creuser, les amis !
Merci, je vais voir ce lien a tete reposé.
Je me suis acheté 2 LCD et 2 petits modules I2C. Ces modules sont essentiellement constitués d'un chip PCF8574 qui prend en entrée les deux fils de la communication (SCK et SDA) et qui redonnent en sorties les 8 bits du byte envoyé. On trouve sur le Net quelques site utilisant ce mode de communication.
Je suis toujours en train de me battre avec la redirection des flux stdin et stdout vers l'un ou l'autre périphérique. Comme je suis débutant en C, j'ai un peu de mal à voir clair entre les "FILE", "Stream", pointeurs, objets pointés, etc... mais à force de lire des infos à gauche et à droite, je finirai bien par y comprendre quelque chose. Je ne doute pas qu'il soit aussi facile de rediriger les stdio vers l'I2C et le LCD que vers l'UART mais quasiment tous les exemples du net concernent l'UART.
Ma petite platine d'expérimentation avec le connecteur ZIF devrait bientôt arriver.
Bien sûr, je tiens le forum au courant de l'évolution.
Bonne bronzette à tous les vacanciers.
Une adresse que tout amateur d'AVR doit connaître (et que je viens seulement de découvrir) : la centrale online de documentation d'Atmel
***** 5 étoiles au guide Michelin.
Pour la redirection des flux, c'est le même principe quelque soit le périphérique :
- Créer une fonction "putChar" ou getChar, qui va être chargée d'envoyer ou recevoir un caractère au périphérique souhaité. Cette fonction devra avoir un paramètre FILE *stream, pour pointer vers un flux d'entrée/sortie (vu comme un fichier)
- Créer une variable de type FILE, et l'initialiser avec FDEV_SETUP_STREAM(putChar, getChar , _FDEV_SETUP_RW);
putChar et getChar sont les fonctions crées à l'étape précédente.
Il est possible de n'avoir que l'entrée ou que la sortie, en remplaçant putChar ou getChar par NULL (suivant le cas, le troisième argument peut être _FDEV_SETUP_READ, _FDEV_SETUP_WRITE, ou _FDEV_SETUP_RW)- Faire pointer stdin/stdout vers l'adresse des variables créées à l'étape 2 : stdout=&uart_stream par exemple
Il est également possible d'avoir plusieurs afficheurs (par exemple un LCD et un terminal sur PC, via l'uart). Dans ce cas, seul l'un des 2 sera lié à stdin/stdout, mais il reste possible d'utiliser des fonctions type fprintf ou fscanf. Elles fonctionnent de la même façon, mais prennent un paramètre supplémentaire : le flux sur lequel écrire ou lire => fprintf(&uart_stream, "Hello world"); (ce flux est à nouveau créé par FDEV_SETUP_STREAM, la seule différence est qu'on n'y fait pas pointer stdout dessus).
Du coup, si tu l'as déjà fait pour l'uart, il ne te reste qu'à écrire les fonctions putChar/getChar pour les autres périphériques, le reste n'est que du copier/coller de ce qui est déjà fait.
Pour plus d'infos, avec un exemple détaillé : http://www.nongnu.org/avr-libc/user-...stdiodemo.html (doc officielle d'avr-libc)
Hello Slan85
Je vois que ce sujet n'a plus guère de secret pour toi.
Il m'a fallu plusieurs jours pour commencer à comprendre ce que tu expliques en quelques lignes. Heureusement, ça commence à entrer.
Peut-être peux-tu répondre à cette question. Si tu ne définis par exemple que la sortie et que tu remplaces getchar par NULL, est-ce que tu économises dans le code compilé toute la partie qui concerne scanf et les fonctions d'entrée associées ?
J'ai encore une autre question. Parfois certaines fonctions ou certains arguments ont un nom qui commence par 1 ou même 2 caractères '_'. C'est probablement un moyen de les distinguer d'autres noms, mais quel est le sens ? Je n'ai pas encore trouvé la réponse.
A ma connaissance, les fonctions qui ne sont pas utilisées dans le programme ne sont pas compilées, et donc pas présentes dans le code final.
J'ai un programme dans lequel j'ai un putchar et pas de getchar, et je viens de vérifier (par debug/windows/disasembly, en mode simulateur sous Studio 6), scanf n'est pas compilé. A priori j'aurais pu faire mettre un getchar, et le résultat aurait été le même si je ne faisait pas appel à scanf.
Tu peux le vérifier sur un programme simple : si une fonction (que tu as écrit ou venant des librairies standards) n'est jamais appelée, elle ne devrait pas être compilée (même si tu as inclu le fichier .h contenant sa déclaration).
Pour les _ sur les fonctions, c'est des conventions d'écriture du C pour certaines librairies. Je n'ai jamais vraiment compris l'intérêt non plus, ce lien donne quelques détails : https://stackoverflow.com/questions/...e-so-much-in-c
Slan85, merci pour tes réponses.
Pour la compilation, j'étais pas loin d'essayer de supprimer ce qui concerne scanf et dépendances pour avoir un code économique d'écriture sur un LCD, puisqu'il n'y a pas de retour provenant d'un clavier.
Pour les caractères '_', c'est vrai que si on les réserve aux librairies, cela permet d'éviter des collisions de variable avec son propre code.
merci Jean-Marie, c'est très riche d'information.
merci Slan85, tu as résumé le principe.
@Jean-Marie: le rôle d'optimisation du compilateur est d'optimiser le code pour sa taille, sa rapidité ou d'éliminer le code non sollicité(les variables et les fonctions non utilisé). donc si tu définis une fonction et tu ne l'appels pas le compilateur vas l'ignorer, et ne vas pas le compiler dans le fichier elf.
Hello Les amis,
Je viens de recevoir ma petite platine d'expérimentation. Je l'ai directement munie d'un Atmega1284P.
La platine est raccordée à un AVRISP mkII (cloné) dont elle reçoit son alimentation.
La platine comporte une Led bleue comme témoin de l'alimentation et 8 Leds raccordées au port D.
Le quartz est un 8 MHz mais peut être remplacé car il est monté sur socquet.
Bonsoir, Jean Marie
Après une petite pause, quelques commentaires/remarques :
- Il existe bien sûr des fonctions « printf» universelles qui permettent d’imprimer n’importe quoi au format voulu, mais elles « pèsent » plusieurs dizaines de Ko et sont peu adaptées aux uC surtout 8 bits. Elles sont en général (délibérément) évitées sur les uC.
- Il est temps maintenant de virer l’AVRisp et d’utiliser l’ATMELice. Un premier essai avec une led est très bien.
- Un petit outil bien utile et pas cher : http://cgi.ebay.fr/ws/eBayISAPI.dll?...m=141272714960
- Pour progresser, s’intéresser aussi à la structure des programmes : Round-Robin, séquenceur de tâches et RTOS (FreeRTOS.org par exemple)
Rajout: Non, les fonctions qui ne sont pas appelées ne se retrouvent pas dans l'exécutable. Elles sont compilées mais pas reprises au link. Si je me souviens, le fichier '.map' (mapping) donne une structure de l'appel des fonctions.
LVPBL
Dernière modification par laveplusblanc ; 01/08/2014 à 21h21.
un très bon achat pour compléter vos outils AVR (un programateur, un deboggeur Jtag, et une platine ZiF).
Hello laveplusblanc,
Pour printf, si je laisse tomber les floats (dont à priori je n'ai pas besoin), la compilation se limite à +/- 2200 bytes. Pour un ATtiny, c'est insupportable mais avec mon Atmega1284, j'ai 128 k de flash, donc c'est peu. Vu la facilité d'affichage formaté, sur LCD par exemple, je crois quand même que cela vaut la peine de garder cette fonction.
Pour l'ATMEL ICE, je suis d'accord avec toi. C'est mon prochain objectif. La sortie de l'Atmel ICE est un connecteur 10 voies au pitch 1,27mm. J'ai dessiné sur Eagle un petit adaptateur pour passer au pitch 2,54mm. Avec un peu de chance, j'aurai peut-être le temps de le réaliser demain.
Pour l'analyseur logique, je crois que j'ai trouvé le même à meilleur compte. Je n'ai jamais utilisé ce genre de matériel. Je pense que c'est un enregistreur à 8 voies. Mais ne faut-il pas un logiciel spécifique pour exploiter les données ?
Les RTOS et techniques associées me mettent l'eau à la bouche. Mais je connais encore tellement peu de C ! N'est-ce pas un peu prématuré ?
Hello Mourad,
La platine dispose de 4 ports de 8 bits. Pour pouvoir les exploiter, je crois que je vais disposer la platine ZIF entre deux breadboard et reporter 2 ports sur chaque breadboard avec des câbles plats.
Les sondes JTAG bon marché de eBay semblent limitées à Studio4, ainsi qu'à certains ATmegasThis simulator can be infinite firmware upgrade, both upward and downward compatible with the latest software support for AVR STUDIO 4.12/4.14/4.16/4.17/4.18!!!!Je ne vois pas l'Atmega1284 dans la liste mais on dit "support all AVR with a JTAG port". Donc, ce n'est pas impossible qu'il soit reconnu.Supported chips:
ATmega128, ATmega128L, ATmega16, ATmega162, ATmega162V, ATmega165, ATmega165V, ATmega169, ATmega169V, ATmega16L, ATmega32, ATmega323, ATmega323L, ATmega32L, ATmega64, ATmega64L (support AVR all with a JTAG port of the microcontroller).
En pensant à ceux qui préfèrent rester en Studio4, j'ai commandé cette sonde JTAG :
Le prix est ridiculement bas : 4,82€
Donc ce n'est pas la ruine si ça ne marche pas. Et peut-être qu'avec un peu de chance, l'ATmega1284 sera reconnu.
« Tempore cognoscemus » (qui vivra verra).
Entre parenthèses, cette boutique chinoise propose plein de choses intéressantes à des prix souvent attractifs. Vaut le détour.
Dans la même boutique, je me suis acheté cet analyseur logique. A nouveau, prix imbattable !
Très, intéressant, mais peut-être va-t-on en rester là car ça commence à faire un peu trop vitrine publicitaire.
la platine que tu as acheter n'as qu'un support zif, avec un câblage fixe hardware du port JTAG.
ce que limite le nombre de microcontrôleur qui ont les même pins qui s'accordent avec ceux du Port JTAG présent sur la platine.
C’est peut être une conclusion un peu rapide.
Mis à part cet analyseur qui tient plus de l’échange de bon plan que de publicité, il n’y a pas de référence de matériel et logiciels autres qu’outils de développement spécifiquement AVR.
Il n’y a pas non plus je pense de revendeur de matériel chinois ou atmel qui intervient sur ce post, contrairement au commercial microchip qui semble attitré à ce forum.
Ou alors, pour rester cohérent, il faudra s’interroger sur tous les posts avec ICdé machin, Pickit truk et PIC dem brol.
LVPBL
Sorry, Jack, je ne l'ai pas fait exprès. J'ai chaque fois donné le lien pour que ceux qui sont intéressés puissent lire les informations exactes. Mais en fait, ce n'est pas une très bonne solution car il y a beaucoup de chance que le lien ne fonctionne que pendant quelques semaines. Peut-être vaudrait-il mieux copier dans le forum le texte du descriptif de l'article. Sur le Forum Arduino, on demande effectivement de ne pas mettre de lien eBay car ces liens sont très provisoires. Que conseillerais-tu ?
J'ai pensé à ce problème. La solution la plus évidente est d'investir dans une platine STK500 d'Atmel mais c'est pas gratuit.
Une autre solution est possible : se construire soi-même une platine accessoire pour les µC à 28 pins par exemple. Cette platine comporterait un ZIF à 28 pins, son propre connecteur JTAG et 2x20 pins mâles sur la face inférieure pour s'insérer dans le ZIF de la platine de base. C'est faisable avec un simple morceau de veroboard préperforé, quelques fils et un peu de soudure.
Ceci dit, il ne serait pas difficile de reproduire soi-même la platine achetée mais avec un ZIF de 28 pins, couvrant ainsi la plupart des ATmegas non cms.
Pour les ATmegas cms (en petits boîtiers de suface), il n'y a pas d'autre solution que d'avoir une platine de développement spécifique car ces µC doivent être soudés sur leur platine.
Je pense que tu n'as pas bien compris le sens de mon intervention: ce qui me gène, c'est qu'on commence à citer toutes les bonnes affaires liées à ce site en particulier.
Si quelqu'un a besoin d'une référence pour acheter une sonde JTAG, donner un lien permettant d'en trouver une pour pas cher ne me dérange pas.
Si quelqu'un d'autre a un soucis avec son pic et qu'une personne lui propose une solution qui marche et qui répond à ses problèmes dans une marque qu'il connait bien, ça me va aussi. En revanche, si ladite personne tente de nous proposer certains produits de la ladite marque sans qu'on le lui ait demandé, dans ce cas la modération intervient.
Tu peux toujours faire référence au site du fabricant en faisant part de tes conclusions sur le fonctionnement effectif de cet analyseur.
Pour le reste, pas de soucis, je me doute bien que tu n'es pas commercial pour ce site et que tu voulais nous faire part de ton enthousiasme pour ces produits vraiment pas cher. Ce erait bien d'ailleurs d'en dire rapidement ce que ça vaut qualitativement.
Hello Mourad,
Je trouve ceci:
Sauf erreur, les µC acceptés par JTAGICE sont des 40 pins.The JTAGICE was the initial version released by Atmel. It only supports JTAG in-circuit debugging/programming for a very limited number of AVR microcontrollers -- see the AVR Studio software release notes for a full list. The majority of third-party clones on the market is only compatible to the JTAGICE with the same limitations. Last time we checked, AVR Studio supported the following micros with the JTAGICE: ATmega16, ATmega16L, ATmega162, ATmega162L, ATmega169, ATmega169L, ATmega32, ATmega32L, ATmega323, ATmega323L, ATmega64, ATmega64L, ATmega128, ATmega128L, AT90CAN128 (with limitations), AT90CAN128L (with limitations).
The JTAGICE mkII is Atmel's successor to the original JTAGICE. The JTAGICE mkII model supports all AVR microcontrollers.
Atmel a proposé JTAGICE (la premiere version) en open source (hardware et software), et elle ne supportait qu'un nombre limité d'AVR qui sont :source 1
- AT90CAN128
- ATmega128
- ATmega16
- ATmega162
- ATmega169
- ATmega32
- ATmega323
- ATmega64
source 2
et c'est aussi les cas pour tous les clones de JTAG ICE.
si j'ai les moyens et l'occasion d'avoir un Debugger, je prendrais un Atmel ICE. elle supporte bien mon Arduino Mega (ATmega2560).
Hello Mourad
Je vois que nous avons la même liste de µC supportés par JTAG ICE.
Mais étant donné que Studio4 supporte l'ATmega1284 et que celui-ci a le même pinout que l'Atmega16 ou 32, je me demande si l'ATmega1284 ne peut pas être ajouté à la liste. Je pourrai répondre à cette question quand mon JTAG ICE arrivera.
Merci pour tes liens.
En attendant, hier je n'ai pas eu l'occasion de fabriquer mon petit adaptateur pour l'ATMEL ICE. Peut-être aujourd'hui ?
Pour ma petite platine d'expérimentation avec le connecteur ZIF, tout fonctionne comme prévu (JTAG pas encore testé). Le connecteur ZIF est incomparablement plus facile à utiliser qu'un soquet ordinaire. Pas besoin de redresser les pattes, pas de risque de torsion de celles-ci. L'introduction et le retrait du µC se font sans exercer de force. Une fois le µC en place, il suffit d'actionner le levier et les contacts sont établis. Dommage que cela n'existe pas pour les composants de surface.
Rien à redire non plus sur la qualité de fabrication de la platine. Mais vous connaissez encore beaucoup d'électronique fabriquée autre part qu'en Asie ?
L'atmega1284 est compatible pin à pin avec la liste des Avr ci dessus (atmega16).
J'espère qu'il sera supporté parmus cette liste.
Hello les amis,
J'ai terminé l'adaptateur de JTAG (du pitch 1,27mm au pitch 2,54mm).
Sans avoir l'air de rien, j'y ai travaillé 4 heures : gravure du PCB, perçage, soudure et vérifications.
Voici le dessin du PCB sous Eagle:
Adaptateur JTAG Eagle.jpg
Voici le PCB après gravure :
Adaptateur JTAG PCB.jpg
Voici la face supérieure après soudure :
Adaptateur JTAG face sup.jpg
Il ne me reste plus que la mise en route de l'ATMEL-ICE sous Studio6, mais pour ça, je dois relire la documentation.
