Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Sujets - bobyAndCo

Pages: [1] 2
2
Aide / DÉPLACÉ: Carte ESP32 universelle + CAN
« le: février 26, 2024, 04:31:01 am »

3
Bonjour à tous,

J'avais rapidement testé les détecteurs par consommation de courant que nous avions réalisé à Locoduino à base de diodes et opto. Il m'a semblé que ceux ci-étaient incompatibles avec notre détection Railcom. Donc j'ai aussitôt abandonné pour aller vers des solution à effet Hall.

Je n'ai pas de certitude sur ce que j'avance et je n'ai malheureusement pas le temps de faire des tests. Cependant, si certains parmi vous ont besoin de cette réponse, CATPLUS est certainement en mesure de faire le test, il a tout sous la main.

Christophe

4
Bonjour à tous,

En répondre au challenge proposé sur le topic : Projet partagé d'un gestionnaire de réseau https://forum.locoduino.org/index.php?topic=1645.0
je propose pour ma part une solution que j’ai nommée satellites autonomes.

L’ambition des satellites autonomes est d’offrir une solution de gestion de réseau simple et rapide à déployer et ne nécessitant par la suite aucune intervention particulière durant l’exploitation. Priorité est donnée au plaisir du jeu en libérant le modéliste d’opérations fastidieuse ou encore de programmation.


Principes généraux :

Les satellites autonomes sont à la base des satellites Locoduino tels qu’ils ont été présentés en 2018. Ce sont des cartes qui reçoivent des commandes en entrée : commandes de mouvement d’aiguille ou de signalisation lumineuse par exemple, et qui envoient en sortie, des informations d’état concernant les équipements de réseaux sous sa responsabilité : Etat d’occupation, état des capteurs en entrée ou en sortie de canton…

Ces satellites auxquels nous avons donné la dénomination v1 sont ainsi des alliés précieux pour un gestionnaire de réseaux puisqu’ils lui apportent les informations nécessaires à la prise de décisions et en retour, exécutent les commandes demandées par ce gestionnaire.

Mais les gestionnaires de réseaux existants sont assez compliqués à programmer et cela rebute nombre d’entre nous à commencer par moi. Je parle de JMRI ou Rocrail pour les logiciels gratuits ou encore Train Controller mais il y en a beaucoup d’autres. Ce sont par ailleurs des solutions qui nécessite pour la plupart un ordinateur dédié (ou un Raspberry).

Mon travail a donc consisté à demander à chaque satellite de réaliser en plus, pour le canton qui est sous sa responsabilité, les fonctions de gestion de réseau : Sécurité et régulation des trains, commandes de ralentissement et/ou d’arrêt des locomotives, gestion de la signalisation lumineuse. J’ai donc introduit comme disent certains, une forme d’intelligence dans le système.

D’où aussi le nom de satellites autonome dans la mesure où il n’y a pas de gestionnaire centralisé.

Les objectifs :

Les objectifs que je me suis fixés avec les satellites autonomes étaient :

1° - Que la phase de description du réseau, des équipements, du nommage de zones ou des cantons, le choix des cibles de signalisation soient simplifiés autant qu’il serait possible. Et je pense que sur ce point l’objectif est largement atteint, voir dépassé comme vous pourrez en juger par la suite.

2° - Que pendant l’exploitation, le modéliste soit totalement libéré des contraintes de sécurité en particulier pour pouvoir pleinement profiter du plaisir du jeu.

3° - Que le modéliste n’ait rien à écrire ou modifier dans le code des programmes. Que les programmes à télécharger sur chaque carte soient tous rigoureusement identiques. De fait, hormis le nom du réseau Wifi et son mot de passe à renseigner une fois, il n’y a rien d’autre à faire.

4° - Offrir une interface simple et intuitive pour les quelques opérations de réglage comme par exemple pour les butées des servo-moteurs d’aiguilles.

5° - Mettre en œuvre les solutions techniques privilégiés par Locoduino comme le protocole DCC (que l’on retrouve aujourd’hui dans LaBox) ou l’adoption d’un bus de communication CAN.

6° - Simplifier autant que cela serait possible le câblage du réseau, nombre et longueur des câbles en particulier. Cela est en partie grandement réalisé par les liaisons en RJ45 qui véhiculent le bus CAN et l'alimentation électrique.

