Reprise du message précédent :

Dans "process", il y a "create mini dump" (ou full dump). C'est de ça dont tu parles ?
 
EDIT : ok, faut faire un "full dump", puis fouiller dans le garbage de 157 Mo qui en résulte.
J'ai lancé une recherche sur "avrdude", il a trouvé quelques occurences sans aucun intérêt car
dans les messages d'erreur (can't open port...) et une avec à priori les paramètres passés :

Désolé, c'est pas très beau à lire    
Ici, j'ai utilisé "Arduino Uno" (le truc qui est d'origine) et il semble que ma théorie soit vraie : Xloader semble n'être
qu'une interface graphique plus agréable à utiliser qu'un shell.
Antouka, ce qu'on récupère ressemble très fortement à ce qui sort en "verbose" de la compilation IDE.
 
Au final, ça ne fait pas avancer le schmilblick  

Doit y avoir un autre bouton mais si ça fait le taff...

Bah si, tu vois comment sont utilisés les paramètres:
-p  m328p   - c  stk500  etc. Y'a qu'à comparer avec la bonne ligne de commande et modifier le fichier de config.

Ca y est, j'ai réussi !
Ca fonctionne du tonnerre, Xloader programme le t45 en direct et m'affiche fièrement "upload successful"    
 
Ca devient - pour moi - beaucoup plus interessant : il me suffirait (j'ignore si c'est possible ou non), de
trouver un moyen de compiler un sketch et d'en faire un .hex pour pouvoir le programmer directement
sans passer par l'IDE (ce qui est assez pénible, car il faut modifier les options à chaque fois).
 
