Discussion :

[Guesset]

Bonjour,

Je ne reviendrai pas sur les conseils avisés sur la gestion du capteur.

En revanche j'attire l'attention sur le fait que le relais principal est à choisir avec le plus grand soin (en français : assez cher) de même que le câblage sortant, Un four ne travaille pas avec quelques mA et quelques volts. Les courants sont importants en fonctionnement mais surtout multipliés au début (à froid la résistance de chauffe est faible). J'ai vu des relais marcher dans ces conditions. Une seule fois car les contacts furent soudés par l'arc initial. Mais peut être le relai ne pilote pas directement la résistance du four ?

Salutations

[misere]

Bonjour,

Mais peut être le relai ne pilote pas directement la résistance du four ?

Bonjour,
oui c'est le cas. Le four est en triphasé 380v. Je déjà des relais qui vont bien et qui encaissent sans problème l'ampérage des résistances.
Avec un relais "Arduino" je compte émuler la bobine du relais de puissance (220v), en passant par une ampoule qui fera office de résistance et en même temps un témoin de chauffe.
Je pense que c'est correct.

[Bernard_68]

Bonjour Misere,

Pour le prototypage la carte UNO plus une breadbord et des fils Dupont c'est Ok.

Pour la réalisation définitive, je dis casse coup avec ce matériel.
Il est trop sensible aux vibrations et aux risques de déconnexions.

Il existe un autre modèle de carte : la nano historique qui utilise le même microcontrôleur (atmega328p) : le programme sera exactement le même.
Cette carte est plus petite et se soude sur un circuit imprimé ou sur une carte de prototypage avec des pastilles au pas de 2,54 mm.

Pour l'achat du matériel il y a les boutiques officielles Arduino et affiliés. Il y a aussi Aliexpress.

Quand on voit que 15 ans après la nano est toujours vendue à son prix de lancement (sur le store Arduino les prix sont hors taxe et hors frais de port) et qu'acheté sur Ali ou Ebay on a la même chose 10 fois moins cher, rendu dans la boite aux lettres, on est en droit de se poser des questions.


Attention avec la nano.
La nano est une création de la société Gravitec qui a été reprise par Arduino.

C'est une UNO en format réduit. Il y a trois différences entre UNO et Nano

• La conversion USB/série qui est bien plus stable sur la nano que sur la UNO qui a tendance à se déprogrammer.
• La nano a deux entrées purement analogiques suplémentaires. Le boîtier du micro dans la UNO n'a pas assez de pins pour sortir ces deux entrées analogiques.
• En cas d'utilisation des entrées analogiques avec une nano il est préférable de ne pas l'utiliser alimentée par l'USB a cause de la diode shottky en série avec le +5 V USB.

Arduino a récemment sorti 3 nouvelles "nanos" qui utilisent chacune un microcontroleur différent => ou comment semer le trouble chez les débutants !
Cas de la nano historique (la seule que je connais) :
La nano "historique" vendue par arduino est livré avec "le nouveau bootloader"
La nano "historique" vendues par les façoniers reste livrée avec le "Old bootloader" => c'est juste une case à cocher dans l'IDE.
La nano est openhardware , sa copie est légale, les façonniers améliorent parfois les produits qu'ils copient.

On peut aussi trouver des copies de cartes UNO ou des pastilles sont prévues pour souder des fils en plus de pouvoir enficher des fils Dupont.


Mon humble avis :

1. on n'utilise pas en production le matériel qui a servi a faire la mise au point.
2. pour la mise au point quand on débute le trio UNO, breadboard, fil Dupont est pratique.
3. pour la production, je n'imagine pas des connexions que ne soient pas soudées ou verrouillées mécaniquement.

Expérience personnelle :

Quand j'ai débuté, j'ai acheté une carte UNO officielle (UNO R2) chez un revendeur officiel en France qui vendait à des prix "officiels".
Résultat : la carte achetée en juin avait un bootloader buggé sous Windows Vista et Linux.
La honte est que c'était connu depuis février et aucune information n'avait été donnée clairement sur le site Arduino.
Depuis tout mon matériel vient de Chine (Ebay ou Ali) et je n'ai jamais eu de problème.

Ce n'est que mon expérience personnelle.

