Auteur Sujet: Les SATELLITES AUTONOMES: évolutions du socle initial  (Lu 68931 fois)

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #45 le: février 13, 2024, 05:51:39 pm »
La partie protection / reverse n a pas pour but de traiter les cas des “frog” au niveau local ( elle le pourrait cependant mais cela imposerait selon moi un câblage dissocié  de chaque cœur, donc autant traiter leur polarisation directement en // de la commode du servo par bascule d un relais ( simple efficace et suffisant )

Elle a pour but d aligner les pôles notamment dans le cas de grills complexes d aiguillages ou un canton horaire ferait face à un antihoraire. ( cas d une boucle notamment )

On peut comme tu le soulignes la sortir du socle. Mais il faudra plus de contact in/out pour traiter les échanges avec le socle

Telle que j imagine alors les choses on pourrait avoir 3 blocs fonctionnels enfichables selon la combinaison de fonctions à produire depuis l’entrée Dcc vers la voie :

Protection / reverse
Détection occupation
Détection railcom ( identification est plus juste d ailleurs)
( puis extension distribution pour grills complexes)
Ou
Seulement les deux derniers par exemple

On aurait alors un socle “carte mère” recevant ces sous ensembles. Au prix de dimensions un peu  plus généreuses sur le socle ( type 10cm x 15 ou 16cm)

Ce surcroît offrira aussi la possibilité t intégrer plus de composants sans “extenders direct”
Si un bloc n’ est pas utilisé on le bouchonne simplement .

Je dois creuser à ce niveau, ce n est pas immédiat et cela va entraîner quelques heures de dessins aussi.

À discuter donc…

Ltr


laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #46 le: février 15, 2024, 01:09:18 am »
Bonjour

Christophe, pour la gestion d un accessoire ( ex commande de servo avec commutation du relais de polarisation de la pointe de cœur, commande d'un signal,...) est il possible  d'imaginer avoir un mécanisme de traitement type "découverte" pour appairer un satellite et un accessoire? ce qui aurait pour but dans ce cas de créer des "couples" [satellite N; accessoire X] qui seraient commandés alors par le bus CAN...

Un petit MEGATINY, un transceiver CAN, une gestion d alim locale et ce que l on veut ajouter sur chaque petite carte (satellite de satellite) ( PS non j ai rien pris! tout va bien) en somme...

Ce qui nous affranchit alors de bus d extension directement type I2C ou à base de 74HC595... et permet de nouveaux type d extensions, même déportés comme pour gérer un TCO avec boutons et leds, commande d un passage à niveau, ... et réduit à 3 bus à distribuer sous le réseau:
Le CAN, le DCC et un bus d alim des accessoires et cartes

Bon coté dimension je ne ferai pas moins que du 180mmx100mm avec les options actuelles.., peut être pas très optimal comme dimension. En FULL CAN un retour sous 100x100 devient possible...

Qu'en penses tu? On satellise les extenders via CAN?

Laurent
« Modifié: février 15, 2024, 02:30:11 am par laurentr »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #47 le: février 15, 2024, 03:07:55 am »
@Laurent
Christophe, pour la gestion d un accessoire ( ex commande de servo avec commutation du relais de polarisation de la pointe de cœur, commande d'un signal,...) est il possible  d'imaginer avoir un mécanisme de traitement type "découverte" pour appairer un satellite et un accessoire? ce qui aurait pour but dans ce cas de créer des "couples" [satellite N; accessoire X] qui seraient commandés alors par le bus CAN...

Oui le principe est envisageable et le CAN est particulièrement fléxible pour ce genre de choses mais...à la condition que je vais poser ci-dessous.

Un petit MEGATINY, un transceiver CAN, une gestion d alim locale et ce que l on veut ajouter sur chaque petite carte (satellite de satellite) ( PS non j ai rien pris! tout va bien) en somme...

Ce qui nous affranchit alors de bus d extension directement type I2C ou à base de 74HC595... et permet de nouveaux type d extensions, même déportés comme pour gérer un TCO avec boutons et leds, commande d un passage à niveau, ... et réduit à 3 bus à distribuer sous le réseau:
Le CAN, le DCC et un bus d alim des accessoires et cartes

Le problème je pense est que l'ATTiny n'a pas de bus SPI ! Alors le MEGATINY que je ne connais pas est-il dans le même cas ? C'est essentiellement un problème de hard. Sur n'importe quel µC à base d'AVR qui disposerait d'un bus SPI doit pouvoir fonctionner avec nos bibliothèques CAN bien aimées. J'ai vu qu'il devait exister des solution logicielle pour avoir du SPI sur ATTiny85.

Et pourquoi pas un ATmega328 et un quartz ? Le satellite peut fournir sans problème le 5V nécessaire.

Jean-Luc saurait certainement nous répondre et connais de toutes les façons des solutions CAN "low cost" puisque c'est de ça dont il s'agit.

PS : Il reste des broches dispo sur l'ESP puisque j'ai viré le RFID. Voir schéma fin article 2


laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #48 le: février 15, 2024, 03:14:13 am »
Les MEGATINY ont nativement le SPI et incluent leur lib SERVO donc:

ACAN compatible!
SLOW SERVOMOTION compatible!

Autant rester sur des pièces HARD qui nous offrent nativement ce dont on a besoin, économiques, dispo et flexibles ( nombreuses ref possibles)

Plus d info pour tt cela grâce à ceci:

https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/SPI

et plus généralement

MEGATINY CORE:
https://github.com/SpenceKonde/megaTinyCore/tree/master

DX CORE
https://github.com/SpenceKonde/DxCore

A user sans moderation! ( et tres pratique à l'usage!)

Ltr
« Modifié: février 15, 2024, 03:17:16 am par laurentr »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #49 le: février 15, 2024, 03:16:01 am »
Et on les achète où ces petites bêtes ? Un lien sur un site marchand ?

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #50 le: février 15, 2024, 03:32:05 am »
Pour des proto rien de mieux que d utiliser ce type de carte:

Pour MEGATINYCORE:
https://www.microchip.com/en-us/development-tool/DM080104
ex chez MOUSER:
https://www.mouser.fr/ProductDetail/Microchip-Technology/DM080104?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10MiU1bSRVZdO1ag7jWmWQuQ%3D%3D
ou
https://www.mouser.fr/ProductDetail/Microchip-Technology/EV50J96A?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10pOzHZoSU7PqXNqc0wSi7Lw%3D%3D

La différence c est la taille de la mémoire( 16k vs 32k) mais l'archi est similaire.

pour DX CORE:
https://www.microchip.com/en-us/development-tool/EV35L43A
ex chez MOUSER:
https://www.mouser.fr/ProductDetail/Microchip-Technology/EV35L43A?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10BFYc6DllOgqEScMi970BUg%3D%3D

Et dans le pire des cas un AVR NANO EVERY peut aussi convenir pour "dépanner" puis que c'est un "cousin" des MAGATINY et AVR Dx.

Au niveau dispo de puces ensuite j utilise souvent OCTOPART.com pour faire une recherche sur les volumes mondiaux dispo, voir les couts... et choisir un fournisseur ou une pre commande chez JLCPCB avant assemblage.

A noter que pour un brochage défini les volumes de mémoire peuvent influer sur les dispo des références donc... on cible ou on substitue.

Ta CB va chauffer ;)!

Ltr
« Modifié: février 15, 2024, 03:37:56 am par laurentr »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #51 le: février 15, 2024, 03:36:33 am »
Oui ça n'a rien de tiny, surtout pas le prix.

Pourquoi ne pas prendre un bon nano en clône à 1€ ?

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #52 le: février 15, 2024, 03:42:16 am »
Paracerque le NANO première génération à base de 328P me semble un peu "HASBEEN".
Sur un PCB dédié c est un peu gros mais sur un PCB socle pourquoi pas cela offre la possibilité à plus de personnes de réaliser le montage.

Que la dispo et son prix ne sont pas ou plus toujours très compétitifs en regard des nouveaux composants et de leur possibilités. Mais dans l absolu un 328P  peut le faire.

Mais je pense que tu verras à l usage que les MEGATINY et AVRDx offre des avantages certains.

Ltr
« Modifié: février 15, 2024, 03:55:26 am par laurentr »


laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #54 le: février 15, 2024, 03:58:21 am »
Oui ça n'a rien de tiny, surtout pas le prix.

Pourquoi ne pas prendre un bon nano en clône à 1€ ?

Exemple de recherche pour un MEGATINY 1606 ( ATTINY1606)

https://octopart.com/search?q=ATTINY1606&currency=EUR&specs=0

Bon, on est loin du prix du module dev proto ( /24 en gros mais juste pour le CPU)

Ltr


laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #55 le: février 15, 2024, 01:52:05 pm »
Bonjour

A la réflexion "cout" une soluce AVR( MEGATINY ou AVR Dx) + MCP2515 (ou MCP2517) +MPC2562 + alim etc fait que cela semble moins intéressant (plus onéreux et fonctionnellement moins riche) que de prendre directement un petit ESP32 a qui confier le job avec un MCP2562.

Lequel prendre? Un double cœur est il obligatoire pour gérer le CAN et afficher quelques leds ou piloter un servo et un relais? ( carte a usage unitaire: ex 1 servo avec un relais à piloter pas plus, pas de carte globale pour gérer N périphériques, ce qui entrerait alors dans de la config dynamique un peu laborieuse a mettre en œuvre simplement)

l ESP32 offrirait en plus nativement une vue web de config ( ex mapping couleur des feux sur les sorties, réglages vitesse de clignotement, réglage du servo( vitesse, pos max, pos min, vitesse du mouvement...) ... alors pourquoi s'en priver?!!

Ltr

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #56 le: février 15, 2024, 04:13:43 pm »
Bonjour Laurent,

Toi qui est à l'aise avec KiKad, je me demande dans quelle mesure il ne faut pas acheter l'ESP32 seul (env 3€) au lieu de carte de développement plus onéreuses (10€) et surtout plus encombrantes.

Du coup, ça fait une belle mécanique pour tes cartes "secondaires" tout en restant peu encombrant et économique.

Si cela était possible, ce serait super sympa bien sûr de le faire aussi pour les satellites.

Mais sinon, oui un ESP32 en carte de développement reste un super rapport qualité/performance/modularité/prix

Christophe

PS : Perso, je ne comprends pas très bien cette envie de réduire à tout prix la taille des cartes ! Elles sont souvent sous le réseau, quel est le véritable intérêt ?

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #57 le: février 15, 2024, 05:29:20 pm »
Bonjour

Pour la taille comme pour le prix il faut trouver des optimaux en gardant une simplicité de mise en œuvre ( soft, hard, connectique , fabrication (dont injection du code) , réglages, dispo,  ...)

Je trouve "surfait" de mettre un gros dev kit ESP32 pour ne gérer que une ou deux I/O mais leur prix fait pencher vers eux naturellement:

on perd en surface et connectique avec des DEV kits comme celui ci à prix discount mais tout est dessus:

https://fr.aliexpress.com/item/1005006140560853.html?spm=a2g0o.productlist.main.25.610e5515yNHlaY&algo_pvid=0fe03238-fd9a-403d-ada1-f255d7f50832&aem_p4p_detail=202402150431591441831242318720011327211&algo_exp_id=0fe03238-fd9a-403d-ada1-f255d7f50832-12&pdp_npi=4%40dis%21EUR%211.75%210.88%21%21%2113.21%216.61%21%40211b618e17080003192136452e3ad9%2112000035941612021%21sea%21FR%210%21AB&curPageLogUid=dj27IzI8coly&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202402150431591441831242318720011327211_13

A comparer avec un module similaire :
https://www.lcsc.com/product-detail/WiFi-Modules_Espressif-Systems-ESP32-WROOM-32D-N4_C473012.html

Edifiant!

Pour la taille pure dans des zones de forte densité plus c'est petit mieux c'est. ( y compris pour nos amis Nistes) ( mais ca se discute) ( ex cas d une potence avec plusieurs feux) surtout si c est uni fonctionnel ( ex 1 satellite de satellite pour 1 feu ( n sorties) , un autre pour un servo avec son relais, ...) Raison pour laquelle je pense que de mettre des modules natifs ESP32 est peut être plus avantageux (en place surtout) . Lequel prendre?

Cote prix il faut garder en tête le cout global et trouver un bon rapport prix/ facilité de mise en œuvre. (pour le plus grand nombre ou avec des consignes ad hoc)

Intégrer un module natif ESP32 ne pose pas de soucis cote layout du PCB, il faut juste bien voir ce qui doit être mis autours (alim 5 vers 3V3 + boutons + mémoire éventuelle selon le type de CPU (ex un ESP32 C3 a déjà la RAM et la Flash intégrée au CPU) - et prévoir un connecteur de programmation à défaut d'un mode OTA.

Ca fera gagner de la place mais peut être paradoxalement contribuera à un prix plus chère! ( voir trop chère!)


Pour les satellites de satellites je pense qu'un module ESP32 C3 serait pas mal puisque CAN compatible, prix moindre et suffisamment d I/O pour des usages simples. Mais un WROOM 32D basic est parfait aussi. ( c es celui utilisé déjà sur le DEV KIT C 38 broches des satellites autonomes)

CAN et EP32 C3:

https://www.seeedstudio.com/blog/2022/07/11/voice-needed-do-you-know-xiao-esp32c3-can-can/

Mais c est peut être aller trop loin que nos bons vieux DEV KIT classiques plus gros, bien connus feraient l'affaire!?

Besoin de réfléchir collectivement sur les "bons choix"!

Pour moi in fine dessiner avec un composant ou un autre relève du même genre d'exercice, donc à voir cote soft comment se simplifier les choses! ( sans flinguer la CB!)

Ltr





« Modifié: février 15, 2024, 05:56:12 pm par laurentr »

trimarco232

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #58 le: février 15, 2024, 10:50:02 pm »
Bonsoir ,
(j'étais absent de vos topics et le temps passe vite , alors n'hésitez pas à me (re)poser des questions)
je reviens vers vous pour vous faire part de mes expériences et réflexions quant au choix de différents arduinos selon le besoin (et l'envie) ... pour tout de suite dire qu'il n'y a pas de solution évidente
perso , j'utilise plutôt des arduino complets , avec USB et bootloader , c'est plus facile à téléverser , à paramétrer , et à interfacer avec un PC ; il est placé en carte fille sur le circuit imprimé , qui comporte les autres composants nécessaires au montage
je les classe très subjectivement en 2 catégories : les 5v et les 3v3 ...
- les 3v3 , qui ont l'avantage de la compatibilité avec certains périphériques modernes
- les 5v ont l'avantage d'une meilleure commande des mosfet , d'une meilleure immunité aux parasites , quand on commande par exemple des circuits externes du genre 74HC165 ou 74HC595 , et une compatibilités avec des périphériques classiques capteurs , etc.) en général , les 5v marchent aussi en 3v3
dans un ordre quelconque :
1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi
4) pi pico , 3v3 , wifi , n'a pas tous les défauts de l'ESP32 , mais des faiblesses comparé au STM32 , pas de CAN
5) les nouveaux AVR de Laurent , 5v , bien , mais désespérément pas de petite carte bon marché
6) UNO R4 , 5v , wifi , CAN , pas de défaut comme ESP32 et pi pico , un peu cher mais il existe des clones acceptables
...
« Modifié: février 15, 2024, 10:56:52 pm par trimarco232 »

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« Réponse #59 le: février 16, 2024, 12:54:44 am »
Bonsoir

Merci Marc pour ces info utiles à nos réflexions pour conduire à des choix optimums.

Pour ce qui est de mes AVR ce sont plutôt ceux de MICROCHIP mais j avoue commencer à bien les connaitre. :)

Cote ESP32 j ai un peu creusé l'opportunité d'utiliser des modules. Il y en a tellement que c est presque une jungle pour  s'y retrouver!

Ex un ESP32 WROOM 32D ( en fin de vie mais discount) ou un ESP32 C3 tiennent la corde.

Vu la très grande hétérogénéité des formats avec les spec j'ai quand même identifié un brochage qui serait pour nous une base commune ( presque substituables pour peu que les pin utilisées soient dispo sur les deux versions)

les versions à base de "32 PINS" et comment les programmer

https://capuf.in/esp32-programmer-v2-capuf-embedded/


Donc un connecteur 6 broches fera bien notre affaire...

Et un programmateur externe bien sympathique pour injecter le code (avant des usages OTA possible ensuite?):

https://capuf.in/esp32-programmer-v2-capuf-embedded/

fonctionne sur le WROOM 32D ou le C3 32S car empreinte de brochage similaire (mais affectation des PINS plus ou moins dispo.) ( à tester of course!)

Comme Marc le souligne il y a pléthore de "petits modules" avec USB natif mais je trouve leur diversité pas évidente à approvisionner dans le long terme et leurs couts plus onéreux...

Vu qu'on va surtout leur demander des choses ultra basiques pas trop d'inquiétude sur leur capacité à faire ( pilotage led, relais, servo, bouton, CAN, voir I2C) Les versions à 1 seul cœur devraient même pouvoir suffire!
Ils offrent surtout une opportunité d'avoir une interface WEB pour lecture/modification de paramètres via un navigateur web! Confort!

Très gros atout donc pour ces CPU.

La réflexion se poursuit donc.

Ltr