Tu sais comment faire ça, toi ? [sous réserve qu'il ne soit pas nécessaire de passer par une usine à gaz...]

Techniquement c'est certainement possible, c'est GCC qui fait le boulot derrière, mais il faudrait trouver les bonnes options et il risque d'y en avoir pas mal. Tu as regardé sur le net si quelqu'un a déjà tenté?
Au pire on pourrait regarder dans le code source de l'IDE, de mémoire tout est OS, mais bon, c'est jamais évident...

Je viens d'y réflechir un peu : after all, l'IDE crée le .hex et le stocke dans /Temp.
Il suffira de lancer un upload, puis d'aller prendre le compilé là-bas directement.
 
De ce que j'ai pu voir, l'IDE vu par Process Explorer, s'appelle "javaw.exe".
Usine à gaz selon moi, je pense qu'il est plus raisonnable d'abandonner cette piste.
 
Sinon, pour revenir à propos des options de dump de PE, je n'ai pas trouvé celle dont tu
parles sans t'en souvenir réellement.    
A mon sens, le plus logique est d'utiliser le "dump complet" du programme en mémoire.

Oui, je crois que l'IDE est écrite en Java, "javaw" doit être le runtime qui permet de lancer le truc (ou qqechose comme ça). Il y a pas mal de critique de l'IDE et il y a des alternatives, on doit pouvoir trouver un truc plus complet mais aussi un truc plus simple.

edit: Oui, le moteur de recherche sort des pistes, notamment ce truc: http://inotool.org/ Après faut pas avoir peur de la ligne de commande... Si tu veux du tout graphique ça risque d'être plus compliqué.

Et pour PE, j'ai regardé, voici à quoi je pensais: https://superuser.com/questions/415 [...] ng-program

Menu Croquis (Sketch) -> Exporter les binaires compilés (Export compiled binary)
 
Ça te collera le .hex dans le répertoire de ton croquis.

"Inotool" = effectivement, ça n'a pas l'air simple du tout.
En prime, c'est essentiellement conçu pour Linux et autres MacOS.
Je laisse ça de côté pour le moment, privilégiant la simplicité.
 
"Superuser" : y'en a des infos là-dedans    
J'imagine que tu parles plus spécifiquement des posts à propos de PE ?
Je m'y pencherai à tête reposée.
 
Et evidemment, j'ai zappé la possibilité d'exporter les .hex directement depuis l'IDE.
Merci beaucoup à tous deux    
 
Je vais en user et en abuser, car il me suffira d'avoir un sketch correct, de générer
son .hex, puis de le programmer directement depuis Xloader.
 
Tenez : ma prochaine expérimentation sera de regarder ce qui se passe si on essaie
de programmer les fuses des Tiny directement intégrés à un .hex.
 
Car j'avoue ne pas du tout comprendre ce que le gars veut dire (voir le site mini player mp3) lorsqu'il
explique que si on n'arrive pas à programmer et le code et les fuses en même temps, il est
possible de le faire en deux fois.  

Je parlais de la première réponse, précisément de ce graphique pour trouver les options avec lesquelles un programme a été lancé: https://i.stack.imgur.com/6mTse.png

Sinon pour les fuses, soit directement dans le hex (je sais pas si avrdude sait le faire) soit avec une commande dédiée avrdude <quelque chose, pas en tête, je peux regarder plus tard>.

ATTENTION: On peut p.ex. désactiver le mode serial programming (Reset Disable) avec les fuses, du coup on ne pourra plus reprogrammer le AVR. Il faut être très prudent avec ces trucs!

Justement, j'aimerais arriver à quelque chose de concluant sans AVRdude "directement parlant".
 
Pour les fuses : oui, j'ai lu les infos indiquant qu'une fois qu'ils sont burnés, on ne peut plus repro l'AVR ensuite.
Cependant, cela reste possible en contournant le truc.
Là tout de suite, je ne me souviens plus s'il faut utiliser un programmateur externe ou pas, mais
je m'y replongerai.
 
RdC, puisque tu es aussi sur le topic "Electronique", tu sais désormais que je vais passer commande
de 5 t85. Au pire, si j'en loupe deux ou trois, ça ira.    
 
Comme dit, le code du mini mp3, je peux toujours le tester sur les t45 puisqu'il ne tient pas dedans.
"Tester" => je parle d'essayer des lignes de commande ou des modifs du .conf d'Xloader bien entendu.

C'est inexact. En principe les fuses, p.ex. ceux pour le choix de l'horloge, peuvent se reprogrammer autant de fois qu'on veut. Par contre si on désactive le mode serial programming en (dé)cochant DisableReset alors il faut un programmateur parallèle que peux de gens ont, il ne sera plus possible de parler au AVR avec le programmateur série habituel. Voilà,

Je ne comprends pas pourquoi tu expliques que "c'est inexact" alors que je le dis moi-même
à la phrase suivante. Idem concernant l'utilisation d'un programmateur.  

Salut, pour info sur arduino je développe uniquement en c++. Il suffit de mettre le code c++ dans le répertoire des libs pour qu'il soit disponible. Dans le .ino on fait include d'un .h de la lib, on fait un appel et c'est parti.

Pour vos questions de multi tâche je vous conseille d'utiliser des machines à états. Perso j'utilise cette lib https://github.com/digint/tinyfsm et le jais plusieurs machines à états que j'active à chaque boucle de loop. Ça permet de gérer des systèmes complexes en simulant du multi tâche.

Pour une utilisation plus typée Arduino je vous conseille cette lib vraiment très complète et facile à utiliser. On peut avec ça gérer plusieurs machines à état en parallèle https://github.com/tinkerspy/Automaton/wiki

Edit: je viens de comprendre que tu faisais référence au fait qu'il n'y a pas de lib standard c++ sur arduino, effectivement, mais on peut très bien coder ou utiliser des classes pour se simplifier la vie plutôt que de tout coder en C dans un .ino (perso ça me rend fou la programmation procédurale)

Bonjour :
Je cherche a faire du IoT avec une carte nano BLE qui prend en entrée du 3.3v ( il me semble , le site est assez mal fait)
lien: https://store.arduino.cc/arduino-nano-33-ble
J'ai lu sur le net qu'on pouvais la connecter sur le pin Vin / grd ou sur l'usb micro.
 
Problème est de pouvoir facilement alimenter cette carte en 3.3v sur un breadboard et possiblement avec une batterie externe.
Des conseils ?

 
La question con du jour.
Je voudrais utiliser ce capteur pour détecter un niveau d'eau.
J'en ai mis un sur D2 d'un arduino nano. Est-ce qu'il faut aussi en mettre un sur GND pour avoir qqc de fonctionnel ? Je suppose que oui pour que le circuit soit fermé mais sait-on jamais.

Si je vois bien la carte contient un régulateur et va accepter un peu n'importe quoi entre 3,3V et 21V maxi. Après si le régulateur est linéaire vaut mieux pas trop monter en tension ou mettre un régulateur à découpage externe ("buck" ou "stepdown" ) pour limiter les pertes (et donc augmenter la durée de fonctionnement avec une batterie).
 

Oula... Pas sûr que ça va fonctionner tout court. L'idée c'est d'en avoir un toujours dans l'eau et connecté à la masse (ou au Vcc) et d'autres à différents niveaux connectés sur des entrées. L'eau va fermer le circuit, mais il faut voir la conductivité qui n'est pas très bonne pour de l'eau sans sel ou autre. A tester.
 
Donc:
-un bidule tout en bas dans l'eau et relié à la masse.
-un bidule au niveau que tu veux détecter et relié à une entrée AVEC RÉSISTANCE DE TIRAGE vers Vcc (interne au AVR, à activer avec du code, "pullup" ).

J'ai testé dans l'eau du robinet et dans 5 cm de flotte, ça passe
A voir dans 20-30cm d'eau de pluie.

"AVEC RÉSISTANCE DE TIRAGE vers Vcc (interne au AVR, à activer avec du code, "pullup""
Pas compris cette partie, je vais googler.

La R de tirage sert à garantir un niveau fixe sur l'entrée si il n'y a pas d'eau (donc pas de lien vers la masse). Il ne faut jamais laisser "flotter" une entrée qu'on utilise.

j'ai trouvé la même réponse ici https://les-electroniciens.com/disc [...] -pull-down
 

J'ai un peu réfléchi pour la v1.1 de mon projet de mesure d'une réserve d'eau et voici les quelques améliorations prévues :
- 1 LED verte, 5mm, sur le côté gauche (coté jack d'alimentation) pour signaler que l'arduino a booté correctement)
- un bouton on/off, pas trop utile mais je trouve ça plus propre (oui, je suis un peu maniaque parfois); il sera aussi ajouté côté gauche (certainement à droite de la prise jack 2.1mm pour compléter tout le bloc "alimentation" du circuit)
- 2 capteurs dans la flotte pour détecter la présence d'eau entre 0 et 20 cm (zone non visible pour le sonar); le capteur "VCC" aura une résistance de pull-up de 10K ohm (si j'en crois mes recherches)
- 1 LED rouge, 5mm; elle sera allumée par l'arduino s'il détecte de l'eau entre 0 et 20 cm du sonar

