Messages

16

Vos projets / Re : L298 et relais

« le: janvier 21, 2022, 04:02:09 pm »

Où est l'erreur ?

... c'est une question !
Malheureusement je ne suis pas qualifié, il faudrait qu'un expert passe par là !

Je remarque seulement que 2millisecondes, c'est énorme, à se demander si le ralentissement permet, ensuite, une mesure représentative ?
Et qu'en appliquant le même calcul à la fréquence de 40Hz que j'utilise, c'est 25ms qu'il faudrait attendre ! Alors que la pratique habituelle est de respecter un délai de 300 à 400 microsecondes (soit une coupure de l'ordre de 600us mesures comprises).
L'échelle (N / HO) aurait-elle une influence ? Je ne vois pas de raison...
Enfin, pourquoi une telle proportionnalité entre fréquence avant coupure et délai d'extinction du flux ? Est-ce empirique ou imposé par l’électromagnétisme ? Dans le second cas, j'aurais tout à revoir... je me joins donc à la question : Où est l'erreur ?
(en demandant à babskwal de pardonner ce détournement du sujet d'origine ! On se rattrapera !)

17

Vos projets / Re : L298 et relais

« le: janvier 20, 2022, 11:38:13 pm »

Les pins et les timers sont différents mais c'est rigoureusement le même principe.

Tout est là : https://arduinoinfo.mywikis.net/wiki/Arduino-PWM-Frequency

Concernant cette remarque de JPM06 :

Je suis étonné qu'on puisse utiliser des fréquences élevées comme 32kHz, parce que ça ne doit pas être facile de mesurer la FCEM.

La fréquence de PWM est à priori sans la moindre incidence puisque la FCEM ne peut pas se mesurer autrement que courant traction coupé.

18

Composants / Re : Benchmark MCU

« le: janvier 20, 2022, 04:13:51 pm »

Ça me paraît en effet très complexe au point que le processus de choix l'est tout autant ; c'est ce que je découvre avec surprise à mesure que j'entre dans cet univers.

Car je ne connais pas de tableau comparatif, c'est bien là la question.
Sauf si l'on parle de comparer les besoins en entrées/sorties avec les pinouts des cartes du marché. Mais pour ce qui est des performances... j'ai plusieurs fois constaté que les benchmark bâtons ne correspondaient pas à mes observations. Ils sont d'ailleurs tellement globaux qu'on ne sait plus ce qu'ils mesurent (ni comment !).
C'est sur ce point que je m'interrogeais et sur l'existence de sources fiables sur le sujet.

Pour ce qui est de mon cas perso, Jean-Luc à bien relevé que le goulot d'étrangement est (ou sera un jour) l'I2C. Car I2C mis à part, la question de la puissance brute ne se pose pas. Que j'exploite aujourd'hui +/- 10% de la capacité d'un Teensy3.5 ou +/-15% d'un ESP32, ça ne fait aucune différence. Mais c'est effectivement toujours l'I2C le traînard (avec lib SSD1306AsciiWire.h).
( Peut-être mon programme fait-il en effet de l'attente active ? J'avoue ne pas savoir ce que c'est mais je soupçonnais quelque chose de ce genre.
Avec deux parades en tête : remplacer les écrans I2C par leur équivalent SPI / ou envoyer les trames par CAN à une carte supplémentaire, dédiée aux écrans)

Ce qui reste un souci très secondaire comparé à la question... carrément existentielle ! (bof) de savoir choisir une carte. Qui devient d'ailleurs chaque jour un peu plus aiguë ! Je viens (seulement) de découvrir la nouvelle "portée" d' Arduino NANO, les officielles. Avec déjà des variantes à ne plus compter en Chine, la championne du bâtardage !

19

Vos projets / Re : L298 et relais

« le: janvier 17, 2022, 10:09:33 pm »

bonsoir,

il y a un fil qui traitait des PCA9685 et du problème de leur synchronisation (sans solution de mémoire, mais il y a sûrement d'autres idées à piocher) :

http://forum.locoduino.org/index.php?topic=1097.0

Attention en effet aux longueurs de fils mais surtout entre l'Arduino et le module car la communication se fait en I2C, sensible au parasitage (bien que des solutions existent). Mais pas de contrainte il me semble entre les sorties PVM du module et les ponts H.
Attention également au fait que les PCA9685 vont fournir une PWM à 60Hz... alors que pour la santé des moteurs vous tomberez sur des recommandations de plusieurs dizaines de kilo-Herz !! Ceci-dit, ayant expérimenté les 9685 je n'ai jamais subi de conséquences... pour moi ça fonctionnait même beaucoup mieux au point que j'ai aujourd'hui des PWM réglées à 40Hz.

En ce qui concerne les 74HC595 : ils fournissent bien des sorties digitales, uniquement. Même si un MEGA en propose un bon nombre... en fait on finit par en manquer et l'autre intérêt, peut-être le principal, des registres 74HC595, est de transmettre les ordres non en parallèle mais en série : => uniquement 4 fils pour à l'arrivée un nombre illimité de pins ( en théorie, car la limite vient du temps de mise à jour des registres)

20

Composants / Re : Benchmark MCU

« le: janvier 17, 2022, 09:42:21 pm »

wouff ! c'est d'un clarté telle que je crois bien avoir tout compris.

le compilateur : plus de souci.

Mais le "SOC" (notion intégrée je crois)... ça soulève quelques questions car dans ces conditions, comment connaître A PRIORI les prédispositions de tel ou tel... même le datasheet (1000 pages parfois!) restera nébuleux, sauf certainement pour un expert.
Expérience perso : l'ESP32, alléchant et approvisionné pour voir, qui se révèle 2x plus lent qu'un Nano en lecture analogique. L'adaptation du code d'un matériel à l'autre ne se faisant pas d'un clic, pouvoir choisir sur papier ça serait quand même pas mal !
Il faudrait une sorte d' "auto-journal" des SOC... ça existe ?

21

Composants / Re : Benchmark MCU

« le: janvier 16, 2022, 06:10:13 pm »

Bonsoir Msport,
et merci... bien que ça sonne hélas comme une réponse valable je m'en rends compte.
Maintenant le compilateur à considérer "en plus" !! Bon bon, mais oui au fait !
Mais là il doit bien y avoir un compilateur plus performant dans l'absolu (sensiblement ?) que les autres !? ( Ou disons... l'un plus que l'autre, mon choix se limitant à Arduino / PIO )

22

Composants / Benchmark MCU

« le: janvier 16, 2022, 03:03:51 pm »

Bonjour,

Je serais heureux de recevoir de l'aide pour devenir capable de bien choisir une carte, selon ses caractéristiques ET mes besoins propres ... aujourd'hui c'est au petit bonheur la chance !
Pour concrétiser rapidement ce qui a amené ce besoin : après être passé par différents matériels et configurations, mon MCU principal, gestionnaire, est aujourd'hui un Tennsy 3.5. Il est sollicité par beaucoup de tâches et s'en sort fort bien mais prend juste beaucoup de temps pour les communications I2C, au point qu'il serait vite coincé sur un réseau de bonne taille, d'où mon souci et ma question.

Sur le site PJRC, on trouve ce tableau de benchmark :


Je suis malheureusement incapable d'en tirer un enseignement... on y voit cependant qu'un ESP32 surclasse le Tennsy 3.5 (pour 10 fois moins cher !!)

Ayant des ESP32, j'ai donc tenté de retrouver dans des tests simplistes cette supériorité potentielle mais ça n'est pas sauf exception ce qui en ressort. (CPU speed sur : Teensy 120 / ESP 80)
Faudrait-il encore que ces tests aient un minimum de validité... un benchmark rigoureux est probablement une discipline, un art, à part entière...
Il doit néanmoins exister des critères élémentaires pour dégrossir la question ?
Donc grand merci par avance pour toute réponse.

Voici le code des tests perso avec les résultats :

Code: [Sélectionner]

/* POUR TESTS DE PERF */
uint16_t count = 0;
uint32_t timerTests = 0;

void setup() {
  Serial.begin(115200);
  delay(100);
}

void loop() {
  for (int f=0; f<1000; f++) {
/* test calculs*/
    float sqr = sqrt(f);          /* resultat TEENSY : 773 Hz / resultat ESP32 : 244 Hz */
/* test IO */
//    digitalWrite(4, HIGH);        /* resultat TEENSY : 1390 Hz / resultat ESP32 : 4074 Hz */
//    digitalWrite(4, LOW);
/* IO rapide - TENNSY 3.5 */        /*resultat TEENSY : 19633 Hz */
//    digitalWriteFast(4, HIGH);
//    digitalWriteFast(4, LOW);
/* IO rapide - ESP32 */             /* resultat ESP32: 9384 Hz */
//    GPIO.out_w1ts = ((uint32_t)1 << 4);  // HIGH
//    GPIO.out_w1tc = ((uint32_t)1 << 4);  // LOW

  }
  count++;
 
  if (millis()-timerTests >= 3000) {
    Serial.printf("%u Hz \n", count/((millis()-timerTests)/1000));
    timerTests = millis();
    count = 0;
  }
}

cordialement

23

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: janvier 08, 2022, 07:22:00 pm »

Bonsoir,

Je me permets de réveiller ce fil pour y mentionner la découverte de deux possibilités... à priori "unexpected" offertes par la mesure de la FCEM sur un réseau analogique.

Il y a juste un pré-requis : que le réseau soit organisé en sections, équipées d'une détection de passage (et/ou présence). Mais c'est certainement toujours le cas ?

Outre la compensation de charge, on peut alors bénéficier de deux fonctions bien intéressantes :

- très simple, la détection du sens de marche, non pas bien-sûr le sens de rotation mais la marche TRACTION/REFOULEMENT
   * premier cas : une section détecte un train et concomitamment une FCEM => c'est une motrice (sauf cas ennuyeux mais très-très rare d'un matériel avec un seul bogie moteur) ;
   * second cas : un train est détecté mais la FCEM reste nulle, ou insignifiante => c'est un CONVOI en refoulement.
     Une donnée qui peut être utilisée pour éviter une marche à grande vitesse en refoulement, possiblement périlleuse (et peu réaliste ?)

- plus "sioux", que je n'ai pas implantée mais les tests sont positifs :
  une FCEM étant le reflet du nombre de tours moteurs, il suffit d'une variable, par motrice, donnant sa démultiplication pour que les mesures de FCEM, intégrées sur un temps donné, indiquent une distance parcourue ;
      * un top détection puis un top fin-de-détection SUR UNE SECTION : la différence des deux temps donnera la longueur du convoi (comptage des wagons, triage) ;
      * un top détection puis l'atteinte PAR LE TRAIN d'une FCEM intégrée prédéterminée => le convoi a atteint un point précis (dépendant c'est vrai de mesures elles-mêmes précises, donc de la qualité du contact rails/roues)
        et ceci quelque soit le sens de marche, traction/refoulement et sa vitesse !
        de quoi disposer à volonté de détecteurs de position virtuels pour ralentissements, arrêts etc

et de quoi s'amuser non ?



   

24

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: juillet 30, 2021, 09:16:02 pm »

Bonsoir Dominique,

Merci pour cette attention !
Et note bien que quand tu te lanceras, ça sera un grand plaisir pour moi si tu veux qu'on échange (d'autant que j'en tirerai profit, j'en suis certain !).

Amicalement
Philippe

NB : Ça sera également un vrai plaisir de répondre sur ce sujet à quiconque le souhaiterait. Je joins d'ailleurs à titre documentaire et pour démystifier le bout de code, commenté, qui permet d'obtenir, pour chaque train, un signal FCEM exploitable par un gestionnaire (dans une logique à 1 satellite pour 4 sections (au plus), communiquant avec un gestionnaire central)

Code: [Sélectionner]

  const uint16_t PWM_OFF = 300;                           // 300 microSeconds - temps de coupure du courant traction
  const uint16_t PWM_ON = 10000;                          // ~10 milliSeconds - période "ON", moteur alimenté
  uint32_t time_ON; 
  bool timeToEmitFCEM;

  const uint8_t NB_SECTIONS = 4;                          // ex : 4 sur ce satellite
  const uint8_t SECTION_PINOUT[NB_SECTIONS][5] = {.......};
// pour chaque section :
// - numéro de la section (sur le réseau)
// - num de la pin(satellite) de polarisation 1 du pont H qui alimente la section
// - pin de polarisation 2
// - pin analogique de lecture FCEM de la section en polarisation 1
// - pin analogique de lecture FCEM en polarisation 2
  uint8_t trainOnSection[NB_SECTIONS] = { 0, 0, 0, 0 };   // contiendra 0 pour libre ou num de train+1 (fourni par ailleurs par le master) si occupée
  bool polarization[NB_SECTIONS] = { 0, 0, 0, 0 };        // data fournie par le master en complément du numéro de train
  uint8_t trainNum[NB_SECTIONS] = { 0, 0, 0, 0 };         // numéros des trains présents sur les sections du satellite (numérotation "vraie")
  uint8_t trains;                                         // nombre de trains différents recensés à l'instant "t"
  uint16_t sumFCEM[NB_SECTIONS];
  uint16_t count[NB_SECTIONS];
  int16_t reading[NB_SECTIONS][6];                        // 6 mesures pour chaque section (si occupée)


void mesureFCEM() {
  if (timeToEmitFCEM) /*=>*/ sendFCEM();                  // LES sats ont reçu (par ailleurs) un message du MASTER enjoignant à transmettre les relevés
  if (micros() - time_ON < PWM_ON) /*=>*/ return;

  if (trains) {
    for (uint8_t i=0; i<NB_SECTIONS; i++) {               // au moins un train détecté => tous pins de polarization LOW (=> coupure du courant traction)
      digitalWriteFast(SECTION_PINOUT[i][1], LOW);
      digitalWriteFast(SECTION_PINOUT[i][2], LOW);
    }   
    delayMicroseconds(PWM_OFF);                           // attente avant mesures
    for (uint8_t i=0; i<NB_SECTIONS; i++) {
      if (trainOnSection[i]>0) {                          // TOUT OU PARTIE du train numéro "trainOnSection[i] occupe la section i
        for (uint8_t j=0; j<6; j++) {                     // 6 mesures
    reading[i][j] = analogRead(SECTION_PINOUT[i][3+polarization[i]]);
        }
      }
    }

  /* TRAITEMENT DES DONNEES */
    int16_t read[NB_SECTIONS] = {0, 0, 0, 0}, maxRead[NB_SECTIONS] = {0, 0, 0, 0}, minRead[NB_SECTIONS] = {0, 0, 0, 0};
 
    for (uint8_t i=0; i<NB_SECTIONS; i++) {
      if (trainOnSection[i]) {                            // il y a un train dans la section i => au moins une section est occupée
        if (polarization[i]) /*=>*/ digitalWriteFast(SECTION_PINOUT[i][1], HIGH);
        else /*=>*/ digitalWriteFast(SECTION_PINOUT[i][2], HIGH);  // rétablissement de la polarization initiale
        maxRead[i] = reading[i][0];                       // première mesure
        minRead[i] = reading[i][0];
        read[i] = reading[i][0];
        for (uint8_t j=1; j<6; j++) {                     // on lit les 5 autres mesures et on repère les deux extrêmes
          maxRead[i] = max(reading[i][j], maxRead[i]);
          minRead[i] = min(reading[i][j], minRead[i]);
          read[i] = (read[i] + reading[i][j]);            // sommation des SIX lectures
        }
        read[i] = (read[i] - maxRead[i] - minRead[i])/4;  // moyenne des 4 valeurs retenues après élimination des extrêmes
        maxRead[i] = 0;
      }
    }
    // si train sur 2 sections (ou plus), on filtre les résultats "fake" (wagons) en comparant les mesures de ce train
    for (uint8_t j=0; j<trains; j++) {  // à ce stade, "trains" est forcément au moins égal à 1, le numéro du premier train nomenclaturé étant inscrit dans trainNum[0]
      for (uint8_t i=0; i<NB_SECTIONS; i++) {    // on recherche ce train sur toutes les sections et on repère son read max
        if (trainOnSection[i] == trainNum[j]) {  // un train a été nomenclaturé à l'indice j (toujours vrai une fois au moins)
          maxRead[j] = max(read[i], maxRead[j]); // max-des-max pour le train j de numéro trainNum[j]
        }
      }
      for (uint8_t i=0; i<NB_SECTIONS; i++) {    // on compare les résultats section par section, on garde ou non
        if (trainOnSection[i]==trainNum[j] && read[i]> maxRead[j]/2) { // écart "normal" => on prend en compte la mesure (maxRead répond à la condition)
          sumFCEM[j] = sumFCEM[j] + read[i];
          count[j]++;     // sumFCEM == première ou nouvelle sommation pour ce train, puis comptage des sommations
        }
      }
    }
  }
  time_ON = micros();
}

void sendFCEM() {
  timeToEmitFCEM=false;
  for (uint8_t j=0; j<trains; j++) {
    if (count[j]) {
      const uint16_t TRAIN = trainNum[j]-1;
      messageCAN_FCEM.id = 72 + TRAIN;       // EXEMPLE : (64 pour satellite"0", 72 pour sat"1" etc) + n° du train converti en valeur "code"
                                             // /!\ une loco en chevauchement sur 2 sections gérées par 2 sats # pourrait générer 2 messages identiques et simultanés, provoquant
                                             // UN PLANTAGE DU BUS. L'ajout du n° de sat dans l'ID permet,de discriminer les messages (+ autres usages) */
      uint16_t fcem = sumFCEM[j]/count[j];
      if (fcem < FCEMtrain[TRAIN]/2) /*=>*/ fcem = FCEMtrain[TRAIN]/2; // "passe-bas", bride les points aberrants
      messageCAN_FCEM.data16[0] = fcem;      // on ne transmet pas la section, c'est une donnée connue du master
      const bool OK = ACAN::can0.tryToSend(messageCAN_FCEM);
      FCEMtrain[TRAIN] = fcem;
    }
    sumFCEM[j] = 0; count[j] = 0; trainNum[j] = 0;
  }
  scanSections();  // AVANT LES PROCHAINES MESURES, ON REFAIT LA NOMENCLATURE DES TRAINS
}

void scanSections() { // inventaire et classement dans trainNum[] des trains présents sur les sections traitées par le sat
  bool flag = 1; 
  trains = 0;
  for (uint8_t i=0; i<NB_SECTIONS; i++) {
    trainNum[i] = 0;
    if (trainOnSection[i]) {
      for (uint8_t j=0; j<=trains; j++) { 
        if (trainOnSection[i] == trainNum[j]) {
          flag = 0;
          break;
        }
      }
      if (flag) {
        trainNum[trains] = trainOnSection[i];
        trains++;
      }
      flag = 1;     
    }
  }
}


25

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: juillet 29, 2021, 10:02:14 pm »

Suite 3 ET FIN
- avec ABANDON de la piste asservissement
car ça marche... fort mal ou sinon dans des conditions extrêmement étroites (mais si c'est faux, je suis vivement intéressé par une démonstration).
Le signal de la mesure FCEM se contredisant régulièrement d'une mesure à l'autre, impossible d'en déduire la moindre action Proportionnelle. Et si l'Intégrale permet d'isoler une tendance, une action intégrale trop majoritaire, ça pompe, c'est obligé.

- MAIS...
idée : substituer à l'action proportionnelle une PWM "classique" : un cran donné de réglage => un équivalent tension => une vitesse... plus OU MOINS assurée compte tenu des nombreux facteurs quasiment tous d'accord pour ralentir (si ça n'est bloquer) la loco.
Plein d'excellentes occasions pour l'intégrale de faire son retour !
Et ça s'appelle de la COMPENSATION DE CHARGE ; dès que quoique se soit ralentit la loco, la FCEM diminuant, l'intégrale se réveille et... compense. (L'intégrale pourrait aussi faire du moins... il faut juste que ça soit à bon escient sinon on retrouve le souci du pompage)

J'aurais tout de suite compris toute la substantifique signification de "compensation de charge"... que j'aurais gagné bien du temps !
Car ça, ça marche ! Et sans aucun besoin d'électronique (problème réglé !) et ça donne enfin un fonctionnement en analogique propre, fluide, régulier, reproductible. Réaliste !
(j'admire au passage le fait que le DCC puisse intégrer, "in situ" qui plus est, une fonction tout de même complexe mais tellement indispensable).

Et pour ce qui est de la marche à basse vitesse... match nul non ? Analogique (avec compensation de charge donc !) et DCC se rejoignent forcément sur les mêmes réalités : selon la loco on obtient effectivement du 5kmh régulier, pour d'autres ça sera jamais moins que 25kmh (et ceci bien sûr à condition que les roues soient astiquées, les rails décapés, les contacts nickels...).
Dernière remarque ; sous réserve que j'ai à peu près compris ce qu'est un réseau en DCC : la loco se charge de tout ! Alors que dans l'analogique ça sera loin d'être aussi simple ; le problème à résoudre sera celui du sectionnement électrique qui impose de compiler et traiter plusieurs relevés de FCEM pour un même train, tant en traction qu'en refoulement (même dans le cas d'une loco solo !).
Mais ça se fait et c'est typiquement le plaisir collatéral de l'analogique, faire tourner un code !

Peut-être à bientôt pour de nouvelles aventures ?
En tous cas bien cordialement

Philippe

26

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: juin 15, 2021, 09:19:38 pm »

Merci à Laurent pour son indication.

En effet ça vole haut. Et c'est surtout très intéressant.

J'ai regardé le code "DSDCCDec_motor_BEMF_04a" et c'est confirmé, j'avais à priori pensé que c'était totalement impossible mais les décodeurs DCC font exactement le travail que propose Jean-Luc en analogique! Seule petite différence, l'algorithme fait en effet plutôt dans la "force brute", plus (+) de mesures, aucun filtrage.

Le gros avantage de l'analogique restant qu'on a pas la contrainte terrifiante de devoir tout faire tenir sur un timbre poste !
Bon d'accord... il ne reste aucun avantage si on a pas comme Laurent le challenge de faire ses propres décodeurs ( !) 

Pour ce qui est de la question de msport  "la branche positive envoie l'AO en saturation dès qu'une tension positive est appliquée. Est-ce le but ? "... Jean-Luc pourrait (pourra ?) sûrement le dire...

27

Infos et bonnes affaires / Re : ESP32 "bonne affaire"

« le: juin 15, 2021, 09:04:55 pm »

Bonsoir,
Merci pour la modif !

RE-RE-EDITION :
J'ai testé PlatformIO. Chez moi pas possible d'installer le dernier release. Mais au moins la 1.10.0 s'installe (en insistant !)

Que ce soit sous PIO ou l'IDE Arduino, l'OTA fonctionne à merveille (à condition de ne pas s'aviser entre temps de désinstaller Python... malheureux !)
La différence avec ce que rapporte BobyAndCo est peut-être que je n'ai pas (encore) tenté de mettre un mot de passe "projet".

Penser éventuellement qu'il faut avoir autorisé les adresses MAC des ESP32 (car ils en ont, chacun la leur !) si dans sa box on est en filtrage (et il vaut mieux)

 

28

Infos et bonnes affaires / Re : Re : ESP32 "bonne affaire"

« le: juin 14, 2021, 11:27:25 am »

A voir : le cloud Arduino pour ESP32 qui propose un televersement en OTA.
Je n’ai pas encore essayé...

Bonjour,
téléverser sans fil, le rêve ! Surtout si l'on imagine un hard avec une dizaine de cartes... le boulot évité chaque fois qu'on veut mettre à jour !
J'ai regardé le cloud Arduino mais je crois qu'il vaut mieux oublier : il faut un abonnement, même s'il y a une option "free" mais limités à 200secondes de compilation par jour...

Mais pourquoi passer par le cloud ? Le WI-FI direct... idéal mais je viens de lire des informations contradictoires sur la faisabilité pour un ESP.
Par contre le WI-FI de la maison c'est apparemment sans problème  :
https://projetsdiy.fr/arduinoota-ota-mise-jour-sans-fil-ide-arduino-programmes-esp8266/

J'ai hâte d'essayer mais attention à la dispersion...

EDITION : Je n'y ai pas résisté.
Voici la procédure, simplissime !
https://projetsdiy.fr/arduinoota-esp32-mise-jour-sans-fil-wifi-ota-ide-arduino/

Le gerber de Boby&Co pour ESP 38 pins va sauver mes cartes (deux) (que j'aurais bien sûr proposées ! ça ne se jette pas !!)
Première chose à faire, une petite modif pour intégrer le condo (à moinsse qu'une version V6 soit déjà prévue dans ce sens ??) car la soudure directe sur la carte... pour le coup elles seraient certainement bonnes à jeter (et c'est trop moche)
(essais en vue pour choisir le condo car le gap entre 0.1µF et 1000µF est monstrueux...!)

29

Infos et bonnes affaires / Re : ESP32 "bonne affaire"

« le: juin 13, 2021, 10:10:09 pm »

Bonsoir,

ESP32 bonne affaire ? Oui finalement car pour un prix incroyablement ridicule on a une puissance de feu et des possibilités étonnantes ! Je pense en faire des cartes "satellites type V2" et elles y seront infiniment sous-employées.
Mais mais mais... j'ai bien  failli jeter l'éponge car ces petites bêtes sont capricieuses et je n'ai pas encore compris ce qu'on doit leur dire pour, par exemple, qu'elles acceptent un download plus de 5 fois sur 100 sans avoir besoin de forcer le boot via le minuscule bouton.
Ça et la note en début du code que je joins...
Peut-être le souci n'est-il pas l'ESP32 mais que le couple avec l'IDE Arduino est mal assorti ? Trimarco parle quelque part de PlatformeIO... à voir.

Le pire a été le bus CAN et quand rien ne marche et que les causes sont multiples... mais enfin ça fonctionne.

Les cartes de la photo postés par Boby&Co vont donc beaucoup m'intéresser... sauf que j'ai maintenant des ESP 38pins, faut d'avoir détecté que les 6pins "flash" ne serviraient à rien !
Alors question à Boby&Co : n'ayant encore jamais édité de fichier Gerber, pour ne pas essuyer de plâtres je serais bien content de profiter du vôtre que je pourrais assez facilement transformer il me semble... mais il n'est pas en PJ comme annoncé ?
Ou, si vous en avez un gros stock, vous demander de me fournir mais dans ce cas je devrais "jeter" mes 38 pins et en commander des 30pins... je n'ai aucune idée de la meilleure solution d'un point de vue économique (à terme je pense que j'en consommerai une dizaine).
En tous cas, cette carte avec le transceiver intégré est parfaite ! (et plus de problème avec l'empattement !)
(Mais pourquoi un convertisseur 5V ? la carte est prévue pour alimenter autre chose ? Et, si je dois approvisionner, quel est ce composant vertical entre le transceiver et le convertisseur ??)

Et à propos encore de cette photo : merci car c'est elle je crois qui m'a donné la solution au problème du bus CAN avec ses deux pins sorties sur RX2 et TX2. Car en brochant sur RX0 et TX0 (deux jours d'obstination !) RIEN ne fonctionne et, même, plus aucun download possible !! (?) (à remarquer que la datasheet espressif est fort sommaire... peut-être pas assez bien cherché ?)

Mais ça marche. Faire obéir la librairie ACAN_ESP32 n'a cependant pas été facile ; on reconnaît en effet le "moule" mais les syntaxes sont sensiblement différentes or tous les exemples fournis sont en loopbak...

Pour éviter peut-être à quelqu'un d'autre de patauger comme je l'ai fait, voici un code sommaire qui tourne. Notez l'avertissement en préambule... vaut mieux le savoir !

Code: [Sélectionner]

/* AVERTISSEMENT (AIMABLE)
 *  Ce code conduira probablement à un message "ERREUR DE COMPILATION", sauf à y effectuer pour commencer n'importe quelle modif inutile, un espace ici par exemple
 *  (va comprendre! vrai en tous cas avec "ESP32 Dev Module" + l'IDE Arduino)
 */

#include <ACAN_ESP32.h>

uint32_t lastTime;
const uint16_t TIMER(1000); 

uint8_t message = 1;
static const uint32_t FREQUENCE_DU_BUS_CAN = 125ul * 1000ul;

CANMessage messageToCAN;      /* MESSAGES EN EMISSION */
CANMessage messageFromCAN ;   /* MESSAGES EN RECEPTION */
/* *************************************************************************** */
void setup() {
  Serial.begin(115200);
  delay(200);
  /* parametres CAN */
  ACAN_ESP32_Settings settings(FREQUENCE_DU_BUS_CAN);
  settings.mRxPin = GPIO_NUM_16 ; // TX2
  settings.mTxPin = GPIO_NUM_17 ; // RX2
//  settings.mDriverReceiveBufferSize = 4;
//  settings.mDriverTransmitBufferSize = 6;
  /* demarre CAN */
  const uint32_t errorCode = ACAN_ESP32::can.begin(settings) ;
  ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::acceptAll () ;
  if (errorCode == 0) /* =>*/ { Serial.println("Configuration OK"); }
  else /* =>*/ { Serial.print("Error Can: 0x"); Serial.println(errorCode, HEX); }

  /* identifiant (standard) des messages émis */
  messageToCAN.id = 0b10000;
  messageToCAN.len = 1 ; 
}

/* *************************** messages CAN réception ************************ */
void fromCAN(const CANMessage & inMessage) {
  Serial.print("Reception message : ");
  Serial.println(inMessage.data[0]);
}

/* **************************** messages CAN émission ************************ */
void toCAN(const uint8_t MESSAGE) {
  messageToCAN.data[0] =MESSAGE;
  const bool OK = ACAN_ESP32::can.tryToSend(messageToCAN);
  if (OK) { Serial.print(F("Emission message : ")); Serial.println(MESSAGE); }
}

/* *************************************************************************** */
void loop() {
  if (ACAN_ESP32::can.receive(messageFromCAN)) /*=>*/ fromCAN(messageFromCAN);

  if ((millis() - lastTime) < TIMER) /*=>*/ return;  // TIMER ne vise pas à soulager le BUS mais seulement à simuler des événements déclencheurs

  toCAN(message);
  message++;
  lastTime = millis();
}

(merci pour toutes les pistes  à propos des breadboards king size)
Cordialement

30

Infos et bonnes affaires / Re : ESP32 "bonne affaire"

« le: juin 04, 2021, 10:51:44 pm »

Bonsoir,
Merci msport pour ces éclaircissements (nécessaires !)

D'après la photo sur Aliexpress, il semble que l’empattement des shields soit bien 25.4 mm

Eh non, la différence est tellement faible que c'est trompeur, c'est du 22,86 mm que j'ai reçu.


"laBox"? Je m'étais appuyé sur la photo de la réponse 467 ! Sans faire attention à la largeur et en retournant regarder il me semble que c'est une carte de 25mm.

Ce qui est d'ailleurs fort embêtant sur les breadboard Arduino classiques car elles limitent le câblage à un seul côté avec une ESP de 25mm !!



Mais après avoir regardé la photo "467" de plus près, je découvre qu'il existe des breadboards "spéciales" avec 2x6 rangées de brochages !
https://forum.locoduino.org/index.php?topic=922.467

Dommage qu'aujourd'hui elles semblent introuvables...