Reprise du message précédent :

ça répond parfaitement à ma question... de toute façon, si je me souviens bien, un timer sur un µ normal, c'est en réalité une interruption.

il n'y avait rien qui nécessitait effectivement une interruption
Merci pour les propals de bibs.

P'tain, je vois enfin le bout d'un (gros) montage que je suis en train de faire, je suis pas peu content…  
 
Une MKR1000 qui va gérer 6 écrans OLEDs, 6 boutons (avec LED intégrée pour chacun), et 14 strips de LEDs (+ 2-3 autres conneries genre un interrupteur 3 positions et des LEDs basiques). J'utilise 2 SX1509, c'est pratique mais c'est un peu plus le merdier à utiliser que ce que je pensais
Le tout étant connecté en Wifi à mon serveur, j'espère que la MKR va supporter tout ça quand tout sera monté

Par rapport à ta remarque sur le fait que l'exécution de l'interruption ne doit pas durer trop longtemps, j'ajouterai que parfois on peut juste mettre un flag dans l'interruption et faire le traitement dans la boucle principale si le flag a été levé.

Non, un timer n'est pas une interruption. Un timer c'est un compteur un peu perfectionné qui est présent dans le silicium du contrôleur (on parle de périphérique). Une interruption c'est un drapeau qui peut être levé par certains disons acteurs, dont les timers, et qui va faire que le processeur va interrompre ce qu'il était en train de faire, exécuter un bout de code spécifique (le contenu de la ISR - interrupt service routine) puis reprendre là où il s'était arreté. Pour faire clignoter une LED nul besoin d'interruption, par contre un timer avec une interruption est p.ex. nécessaire si on veut faire une liaison série en pur code (sans périphérique associé, dit software UART). Après ça devient vite un peu complexe par contre.

ok

Tiens. J'ai fait un code en pur C qui peut se compiler sur ordinateur ou s'adapter pour Arduino. L'opérateur % se dit "modulo" et retourne le reste entier d'une division.

Pour mon niveau c'est gentil mais je suis très loin d'être un pro aussi.

void? Ca veut dire "rien", soit une fonction ne retourne rien soit elle ne prend rien comme arguments. Tout bête.

Sympa, ton code, et pas très compliqué à comprendre, ça ressemble pas mal à du GFA.
Je vais essayer de le transcrire en Ardui, ça me fera un excellent entrainement.
 
Ceci dit, tu as loupé un de mes messages, car le truc est résolu    
 
Dans le même temps, j'ai voulu essayer la version 2 du coucou : j'ai déjà un afficheur 2x16 et des pièces
en rab.
Je n'ai donc pas démonté le coucou dont je vous rabats les oreilles depuis quelques jours, j'en ai
utilisé un deuxième.
Le truc, c'est que sur cette 2eme version, le gars utilise un nano et non plus un uno. De plus, le fritzing
est de mauvaise qualité => j'ai cherché le brochage nano, et branché les pins identiques sur mon uno.
Ca n'a pas fonctionné
 
Du coup, j'ai trouvé un tuto tout simple pour relier l'afficheur (1602A, un nom comme ça) et j'ai pu voir
qu'il fonctionnait toujours : coup de bol, les connections sont différentes du schéma du gars-coucou, mais
ça marche nickel.    
L'article est d'ailleurs incomplet à mon sens : nulle part, il ne précise ce que fait tel bouton (il faut regarder
son branchement, et fouiller dans le code), et il n'indique pas la ref de l'afficheur.
 
Il me reste à cabler tout ça en "dur" et l'intégrer dans une ptite cabane à oiseaux, pour avoir un look "pendule coucou".
 
 
Concernant le "void", oui je savais que ça veut dire "rien". Je voulais dire que j'ai des vieux restes de son utilisation
en GFA.
Pour être plus clair, pour moi :
GFA : void XBIOS(x,y,z)  ===> ça me renvoie ici :
 