[misere]

Bonjour Misere,

Pour le prototypage la carte UNO plus une breadbord et des fils Dupont c'est Ok.

Pour la réalisation définitive, je dis casse coup avec ce matériel.
Il est trop sensible aux vibrations et aux risques de déconnexions.

Il existe un autre modèle de carte : la nano historique qui utilise le même microcontrôleur (atmega328p) : le programme sera exactement le même.
Cette carte est plus petite et se soude sur un circuit imprimé ou sur une carte de prototypage avec des pastilles au pas de 2,54 mm.
.

Merci Bernard pour ces infos. Piqué un peu par ce projet j'ai acheté "ARDUINO" de QUETIN éditions La Fabrique. J'ai donc une vue plus sûre sur le codage. J'ai bien vu également qu'il y avait des cartes diverses avec des extensions pour un peu tous les usages.
Mais, je n'avais pas percuté sur ce point. N'ayant jamais eu une carte en main, je pensais naïvement faire un montage enfiché pour le test, puis ensuite tout souder et fixer dans un boitier. Ah, les choses ne sont jamais aussi simples...

J'ai bien vu que sur Ali ou Amazon les prix sont vraiment dérisoires. Je vais commander du matériel pour mon projet immédiat, mais cela dit, ce monde que je découvre m'ouvre d'autres perspectives ! ( Par exemple j'entrevois une possibilité intéressante de donner goût aux enfants pour le code. Il y a une interaction immédiate entre le code et un résultat pratique).

Bien à vous, et la meilleure journée possible à tous.
Eric.

[Guesset]

Bonjour,

Il y a des PCB qui reprennent la logique d'une breadboard mais avec des soudures à faire en lieu et place des fiches/fils à enfoncer. Cela permet de pérenniser sans trop d'effort un montage volant.

A propos des breadboards, les résistances livrées en bandes (avec une solidarité assumée par des doubles bandes de papier collant) ne doivent pas être décollées des bandes mais coupées sauvagement. En effet, si elles sont décollées des résidus de colle restent sur les extrémités des fils des résistances et encrassent les contacts des breadboards qui deviennent alors de moins en moins moins fiables.

Salutations

[misere]

Bonjour,

Il y a des PCB qui reprennent la logique d'une breadboard mais avec des soudures à faire en lieu et place des fiches/fils à enfoncer. Cela permet de pérenniser sans trop d'effort un montage volant.

què és això PCB ( qu'est ce que c'est ). J'ai cherché et trouvé circuit imprimé.

Enfin, j'ai trouvé la définition... maintenant je dois chercher ce type de circuit.. J'ai trouvé des sites qui proposent une bonne douzaine de cartes sur une seule recherche, mais en choisissant seulement avec la photo. Bonjour la facilité pour un débutant qui n'a jamais vu à quoi cela ressemble!

Je vais donc chercher une carte Nano, (Ou Uno) soudable; avec un port USB, et qui accepte une carte relais.

[Guesset]

Bonjour,

Sur Ali express avec les mots clés : PCB prototypage.

Celui là est en fibre de verre et époxy (souvent raccourci en PCB époxy). Il y en a d'autres; par exemple moins chers, en bakélite (marron chocolat au lait).

Celui ci avait l'avantage d'être présenté avec la breadboard qu'il remplace.

Salutations

[misere]

Bonjour,

Voilà, j'ai reçu le matériel, et je reviens vers vous car j'ai des problèmes que je ne sais pas résoudre.

J'ai écris pendant les vacances le logiciel en Windev pour piloter mon four. Mais pour tester la partie pilotage j'avais besoin de la carte UNO.

J'ai deux soucis. Le premier matériel. J'ai connecté la carte. Deux leds s'allument. Une rouge fixe, et une rouge clignotante à la fréquence env. 1 s. Je mets une image de la carte.

Avec Windev l'ouverture du port série ne me renvoie pas d'erreur.

