Reprise du message précédent :
   
 
Toujours en train de bosser sur le code source à modifier.
Mais je n'arrive à rien, que ce soit avec Atmel Studio 7 ou CodeBlocks. Enfin si, j'obtiens
quelque chose : des erreurs à tire-larigot  

Un DC barrel connector comme celui-là :

Y'a besoin d'autres éléments électroniques pour aller avec ?  
 
Parce que quand je regarde les modules genre ça :

Y'a une résistance, une diode, et même un truc "F" que je sais pas ce que c'est.

C'est pour un fusible si tu le souhaites.
Par défaut il y a visiblement un pont/résistance nulle.

Mais du coup, ceux qui ont déjà équipé leur projet d'un barrel connector tout simple, vous aviez rajouté ces éléments en plus ? Ou alors directement du barrel aux rails de courant d'une PCB par exemple ?

J'en ai utilisé un récemment sur mon dernier projet. J'ai monté ça simplement en soudant le + et le - sur le PCB. Pas soudé l'autre pate qui est censée être le détecteur de présence du jack si j'ai bien compris.

Ouais, c'est bien ce que je me disais, merci Du coup je comprends pas trop à quoi est censée servir la résistance…

A limiter le courant pour la LED D1 qui indique la présence de tension. Ce n'est evidemment pas indispensable.

Déjà faut que tu puisses compiler le code NON modifié, après tu peux bricoler. Et je dirai même avant de te pencher sur ce code il faudrait tester avec un exemple tout simple pour vérifier que tout est bien réglé.
Tu as regardé sur internet, il doit y avoir de la lecture comment changer/régler le compilateur sur C::B.

Ah euh. J'en suis toujours au stade "essaie avec le code d'origine"    
 
Le compilateur, bah c'est bon, j'ai avr-gcc machin là.
 
Mais je ne capte rien à la façon d'intégrer les fichiers nécessaires, y'a trop de paramètres
que je ne comprends pas.  

Ha bah oui, effectivement, j'aurais pu y penser moi-même…

C'est à dire?
 
De mémoire sous C::B faut créer un projet et ensuite rajouter tout les fichiers .c, PAS les .h mais uniquement les .c.
 
Tu connais la différence entre .c et .h et toussa ou pas?