Dans la version actuelle, les possibilités offertes sont particulièrement bien adaptées pour une mise en œuvre simple sur des petits et moyens réseaux, des dioramas, des va-et-vient sur lesquels je dirais, il n’y a qu’à poser les satellites à proximité des cantons, souder quelques fils, procéder à la reconnaissance mutuelle, régler le cas échéant les valeurs de servos moteurs d’aiguilles et c’est tout. Il est possible d’utiliser son réseau avec trois satellites pour en tester le comportement et d’ajouter un quatrième, puis un cinquième puis tous les autres. Rien de ce qui a déjà été fait n’est remis en cause.
Les satellites autonomes permettent donc de couvrir les besoins de la grande majorité des modélistes Je suis bien conscient et j’assume le fait que cela ne répondra pas par exemple aux besoins d’une vaste gare cachée avec de nombreuses aiguilles ni encore à ceux d’un grand réseau complexe.

Point important à noter : Pour rester cohérent avec mon objectif de simplification, j’ai retenu la technologie Railcom pour la détection et l’identification des locomotives. Cela nécessite donc que toutes les locomotives disposent de cette technologie. La reconnaissance par RFID est aussi incluse (mais optionnelle) mais elle ne peut pas se substituer à Railcom.

Voilà donc posés les principes généraux et la philosophie de ces satellites autonomes. Je vous présenterai par la suite les différents matériels, la mise en œuvre concrète et bien sûr, pour ceux que cela intéresse le code des programmes.

En attendant, voici ce à quoi ressemble un satellite autonome :


Je répondrai volontiers à toutes les questions que vous voudrez me poser, mais n'anticipez pas trop sur ce que je dois vous présenter par la suite.

Christophe

5
Bonjour à tous.

J’avais déjà parlé dans divers fils du forum du travail réalisé en commun avec Marcel (Catplus) pour réaliser une solution complète de détection Railcom.

Un article du site éditorial présente en détail cette réalisation : https://www.locoduino.org/spip.php?article334
mais il ne peut malheureusement pas aborder tous les points et/ou les aborder avec tout le niveau de précision que certains auraient pu souhaiter.

L’objectif de ce fil créé en parallèle de l’article est justement de permettre à chacun de s’exprimer, de proposer, de poser des questions.

Ainsi, nous l’espérons, nous pourrons faire évoluer encore les choses et probablement apporter des compléments à la publication de base.

N’hésitez surtout pas à vous mettre au clavier !

Christophe

6
Bus DCC / EX-DCCInspector
« le: septembre 28, 2023, 11:25:42 am »
Bonjour à tous,

Catplus et moi travaillons sur un projet qui nécessite de « sniffer » les trames DCC envoyées sur un réseau. En précisant que nous souhaitons utiliser l’ESP32 comme plateforme.

EX-DCCInspector semble faire l’unanimité pour le job. Il en est plusieurs fois question sur le forum mais rien pour en parler de manière un peu exhaustive. C’est l’ambition de ce fil.

Tout d’abord, la page traitant de EX-DCCInspector se trouve ici : https://dcc-ex.com/ex-dccinspector/index.html#gsc.tab=0

Il y a deux manières de se procurer le fichier, soit en téléchargeant un fichier .zip, soit sur le GitHub.

J’ai rencontré plusieurs problèmes :

1° - Le scketch ne compile pas avec une version de l’IDE Arduino inférieure à 2.0
2° - J’essaye alors avec PlatformIO et je rencontre aussi un problème à la compilation.

Avec l’IDE Arduino, la solution a été d’installer la dernière version, pour moi la 2.2.2 (au 28 sept 2023)

Avec PlatformIO, les fonctions doivent être déclarées avant leur première utilisation. Or plusieurs fonctions utilisées dans le loop() sont définie après dans le code.

J’ai donc ajouté le prototype des fonctions juste avant le setup() et ça fonctionne.

void clearHashList();
bool processCommands();
void UpdateLED();
void DecodePacket(Print &, int, bool);
bool processDCC(Print &);