Les LED seront mises en série avec une résistance (à déterminer suivant l'intensité désirée et mes stocks de résistance dispo).

J'ai surtout un doute sur l'interrupteur on/off que je peux utiliser. J'ai reperé ce modèle .
- Ca convient pour mon alimentation 12 V/2A (je suppose vu les specs mais je prefere demander ^^) ?
- Pourquoi il y a 3 broches (une histoire de "normalement ouvert" et "normalement fermé" comme sur un relai ?) ?
- Sinon, ils existent en 2 broches si c'est plus simple.

Merci de supporter ma noobitude

1) L'Arduino ne boote pas vraiment comme un PC puisqu'il n'y a pas de système d'exploitation, mais peu importe.  
 
2) Pour ton pullup 10k c'est bien mais inutile d'en mettre un physiquement, il y en a dans l'AVR à activer avec un appel d'une fonction Arduino (j'ai pas les détails en tête).
 
3) Ton interrupteur, oui, c'est comme sur un relais, la broche du milieu qui est reliée à une des deux extrêmités selon la position de la bascule.
 
4) Il n'y a pas de datasheet pour cet interrupteur avec les spécifications pour du DC, mais pour un petit Arduino ça passera dans tout les cas.
 
5) Pour tes LED, tu peux calculer la valeur de la résistance avec R=(U-U_LED)/I avec I 20mA maxi pour une LED standard mais il vaut mieux rester bien en dessous pour un simple indicateur, les LED modernes sont vraiment très (trop) lumineuses. Tu peux mettre 1k...10k au pif et voir si ça te convient au niveau luminosité.