Non, désolé.
"C" je pense que ça veut dire que c'est écrit en C quelque chose.
"H", aucune idée (comme ça, ça me rappelle "hexa" mais c'est pas ça, evidemment).
 
J'essaie de créer un nouveau projet = le truc fait un bordel et puis il s'arrête.
A ce moment-là, je copie-colle le "main.c" du lecteur MP3.
Et c'est précisément là que tout part en kouye : ça commence par le "include io.h" puis les copains.
En cherchant un peu, j'arrive à les foutre là où ça le rend content.
Et précisément après cette étape, y'a ouatdouzmil erreurs qui surgissent...

Bon. Je te le fais en bref, à toi de te renseigner si tu veux en savoir plus. On peut remplir des heures de cours avec ça.
 
Un fichier .c contient du code écrit en language C.
 
Un fichier .h est un fichier header qui contient les prototypes de fonctions, les #define et autres trucs qui ne sont pas directement du code exécutable.
 
Généralement on a plusieurs fichiers .c avec chacun son fichier .h et peut-être d'autres fichiers .h.
 
Dans les fichiers .c on inclut les fichiers .h nécessaires avec #include.
 
#include <abc.h> va chercher dans les dossiers système je vais appeller ça.
 
#include "abc.h" va chercher dans le dossier où se trouve le fichier dans lequel se trouve cette instruction (directive préprocesseur comme tout ce qui commence par un #).
 
Au moment de la compilation chaque fichier .c est compilé SÉPARÉMENT en un fichier .o puis les fichiers .o sont réunis dans un fichier exécutable / un fichier .hex pour un µC. Compilation fichier par fichier veut dire chaque fichier doit être compilable en lui-même sans avoir besoin d'autres fichiers, d'où l'importance des prototypes de fonctions p.ex.
 
Crée donc un projet POUR AVR (important, pas un projet pour le GCC pour Windows/Linux!) et copie le code suivant. Ca devrait compiler, sinon tu postes les messages d'erreur. Il faut aussi préciser le type de processeur quelque part, genre mega328P.
 

Merci beaucoup pour l'explication à propos de "" et <>, je comprends bien mieux maintenant.
 
J'ai donc ouvert C::B, créé un nouveau projet "AVR project" (mon truc est tout en anglais, bon...ça ne me gêne pas).
Partant de là, il me crée un workspace, et je n'ai aucune idée de comment on entre des lignes de code
là-dedans.    
Sinon, je suis dans la bonne direction ou je me plante déjà d'entrée de jeu ?    

J'ai trouvé comment rentrer du code    
 
EDIT : j'ai aussi compris un truc, un paramètre était faux, le compilateur pour AVR.    
 
Donc, voilà ce que donne un "build" :

 
Par contre, un "run" donne un message d'erreur, mais je suppose que c'est normal. Le code que
tu m'a demandé de tester semble ne servir qu'à vérifier si les logiciels sont à jour...?

Je pense avoir réussi à tout configurer correctement.
 
Là, je bute sur l'utilisation du "makefile_mo" fourni. J'ai beau regarder des tutos, je n'y
comprends rien : je fais ce qui est dit, mais je n'obtiens qu'une erreur à propos
du makefile...
 
Ca me suffira pour aujourd'hui.  

L'intérêt de C::B c'est de ne pas devoir bricoler les makefiles (mais on peut).
 
Sinon le "run", bah oui, faire tourner un code compilé pour AVR sur un PC c'est pas possible (directement, il faudrait un simulateur).
 
Si tu arrives à compiler l'exemple (qui ne fait rien), tu peux maintenant essayer de compiler le projet qui t'intéresse sans le modifier et ensuite tu peux bricoler.

Oui, mais tu me disais toi-même qu'il y a un makefile fourni pour chacun des modèles de lecteur.
 
Et je n'arrive pas à l'intégrer dans le projet. Pas plus que je ne sais m'en passer.

Ok ok, j'ai re-tenté de compiler l'exemple que tu as donné, puisque j'ai à peu près réussi
à paramétrer quelques trucs.
 
A un moment donné, tu parlais de "préciser que c'est pour du Tiny" => quand je crée un projet
pour AVR, il me demande pour lequel, je lui réponds donc "t85".
 
Ton exemple, ça donne ça, pour la partie BUILD :

 
Pour la partie RUN :

 
Bref, ça ne fonctionne pas, parce que j'ai loupé un truc quelque part, et je n'ai aucune idée de quoi.

Le RUN tu oublies, comme je disais tu ne peux pas exécuter un truc compilé pour AVR sur PC.
 
Pour le reste, si tu tappes srec_cat en ligne de commande ça donne quoi? Si Windows ne trouve rien soit il manque ce logiciel (qui ne me dit rien) soit c'est un soucis de variable PATH.

Ok, je viens de comprendre l'histoire de truc pas exécutable. Dacodac.
 
"Srec_cat" : aucune idée de ce que c'est, ça renvoie "commande inconnue" ou un machin comme ça.
J'ai même fait une recherche globale (dossiers et tous sous-dossiers) : ça n'existe tout simplement pas.
Idem, vu qu'il y a "bin" derrière, j'ai cherché ça aussi : y'en a aucun.
 
Voici typiquement le genre d'erreur devant laquelle je n'ai aucun début d'inspiration quant à savoir
dans quelle direction regarder.

Le moteur de recherche me dit que ce truc sert à manipuler les fichiers EEPROM et se trouve ici: https://sourceforge.net/projects/sr [...] p/download
 
Pense à ajuster la variable PATH si tu le mets dans un dossier unique.

Il fait trop chaud. J'ai pensé à un moment de chercher sur Gaggle. Puis cette idée a fondu...    
 
J'ai pris ton lien, j'ai foutu les 3 .exe dans le dossier principal de C::B et j'ai relancé le build de ton
ptit bout de code.
Aucune erreur cette fois-ci.    
 
Now, what to do next ?    
J'efface ton bout de code, et je mets le main.c du lecteur MP3 et je retente le build direct ?

Avant vérifies avec mon code qu'il te sort bien un .hex.  
 
Après du peux mettre les fichiers du lecteur MP3 et tenter de compiler. Attention, si il y a plusieurs fichiers .c il faut TOUS les rajouter au projet.

1- Ca semble content, y' a un .hex qui est créé avec ça dedans :

 
2- Bah j'ai tenté. Y'a au moins 50 erreurs en sortie...    
Par exemple, ça rale parce que ça connait pas "DWORD" et autres conneries du même style...
Pour des fichiers .c à inclure, je ne sais pas de quoi tu parles. Cependant, à gauche dans l'arborescence du projet, y'a
plein de fichiers qui sont inclus. Mais je crois que ce ne sont pas des .c
 
Et je n'ai toujours pas compris comment on inclut le makefile.mo qui vient avec le projet MP3.
J'ai coché "ceci est un makefile custom", mais je n'ai aucune idée de ce qu'il fabrique avec, à part qu'il
n'a pas l'air content...

Ok pour le .hex.
 
Pour le makefile, il doit y avoir moyen de dire à C::B de l'utiliser, mais c'est pas forcément pertinent, le but de C::B étant justement d'automatiser tout ce bazar. Donc perso je l'oublierais moi ce makefile. Ou alors plutôt je compilerais avec le makefile mais en ligne de commande.
 

Il y a bien plusieurs fichiers .c dans ce projet? Doit y avoir un bouton "ajouter fichier au projet" ou du genre, demande au moteur de recherche. Je n'utilise plus C::B depuis des années, donc là c'est un peu difficile...

Bon ok.
Simplifions tout ca.
 
Imaginons que tu veuilles toi, compiler ce bordel, tu procéderais comment ?
Je suppose : tout à la ligne de commande.    
 
Mais imaginons plus loin : si tu décidais de passer par un GUI pour te simplifier la vie, tu
prendrais quoi ?
 
Car là, je suis en train de me dire que je te demande de l'aide par rapport à quelque chose que
tu n'utilises pas : par conséquent, si tu arrives à faire ça à ta façon à toi, ça devrait n'en être
que plus facile pour moi, dans la mesure où je pourrais me contenter de simplement copier
ce que tu feras.    
 
Et j'en profite pour rappeler ce que tu me disais : il faut que je prenne le bon makefile qui va avec
le modèle (parmi 4) que je veux réaliser => celui qui fonctionne actuellement, à savoir le "simple mono".
Mais maintenant, et excuse-moi d'insister là-dessus, mais tu me dis qu'il faut laisser le systeme fabriquer
le sien.
Là, je ne te suis plus, désolé.  

Ecoute, peux-tu tout simplement aller sur la page du projet et downloader l'archive pour regarder
toi-même stp ?
 
sd8psrc.zip c'est tout petit, et y'a 3 .c dedans, plus les .h requis par le projet.

Oui, je ferai la compilation en ligne de commande. Si il y a un makefile alors il suffit de se mettre dans le dossier de ce dernier et tapper "make". Le soucis c'est que je suis sous Linux où tout fonctionne, sous Windows ça peut être plus compliqué.  
 
Après pour éditer les fichiers de code j'utilise Geany sous Linux, sous Windows j'utilisais Programmers Notepad qui est très bien et très léger (par rapport à un truc genre C::B).
 
Si tu vas dans le dossier avec le makefile et tu tappes "make" il se passe quoi? Commande non trouvée ou autre chose? Si 1) alors regarde si il existe une version Windows de cet outil, car dans ce cas tu peux utiliser le makefile fourni et - dans l'idéal - tout est automatique. Après pour éditer les fichiers tu peux très bien utiliser C::B.