void setup() {

Pour utilisation avec un ESP32, il vous faut renseigner le réseau WiFi utilisé ainsi que son mot de passe dans le fichier Config.h

#define WIFI_SSID "myssid"
#define WIFI_PASSWORD "mypassword"

Nous commentons la ligne //#define USE_OLED car nos n(utiliserons pas d’écran OLED.

En contrepartie, l’ESP32 autorise l’affichage des données dans un navigateur web à l’adresse http://DccInspector.local/



Voilà quelques précisions pour pouvoir utiliser EX-DCCInspector sur un ESP32 avec visualisation des données dans une page web.

7
J'utilise assez souvent chatGPT pour avoir un retour sur du code que j'ai pu écrire et je dois avouer que souvent, je trouve des suggestions intéressantes. Mais alors ce matin, je lui ai soumis un vieux code (2012) qui n'incorporait pas des évolutions intéressantes de C++ 11 comme les listes d'initialisation par exemple. Voici le texte de nos échanges (sans le code que je pourrais poster si cela vous semble intéressant). C'est assez éloquent :

Moi
Bonjour Chat

ChatGPT
Bonjour! Comment puis-je vous aider aujourd'hui?

User
Dis moi comment tu écrirais ceci en C++ moderne ?

ChatGPT
Voici le code en C++ moderne pour la classe TrackController que vous avez fournie :

Ce code utilise les fonctionnalités du langage C++ moderne, telles que l'initialisation de membres dans la liste d'initialisation du constructeur (mHash(hash), mDebug(debug), etc.), ainsi que l'inclusion de la bibliothèque Arduino (<Arduino.h>) pour utiliser Serial.println(F(...)) avec la macro F() pour économiser de la mémoire.

User
Je suis d'accord avec toi qu'il faut utiliser des listes d'initialisation mais tu ne le fais pas !

ChatGPT
Je m'excuse pour l'omission dans ma réponse précédente. Vous avez raison, il est préférable d'utiliser des listes d'initialisation pour initialiser les membres de la classe. Voici le code mis à jour en utilisant des listes d'initialisation :

Dans ce code mis à jour, les membres mHash, mDebug, mLoopback et mGbxBoot sont initialisés dans les listes d'initialisation des constructeurs correspondants, plutôt que d'être assignés dans le corps du constructeur init(). Cela améliore l'efficacité et la lisibilité du code.

User
tu dois être fatigué aujourd'hui car la fonction init n'est plus nécessaire :  void init(word hash, boolean debug, boolean loopback, boolean gbxBoot) {
        mHash = hash;
        mDebug = debug;
        mLoopback = loopback;
        mGbxBoot = gbxBoot;
    }

ChatGPT
Je m'excuse pour la confusion précédente. Vous avez tout à fait raison, la fonction init() n'est plus nécessaire puisque nous pouvons initialiser directement les membres dans les listes d'initialisation des constructeurs. Voici le code mis à jour sans la fonction init() :

Je m'excuse à nouveau pour l'erreur précédente et je vous remercie de votre patience. Le code ci-dessus initialise maintenant directement les membres dans les listes d'initialisation des constructeurs, sans avoir besoin de la fonction init().

User
Je me demande si je peux te faire confiance

ChatGPT
Je comprends que mes erreurs précédentes ont semé le doute. En tant qu'IA, je m'efforce de fournir des réponses précises et fiables, mais il peut arriver que des erreurs se produisent. Je suis constamment en apprentissage et j'essaie d'améliorer mes performances.

Je vous recommande de toujours vérifier les réponses que je vous donne et d'utiliser votre propre jugement et connaissance pour prendre des décisions. N'hésitez pas à poser des questions de suivi ou à demander des éclaircissements si quelque chose ne semble pas correct.

Mon objectif est de vous aider du mieux possible, et je ferai de mon mieux pour répondre à vos demandes.

8
Bus CAN / Pénurie de MCP2562
« le: août 01, 2022, 07:56:09 am »
Bonjour à tous,

Comme il est écrit dans le titre du sujet, il y a depuis quelques semaines une pénurie sur les approvisionnements des petits MCP2562, transceiver bien pratiques et économiques sur nos montages à base d'ESP32 entre autres.

Quelqu'un a t'il une proposition d'approvisionnement (fiable et économique) ou une solution de remplacement ? Plus particulièrement en montage traversant.

Merci par avance

9
Discussions ouvertes / Economies d'énergie !
« le: mars 12, 2022, 10:12:57 am »
La SNCF ne manque pas d'humour ! Du coup, je me suis adapté et j'ai réduit l'intensité sur mon réseau de 12 à 9 volts  :) Et les vaches vont à nouveau pouvoir contempler les trains.


10
Bus DCC / Une station DCC compatible RailCom
« le: janvier 09, 2022, 02:58:44 pm »
Bonjour à tous,

Ce nouveau fil pour la réalisation d’une centrale DCC compatible RailCom (oui je sais c’est déjà dans le titre).

Pour beaucoup de modélistes ferroviaires et en particulier à Locoduino, la découverte de DCC++ a été une véritable révélation. Que son concepteur Gregg E. Berman en soit une fois une nouvelle fois ici remercié.

Mais au fil des ans, DCC++ a montré ses limites. A Locoduino, Thierry en particulier, nous avons beaucoup travaillé à y apporter des améliorations. Ainsi est né par exemple DCCpp écrit sur la base de classes C++ rendant la programmation de base universelle et donc les utilisations potentielles plus larges et simplifiées.

Le projet La Box sur base d’ESP32 est aussi l’une de ces évolutions.

Récemment, à l’occasion de la sortie de la seconde édition du livre de Pascal Barlier, nous avons découvert une nouvelle centrale (non plus sur base de DCC++) mais qui m’a tout de suite intéressée car elle promet de permettre la détection RailCom (qui est aussi absente dans DCC++).

La licence GNU autorisant la modification et la publication du code modifié, j’ai souhaité « élargir » les utilisations de cette nouvelle centrale pour pouvoir la rendre compatible avec les multiples applications open source que nous avons développées ou adoptées autour de DCC++ comme JMRI par exemple.

L’objectif étant de pouvoir bénéficier à terme de la détection RailCom sans avoir à remettre en cause ces différentes configurations existantes.

Je mets en téléchargement un programme de test mais opérationnel qui permet de réaliser une station sur Arduino avec un LMD18200 (dans cet exemple) et qui peut (pour l’instant) être pilotée par le port série par JMRI par exemple mais aussi par toute application capable d’envoyer de informations par le port série.

Toujours pour des raisons de compatibilité, j’ai adopté le protocole de communication de DCC++ tellement connu du type <t 1 12 100 1>. Reportez-vous à l'entête du fichier principal plus d'informations.

L’ambition à ce stade du projet que je soumets n’est autre que de tester le retour d’information RailCom au travers des détecteurs également conçus par Pascal Barlier. Les PCB sont en fabrication et quelques uns d’entre nous se sont déjà proposés pour les tester.

L’autre espoir que j’ai est que la lecture et l’écriture des CVs soient améliorées par rapport à DCC++. Mais ce sera pour plus tard.

Si donc vous utilisez DCC++ et que vous souhaitez en plus pouvoir profiter de la détection RailCom, ce fil devrait vous intéresser et nous comptons sur vous pour nous aider à améliorer le projet.

Bien cordialement

Christophe

11
Trucs & astuces / La fonction printf() en Arduino
« le: décembre 31, 2021, 06:31:51 pm »
Bonjour à tous,

Pour bien terminer l’année, je vous propose la petite astuce suivante : Tous ceux qui connaissent la fonction printf() en langage C sont sans doute frustrés comme je l’étais qu’elle ne soit pas disponible dans le langage Arduino.

Je précise rapidement que la fonction printf() correspond à la fonction Serial.print() de l’Arduino mais offre l’avantage de pouvoir inclure en même temps que du texte, des variables dans les paramètres.

Voici un exemple simple : si vous souhaitez écrire un texte plus la valeur de i dans la boucle ci-dessous, vous devrez appeler deux fois la fonction Serial.print() (ou Serial.println() pour avoir un retour à la ligne).

for(byte i = 0; i < 10; i++) {
  Serial.print("La valeur de i est ");
  Serial.print(i);
}

Avec la fonction printf, le code devient :

for(byte i = 0; i < 10; i++) {
  printf("La valeur de %d est ", i);
}

C’est plus compact et avec l’habitude, plus facile à écrire d’autant que l’on peut placer plusieurs variables sur une seule ligne comme nous le verrons dans l’exemple suivant.

J’ai repris pour l'essentiel un code que j’ai trouvé sur internet mais que j’ai placé dans un fichier distinct pour qu’il ne vienne pas « polluer » le code du fichier principal (.ino)

Il suffit donc d’ajouter un nouvel onglet dans l’IDE Arduino, d’appeler ce fichier « Printf.h » et de copier le code suivant :


#ifndef printf_h
#define printf_h

// Define a file descriptor for the serial output:
static FILE uartout = { 0 };

// Declare our put-character function:
static int uart_putchar (char c, FILE *stream);

// My char output function
static int uart_putchar (char c, FILE *stream) {
  if ( c == '\n' )
    Serial.write('\r');
  Serial.write(c) ;
  return 0 ;
}

struct Printf {
  static void begin(long);
};

void Printf::begin(long baud) {
   // Fill in UART file descriptor with pointer to my char-out func.
  fdev_setup_stream(&uartout, uart_putchar, NULL, _FDEV_SETUP_WRITE);
  stdout = &uartout;
  Serial.begin(baud);
}

#endif

Dans le fichier principal (.ino), il faut tout d’abord ajouter le lien #include "Printf.h" et dans le setup() placer Printf::begin(xxxxxx); au lieu du traditionnel Serial.begin(xxxxxx) ;

Enfin, je vous donne un exemple complet. Pour l’utilisation optimale de cette fonction printf(), je vous renvoie au nombreux tutos d’internet comme celui-ci : https://www.gladir.com/CODER/C/printf.htm

#include "Printf.h"

void setup() {

  Printf::begin(115200);
  printf("Hello world\n");
}

void loop( void ) {
  long compt = 0;
  for (byte i = 'A'; i <= 'z'; i++) {
    compt++;
    printf("Le code ASCII de %c est %d et le nombre de caractères lus est %ld\n", i, i, compt);
    delay(1000);
  }
}




12
Bonjour à tous.

J’ai ouvert ce nouveau fil pour, je l’espère, que de nombreux contributeurs puissent apporter leur point de vue et leur expérience sur un sujet important pour notre hobby à savoir la continuité de l’alimentation en courant des locomotives.

Quoi de plus désagréable que le convoi qui s’arrête au passage d’une aiguille ou le petit locotracteur qui peine à avancer correctement parce que sa prise de courant est insatisfaisante.

Je sais que de nombreuses « écoles » défendent des points de vue souvent très différents et c’est justement pour cela que l’exercice est intéressant et instructif si chacun peut présenter ses choix tout en acceptant ceux des autres pour arriver à un résultat constructif.

L’objectif visé au final est qu’un modéliste néophyte puisse avoir une vision globale et éclairée du sujet et puisse ensuite appliquer ses propres solutions en fonction de sa sensibilité, ses compétences et son budget.

Alors on entend beaucoup que, si les rails sont propres, si les roues des locomotives sont nettoyées, si les cœurs d’aiguilles sont alimentés, si chaque tronçon est lui aussi alimenté… alors tout se passe bien.

Personnellement, je pense qu’il y a là de nombreuses vérités, mais que de nouvelles solutions techniques se font jour qui s’ajoutent à cela avec bénéfice.

Tout ceux qui ont pu voir par exemple le Moyse DCC + Power Pack de REE à l’œuvre sont restés époustouflés. Nos petits locotracteurs ont souvent des comportements très éradiques dû principalement au faible nombre de prises de courant et à la faible inertie. Le petit Moyse de REE se joue totalement des passages d’aiguilles délicats ou des tronçons mal alimentés. Il est capable de stocker environ 20 secondes de roulage avec absence totale de courant !



REE reste très discret sur la technologie qui équipe le Moyse. De ce que j’ai compris, ce sont 2 super capa de 2,7 volts qui produisent 1 Farad. Mais 5,4 volts au total cela est loin de suffire. Il y a donc une électronique pointue en sus, d’autant que les super capa ont la particularité de baisser très vite en tension quand elles se déchargent.

Sommes-nous capables cette fois encore d’apporter en DIY des solutions qui rivalisent ?

Pour ma part, j’ai essayé pas mal de choses dont je parlerai dans des posts à suivre. Je propose pour commencer ce montage, sans énormes prétentions, mais qui améliore très significativement le comportement de mon Y6400 de chez EPM.



A vous d’apporter ici vos propres expériences et contributions.

13
Bonjour à tous,

Il y a deux ans déjà, je vous parlais de l’automatisation d’un pont tournant FLEISCHMANN 6152 que j’étais en train de réaliser.

https://forum.locoduino.org/index.php?topic=371.msg8971#msg8971

Ce pont fonctionne depuis un moment, mais, confinement aidant, j’ai repris l’ouvrage pour en faire un article, simplifier et optimiser autant que faire ce peut pour que ce projet puisse être réalisé par d’autres. C’est tout de même le but des publications sur Locoduino.

J’ai une question d’électronique qui n’est pas mon domaine de prédilection. Le changement de polarité sur les rails du pont est une nécessité en fonction du sens de sortie de la locomotive. Alors que dans mon projet initial, le changement de polarité dans les rails était assuré par un relais à l’extérieur, je voudrais ici réaliser ce changement de polarité avec des mosfet (BS170) placés sur le PCB qui lui-même est sous le pont.

La commutation serait assurée par deux broches d’un micro contrôleur. Alors qu’une broche est à HIGH, l’autre est à LOW et vis et versa.

Le montage ci-dessous est-il correct ? Faut-il que je prévoie des diodes roues libres ?



Merci par avance pour vos contributions.

PS : J'ai ouvert un nouveau fil où pourront être déposées toutes les discussions sur ce sujet quand l'article sera publié (ou avant pour ceux qui le souhaitent)

Christophe


14
Bus DCC / Passerelle CAN/WiFi-TCP/Serial
« le: novembre 05, 2019, 03:05:08 pm »
Bonjour à tous,

Je viens de finir ma passerelle entre les réseaux CAN et TCP (WiFi) et aussi série sur base d'ESP32. L'ensemble est disponible sur le Github de Locoduino : https://github.com/Locoduino/CAN_WiFi_gateway32

Ce projet avait été initialisé pour Orléans 2018 sur la base d'ESP8266. Ici, il s'agit d'un ESP32 et d'un module CAN SN65HVD230 qui simplifient considérablement le montage et son cout puisque cette passerelle me revient à 6€ au total !

Il est donc possible de lire les trames CAN qui circulent sur un bus avec des applications reliées, soit en WiFi, soit en Ethernet ou soit encore en série. Et il est inversement possible d'envoyer des trames CAN avec ces mêmes applications.

J'avais présenté à l'époque un TCO sous forme de page Web qui, relié avec les 8 satellites du Locoduinodrome, se mettait à jour dynamiquement. J'utilise toujours ce projet qui est visible ici

J'utilise pour cette vidéo un sketch chargé sur un autre Arduino qui envoi en boucle et à raison d'un message par seconde les mêmes messages que les satellites avec les détecteurs d'occupation (consommation et ponctuels). J'ai poussé le débit des messages au rythme de 1 message toutes les 100ms et la réception TCP n'a pas bronchée.

J'avais aussi montré comment il était possible de faire les réglages des satellites à partir d'une page web :

Pour ma part, c'est un outil très important et mes futurs recherches vont aller dans le sens d'une gestion automatisée de mon réseau sur une base de données (qui existe déjà) et qui va être en interaction directe avec les périphériques CAN (satellites).

C'est aussi ce type de passerelle qui pourra être mise en œuvre par ceux qui voudraient interfacer JMRI avec le bus CAN et les satellites par exemple.

Je ne dispose que peu de temps malheureusement pour faire des présentations plus détaillées (voir cependant sur le Github), mais je peux au travers de ce fil apporter des précisions à tous ceux qui souhaiteraient mettre en œuvre une telle architecture.

Je suis intéressé également par toutes les propositions d'amélioration.

Christophe.






15
Trucs & astuces / Cohabitation 5V - 3,3V
« le: août 22, 2019, 08:49:42 am »
Bonjour à tous,

Ma question concerne la cohabitation de courants en 5 et 3,3V dans un même montage et devrait concerner de plus en plus de monde avec le développement des cartes en 3,3V.

Je viens de terminer l'automatisation de mon pont tournant avec un ESP32 (en 3,3V donc).



J'utilise comme carte moteur un Pololu 4990 qui peut s'alimenter de 2 à 5,5V pour ce qui est du courant de commande (VCC).

https://www.pololu.com/product/2137/pictures#lightbox-picture0J5015

J'ai placé sur mon montage (alimenté en 12V) deux convertisseurs, un en 5V, l'autre en 3,3V. Le 5V me sert pour 2 capteurs à effet Hall et 2 LEDs. Jusqu'ici, j'ai fait touts mes tests en alimentant la carte Pololu à la même tension que l'ESP32 (3,3V) mais il serait bien que je puisse mieux équilibrer les charges et j'ai pensé alimenter la carte Pololu en 5V.

Pour mes capteurs à effet Hall (5V) vers ESP et mes LEDs, j'ai des transistors, mais pour les quatre sorties moteur de l'ESP vers Pololu, je n'ai pas vraiment la place pour mettre des transistors.

Pensez vous que ce soit dommageable pour l'ESP si j'alimente la carte Pololu en 5V sachant que le courant est "sortant" de l'ESP vers le Pololu ? Est-ce que les broches de l'ESP sont tout de même exposées au 5V ?

Merci pour vos réponses ou autres propositions.

Bien cordialement.

Christophe



Pages: [1] 2