J'ai donc écrit une "moulinette" pour allumer et éteindre une led, manière de tester la communication.
Là impossible de faire fonctionner la carte.
JLa carte me renvoie des messages. En tentant "Graver la sequence d'initialisation" : Error while burning the bootloader: Missing programmer
J'ai tenté "Formatage automatique.
J'ai tenté de téléverser le prog. écrit pour l'Arduino et j'ai des errerus de compilation. Je vous mets le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// declaration des variables
    int LedVerte = 9;
    int MessageRecu = 0;
 
  void
  setup() {
 
  // Initailiser le moniteur série
  Serial.Begin(9600);
  Pin.Mode(LedVerte, output);
}
 
void loop() {
  if (serial.available() > 0) {
    MessageRecu = serial1.read();
    If(MessageRecu = 1) {
      // allume la led
      digitaLwrite(LedVerte, HIGH);
    }
    If(MessageRecu = 2) {
      // éteint la led
      digitaLwrite(LedVerte, LOW);
    }
  }

Voilà; si vous avez un peu de temps... merci de me tuyauter pour mettre cette carte en fonctionnement.
Bien à vous
Eric

[Guesset]

Bonjour,

Ce programme n'a aucune chance de compiler, il y a trop d'erreurs dont les trois types principaux sont :

• Le C++ est un langage sensible à la casse : par exemple, Serial est différent de serial (seul le premier est prédéclaré).
• Il y a des fautes de frappe serial1.read au lieu de Serial.read.
• Pin.Mode cumule toutes les erreurs Pin au lieu de pin et Pin.Mode au lieu de pinMode.

Il faut apprendre a minima le langage et lire la doc des bibliothèques utilisées. Les moteurs de recherche sont nos amis.

Il y a aussi ChatGPT pour ne rien apprendre et avoir un code moyen.

Salutations

[misere]

Bon, je me suis fait retoquer... c'était mérité.

J'ai corrigé toutes mes erreurs de code et le compilateur ( Fonction Téléverser ) n'émet plus de message d'erreur.
La Led rouge "Clignotante" est maintenant allumée.
Je remets le code car j'ai changé le type la valeur "MessageRecu"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
// declaration des variables   Code ARDUINO
    int LedVerte = 9;
    char MessageRecu = "0";
 
  void setup() {
 
  // Initailiser le moniteur série
  Serial.begin(9600);
  pinMode(LedVerte, OUTPUT);
}
 
void loop() {
  if(Serial.available() !="") {
    MessageRecu = Serial.read();
    if (MessageRecu == "1") {
      // allume la led
      digitalWrite(LedVerte, HIGH);
    }
    if(MessageRecu == "2") {
      // éteint la led
      digitalWrite(LedVerte, LOW);
    }
  }
}

Avec Windev j'envoie sans message d'erreur les caractères "1" et "2".
Windev me renvoie bien le message 1 caractère envoyé sans erreur

Par contre sur mon montage la Led ne s'allume pas.
J'ai mis en série une résistance et la Led entre le pin 9 et le pin marque Tx->

Avec Windev je lis le buffer de la carte j'ai une chaine vide ""

Je ne sais pas trop comment avancer.

[misere]

Je viens d'avoir l'idée de retourner la Led
Du coup elle est allumée en permanence

Je ne dois pas avoir le bon Pin en Tx ?

[misere]

Et j'ai le même comportement entre 9 et GND.
Il ne se passe rien.

[Jay M]

attention aux apostrophes et guillemets

un char se représente avec des apostrophes alors qu'une chaîne sera avec des guillemets (un tableau de caractères)

essayez

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
// declaration des variables   Code ARDUINO
int LedVerte = 9;
char MessageRecu = '\0';
 
void setup() {
 
  // Initailiser le moniteur série
  Serial.begin(9600);
  pinMode(LedVerte, OUTPUT);
}
 
void loop() {
  if (Serial.available() != 0) {
    MessageRecu = Serial.read();
    if (MessageRecu == '1') {
      // allume la led
      digitalWrite(LedVerte, HIGH);
    }
    if (MessageRecu == '2') {
      // éteint la led
      digitalWrite(LedVerte, LOW);
    }
  }
}

on peut simplifier en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const byte LedVerte = 9;
 
void setup() {
  Serial.begin(9600);
  pinMode(LedVerte, OUTPUT);
}
 
void loop() {
  switch (Serial.read()) { // retourne -1 quand il n'y  rien à lire
    case '1': digitalWrite(LedVerte, HIGH); break;
    case '2': digitalWrite(LedVerte, LOW); break;
    default: break; // on ignore les autres caractères ou le -1
  }
}

[misere]

Super. Ca fonctionne.

Je ne sais comment vous remercier... MERCI, MERCI.

Bonne soirée à tous, et je vous ferai un retour quand mon four fonctionnera.
J'ai maintenant tout ce qu'il me faut.

[Guesset]

Bonjour,

Je ne sais pas ce qu'envoie Windev mais :

• La première version attendait un octet à 1 ou 2 (0x01 ou 0x02)
• La deuxième version attend une chaîne de caractères "1" ou "2" soit deux octets (0x31 0x00 ou 0x32 0x00) car une chaîne se termine par un 0. Cela ne risque pas de marcher avec Serial.read qui ne lit qu'un octet.

MessageRecu est une chaîne de 2 caractères soit un tableau de 2 octets initialisés à 0x30 0x00 (0x30 est le code du caractère '0') pour "0".
Ecrire char MessageRecu = "0"; est équivalent à écrire char MessageRecu[] = {'0', '\0'};.

Alors écrire MessageRecu = Serial.read(); revient à écrire que l'on change (mal) l'adresse du tableau MessageRecu. Normalement il devrait y avoir au moins un warning à la compilation pour signaler ce casting sauvage.
En l'état, il est donc normal qu'il ne se passe rien (et on a de la chance).

Si on écrit MessageRecu[0] = Serial.read(); cela devrait marcher si windev envoie bien les caractères '1' et '2'. Mais il y a du gaspillage de temps et d'espace car une chaîne n'est pas utile.

Plus simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const int LedVerte = 9;                          // broche de la led verte
 
void setup() {
   // Initailiser le moniteur série
   Serial.begin(9600);
   pinMode(LedVerte, output);
   digitalWrite(LedVerte, LOW);                  // commencer la led éteinte
}
 
void loop() {
   if(Serial.available() < 1) return;
   switch(Serial.read()) {
      case 1 : digitalWrite(LedVerte, HIGH);     // allume la led (case '1' si Windev émet un char) 
         break;
      case 2 : digitalWrite(LedVerte, LOW);      // éteint la led (case '2' si Windev émet un char) 
   }
}

Salutations

[misere]

La fonction de Windev qui écrit dans le buffer envoie uune chaine de caractères.
J'y ai fait attention quand j'ai corrigé le code après les premières observations.

C'est pour cela que j'ai remplacé le type de la variable.

Tout à l'heure je me suis précipité pour corriger la façon de rentrer le caractère et je n'ai pas vu vos versions bien plus "belles".
Comme c'est la première fois que je code autre chose que le WLangage je me suis concentré sur le minimum de fonctions.

Je suis un autodidacte de l'informatique. Durant mes études c'étaient des ordinateurs à cartes perforées ! Je suis passé par le basic, puis DbaseII puis un compilateur de DbaseII et quand Windows à proposé les fenêtres j'ai acheté Windev. Depuis je le reconnais volontiers je suis "prisonnier" d'un système, et à mon âge je ne veux de toutes façons pas en sortir.
Après ce projet de four, je vais me mettre dans des programmes ludiques pour mes petits enfants, et je progresserais avec eux!
Je vérifierai quand même les versions que vous m'avez proposé.

[Jay M]

Bonjour,
Ecrire char MessageRecu = "0"; est équivalent à écrire char MessageRecu[] = {'0', '\0'};.

Non absolument pas

MessageRecu est défini comme étant un char, donc 1 seul octet.
Ce n’est pas magiquement devenu un tableau
Effectivement écrire "0" revient à déclarer une chaîne constante contenant le caractère 0 suivi d’un caractère nul. Mais cette chaîne est représentée par son pointeur (on pourrait écrire const char * ptr0 = "0";)
L’affectation met donc l’octet de poids faible du pointeur vers cette chaîne constante dans MessageRecu… évidemment ce n’est pas ce qui était attendu…

Si vous activez les messages d’erreurs dans la compilation vous aurez d’ailleurs sans aucun doute un gros warning…

[Guesset]

Bonjour Jay,

Si vous activez les messages d’erreurs dans la compilation vous aurez d’ailleurs sans aucun doute un gros warning…

Si le compilateur se contente d'un warning et non d'une erreur c'est qu'il transforme la déclaration erronée.

1. Soit il force le type comme je l'ai proposé (char en char * ou char []).
2. Soit il met juste le premier caractère de la chaîne.
3. Soit (pire) il met le premier octet de l'adresse de la chaîne déclarée.
4. Soit...

Ceci étant j'aurais du le corriger.

Normalement les casting implicites d'un type plus grand vers un type plus petit génèrent une erreur et non une alerte (cas 1 et 3).

Salutations

[misere]

Bonjour,
J'ai maintenant un problème de lecture.
J'ai le code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
float Temperature;
int CapteurVal;
float Tension;
 
void setup() {
 Serial.begin(9600);
}
 
void loop() {
  CapteurVal = analogRead(2);
  Tension = (CapteurVal/1024.0)*5.0;
  Temperature = (Tension-.5)*100;
 
  // Vider le buffer de sortie série avant d'y envoyer la nouvelle valeur
  Serial.flush();
  Serial.print (Temperature);
 
  delay(3000);
}

Je récupère une chaine de caractères du style "&)0" ou "!"<tab>0".
J'ai essayé avec la fonction String mais j'ai les mêmes sorties. Rien trouvé sur les forums qui m'ait aidé.

Sûrement un problème de conversion de chaîne mais je n'ai pas su repérer le format.

[Jay M]

Si le compilateur se contente d'un warning et non d'une erreur c'est qu'il transforme la déclaration erronée.

1. Soit il force le type comme je l'ai proposé (char en char * ou char []).
2. Soit il met juste le premier caractère de la chaîne.
3. Soit (pire) il met le premier octet de l'adresse de la chaîne déclarée.
4. Soit...

la norme C++ est claire à ce sujet, convertir un pointeur vers un char n'est pas autorisé sans passer par un reinterpret_cast mais
- le type de la variable, tel qu'elle est déclarée n'est jamais modifié par une affectation
- si la valeur affectée n'est pas directement compatible avec le type de la variable (et que la classe de la variable ne fournit pas de promotion) alors le compilateur essaye de faire une conversion implicite

mais le compilateur peut avoir un fonctionnement spécifique (être un peu laxiste) par exemple une promotion vers un entier.

Ici, notre GCC fait une transformation directe, adresse de la case mémoire pointée = valeur entière du pointeur, sur 2 ou 4 octets suivant la plate-forme

ensuite la norme C++ définit que lorsqu'on essaie d'affecter une variable dont le type est trop grand par rapport à la variable affectée alors il se passe différentes choses. Pour l'affectation d'un entier à un char c'est autorisé (avec un warning suivant les flags de compilation) et GCC prend simplement l'octet de poids faible. Comme ça si la variable entière tenait sur un octet, on a la bonne valeur, sinon ça tronque. (Le même principe est appliqué pour des unsigned mais la c'est documenté)

Bref on transgresse des règles et GCC sait que c'est dangereux, d'où le warning

si vous compilez cela sur UNO avec les avertissements au Max dans les préférences de l'IDE

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
char MessageRecu = "\0";
 
void setup() {
  Serial.begin(115200);
  Serial.println(MessageRecu);
}
 
void loop() {}

vous aurez comme message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
sketch_aug31b.ino:1:20: warning: invalid conversion from 'const char*' to 'char' [-fpermissive]
 char MessageRecu = "\0";
                    ^~~~

qui vous dit que dans l'absolu c'est interdit mais l'option -fpermissive (mise par l'IDE) comme paramètre de la compilation est utilisée pour permettre au compilateur d'être plus permissif envers certaines violations de la norme C++ et donc il laisse passer.

on aura donc l'affectation d'un int à un char, et GCC prend l'octet de poids faible.

---

compilez maintenant le même programme pour ESP32 et là les outils sont moins laxistes. Le compilateur va donc considérer cela comme une erreur et vous aurez

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
sketch_aug31b:1:20: error: invalid conversion from 'const char*' to 'char' [-fpermissive]
 char MessageRecu = "\0";
                    ^~~~
exit status 1
invalid conversion from 'const char*' to 'char' [-fpermissive]

Mais en aucun cas le type de la variable changera