J'ai testé: Décompresser le projet puis "make -f Makefile_mo" et ça roule, ça prends genre 1 seconde à compiler.
edit: Le fichier .hex se trouve dans le sous-dossier sd8psrc/obj_mo.

Oki oki.
 
Essai de "make" = command not found, mais je m'y attendais.
 
Recherche globale dans la racine de "C::B", il en trouve deux :
- ./cbp2make.exe
- ./MinGW/bin/minGW32-make.exe
 
Il me faut également avouer que je n'ai toujours pas compris ce qu'est un makefile ou même à quoi
ça sert concrètement.
Ni même pourquoi C::B peut en créer un à partir d'un projet, et ni même pourquoi/comment y'en a
déjà un de fourni avec le projet.
 
Comme je l'ai dit : il y a 4 players MP3 différents avec chacun son propre makefile, mais qu'en réalité, il n'y
a qu'un seul paramètre qui change à chaque fois.
J'insiste : je n'y comprends rien du tout. Je n'ai même pas un début d'idée quant à l'usage de ce machin

Un makefile c'est juste la recette comment compiler un projet. Demande à Wikipédia si tu veux tout savoir.  
 
Le make de MinGW doit être bon, faut modifier la variable PATH pourque Windows le trouve ou spécifier le chemin complet. Donc tu te mets dans le dossier du machin MP3 et tu tappes genre C:\CodeBlock\MinGW\bin\make.exe -f Makefile_mo (chemin à ajuster bien sûr).