1) je pensais après la phase d'init()" quand je parlais de boot
 
2) ah oui, j'avais mis l'option en plus dans mon prog de test
 
3) Et donc, un 2 broches suffit ? Si je prend un 3 broches, l'un des 2 broches ne sert à rien ?
 
4)
 
5) C'est ce que j'ai commencé à faire avec 150 Ohm  et 200 Ohm  mais le vert n'est pas très puissant comparé au reste, il me faudrait du 100 Ohm je pense.

3) Oui et Oui.
5) Les LED vertes il y en a deux types (matériaux de dopage(??) différents, j'y connas rien, demande à un chimiste), l'un est beaucoup plus lumineux que l'autre. J'ai pas fait le calcul mais 100 Ohm et même 200 Ohm ça me paraît assez faible.

3) Merci, c'est commandé
 
5) Je testerai avec 1K ohm pour le rouge mais pour le vert, c'est assez faible avec 200 Ohm, j'ai peur que ça soit peu visible en plein jour.

J'ai vérifié, 200 Ohm ça passe pour du vert et 5V Vcc (<-tension utilisée pour le AVR qui pilote la LED). Tu peux même descendre plus bas, en mesurant la tension à travers la résistance connue tu peux calculer le courant réel sans ampèremètre / sans insérer un appareil dans le circuit qui va influencer / falsifier la mesure (résistance interne du multimètre en mode courant ou "burden voltage" ). 20mA maxi.

J'ai retrouvé les specs du pack de LED, il est en description ici.
En faisant les calculs pour 5V et 20mA, je trouve :
- led rouge : entre 95 et 110 ohm
- led verte : entre 80 et 100 ohm
 
En faisant des tests avec différentes valeurs de résistance (50, 100, 150, 200, 500 et 1K) :
- led rouge : jusqu'a 500 Ohm, ça reste assez puissant comme lumière, ça me semble bien pour indiquer une erreur (même en plein jour d'été)
- led verte  : meme à 50 ohm, ça reste faible; je me demande si je ne vais pas utiliser du bleu à la place

Comme je disais, il y a deux chimies différentes pour le vert, tu doit avoir celle qui éclaire faiblement (mais coûte moins cher à produire je suppose ). Tu peux toujours racheter des LED de marque (ou pas si tu es joueur) pour comparer.

Faut mesurer le Vf surtout. Les LED bleues sont devenues tellement courantes que c'est devenu probablement plus intéressant de foutre une couche de phosphore verts par dessus pour faire une LED verte plutôt que de produire des die verts.

La flemme, je ferai avec.
 

La Vf ?

Tension de seuil en français je crois, tension aux bornes de la LED quand un certain courant (20mA?) la traverse. Je l'avais appellé U_LED dans la formule pour le calcul de la résistance.

 
 
Reçu ce jour les fameux ATtiny85    
 
Le projet "cuip-cuip" repart de plus belle !    
La partie programmation est "débugguée", ça devrait donc être une partie de plaisir de passer
à la suite...

comment je peux connaître l'intensité max que délivre une pile ?

En court-circuit, beaucoup

Je dirais que ca doit dépendre de la résistance interne de la batterie (= chauffe et chute de tension que cela occasionne)
Bref ca doit dépendre de la chimie/type de la batterie.

