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.


Messages - trimarco232

Pages: [1] 2 3 ... 13
1
 

Si quelqu'un est intéressé, je peux vous fournir tous les renseignements soit sur le forum, soit par messagerie privée.

Cordialement
Antoine
Bonjour,
tiens j'avais raté ceci, je dois dire que c'est bien vu, notamment le hct595 pour travailler en  5v, les smd (très facilement soudable) d'un côté et le th de l'autre
alors même si je dois encore déplorer l'absence inadmissible de plan de masse, n'hésite pas à ouvrir un sujet, je pense que le forum est là pour ça !

2
Vos projets / Re : PWM Bit Banging ISR
« le: mars 11, 2023, 12:49:21 am »
Bonjour Laurent,
pèle même :
- si possible diminuer la fréquence ou le nombre de crans, ou du moins éliminer les crans correspondant aux duty les plus courts
- oublier les bibliothèques : ou bien tu ne sais pas au juste ce qu'elles font : c'est casse gueule, ou bien tu sait comment elle fonctionne, donc tu peux réécrire en optimisant pour ton appli
- choisir un mcu + rapide, genre arm, ce qui te permet de prioriser tes interruptions, voire d'en accélérer le traitement
- choisir un pi pico : il a 8 timer ayant chacun 2 sorties pwm ; de plus tu peux programmer le périphérique pio pour te donner 8 pwm supplémentaires, ça fait 24 ; et les pwm peuvent fonctionner avec la dma, donc sans interventions des cpu ; car il y a 2 cpu à 133MHz chacune ...

3
Vos projets / Re : Re : Micro centrale DCC
« le: janvier 26, 2023, 03:14:09 pm »
Bonjour(...) comment synchroniser les ponts en H qui sont alors en parallèle les uns avec les autres...?
Laurent
mp car hs

4
Vos projets / Re : Micro centrale DCC
« le: janvier 26, 2023, 02:59:30 pm »
Bonjour,
peut-être il faut 2 paramètres pour le délai soft : un pour le démarrage, un autre pour le fonctionnement normal
(mais je n'aime pas pour ce projet, proposer des trucs qui en altèrent la philosophie)

5
Vos projets / Re : SIGNAUX: CIBLES ET DECODEURS
« le: janvier 10, 2023, 07:23:59 pm »
mais il n'y a pas le moindre souci, Laurent est un ami, si j'ai parlé d’élégance, c'est pour le taquiner , en laissant entendre que "ma" solution, cad. le charlieplexing, était plus élégante que la sienne
j'avais fait quelques dessins embarquant un microcontrôleur sur le signal, mais ça ne me plaisait pas ...
néanmoins je suis le projet de Laurent avec beaucoup de bienveillance, et n'hésiterai pas à lui donner mon aide, au besoin, car j'ai pris un peu d'avance sur ce thème

6
Vos projets / Re : SIGNAUX: CIBLES ET DECODEURS
« le: janvier 10, 2023, 05:28:57 pm »
Bonjour,
un peu d'élégance  :  https://forum.locoduino.org/index.php?topic=1269.0

7
Bonjour et bonne année
pour commencer les discussions relatives à ce projet, je propose la modification suivante, consistant à utiliser une fonction html/css pour faire pivoter les éléments du TCO
le but est de réduire d'une bonne moitié le nombre d'éléments de base, mais surtout d'orienter facilement les aiguillages, sans devoir en tenir compte dans le code ; j'ai ainsi pu ajouter un aiguillage triple vertical, sans disposer du dessin
il faut pour cela compléter la classe de style ".im1" par 3 autres classes, selon la rotation voulue
    .img1 {border: 0px; width: 64px; height=64px;}
    .img1_090 { border: 0px; width: 64px; height=64px;
            -webkit-transform: rotate(90deg);
            -moz-transform: rotate(90deg);
            -ms-transform: rotate(90deg);
            -o-transform: rotate(90deg);
            transform: rotate(90deg);  }
    .img1_180 { border: 0px; width: 64px; height=64px;
            -webkit-transform: rotate(180deg);
            -moz-transform: rotate(180deg);
            -ms-transform: rotate(180deg);
            -o-transform: rotate(180deg);
            transform: rotate(180deg); }
    .img1_270 { border: 0px; width: 64px; height=64px;
            -webkit-transform: rotate(-90deg);
            -moz-transform: rotate(-90deg);
            -ms-transform: rotate(-90deg);
            -o-transform: rotate(-90deg);
            transform: rotate(-90deg); }

le paramètre "angApp" des fonctions "ChangeAig..." n'est plus nécessaire (je ne l'ai pas modifié)
je joins le fichier "Mon_TCO_No04" modifié, à titre d'illustration ; on doit obtenir ceci :

 