J'suis en train d'essayer de modifier le PATH pour rajouter le chemin qui mène à gw32make machin.
 
J'ai même essayé d'installer C::B en version setup, pensant que ça modifierait le PATH tout seul.
Et en fait : non.
500 Mo d'installation pour rien.  
 
PS : on gagnerait pas du temps si tu compilais le main.c en version "arrêt après lecture du 1er fichier" ?
Parce que là, comment dire ? Je t'ennuie de plus en plus, et de mon côté, je crois que j'ai épuisé tout
mon stock de patience.
Je veux simplement modifier UN PETIT PARAMETRE dans un fichier, et on voit où ça me mène...
Autant attaquer une mouche avec une bombe H...
 
EDIT : je n'ai pas XP ni 10, mais 7.

C'est pas sorcier pourtant. Enfin sous XP c'était simple, qui sait comment c'est sous W10.  
Sur ce coup je passe mon tour, aucune idée...

Je peux faire ça oui... Un instant...

Bon, je comprends pas trop le code mais j'ai rajouté un

après le play(), ça devrait le faire. Faut tester. Je t'envoye le .hex par MP car c'est un peu long ok? edit: sent.

edit encore: Tu sais qu'il n'y a plus de màj pour W7? Faut penser à changer. Et si tu passais du côté manchot?

Oui, pas de souci, prends tout le temps dont tu as besoin.    
 
J'ai eu des moments de reflexion, du genre : ah tiens si ça le tente, on pourrait essayer du vocal, ça
gagnerait du temps...
Ou : ah bah tiens il pourrait venir chez moi via TeamViewer, ça gagnerait encore plus de temps...
Ce genre de choses. Déjà testées autrefois dans d'autres domaines, c'était pratique, toussa toussa.    
 
Sinon, j'avais repassé une commande au même endroit que l'adaptateur SD. Je me suis aperçu en
farfouinant qu'ils ont également un modèle µSD, j'en ai pris 2    
Le concept est quasiment identique entre les deux, je suppose donc qu'il suffira de les intervertir pour
que ça reste identique dans le fonctionnement.
 
J'ai aussi trouvé un mini ampli stéréeo 3 W à base de PAM8403, j'en ai pris deux aussi.
 
Faut que je teste tout ça...ouais : je vais probablement revenir saouler le peuple avec ça.    
 
Par la suite, je re-reviendrai avec le programmateur USBasp, vu que je ne l'ai pas encore testé in situ, même
si j'ai déjà commencé à me documenter.
 
EDIT : oui, je sais pour les MAJ 7. Je n'ai pas de problèmes avec ça    
Le pingouin ? J'en ai un en machine virtuelle, et il ne me sert quasiment qu'à tester des URL qui me
semblent louches  

C'est un manchot, pas un pingouin!
 
Concernant ton W7, tu risques gros. Une faille qui est découverte/utilisée et c'est la cata puisqu'il n'y a plus de màj. Tu as des backups au moins?
 
Pour tout ce qui est prog' (sauf le Visual Basic ou autre machin MS) Linux c'est quand même bien pratique.
 
Enfin bref. [/HS]

Oui. J'ai pensé "manchot" et j'ai écrit "pingouin"    
C'est comme FF : renard ou panda    
 
T'en fais pas : même si je n'ai pas l'air doué sur ce topic-ci, je sais tout de même où je m'en vais.
Mon chez moi, c'est informatique partout => oui, j'ai des backups dans tous les coins.    

Il est temps de l'initier au brassage de bière
 
https://ouiaremakers.com/posts/tuto [...] c-un-ardui