Tout à fait, mais c'est le plus gros site de modélisme au monde donc ils se réapprovisionnent régulièrement, puis de toute façon je ne suis pas pressé
Je ne sais pas si sans un usbasp on peut également utiliser avr-dude pour envoyer notre programme compilé par l'usb et le ftdi embarqué sur l'arduino nano sans que ça enlève le boot loader?
Petite chose que je viens de lire:
http://fr.wikipedia.org/wiki/Serial_...eral_Interface
Ce qui signifie que mon code qui gère des max7219 ne créé pas de liaison de type spi mais plutot de type i2c? Car pour brancher un max7219 j'ai besoin de 3 fils, data, load, clock, et pour en brancher jusqu'a 8 il m'en faut toujours le même nombre, contrairement à ce qu'explique wikipedia avec spi, ou il faut 3 fils à la base + 1 par max7219 ou autre ic.
Pour ce qui est d'utiliser n'importe quelle pin pour faire une liaison série et donc qu'arduino ai codé une liaison série en manuel sans utiliser une fonction hardware sur des pins dédiées spécifiques, je pense finalement que c'est très bien car ça permet d'avoir un système plus souple, si on utilise beaucoup de pins on peut faire ce qu'on veut, enfin je ne sais pas ce que vous en pensez?
Quel bugs?Studio 4.19 et Studio 5 contiennent des bugs et ne sont pas conseillés.
J'ai installé la 4.19, s'il y a des bugs j'aimerais bien les connaitre !
Pour l'instant j'ai vu les fichiers absents pour le C (d'ailleurs décrit dans les posts précédents)
et le driver AVRISP qui est spécifique à Studio 4.
Voir par exemple ici : http://www.ermicro.com/blog/?p=2292Envoyé par sylvainmahe
L'avantage d'utiliser un moduler dédié est que cela décharge le CPU
LVPBL
Dernière modification par laveplusblanc ; 13/10/2014 à 22h49.
Ok merci pour le lien *laveplusblanc
J'ai bien lu son code et j'ai l'impression qu'à part les parties arduino du mien transformées en avr sur le sien, les seules parties qui changent sont le fait d'utiliser les bons ports, et c'est tout. Peut être je me trompe mais je ne vois pas ou est l'erreur chez moi à part ça.
Je vous monterais sans doute mon code une fois rentré chez moi, la je suis en déplacement donc j'ai que le pc portable sans mes trucs dessus.
Dernière modification par sylvainmahe ; 13/10/2014 à 23h51.
Voila je suis sur mon pc:
Je vais attendre d'avoir le usbasp car en mettant avrftdi en argument (-c) ça ne passe pas, enfin je m'en doutais un peu
Sinon y a du monde dans /arduino/hardware/arduino/bootloaders mais c'est un petit bordel la dedans donc je ne sais pas trop lequel utiliser.Code:#!/bin/bash while true do avr-gcc main.cpp -mmcu=atmega328p -DF_CPU=16000000 -Os -o main.elf objcopy main.elf -O ihex main.hex avrdude -c avrftdi -p m328p -P /dev/ttyUSB0 -U flash:w:main.hex read clear done exit 0
Hello les amis,
Je reviens un peu sur le devant de la scène du forum après une interruption de presque 2 semaines due au fait que je ne recevais plus d'avis de nouveaux messages, mais également due à une petite hospitalisation et surtout à une mise au point laborieuse de mon programme de Terminal série sur LCD 16x2.
Hier en fin de soirée, mon programme étant fonctionnel, j'ai voulu le déposer sur le forum mais j'ai constaté que le forum avait avancé de 3 pages pendant mon absence. J'en ai terminé la lecture ce matin et j'en profite pour souhaiter la bienvenue à Sylvain qui nous sera probablement d'un grand secours vu ses compétences en "C épuré".
Comme promis, je vous livre donc mon petit programme. J'espère qu'il ne contient plus trop de bugs. Par contre, il est certainement perfectible.
Dans son état actuel, il peut servir de module d'affichage autonome, à adjoindre à n'importe quel projet désirant afficher des données à envoyer par USART.
Le programme est écrit pour un Atmega8 tournant à 8 MHz avec l'oscillateur interne. Je n'ai pas utilisé de quartz pour pouvoir utiliser la totalité du PortB pour la commande du LCD. Le programme faisant 578 bytes, il pourrait facilement être adapté à un Attiny2313. Il peut aussi être facilement adapté à un Atmega328 mais ce serait un peu du gaspillage de puissance.
Le programme peut facilement être testé en mettant en oeuvre une liaison série avec le PC et en ouvrant sur celui-ci un Terminal (par exemple le Terminal de Bray++). Ce Terminal PC permet d'envoyer des caractères ou des mots au LCD. Les envois se terminant par un carriage return (ASCII 13) font passer à la ligne suivante sur le LCD.
@ sylvainmahe
As-tu essayé d'utiliser AVRDUDESS pour commander avrdude et programmer ton NANO ?
AVRDUDESS dispose des paramètres pour un nombre impressionnant de programmateurs, y compris les configurations avec ftdi.
J'espère que tu va bien Jean-Marie45, ne te connaissant pas mais aillant des proches souvent confronté au fait de devoir essayer des médecines alternatives parce que rien ne fonctionne, ...
Ok je vais essayer avrdudess pour voir et ensuite je reviens vers le forum
Sinon j'ai regardé ton petit GCC_Serial_LCD, je prend de la graine comme on dit pour l'avr c et par la même occasion le c pur est très bienEn tout cas c'est très commenté ! Du coup on comprend bien le fonctionnement.
En fait je n'ai pas grand chose à dire à part que:
Les #define il me semble que ça génère un code compilé moins optimisé qu'une constante typée, donc généralement je ne met jamais de define, mais j'imagine bien que dans ton cas elles sont utiles de cette façon en tant que directive de compilation, sauf peut être pour certaines.
Le main retourne un int: http://fr.openclassrooms.com/informa...-fonction-main
A savoir si les arguments on quelque chose à faire sur un environnement avr, ça je ne sais pas
L'écriture "conventionnelle" des noms sinon c'est souvent:
variable à portée limitée (locale) maVariable
variable à portée plus grande _maVariable
constante à portée limitée (locale) MA_VARIABLE
constante à portée plus grande _MA_VARIABLE
méthode autre que main (en c dans le main.c) MaMethode
constructeur ou destructeur dans une classe (en cpp) MaMethode
autres méthodes dans une classe (en cpp) maMethode
J'avais trouvé une page sympa qui récapitule quelques bonnes pratiques la voici: http://skyduino.wordpress.com/2012/1...-pour-avr-gcc/
Ça ne dois pas être utile pour toi mais si certaines personnes on besoin (dont moi pour comprendre quelques paramètres de avr-gcc).
Par exemple dans "6 – Les makefiles, tu utiliseras et ton compilateur, tu configureras", je ne sais pas ou mettre "-Wl" et "-gc-sections" ou équivalent au linker pour réduire la taille du code, sachant que j'ai ceci au final dans mon bash (peut être j'utiliserais les makefile, que j'ai déja utilisé par le passé):
Je pense que c'est bien comme ça mais on peut encore réduire le code dans l'eeprom normalement en enlevant des sections qui pourraient ne pas être utilisé, donc si jamais vous avez une idée, j'ai regardé les paramètres à passer à avr-gcc, objcopy, et avrdude, et je ne suis pas sur du truc..Code:#!/bin/bash while true do avr-gcc main.cpp -mmcu=atmega328p -DF_CPU=16000000 -Wall -Os -ffunction-sections -fdata-sections -o main.elf objcopy main.elf -O ihex main.hex avrdude -c ftdi -p m328p -P /dev/ttyUSB0 -U flash:w:main.hex read clear done exit 0
Ah ok je viens de regarder, avrdudess c'est une gui
Ce sera non car je veux compiler linker uploader en une simple pression sur la touche entrée dans le terminal linux, on fait tellement beaucoup de tests à intervalles réguliers quand on débute un nouveau projet que ça me soûlerais vite de devoir cliquer, choisir le fichier, etc...
J’attendrais l'usbasp
Si tu veux parler des macros setbit et clearbit, j'ignore leur rendement en terme de code compilé.
Les autres #define permettent seulement de rendre le programme qui suit indépendant de la configuration matérielle du montage physique. Ils n'ont rien à voir avec des directives de compilation.
Effectivement, le "main" devrait retourner un int. Il le fait dans les ordinateurs, mais dans les AVR, il n'y a pas de système d'exploitation et on ne sort jamais du "main". Donc, fatalement, le "main" ne retourne jamais rien. Enfin, tant qu'on n'implante pas un système d'exploitation qui coiffe le programme.Le main retourne un int: http://fr.openclassrooms.com/informa...-fonction-main
A savoir si les arguments on quelque chose à faire sur un environnement avr, ça je ne sais pas
Merci pour ton lien vers Skyduino. J'examine ça plus en détail demain car contrairement à ce que tu crois, j'ai sûrement beaucoup à apprendre.
Les "-WI" et autres configurations de compilation peuvent être précisés dans Studio. Par contre je ne suis d'aucune utilité pour les makefiles car je ne connais malheureusement rien au monde Linux. Mais certains qui interviennent sur le forum pourraient sans doute t'aider.
AVRDUDESS est effectivement un gui, mais c'est bien pratique quand on n'est pas de la planète Linux.
Ok
En fait je parlais de directive de compilation pour les define parce qu'en c ou cpp ça ne sert que de directive préprocesseur, et qu'il ne faut pas les utiliser pour autre chose que cela parce que tout ce qui n'est pas déclaré typé est forcément moins bien car le compilateur devra rechercher le type de donnée dans le define, et donc risque fort de rajouter des choses inutiles, et également parce que F_CPU on peut très bien le mettre en dur au compilateur directement:
-DF_CPU=8000000
Donc à mon avis pour le reste si ça ne sert vraiment à rien d'autre autant mettre par exemple pour #define RS 5:
const uint8_t RS = 5;
Enfin il me semble, à corriger si ce n'est pas ça et si il est préférable de mettre 00000101
Ok pour le main, donc si je comprend bien, enfin je m'en doutais mais, les mémoires du ic sont vraiment totalement vides si on a jamais rien mis dedans? Et y a rien au dessus du main.
Pour les makefile je sais comment faire car j'ai déjà utilisé ce principe, c'est tout con y a 2 commandes et ça fonctionne très bien, c'est juste que j'avais envie de faire un test tout manuellement avec le ftdi pour voir, mais je verrais ça plutôt avec l'usbasp ça fonctionnera.
Pour la définition de F_CPU, je ne sais pas trop comment faire pour la supprimer du programme car cette fréquence est nécessaire d'une part à la fonction d'initialisation de l'USART pour calculer les valeurs à introduire dans les registres, et d'autre part aux routines de délais.Ok
En fait je parlais de directive de compilation pour les define parce qu'en c ou cpp ça ne sert que de directive préprocesseur, et qu'il ne faut pas les utiliser pour autre chose que cela parce que tout ce qui n'est pas déclaré typé est forcément moins bien car le compilateur devra rechercher le type de donnée dans le define, et donc risque fort de rajouter des choses inutiles, et également parce que F_CPU on peut très bien le mettre en dur au compilateur directement:
-DF_CPU=8000000
Donc à mon avis pour le reste si ça ne sert vraiment à rien d'autre autant mettre par exemple pour #define RS 5:
const uint8_t RS = 5;
Pour le #define RS 5, j'ai voulu essayer ce que cela changeait de le définir comme une constante.
J'ai d'abord compilé le programme tel quel :
342.jpg
La compilation produit 578 bytes pour le programme et 84 bytes de données.
J'ai ensuite remplacé "#define RS 5" par "const char RS = 5;" (uint8_t est remplacé par char pour éviter un include supplémentaire).
343.jpg
La compilation du programme passe à 600 bytes mais les données ne bougent pas.
J'ignore la raison de cette augmentation mais elle semble indiquer que j'ai intérêt à utiliser les #define.
As-tu une explication ?
J'ai déjà lu quelque part (mais où ?) que tout n'est pas remis à zéro automatiquement lors d'un Reset. Il est donc prudent de réinitialiser les variables en début de programme.
Ok, ça ne bouge pas au sens qu'il y a 600 bytes + 84 bytes de données?
Peut être l'exemple n'est pas bon pour ce cas ici.. mais il est vrai que j'ai toujours vue ça en programmation, pas de define sauf si on est obligé. Parce que sinon alors on fait pratiquement tout notre programme non typé et dans un seul define dans ce cas, et ça fonctionnerait, mais ça n’aurait plus aucun sens?
A voir
Pour le main d'accord
J'ai une question sinon, est ce quelqu'un connais un bon fabricant de carte pcb ailleurs qu'en chine et pas trop chère? Je trouve ça abusé qu'en france avec notre société de service à la con on est pas des petites mains pour fabriquer ça comme il faut, et qu'il faille sans arrêt commander à l'autre bout de la terre, la france est en train de couler les amis, on ne sais plus rien faire ici !
La majorité des #define sont utilisés pour définir des constantes qui ne sont pas nécessairement utilisées telles quelles durant l'exécution, ou qui n'apparaissent qu'à la compilation.
Au lieu de définir une constante typée, qui devra par la suite est convertie pour servir dans des calculs, et qu'on espère être finalement éliminées du programme par la passe d'optimisation du compilateur, on préfère utiliser des #define pour s'assurer du résultat.
C'est particulièrement utile pour les manipulations de bits, car le C ne reconnaît pas ce type de donnée, alors que le microcontrôleur sait les manipuler directement.
Ok je vois, mais pourtant c'est ce que j'avais appris à l'époque et qu'on peut retrouver un peu partout sur internet toujours actuellement, tiens par exemple ici dans un document que j'ai déjà montré:
"5 – Les define et les macro, tu n’utiliseras pas"
http://skyduino.wordpress.com/2012/1...-pour-avr-gcc/
Ou encore:
"#define _Pi 3.1415927
Toutefois, avec cette méthode les constantes ne sont pas typées, c'est pourquoi le C++ rajoute le mot réservé const, qui permet de définir une constante typée, qui ne pourra pas être modifiée pendant toute la durée d'exécution du programme. Il est ainsi nécessaire d'initialiser la constante dès sa définition : "
Et sinon si tu veux vraiment éliminer les choses une fois l'utilisation terminée, je pense que le mieux c'est d'utiliser les pointeurs, la effectivement on peut libérer exactement ce qu'on veut en mémoire, que ce soit des int, des char, des objets perso bien plus complexe, etc...
Développer, ce n'est pas suivre des dogmes et se laisser conduire par ses outils, c'est réfléchir et utiliser ce qui est nécessaire ou utile afin de réaliser ce qu'on a décidé.
Comme je l'ai rappeler plus haut, le langage C a été conçu pour fonctionner sur de plus gros systèmes. Le modèle matériel auquel il correspond est beaucoup trop simplifié par rapport aux particularités incontournables des petits microcontrôleurs (registres d'entrée-sortie, espaces mémoire multiples et spécifiques, place limitée, capacité de manipulation de bits, ...). Mais on l'utilise tout de même afin de profiter des avantages qu'il apporte (portabilité, lisibilité, rapidité d'écriture, logithèque existante, ...), grâce à des "rustines" qui pallient ses manques et qui peuvent varier d'un environnement de développement à l'autre.
Écrire un programme, ce n'est pas seulement décrire les opérations réalisées par la machine, c'est aussi donner à la chaîne de compilation les ordres permettant de créer le logiciel souhaité. D'ailleurs, c'est la principale fonction du préprocesseur.
Les informations dont les traitements sont à réaliser avant la compilation n'ont aucune raison de se retrouver dans le code exécutable, et les faire figurer parmi les ordres destinées à la machine cible fait prendre le risque de les y voir figurer.
Dans ton exemple, la définition de _Pi dans un #define permettrait par exemple d'utiliser les valeurs de π/2 et 2π dans le programme sans devoir consommer de la mémoire pour stocker π ni devoir effectuer les conversions et calculs nécessaires durant l'exécution.
S'agissant de ta proposition d'utiliser des pointeurs, tu noteras que ce sont des variables, et qu'à ce titre ils consomment de la mémoire et du temps d'exécution pour exister et être manipulés. Or, le but est de ne pas consommer sur la machine cible des ressources qui ne sont nécessaires qu'au système de développement. De plus, les pointeurs sur les bits n'existent pas en langage C.
Je n'ai pas eu le temps de corriger avant le délai imparti. Il faut lire :
« ... et les écrire parmi les ordres destinées au fonctionnement de la machine cible fait prendre le risque de les y voir figurer, si l'optimisation escomptée n'est pas réalisée. »
Ok merci PA5CAL pour cette mise au clair
C'est pas évident de savoir vraiment ce qu'il faut optimiser finalement avec avr et ces petites puces, la vitesse d’exécution ou la place en mémoire? Un petit ic pas chère tourne souvent déjà à 8mhz, donc effectivement je pense que c'est la place en mémoire qu'il faut optimiser car il sera souvent assez rapide.
Pour exemple qu'il ne faut pas amalgamer place en mémoire et vitesse, j'avais fait un petit jeu, ou plus exactement une démo jouable en 3D pré-calculé, ça faisait plusieurs centaines de méga pour 5 minutes de jeu mais malgré les graphismes plein écran en 1280x720 60fps, le processeur restait toujours à 0% d'utilisation, et le gpu aussi, j'avais balancé ça sur le site du zéro à l'époque, personne n'y comprenait rien
Puzzlegame1.jpg
Puzzlegame2.jpg
Dire qu'il m'en reste que des screenshots à deux balles, je suis pas très conservateur en informatique, quand la passion part, la corbeille est pas loin
Pourtant rien qu'à revoir ça c'était un truc de fou, tout était animé à l'écran, les items pivotaient en 3D sur eux mêmes, tout ce qu'était en vert dans l'interface bougeait ou scintillait pour imiter des vrais écrans cathodiques ou lcd, y avait vraiment le soucis du détail, on pouvait ce déplacer dans le décor, explorer les différentes pièces, j'avais pas encore implémenté des monstres car ça faisait trop longtemps que je programmais ça et j'en avais bien marre, mais j'étais jeune à l'époque, j'avais de l'ambition, maintenant tout est parti, quelle déchéance
Alors encore une fois à savoir si c'est pareil avec des micro-contrôleurs? Comme le monde des ic à l'air d'être un monde d'extraterrestre régit par des lois différentes de celles des ordinateurs je préfère m'en référer au professeur tournesol
Bon sur ce j'ai presque fini une petite bibliothèque c++ pour piloter des max7219, et s'amuser avec des interrupteurs:
Pour s'en servir, c'est tout simple:
Il y a aussi d'autres méthodes assez pratique comme clearAll, clearDigit, digit, segment, comma, ou encore brightnessAll, j'ai vraiment tout prévu pour que ce soit utilisable immédiatement.Code:#include "custom/display/LedMax7219.cpp" // Il faut déclarer un objet afficheur LedMax7219 ledDisplay = LedMax7219 (1, 2, 3, 4); // 1 c'est le nombre de max7219 branché en cascade // 2 c'est le port qui va vers Din du max7219 // 3 c'est le port qui va vers Load du max7219 // 4 c'est le port qui va vers Clock du max7219 // Afficher un nombre ledDisplay.number (1, 1, 8, 7205, 0, false); // Le 1er 1 c'est le numéro du max7219 en cascade, ici il y en a qu'un de branché donc on ce sert du 1 dans tous les cas // Le 2ème 1 c'est le numéro du 1er digit, la ou commence à être affiché le nombre (pratique quand le bloc de 8 digits est coupé en deux, on appel deux fois number, voir vidéo sur l'afficheur du milieu) // 8 c'est la ou s'arrête le nombre à afficher (voir vidéo pour comprendre) // 7205 c'est le nombre à afficher // 0 c'est le nombre de décimales, j'ai préféré travailler uniquement avec des entiers pour éviter les erreurs de virgule flottante, mais je pourrais implémenter les décimales à l'avenir // false c'est le coté ou est calé le nombre qu'on souhaite afficher (false c'est à gauche, true c'est à droite) // Effacer ledDisplay.clearDevice (1); // 1 est le numéro du max7219 en cascade // Changer la luminosité ledDisplay.brightness (1, 12); // 1 est le numéro du max7219 en cascade // 12 est la luminosité (de 1 à 16)
Je vais finir de programmer tout ça, j'ai envie d'implémenter quelques animations un petit peu génériques avec les digits, ça peut être sympa.
En ce qui concerne la classe des interrupteurs/boutons elle est complète aussi mais il reste pas mal de choses à rajouter, actuellement je n'ai programmé que deux états possible pour un inter, à savoir appuyé en continu, ou un clic si on reste appuyé en continu, comme on peut le voir dans la vidéo. Je souhaite enrichir ça et programmer jusqu'a 8 états.
Pour l'instant, quand vous branchez un inter sur l'ic, voila comment programmer:
Je pense que je programmerais ça avec la possibilité d'utiliser les interruptions en plus, mais franchement en l'état actuel, sans interruption ça fonctionne parfaitement bien.Code:#include "custom/switch/OnOffOn.cpp" // Il faut déclarer un objet interrupteur OnOffOn switch = OnOffOn (5, 6); // Ici c'est un 3 positions donc il y a deux fils, branchés sur le port 5 et 6 (ça peut très bien être 2 inters 2 positions branchés en 5 et 6) // Puis on récupère facilement les deux états dans une boucle ou pas avec: switch.continuous(); switch.momentary();
Je vous passerais tout cela quand ce sera terminé
8 MHz ce n'est pas forcément beaucoup, surtout quand il s'agit de faire des traitements rapides qui ne peuvent pas recourir à des opérations câblées. En effet, la division, les fonctions transcendantes et les traitements sur plus de 8 bits doivent être décomposés en séquences souvent longues. Le moindre calcul évolué prenant alors un temps notable, pour répondre aux impératifs de débit ou de latence on a souvent recours à des tables pré-calculées, consommatrices de mémoire.
On peut aussi disposer des traitements câblés nécessaires mais se trouver trop près de la limite de vitesse de la puce. Par exemple, avec un AVR 8 bits cadencé à 16 MHz, pour pouvoir transférer un bloc de 8000 octets en 1 ms (cas typique d'un générateur de fonction ou d'un enregistreur de signaux numériques), on n'a plus le temps d'exécuter des instructions de boucle, et on ne peut donc pas faire autrement que d'aligner 8000 instructions de transfert à la suite dans le code. Cela prend 8000 mots en mémoire de programme, mais en général la taille de la mémoire Flash à disposition (128K×16 sur un ATmega2560) le permet. En revanche, avec 8Ko de SRAM il faudra par ailleurs certainement optimiser l'utilisation des 192 octets restants (qui s'ajoutent aux 32 registres généraux).
En fait, tout dépend de l'application. On doit la plupart du temps faire un compromis entre la vitesse et la place en mémoire, le seul critère étant le résultat final pris dans sa globalité.
Mais en principe les optimisations en taille et en vitesse sont la règle, sinon c'est le signe qu'on a probablement sur-dimensionné le matériel au moment de son choix. Et pour arriver à ses fins dans ce cadre particulier, il ne faut pas hésiter à transgresser les règles usuelles de programmation, qui n'ont pour la plupart été édictées que pour des questions liées au seul processus de développement (lisibilité, adaptabilité, réduction des erreurs potentielles, etc.). Par exemple, et même si cela constitue une hérésie pour certains puristes, des goto bien placés ou des if/else en cascade s'avèrent souvent beaucoup plus efficaces que des tests de sortie de bloc ou des switch/case.
Hello,
Pour juger de la qualité du code émis pas un compilateur, il faut disposer du code assembleur qu'il a émis. Seul ce code permet d'apprécier le caractère optimisé ou non du code, la longueur du code émis apporte peu d'informations à ce sujet ... si ce n'est sur sa longueur.
Pour un code compilé avec GCC, l'outil de l'IDE Arduino (???donc avr gcc???) avr-objdump.exe permet d'obtenir ce code assembleur à partir du fichier '.elf' émis par l'IDE Arduino en utilisant la ligne de commande suivante :
Ceci doit aussi être possible avec avr studio ???Code:avr-objdump.exe -S monbeau.elf >> nimporte.quoi
-------
Pour les #define, il s'agit d'ordres pour le préprocesseur qui réécrit le code C en apportant les modifications imposée par les commandes '#' AVANT de compiler 'réellement' le code. Dans le cas de #Define PI 3.141592, le precompilateur remplacera toutes les occurences PI qu'il trouvera dans le code C par 3.141592.
-------
C est le plus ancien des langages de 'haut' niveau(??1968??). Il a été conçu pour des machines très lentes par rapport à ce que nous connaissons aujourd'hui et à une époque où on achetait très cher du temps machine, les compilations devait donc prendre peu de temps, c'est une des raisons du caractère 'crypté' de C ({ ; ,) ...
Biname
FORTRAN et COBOL datent des années 50C est le plus ancien des langages de 'haut' niveau(??1968??).
Oui, j'avais oublié ces deux là et C est né en 1972 ; ma remarque concernant C est donc moins pertinente.FORTRAN et COBOL datent des années 50
Deux grosses fautes d'orthographe aussi ... au moins
Biname
T'as pas accès au .hex pour voir ce qui a été fait du coup? En ligne de commande je dois le supprimer moi même après upload dans la carte c'est pour dire que j'y ai accès sans rien faire si je fais pas un delete dans le shell bash lol... (vive linux)
Effectivement *biname je parlais de cette longueur que tu mentionnes quand j'ai indiqué que certaines choses en c faisait produire au compilateur des choses moins optimisé, encore une fois je ne comprend pas l’amalgame qui est fait entre nombre de bit, vitesse d’exécution, qualité du code, etc...
Je dis cela comme ça mais j'ai presque l'impression que cette discussion c'est 30 pages de vent à comparer la taille des bits alors que finalement le but 1er, ce séparer d'arduino, est un but atteint sans difficulté pour peut qu'on sache déjà programmer en arrivant sur le forum. C'est vrai, toutes les infos se trouvent déjà sur le net une fois qu'on connait les mots clé à rechercher.
Dernière modification par sylvainmahe ; 17/10/2014 à 21h00.
(linux+avr-gcc+avrdude) Pour ceux qui veulent continuer à utiliser le bootloader de leur arduino avec l'usb et ftdi intégré j'ai testé ça sur ma arduino nano et ça fonctionne bien:
Il fallait juste indiquer la vitesse à -b 57600, j'ai essayé tout le reste et ça ne fonctionne pas, à croire que le ftdi ne fonctionne qu'à cette vitesse, ou bien c'est en relation avec mon usb 3, j'en sais rien, si il y a des connaisseurs ?Code:#!/bin/bash avr-gcc main.cpp -mmcu=atmega328p -DF_CPU=16000000 -Wall -Os -ffunction-sections -fdata-sections -o main.elf objcopy main.elf -O ihex main.hex avrdude -c arduino -b 57600 -p m328p -P /dev/ttyUSB0 -U flash:w:main.hex:i rm main.elf -f rm main.hex -f exit 0
Sinon pour le reste j'avance bien dans ma programmation, avec le manuel d'avr et le datasheet de l'ic ça ce fait tout seul finalement
Pas de problème aussi pour les fuse, il y a pleins de tutos sur le net, ce qui permet d'aborder le datasheet avec plus de compréhension quand on débute comme moi (voir l'encart en rouge):
http://www.chicoree.fr/w/Le_programm..._cher_du_monde
etc..
hello,
dans ma chaine de développement (linux + avr-gcc + avrdude) comme SYLVAINMAHE
au lieu d'utiliser un script comme lui, j'utilise un Makefile (Jörg Wünsch / Peter Fleury & al) très légèrement customisé (nom du processeur, nom du fichier source, éventuellement la vitesse et le niveau d'optimisation)
Ce Makefile va invoquer plusieurs fois avr-gcc et lui envoyer les options nécessaires, ce qui m'évite de (trop) rentrer dans les 858 pages du manuel d'avr-gcc
liste des commandes envoyées à avr-gcc par le Makefile :
Compiling: main.c
avr-gcc -c -mmcu=attiny13 -I. -gdwarf-2 -DF_CPU=1240000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o
<...>
Linking: main.elf
avr-gcc -mmcu=attiny13 -I. -gdwarf-2 -DF_CPU=1240000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o -std=gnu99 -MD -MP -MF .dep/main.elf.d main.o --output main.elf -Wl,-Map=main.map,--cref -lm
<...>
Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep
avr-objcopy: --change-section-lma .eeprom=0x0000000000000000 jamais utilisé
Creating Extended Listing: main.lss
avr-objdump -h -S main.elf > main.lss
Creating Symbol Table: main.sym
avr-nm -n main.elf > main.sym
les fichiers générés incluent les listings assembleur main.lss et main.lst
j'utilise l'avrdude en ligne de commande pour programmer la puce et les fusibles via un USBASP ou un interface RS232 (en déplacements, avec une vieille machine) fait par YORUK
pour les arduinos nano pro (pour leur prix imbattable) dont je ne sers que du hard avec les ports d'origine (rarement modifiés à la main)
j'ai récupèré et stocké le bootloader, au cas où, par
avrdude -p m328p -c usbasp -U flash:r:bootloader.hex:i
que je peux toujours réinstaller par :
avrdude -p m328p -c usbasp -U flash:w:bootloader.hex
saluts
Effectivement c'est intéressant de voir ce qu'il met en automatique avec le makefile, j'avais eu la flem d'en faire un pour regarder
Dans mon cas il suffit de remplacer arduino par usbasp et ça fonctionne également, c'est juste que dans le cas de l'utilisation du ftdi embarqué et le bootloader, il fallait préciser la vitesse de transmission, alors que celle par défaut convient pour pas mal d'autres programmateurs.
hello,
je n'utilise pas de ftdi puisque le nano pro (à 3$) n'a pas de lien usb , je lui cable simplement un header ICSP 6 ou 10 pins pour l'usbasp
pour le debug, j'utilise un chip prolific (dans une autre interface à 3$ RS232-USB) lisible par gtkterm
le makefile est du domaine public
# WinAVR Makefile Template written by Eric B. Weddington, Jörg Wunsch, et al.
#
# Released to the Public Domain
#
# Additional material for this makefile was written by:
# Peter Fleury
# Tim Henigan
# Colin O'Flynn
# Reiner Patommel
# Markus Pfaff
# Sander Pool
# Frederik Rouleau
makefile complet en PJ
attention, enlever l'extension ".txt" qui n'est là que pour être acceptée par futura
bootloader non utile dans mon cas
saluts
Je ne te force à rien lol.
J'ai un atmel sur breadboard sans bootloader mais aussi l'arduino nano que j'avais acheté en premier, j'indiquais juste pour ceux qui n'ont qu'une carte avec son ftdi intégré que voila avec deux paramètres bien renseigné ça passe, je ne comprend pas ou est le bins?
Bonjour, J'apprent a programmer en c depuis les dernier mois mais j'aimerais pouvoir l'utiliser sur quelque chose de plus concret. Ex. Arduino
Je trouve ce forum ainsi que les liens d'autre tutos tres interresent. Felicitation pour ton initiative et j'aime voir que d'autre persones partage aussi une meme passion. Bonjour a tous.
Hello driftX86,
Bienvenue parmi les apprentis du C.
Le sujet tourne au ralenti pour le moment.
Personnellement, j'ai repris avec un ami une ancienne discussion sur le design d'une carte de développement pour les AVR.
Sur Arduino, tu peux faire des choses très concrètes. Le web fourmille d'exemples. Mais tu n'avanceras pas des masses dans l'apprentissage du C car avec l'Arduino, on se contente bien souvent de coller une librairie toute faite, en modifiant éventuellement l'une ou l'autre pin mais sans décortiquer la librairie en profondeur.