$68000 :  
move x, D1
move y, D2
move z, D3
trap 13     <----- déclenche le "void XBIOS"
 
C'est une exemple bidon de ce que je maitrisais plutot bien autrefois. Voilà.

Il faut juste remplacer pseudo_parle par parle et copier-coller la bonne partie du code dans ton truc Arduino, le code en soit n'a pas besoin d'être changé. Vive la portabilité du C.

Non j'avais vu, je voulais coder quand même...
 

Cool si je t'ai donné envie de "sévir en codage"    
 
Si tu es toujours dans ce mood, j'ai une suggestion : modifier un tantinet le code pour obtenir
un ding à "et quart", deux à "la demie" et trois à "moins le quart".    
 
J'ai la ferme intention de retourner dans mon village natal, et enregistrer les sons de la cloche de
l'église : y'en a un spécifique pour les heures pleines, et un autre pour les intervalles de 15 mn.
Ca pourrait être chouette ^^

Je n'ai pas pu m'empêcher d'essayer    
 
Je me suis dit puisque dans le code, le gars sonne une fois aux demi-heures, bah je n'ai qu'à
extrapoler cette partie-là.
Préalablement, j'ai pécho deux sons de cloches différentes, leur ai donné le nom correct, et ajouté
la partie qui joue ces sons.
 

La compilation me donne un message alakon à propos de "braces suggested", mais ça fonctionne en passant outre,
je n'ai donc pas cherché plus loin.
 
Le souci (eh oui, je suis vraiment une super-quiche), c'est que dès que le code est uploadé, la cloche sonne
sans arrêt    
Putaize je suis même pas capable de réussir ça tout seul    
 
Le gars testait avec "30" pour "xx heures et 30 minutes". Donc, mon idée de mettre "15" pour les quarts d'heures
et "45" pour moins le quart, elle devrait fonctionner du premier coup...

Lignes 14 et 17, si tu mets un point-virgule derrière ton if tu dis au compilateur d'ignorer ce if et de toujours exécuter ce qui suit. Je ne pense pas que ce soit voulu. Avec une meilleure mise en page de ton code on voit tout de suite. Je n'ai pas cherché plus loin pour l'instant.
 
Concernant les warnings il ne sont jamais "à la con", au contraire il faut toujours les prendre en compte!!

 
 
Je ris parce que j'avais compris que ";" indique qu'il y a quelque chose qui suit.
Et ne te formalise pas parce que j'ai lâché un "alakon", c'est mon abus de langage perso ^^
 
Et je l'ai bien pris en compte, recherche google, et je n'ai rien compris. Et comme l'erreur n'est
pas bloquante, je suis passé outre.
 
Ceci dit, programmer un Arduino, mine de rien c'est super complexe pour un débutant    
 
Il n'existerait pas un "émulateur Arduino" qui permettrait de tester du code sans devoir passer  
son temps à l'uploader dedans ?

