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

bof, là vu le système, si ça marche, c'est immédiatement visible. Enfin je veux dire ça ne devrait pas changer de comportement au cours du temps.

Le problème que j'avais avec la première version, c'était le reboot du FTDI qui m'empéchait de suivre justement le moment ou ça bugguait...

La nouvelle carte quasiment finie :

Cool

bricofoy:
La nouvelle carte quasiment finie :

bonjour bricofoy
belle rea
c'est quoi le fil bleu en "diagonale" (strap) , un impératif pour rester sur du routage 1 face ?

c'est le mise à la masse des bobines des relais, pour ne pas passer par le plan de masse qui est en dessous. C'est pour écarter le passage du courant "puissance" (ça reste relatif, la puissance de 4 bobines, mais enfin) de la masse numérique, surtout vu que j'ai la masse du circuit résonnant du quartz qui est juste sur le trajet sinon.

c'est la mise en pratique des conseils trouvés ici et d'après mon pote d'airbus sur la séparation des alims et des masses :slight_smile:

Bon, aujourd'hui je me replonge dans le projet. Et là, c'est le drame : impossible de programmer l'atmega sur la nouvelle carte...

En fait sur ma carte, j'ai juste sorti sur un bornier les pins TX,RX et GND (les trois broches visibles sur la photo de la carte, à coté du poussoir reset), et sur ce bornier je viens brancher ma première nano dont j'ai grillé, puis dessoudé l'atmega. Cette carte est donc devenue un convertisseur USB/TTL puisqu'il ne reste dessus que le FTDI.

À priori cette bidouille fonctionne, puisque si je reboucle tx et rx, je reçois bien ce que j'envoie, et aussi si je connecte cette carte au port série de ma uno, je reçois bien ce qui transite. J'ai aussi fait des essais sur la nano avec software serial, ça communique dans les deux sens.

Donc, le convertisseur fonctionne. Jusque là, tout va bien.

Mais quand je branche ça sur ma carte maison, sur laquelle est monté un atmega neuf avec le bootloader (puce testé sur la uno, elle fonctionne), ben lorsque je fais "upload" ben... rien. Ça compile, j'appuie sur reset, il y a un moment d'attente et je reçois l'erreur suivante :
avrdude: stk500_getsync(): not in sync: resp=0xe0

le plus souvent la valeur à la fin du message est plutot 0x00

j'ai du coup essayé de flasher ma carte uno sur le même principe, puisque elle elle marche à coup sûr. Même résultat.

J'avoue que là, je sèche.

DU coup, je flashe l'atmega en le montant sur la uno, puis je le remet sur ma carte, mais c'est légèrement fastidieux, et je doute que les pins de la puce supportent très longtemps le traitement :confused:

bricofoy:
Bon, aujourd'hui je me replonge dans le projet. Et là, c'est le drame : impossible de programmer l'atmega sur la nouvelle carte...

En fait sur ma carte, j'ai juste sorti sur un bornier les pins TX,RX et GND (les trois broches visibles sur la photo de la carte, à coté du poussoir reset), et sur ce bornier je viens brancher ma première nano dont j'ai grillé, puis dessoudé l'atmega. Cette carte est donc devenue un convertisseur USB/TTL puisqu'il ne reste dessus que le FTDI.
...
DU coup, je flashe l'atmega en le montant sur la uno, puis je le remet sur ma carte, mais c'est légèrement fastidieux, et je doute que les pins de la puce supportent très longtemps le traitement :confused:

Bonjour bricofoy
Sans que ça réponde directement à ta question :
J'ai une carte uno, constat le 8U32 a "morflé"
j'ai essayé de programmer le 328 en utilisant RXD/TXD au travers d'un adaptateur USB<--->COM
après quelques essais juste pour le fun (pas trop de temps) j'ai laissé "tombé" , j'ai noté dans un coin qu'il manquait (peut être ? ) le signal DTR .

prendre là le topic

ben quand tu regardes par exemple une arduino pro et le convertisseur à FTDI ou 8U32 qui va avec, il n'y a que TX, RX, GND, 5V et le reset qui sont reliés.

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.

l'alim, ben ma fois tant que la carte est alimentée, je ne vois pas en quoi ça pourrait déranger.

et il ne reste bien que tx/rx, non ?

en plus j'ai sous les yeux les schémas de la nano et de la uno, il n'y a a bien que tx/rx et le dtr->RESET qui sont reliés entre le ftdi et l'atmega.

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