Il me semble que pour les batteries lithium, il ne vaut mieux pas dépasser les 2C (ex: pour une 1Ah, max 2A). Pour les piles boutons c'est 1-2mA de mémoire (ou 10mA, je ne sais plus)...

https://www.youtube.com/watch?v=QgPOYquSVWE

Cet apres-midi, un avancement sur la v2 de mon projet :
- soudage des nouveaux composants
- percage de 3 trous dans le boitier pour les LED (verte, jaune et rouge)
- debug du code (quel boulet je fais, j'avais oublié les digitalRead() )
 
Finalement, pas d'interrupteur on/off car :  
- flemme de revoir le schema électrique
- flemme de percer un trou rectangulaire
 
Quelques photos :
- les 3 LED

- la plaque de prototypage recto/verso


 
On termine l'installation demain avec mon père
 

Parfait merci

 
 
J'suis en train de bosser sur le cuip-cuip miniplayer MP3.
 
Résumé du dernier épisode : on avait réussi (merci le topic) à programmer un t45 en passant
par Xloader (une sorte de GUI pour AVRdude) en découvrant les bons paramètres à lui .CONFier.    
 
J'avais terminé par un flash avec succès du "blink.hex" dans le t45.
Confiant, j'avais alors essayé de flasher le "miniplayer.hex" dans un autre t45.
Ce qui avait échoué, car il n'a semble-t-il pas assez de mémoire, comparé à un t85
originellement prévu dans le lecteur...
 
J'ai donc reçu des t85, et à l'instant, j'ai tenté de flasher "miniplayer.hex" comme précédemment.
Bon, "upload failed".
Ca commence bien, ou alors je n'ai vraiment pas de bol...
 
J'investigue, et je ferai certainement des retours par la suite.  
 
 
PS : j'allais oublier de préciser que j'ai essayé de flasher les .hex avec et sans les fuses. Rien.

Je progresse, pas vite mais je pense que je progresse.    
 
J'ai remis le t45 : j'y remets aisément le blink = ok.
J'essaie le playerMP3 : fail (mais c'est normal ici).
 
J'ai tenté avec deux t85 sur les 5 que j'ai : ni le blink, ni le MP3 ne rentrent    
 
Les brochages sont les mêmes, aussi je ne comprends pas ce qui cloche.
 
 
EDIT 1 :  
- Essayé de flasher le blink depuis l'IDE = ok.
- Essayé de flasher le bootloader (en 1 Mhz interne) dans un des deux t85 = ok.
 
Next : essayer de flasher directement depuis le shell avec AVRdude puisqu'on a aussi trouvé
la bonne commande à utiliser.
 
EDIT 2 : YES J'AI RÉUSSI !!!    
Avec ça dans le shell : avrdude -v -p attiny85 -c arduino -P COM11 -b 19200 -Uflash:w:sd8p_mo_sans_fuses.hex
Ca écrit plein de bordel, mais à la fin, il dit que tout est ok (je colle pas, parce que c'est très long).
 
Par contre, dans ce .hex, et comme son nom l'indique, j'ai supprimé les deux lignes à propos
des fuses, car sinon, ça renvoie une erreur bidon.
 
Je suis donc extrêmement content, d'autant plus que j'ai déjà cablé tous les fils nécessaires sur le
lecteur de carte SD (voir topic electronique@HFR) : il ne me reste quasiment plus rien à faire.
Enfin, je suppose qu'il faut flasher d'une manière ou d'une autres les deux lignes à propos des fuses...
Dans l'article, le concepteur du player dit bien qu'on peut le faire en deux fois pour cette version-ci
du player.
Mais je ne sais pas le faire, je ne comprends pas, au débotté, comment je suis censé faire ça ?
Je crée simplement un fichier .hex avec juste les deux lignes "fuses" dedans ?
 
EDIT 3 : essai d'un simple fichier avec simplement les deux lignes concernant les fusibles = ECHEC.

Erreur sur la deuxième ligne, une addresse est fausse à ce qu'il me dit...