Je pense que tu devrais lire un bon livre sur le C. Comme je disais le K&R (en anglais en tout cas) n'est pas mauvais mais il doit y en avoir d'autres. Je déconseille vivement les tutos "apprenez le C en 5 minutes"!  
(Certes, l'Arduino c'est pas du pur C mais les bases du C restent valables, le peu de C++ nécessaire peut s'apprendre ensuite.)

Bonne question. Il existe(ait) des simulateurs de AVR, mais c'est pas forcément simple à utiliser. Un truc spécifique Arduino je sais pas.
Après pour des trucs purement algorithmiques on peut faire du code C qui peut se compiler sur PC aussi, là on a toute la palette des fonctions IO, un clavier, des fichiers, des debuggeurs etc à disposition. Le code en haut il est fait ainsi, c'est un fichier de C valide.

 
 
J'ai continué à bricoler mon horloge-coucou   (têtu, le gars hein).
 
J'ai résolu le problème de "sonne 1 coup à 15 mn", "deux à 30" et "trois à 45".
Maintenant, j'ai une horloge qui a deux cloches, tout comme l'église à côté de laquelle
j'ai vécu pas mal d'années. Mais vvef, ok.
 
J'ai même trouvé un autre bug dans le code du gars : par exemple, à 13:21, le truc dit "il est, treize, heures,
vingt, et, minutes"    
C'est réparé, assez simplement j'avoue. Bon, je n'ai pas essayé toutes les combis possibles, donc il reste
ptetre des erreurs = je verrai à l'usage...
 
Me reste plus qu'à passer à la version II qu'il propose plus bas sur sa page. Il ne dit nulle part quel afficheur
il a utilisé, et j'ai un 1602A. J'vais bien réussir à en tirer quelque chose !
 
GROS MERCI à tous les coups de pouce que vous m'avez donné    
 
 
Je conclus en disant que j'ai deux Arduino : l'un, estampillé Geekreit, est un "vrai", Windows le reconnait direct.
L'autre est une copie, puisque Windows demande le driver "CH340"...
 

Les afficheurs texte sont tous plus ou moins compatibles HD44780.

Le CH340 est un convertisseur USB-UART très connu, le pilote se trouve facilement.

Un autre point qui me chagrine : le DFPlayer mini utilisé pour jouer les sons, est brûlant après
quelques minutes. Pourtant, il n'est pas utilisé très souvent.
 
Ce serait possible, avec l'Arduino, de bricoler un branchement qui n'enverrait le jus dans le DFP
qu'au moment où il en aurait besoin ?
 
J'imagine qu'avec un petit relais, ça doit être faisable ; mais sans ?

Fais voir ton branchement (schéma + foto).
On doit pouvoir alimenter ton module à travers un MOSFET commandé par l'Arduino, mais il y a peut-être un autre soucis à régler. Tu n'alimenterai pas un truc 3,3V en 5V ou autre?

Tu as tout sur la page du coucou. http://www.honocorp.com/horlogeparlante2.html
 
En gros, le DFplayer est branché en permanence sur le +5V. Mon idée serait de le débrancher, et de dire
à l'Arduino de ne lui envoyer le +5 que lorsqu'il a besoin d'émettre un son.
 
Je suis en train de fouiller sur gougoule, mais je ne trouve pas grand-chose de probant, à part alimenter des leds...
Un mosfet ne serait pas overkill dans mon cas ?

J'utilise des DFplayer et ils ne deviennent pas brûlants au bout de quelques minutes, c'est peut-être un module défectueux ?

Et tu as branché ça exactement pareil?

Un relais serait overkill, un MOSFET c'est très bien.
 
Par contre vu ce que dis Turkleton un MOSFET ne ferait que cacher des conséquences, il doit y avoir une cause pour cet échauffement. Soit problème de câblage soit module HS. Tu as un multimètre pour mesurer du courant?

Ici, j'ai deux DFplayers, et les deux sont brulants (j'ai monté deux coucous, un en service 7/24, l'autre pour tester).
Un avec le Geekreit, l'autre avec le CH340.
Les deux cablés exactement pareil que le gars.
 
Oui oui j'ai un multimètre, et quelques notions en électronique.
Je dois aussi avoir quelques mosfets de recup, y'aura ptetre moyen de moyenner quelque
chose avec (s'ils sont encore bons).

Mesure donc la tension d'alim de ce module et le courant qu'il tire à vide et lors du fonctionnement (jouer un son). On pourra comparer avec la doc (si elle existe ).

A vide et en lecture audio : 4,5 volts environ.
 
Sur le calibre 200 mA, j'obtiens environ 0,42 à vide et en lecture audio.

Du coup si tu te mets sur le calibre supérieur tu as quoi comme mesure ?
0.42A ou 0.42mA ?  

Je trouve une question alakon de gamme supérieure

0,42mA c'est très peu, ça ne devrait pas chauffer. Tu peux mesurer le courant qui transite sur les lignes TXD/RXD? Normalement c'est très très faible aussi.

J'ai trouvé quelques infos à propos de l'intensité utilisée, de mémoire des gars parlaient de 40, mais je
ne sais plus si ce sont des mA ou non.
 
Pour les lignes TX et RX, on ne cable que le TX, parce que "on n'a pas besoin que le DFP renvoie quelque
chose", dixit le créateur.
 
La seule "GROSSE" différence entre mon cablage et le sien, c'est qu'il utilise une resistance de 1 Ko sur
le TX, et moi j'ai une 680 ohms car il ne restait plus que ça chez Addison.
Et encore : elle est nécessaire sur le Geekreit, sinon ça gueule qu'il y a un probleme à l'upload.
Le clone en CH340 lui, il s'en fout royal, donc j'en ai pas mis.
 
Mais les deux montages chauffent pareil  

Ce ne sont certainement pas des Ampères.  
 
Hm, avec 680Ohm le courant est déjà limité. A vrai dire je doute un peu de ces 0,42mA. Tu en est sûre?

Ah, c'est certain que si ce sont des ampères, je ne serais pas là    
Non, mais ça pourrait être des µA.
 
Bravo, tu m'as mis le doute, je vais vérifier tout ça    
Je repasse un peu plus tard avec les résultats.

Non, il faut quelque (dizaines de) mW au niveau du haut-parleur et la puissance ne peut venir que de l'alim.

Je veux bien vérifier, mais il me semble bien que ça ne chauffait pas chez moi dans mon souvenir. En tout cas j'en ai un qui fonctionne presque tous les jours sans problème depuis plus de 6 mois

Ce serait avec plaisir   (j'aurais d'ailleurs une question "électronique" à propos du DFP)
 
Je viens de mesurer TX. Multi réglé sur 200 mA.
Lecture au repos : environ 3,4
En lecture de l'heure, ça ne bouge pas.
 
Pour la conso du DFP, c'est bien 4,2 sur le même calibre.
 
EDIT : ok, je me suis planté  

   
Il y a pas une contradiction là?

Oui, j'ai voulu poster trop vite, c'est rectifié désormais.

Ah d'accord, 4,2mA et pas 0,42mA. Ca paraît correct, aucune idée pourquoi ça chauffe...

Le DFP possède deux pins ground, un de chaque côté.
L'un des deux n'est pas câblé, tu penses que ça pourrait venir de là ?
 
Aussi, lorsque le DFP joue un son, une petite led s'allume. Lorsqu'il ne fait rien, ben elle
reste éteinte => logiquement, il devrait consommer moins, j'comprends pas ce truc...
 
Le HP que j'utilise est un 4 ohm, il fait environ la largeur d'un paquet de clopes, ça serait
pas sa faute des fois ?
 
Ptetre que Turkleton pourra verifier le sien, et nous dire s'il chauffe aussi.

Et est-ce que ça vient pas bêtement de l’impédance de ton haut parleur ? T’as pas un petit en 8ohms qui traîne pour tenter ?

Tu mesure une continuité entre ces deux pins? Dans ce cas probablement non.

Pas sûr que ça change grand chose, une LED moderne 1mA peut suffire. Et ton multimètre doit être suffisamment rapide pour vraiment faire la mesure pendant le court moment où est joué le son.

Tout à fait possible! Mets du 8Ohm voire plus. Et si il y a du DC sur la sortie HP il faut rajouter une capacité aussi. À mesurer (tension continue sur la sortie HP en standby).

J'ai retrouvé un vieil HP, c'est marqué 32 ohm dessus, c'est pas trop grand ?
 
Je mesurerai la tension sur le HP un peu plus tard.

Tu ne risques pas grand chose à mettre plus grand : quand tu augmentes la résistance tu diminues l’intensité (à tension égale).