8
Vos projets / Re : Caméra WIFI embarquée à l'échelle N
« le: décembre 06, 2022, 08:03:15 pm »
ben oui, mp pour la suite , à +

9
Vos projets / Re : Caméra WIFI embarquée à l'échelle N
« le: décembre 06, 2022, 07:44:55 pm »
Bonjour,
tu as des pcb en rab ?

10
la carte est en service depuis quelques jours, à la grande satisfaction de l'utilisateur, alors quelques photos
- carte terminée (on voit les pattes des leds sur le connecteur, qui m'ont servi à tester la carte)
- carde raccordée et en service (reste à la fixer et à arranger les câbles)
- tableau qui reprend le câblage
reste à corriger un bug qui fait des fausses indications au démarrage ... le programme fonctionnant très bien par la suite

11
les 2 1ers prototypes fonctionnent, ils seront mis en service sur le réseau prochainement
j'ai finalement opté pour + de souplesse
un petit dessin pour illustrer le principe : les leds des signaux se raccordent à la suite, il n'y a pas de séparation gauche droite, mais une continuité :
à gauche leds 1 à 10  ↓_↑  leds 11 à 19 à droite
exemple de câblage des signaux sur la 2ème carte dans l'illustration
Edit : les prototypes sont abandonnés suite changement de principe de mesure de la durée des bits DCC, ils sont disponibles à la vente grâcieuse (en échange d'une adresse), ou à la casse ...

12
Tu peux très bien fonctionner en 5V sur les nouveaux AVR et ATTINY. Donc pas de sujet la dessus
oui, mais il y a peut-être d'autres personnes qui seront intéressées par cette réalisation : il est souhaitable de simplifier les choses en utilisant un module tout fait, avec alim, interface et prise usb ; cela n'existe pas, dumoins à un prix décent, avec les nouveaux avr
C est en effet diffèrent avec l autre puce qui est susceptible d'être un "must have" la RP2040... mais là, la lib d AK n'est pas compatible et il faut donc soit la faire évoluer soit repasser vers la DCC NMRA pour en profiter. (ou une autre mais laquelle?)
je ne pense pas qu'on puisse parler de must have : pour chaque projet, on peut se contenter de "l'arduino" qui suffit ; j'ai cité le RP2040 car il a des atouts : d'abord, d'abord ... c'est un arm : ça ne se programme pas comme un avr ; pour les avr, il faut toujours se dépêcher de sortir rapidement des isr en plaçant des flags si besoin ; pour un arm, c'est l'inverse : si 90% du programme peut être placée dans un isr, éh bien tu le laisse dedans ; si d'autres isr doivent intervenir en priorité, il suffit de leur attribuer une priorité plus haute, et ils viendront interrompre l'isr en cours, qui reprendra quand l'isr prioritaire est terminé
 ... de +, le RP2040 a 2 cœurs ! ça veut dire qu'on peut affecter un cœur à la seule tâche du décodage dcc ; cela permet d'nvisager des améliorations, comme la réparation de messages endommagés par un cc, un faux contact, ou des parasites ; on serait sur un autre niveau de qualité, et il me semble qu'aucune bibliothèque existante n'offre de telles possibilités ; malheureusement la flash externe fait revenir le truc + de 30 ans en arrière, complètement inadapté à des décodeurs embarqués, quand la place est comptée
on peut utiliser la bibliothèque nmra dcc pour le RP2040, c'est juste un peu dommage : j'aprécie beaucoup des auteurs comme Aiko Pras car ils se restreint aux mcu qu'il connait bien, ou l'incroyable et Khoi Hoang, qui décline des bibliothèques en autant de catégories, voire de sous catégories de mcu qu'il connait, et il y en a un paquet ; cela permet d'optimiser le programme au mieux, au contraire des gens de la bibliothèque nmra dcc, qui ont plutôt tendance à régresser sur ce point, afin d'augmenter la portabilité du truc ; mais restons pragmatiques, l'important finalement, c'est que ça fonctionne
 

Pour moi je vois 2 points à ajouter a la classe LED d AK:
sur le mode flashsingleserie la possibilité de sortir de la série avec un état haut ou bas au choix du paramètre à configurer. ( en bas éteint, en haut allume) avec cela on sait alors générer un start de néon et rester allumer à la fin.
l autre modifs consiste a avoir un PWM sur le "ON" ou "OFF" pour gérer le level d intensité lumineuse en "ON" ou "OFF" et ne pas être sur du tout ou rien 0/1 mais sur un setPWM level...
ben faut lui en parler, lui expliquer : il décidera s'il veut l'implanter ou non, mais il faut déjà qu'il ait l'info ; j'ai su le faire ici, donc il saura aussi
Je pense que cela doit être combinable avec les lib précédemment évoquées...

Je m interroge en fait sur un point: la gestion des PWM avec la lib de Khoih via les ISR ( dont on voit la pertinence) et l utilisation de la gestion soft du PWM par la classe led de AK dont on voit une grande proximité mais qui n est pas dans un ISR...
j'ai pas regardé, mais Khoih, comme tout le monde, doit aussi sortir le + rapidement possible de l'isr, sous peine de bloquer le reste

Je vois bien que selon la charge CPU si on est pas dans une ISR on a un risque d irrégularité de traitement du signal en sortie...
exact, mais on n'a pas le choix ; tout l'art, c'est de maîtriser ou pallier ce risque ;)
D ailleurs comment visualiser cette charge CPU dans le monde Arduino?
c'est fastoche, il faut d'ailleurs commencer par ça ; l'arduino n'est qu'une couche qui s'ajoute au dessus du reste ; il faut utiliser quelques broches qui à l'aide de l'analyseur logique, moucharderont ce qui se passe dans la bête : par exemple ici, j'ai pour chacune des 2 isr une broche qui change de niveau au début et à la fin de l'isr, et une troisième qui change de niveau sans la loop (par ex.: PINB = _BV(3)) ; on voit le début et la fin de chaque interruption, et l'impact que ça a sur la durée de la boucle 

Si quelqu'un peut exposer les + et - de chaque cas pour la gestion de ces PWM... je suis preneur d info...
ben faut faire le test et mesurer, intuitivement je penserais que c'est peu ou prou pareil, le principal c'est que tu utilises le capture pour le dcc

J ai récemment été exposé à un cas analogue dans un petit programme de gestion d effet de démarrage de tube néon.
Avec 95 CHAR de serial print dans la boucle principale les effets sont "fabuleux" et visuellement "parfait"
Sans les serial print la boucle est "trop rapide" et les effets visuels sont différents et ne reflètent pas l attendu.
Donc ou identifier la charge et les temps d exécution pour savoir ou ajuster... les meilleurs timing!???
il faut t'afranchir de la durée aléatoire de la loop, et piloter ça par un timer ; le serialWrite, c'est la merdre, il est indispensable pour déboguer, mais quand c'est fait, il faut le virer

13
Bonsoir Laurent,
merci,
merci pour les liens
en fait j'ai choisi un AVR classique (quoiqu'un peu exotique), pour pouvoir fonctionner en 5V : les 2 feux jaunes du  Ralentissement, comme ceux du rapPel sont en série, donc 3v3 ça suffit pas
pour les timers et le pwm, je connais (il y a longtemps, j'ai commencé à programmer les AVR en assembleur, bare metal total), donc une bibliothèque autre ne m'apportera rien (il y a désormais beaucoup de gens qui font des bibliothèques sans trop maîtriser leur sujet)
j'ai signalé à Aiko Pras la possibilité, voire la pertinence et la facilité, d'utiliser la fonction capture sur des AVR classiques ; il fera ce qu'il voudra
le nano every est chouette, mais même en clone, c'est 3x le prix des modules à LGT ... alors par les temps qui courent ...

14
les différents signaux peuvent avoir de 1 à 8 feux (les ralentissement et rappels comptent pour 1 feu, car leurs 2 leds jaunes sont câblées en série)
avec les variantes, ça me fait 14 types de signaux différents, c'est peut-être suffisant
la configuration de chaque arduino se fait au moniteur (arduino ou émulation terminal), je trouve dommage de devoir configurer des CV depuis une centrale quand on dispose de l'USB !
il y a un petit menu ; on saisit une lettre pour dire qu'on veut configurer, puis on saisit :
- l'adresse de base
- le type (parmi 14) du 1er signal raccordé
- puis le type des signaux suivants, j'usqu'à ce que toutes les sorties soient occupées
au fur et à mesure des saisies s'affichent les types, l'adresse de chaque indication, le branchement de chaque led, le nombre de leds qui peuvent encore être branchées
dans mon exemple, à la fin, il restait une sortie libre, j'y ai représenté une led, qui peut servir dans le décor, par exemple, en utilisant une adresse ; on peut aussi configurer en sortie permanente, HIGH ou LOW, donc pas besoin d'adresse
quand la config est terminée, le menu propose d'appuyer sur une touche pour sauvegarder la config  ... is that simple
il y a quelques sorties CV (commun voltage, en orange sur le dessin) réparties le long des borniers

au démarrage l'arduino va rechercher la config dans l'eeprom et la place dans la ram
après mûre réflexion, et lecture studieuse du réglement S1A, j'ai retenu l'odre suivant pour les indications :
Ve,Se, Vc,Av, Sc,Ac, Ca,Cv, Pe,Pc, Ra,Rc, M,Mc (Pe c'est le rapPel 30 et Pc le rappel 60, c pour clignotant)
on a donc 14 indications, soit 7 adresses pour le signal le + complexe
Et que c'est pas fini
bien entendu, l'oeilleton est géré, il s'alume et s'éteind en fonction des indications
il y  a aussi les indications combinées : Pa+Av, Pa+Ac, Pc+Av, Pc+Ac, et Rc+Ac, ; elles s'obtiennent simplement en commandant à leur tour les indications compatibles, par exemple si on veut le rapPel 60 + l'Avertissement, on commande d'abord le Pc, puis on commande l'Av, et on obtient Pc+Av
Pc+Av peut aussi être obtenu en commandant d'abord Av, puis Pc
si maintenant on commande le rappell 30, Pe, on obtient Pe+Av, car les 2 indications sont compatibles, il n'y a pas lieu d'effacer l'Av
par contre, si on commande par la suite, par exemple le Ralentissement 30, Ra, le R s'affiche tandis que le A doit s'éteindre progressivement

progressivement ? of course ! alors un peu de technique
bien qu'il doit être possible de lui adapter mon code, j'ai laissé de côté le nano classique au profit du LGT8F328P, car il permet de faire + pour moins cher
j'ai notamment besoin de + de vitesse (32MHz) et d'un 2ème timer à 16 bits, le timer 3
le timer3 me sert à piloter le pwm des leds (19 ou 32 leds suivant le modèle) , selon une rampe de type exponentielle avec une précision de 10 bits sur 45 pas
le timer1 me sert à mesurer les durées des impulsions DCC, avec une précision de 1/2us ; j'utilise l'entrée capture du timer : cela me permet d'avoir une mesure exacte, même si une autre interruption est en cours au moment de la transition du signal DCC, et aussi de disposer d'un filtre qui élimine automatiquement les éventuels parasites du signal ; la suite du décodage se fait selon la bibliothèque d'Aiko Pras, que j'ai adaptée (facilement) pour avoir la fonction capture sur un AVR de type classique

en vrac :
l'ordre de câblage des feux des signaux est le suivant (ça suit peu ou prou l'ordre des indications) : V, S, A, C(ouCv), O, P, R, M ; dans l'exemple , j'ai des signaus de type S,A,V, R (ou S,A,R,V, je ne sais pas, en tous cas chez moi c'est V,S,A,R) : si on suit l'odre des feux comme indiqué ci avant, il faudrait laisser libres les sorties correspondant aux feux C(carré) et O(oeilleton) : j'ai donc créé un type (le 42), qui permet d'éviter ça et de câbler le R directement à la suite du A (on économise 4 sorties dans l'exemple)
j'ai laissé tomber le choix alim par DCC ou dédiée par cavalier : comme le montre l'illustration, si on veut alimenter par le DCC, il suffit de ponter les sorties DCC et alim sur le dernier bornier en bas (notons que chez trimarco232, le câblage des modules suivants est évident, pas besoin de faire de dérivation...)
pour avoir des feux qui s'allument alors que d'autres s'éteignent sur un même signal, on peut avoir jusqu'à 5 leds qui s'alument ou s'éteignent simultanément et progressivement (par exemple, l'indication Ca qui suit l'indication Pe+Av : on a les feux P+A+O qui s'éteignent progressivement, alors que les feux S+C s"allument pareil) ;  j'ai donc 5 tableaux de 8 lignes (le nombre de feux) et 19 colonnes (le nombre d'indications), en PROGMEM, qui me donnent instantanément ce que chacune des 5 leds doit faire, sans que l'AVR n'ait à effectuer le moindre calcul ; c'est un peu fastidieux, mais comme la CPU doit aller vite c'est la bonne méthode ; en principe perso, alors que certains en sont à l'intelligence artificielle, je programme complètement à plat, c'est l'intelligence zéro, tous les cas sont listés, puis pour chaque cas j'ordonne au cpu ce qu'i doit faire

on va terminer par un petit quizz :
dans l'illustration il y a une petite erreur au niveau du câblage, laquelle ?
dans l'ordre des indications, j'ai mis Vc (vert clignotant) dès la 3ème position (2ème adresse, 1ère position), pourquoi ?

15
les 2 1ers prototypes fonctionnent, ils seront mis en service sur le réseau prochainement
Edit : suite à l'adoption définitive de la technique "capture" du timer1 pour mesurer la durée des 1/2 bits DCC, les prototypes sont disponibles à la vente grâcieuse, (ou à la casse)
j'ai finalement opté pour + de souplesse
un petit dessin pour illustrer le principe : les leds des signaux se raccordent à la suite, il n'y a pas de séparation gauche droite, mais une continuité :
à gauche leds 1 à 10  ↓_↑  leds 11 à 19 à droite
exemple de câblage des signaux sur la 2ème carte dans l'illustration

Pages: [1] 2 3 ... 13