Commande automatique de groupe électrogène - machine à états et autres questions

bricofoy:
Le dtr->reset, si on appuie sur le bouton reset au bon moment, on s'en passe, j'avais fait ça sur la nano de la V1 du projet en virant le condo car le reset auto me gênait, ça marchait bien.
...

C'etait une simple "reflexion"
j'en etait "intellectuellement" resté à ce que mon doigt :grin: ne gerait pas correctement le reset "dans une bonne fenetre temporelle"
et/ou que le bootloader devait etre changé.

ben c'est ce que je me demande aussi... mais pourtant, sur la nano qui est sur la carte V1 du projet, j'ai viré le reset auto qui m'empéchait de débugger correctement, et l'upload marchait bien en appuyant sur reset au moment où l'ide affiche la taille du sketch compilé.

je vais couper le strap "reset_en" sur la uno pour vérifier à nouveau...

bon, test effectué avec la UNO en coupant le strap : l'upload fonctionne bien, mais c'est vrai que la fenetre de temps pour appuyer sur reset est courte, faut vraiment appuyer dès l'affichage de la taille du code dans l'ide.

par contre, quand on rate de moment, on n'arrive pas du tout au message d'erreur qu'il y a dans l'autre cas, mais simplement un laconique
avrdude: stk500_recv(): programmer is not responding
ce qui semble parfaitement logique.

dans l'autre cas, il semble qu'il y ait donc bien un problème au niveau de a communication. Est-ce que la longueur des fils où transitent les signaux TTL peut perturber ? Faudrait-il utiliser éventuellement des câbles blindés ?

Tu pourrais peut être flasher dans ton ATmega (depuis la UNO) un soft qui sort des traces sur la liaison série
Et voir si tu les reçoit via la Nano/FTDI

Même faire en sorte que ce soft te renvoie quelque chose de différent s'il reçoit quelque chose sur la liaison entrante
Comme cela tu valide la liaison série indépendamment d'avrdude

oui, j'ai déjà essayé ça, ça fonctionne. la liaison est parfaitement opérationelle, il n'y a que pour l'upload que ça foire.

Et le bootloader est ok puisqu'il marche quand le chip est sur la Uno.

Reste le reset qui ne se fait pas au bon moment ?

Normalement le bootloader fait pulser 2 fois la led 13 quand il démarre. Est-ce que tu as une led sur la pin D13 ?
Ou en mettre une juste pour vérifier ?

pas deux fois, mais 3. sur la carte il y a un relais d'alim sur cette pin, qui claque bien trois fois.

mais ce n'est pas sur ma carte le soucis, c'est sur le convertisseur usb/ttl, car quand je le branche sur la uno de la même manière, j'ai le même résultat.

et pour ce qui est du reset, quand je programme la uno en ayant supprimé le reset automatique, ça fonctionne parfaitement, faut juste appuyer sur reset au bon moment. Et si on rate le moment, le message d'erreur est différent de celui que j'obtiens avec le convertisseur FTDI. (enfin quand j'appuie sur reset au bon moment, en tout cas. Avec le convertisseur aussi j'obtiens le message de non réponse si je rate le reset)

ce qui est gonflant, c'est que quand je met sur ma carte un atmega programmé avec un truc qui débite et reçois des infos sur le port série, ça fonctionne parfaitement, le convertisseur semble faire son boulot tout à fait correctement.

il n'y a qu'un truc qui m'a semblé ouche, c'est que de temps en temps, il y a des espaces en trop dans ce qui est reçu via le convertisseur. mais j'ai vu ça une fois et je n'ai pas réussi à le reproduire, pourtant je suis certain que ça ne venait pas du soft dans le micro.

je me demande vraiment si je n'ai pas des perturbations du fait de la longueur des fils que j'ai mis entre la carte nano qui me sert de convertisseur et ma carte ou la uno (environ 25cm). je vais essayer de les raccourcir fortement.

ou alors c'est parce-que j'ai tressé les trois fils pour pas qu'il se baladent, ça a faire des paires foireuses ?

Bon, finlement, succés ! En fait il suffisait de choisir "duemilanove" comme carte, et là l'upload fonctionne. J'avoue que je ne comprends pas bien pourquoi, vu que c'est le même micro et le même ftdi que par exemple la uno, la nano ou la pro, mais bon. En fouillant sur le forum anglais, j'ai trouvé des erreurs similaires, qui avaient été résolues en changeant de modèle de carte, et finalement en les essayant toutes, y'en a bien une qui fonctionne :slight_smile:

Du coup, le premier truc que j'ai uploadé dans la carte, c'est "blink"... et comme j'ai sur la broche 12 et la 13 des relais, ça donne un résultat assez amusant :

EDIT : avec le bon lien, c'est mieux :slight_smile:

Tu veux un indice ?

Petite expérimentation pratique :

  • Met le chip sur ta Uno
  • Flash Blink
  • Regarde le clignotement de la led
  • Met le chip sur ta carte
  • Ecoute les relais (ca serait mieux avec une led)
  • Crie "P.... mais c'est bien sur"

Ah tiens, ça me rappelle quelque chose :slight_smile:

Pourquoi ? Tu as fait la même chose B@tto ?
:grin:

barbudor:
Tu veux un indice ?

Petite expérimentation pratique :

  • Met le chip sur ta Uno
  • Flash Blink
  • Regarde le clignotement de la led
  • Met le chip sur ta carte
  • Ecoute les relais (ca serait mieux avec une led)
  • Crie "P.... mais c'est bien sur"

ouais non mais t'inquiètes, j'avais compris, hein

mais le résultat sur un relais mérite quand même d'être écouté :stuck_out_tongue: il doit y avoir moyen de faire des instruments de musique avec ma carte :stuck_out_tongue:

edit : lien corrigé dans le message plus haut

Ce qui veut dire aussi que toutes les tempo de ton code sont fausses.

gné ? comment ça ? la duemilanove n'est pas à 16MHz ?

Je crois que tu n'as pas compris mon indice.

Le bootloader de la UNO tourne à 115200
Celui de la Duemilanove est à 57600

Si ton téléchargement fonctionne à 57600 c'est parce que ton ATmega tourne en fait à 8MHz au lieu de 16MHz, mais qu'il ne le sait pas (à l'insu de son plein gré dirions nous).

La photo de ta carte n'est pas suffisante pour vérifier si ton quartz est bien à 16MHz.

Mais c'est pour cela que je te suggère de vérifier qu'un code connu flashé dans le même chip s'exécute à la même vitesse (ou pas) sur les 2 plateforme.

Si ton quartz est bien à 16MHz et que tu constates une différence de vitesse, c'est que tu n'a pas le bon quartz par rapport aux FUSE de ton ATmega (des histoires de résonance parallèle ou série qui font que le quartz oscille sur la fondamentale ou l'harmonique).

oula... ouais ok... pourtant en activant le mode "verbose output" lors de l'upload, dans tous les cas il essaye la comm à 57600, que ce soit avec la carte UNO ou la carte Duemilanove sélectionnées...
Mon quartz est bien à 16MHz, et là je viens de charger le programme prévu pour dans la carte, les tempos me semblent OK.

EDIT : je viens de vérifier en chronométrant, les tempos sont bien ok. Ceci dit, il y a quoi comme quartz sur la duemilanove ? si ça se trouve ça tourne en fait à 8MHz mais c'est aussi compilé pour...

Pourtant :

uno.name=Arduino Uno
uno.upload.speed=115200
...
atmega328.name=Arduino Duemilanove w/ ATmega328
atmega328.upload.speed=57600

Je ne vois pas d'autre raison pour expliquer le comportement différent entre les 2 cartes qu'une horloge divisée par 2.

arghhhh je deviens fou, je refais à l'instant un essai en sélectionnant "uno" pour te copier coller la ligne où il raconte qu'il commmunique à 57600, et quand j'uploade... ça marche x_x

du coup je re-sélectionne "duemilanove", et... ça marche plus je crois que je vais faire exorciser ma carte et mon pc :stuck_out_tongue:

en fait ce que tu me dis sur les vitesses, ça semblerait vouloir dire que l'IDE a buggé et ne prenait pas en compte mon choix de carte, en fait il restait sur 57600 quel que soit le choix effectué.

Ensuite il a planté et j'ai du le relancer suite à une déconnexion de l'USB, et depuis il fonctionne normalement, et le bon choix est bien "uno", vu que j'ai une atmega328P avec un bootloader uno dessus, à 16MHz.

Donc vinalement tout fa bien ? :slight_smile:

ben du coup, oui, mais il semble tout de même qu'il y ait un bug dans l'IDE 1.0

Par contre ça ne va pas si bien car mon soft lui fait n'importe quoi, mais ça c'est un autre soucis :stuck_out_tongue: