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 ... 4 5 [6] 7 8 ... 21
76
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 27, 2023, 11:54:28 am »
"A noter qu'à la différence du croquis de Trimarco il n'est pas possible de lier directement en interne ( by software) la sortie de l'AC (out)  et ADC(in)."
mon dessin est juste , si on le lit à l'endroit

77
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 25, 2023, 12:12:38 pm »
(les 4 0402 amènent les tensions DCC dans le domaine mesurable)
grâce au MUX , l'ADC mesure alternativement le rail gauche et le rail droite , pour voir si on est sur un tronçon ABC
il faut tenir compte du fait que ces mesures perturbent la suite
l'ICP (input capture) utilise le MUX pour fonctionner sur le rail qui détient l'impulsion de 29us : ce rail est déterminé en observant les transitions bit DCC 0 <-> DCC 1 , à la mise sous tension , ou en cours de route , si l'engin passe par une boucle
compte tenu de la disparité des tension admise par la norme , il est possible que les signaux n'atteignent pas les 0.7*VCC nécessaires pour que l'ICP puisse voir un 1 logique : le comparateur y remédie , en employant la référence qui va bien ...
ne sont pas représentés , les différents filtres digitaux , qu'il faudra mettre en oeuvre en selon le MCU utilisé
 

78
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 25, 2023, 11:55:04 am »
il faut tenir compte du fait que la capture doit se faire sur le rail qui va bien : si elle se fait sur le mauvais rail , le bit DCC tronqué à 29us sera désespérément plat , on n'aura pas de top de référence pour les émissions railcom
voici comment je vois l'intérieur de l'AVR :
édit : PRINCIPE POUR LES ANCIENS AVR :

79
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 21, 2023, 12:30:19 pm »
on a un four , une horloge , alors on va cuire un gateau :
il faut le mettre 10mn à thermostat 7 , puis 20mn à thermostat 3
on le met au four à thermostat 7 , on regarde l'heure il est 11h05 , on s'en souvient
et là on surveille l'horloge de la cuisine :
ah , il est 11h15 (11h05 + 10mn) , on met thermostat 3
et on surveille l'heure , sans se laisser distraire
ah , il est 11h35 (11h05 + 10mn + 20mn) , on sort le gateau
il n'est pas beau mon gateau ? et pourtant je n'ai jamais eu besoin d'une seconde horloge !
ben là c'est pareil , TIMB0 continue de tourner , on fait du polling sur sa valeur pour savoir le temps écoulé depuis la capture (qu'on a sauvegardée) et ça suffit ; si certains parlent d'un second timer , c'est qu'ils n'ont pas compris un truc , où alors c'est moi ...

l'UART a 2 registres , un pour l'écriture TXDATA , et un , à décalage , qui transmet ; quand on écrit dans TXDATA , le byte est immédiatement transféré dans le registre à décalage, qui démarre immédiatement la transmission : on peut donc mettre de suite le 2ème byte dans TXDATA , qui ne sera automatiquement transféré dans le registre à décalage que quand ce dernier aura fini la transmission en cours
par contre , si on veut mettre un 3ème , il faut attendre que la transmission en cours soit finie
alors c'est peut être TXDATAL , ça dépend comment les registres sont définis , je n'ai aps vérifié ça

après relecture il semble bien que la priorité 1 soit une priorité de préemption, c'est à dire qu'elle peut interrompre une ISR en cours , et aussi qu'elle ne risque pas de se faire interrompre à son tour : on a donc une option qui permet(trait) d'éviter d'interdire les interruption pendant l'ISR du cutout ; la question sera aussi de voire comment se comporte le core vis à vis de ces options




80
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 20, 2023, 02:44:14 pm »
voilà comment je vois la chose :
1) au front montant de la 1ère impulsion du cutout (la 1ère partie du 1er bit du preamble , celle qui sera tronquée à 29us par la station) , TIMB0 provoque une interruption suite à la capture ; on fera toutes les opérations du cutout dans l'ISR correspondante , comme ça on ne sera pas gênés par d'improbables autres activités de l'arduino , pendant toute cette période ; de même , on ne fera appel à aucune instruction de type arduino , pour être certains que celles-ci ne perturbent pas notre timing , un peu critique : cela implique d'écrire directement dans les registres ;
la valeur capturée est mise en ram : uint16_t c = TCB0.CCMP0 ;
on fait aussi les opérations habituelles de décodage , qui permettent de vérifier qu'on est bien au début du cutout
2) il faut à présent attendre le début du cutout , cad. les entrées correspondant aux 2 rails à LOW ; il faut faire un double polling d'abord sur if (PORTx.IN & 0b00100100 == 0) , et aussi sur if ((TCB0.CNT - c) > 80) ;
il faudra aussi vérifier (TCB0.CNT - c) > (80+15) , auquel cas on arrête aussi les frais
si c'est ok , on envoie le canal 1 :
USART0.TXDATA = railcom_canal_1_byte_0 ;
USART0.TXDATA = railcom_canal_1_byte_1 ;
3) faire un polling sur if (PORTx.IN & 0b00100100 == 0) , et sur if ((TCB0.CNT - c) > 193) ;
il faut faire un double polling d'abord sur if (PORTx.IN & 0b00100100 == 0) , et aussi sur if ((TCB0.CNT - c) > 193) ;
il faudra aussi vérifier (TCB0.CNT - c) > (193+15) , auquel cas on arrête les frais
si c'est ok , on envoie le canal 1 :
USART0.TXDATA = railcom_canal_2_byte_0 ;
USART0.TXDATA = railcom_canal_2_byte_1 ;
puis on fait un polling sur la fin d'émission du 1er byte :
if (USART0.TXDATA & DREIF) USART0.TXDATA = railcom_canal_1_byte_2 ;
etc. , jusqu'à l'envoi des 6 bytes
là , les opérations du cutout sont terminées , on peut quitter l'ISR sans autre forme de procès !

81
Vos projets / Re : Re : Décodeur de locomotive multifonctions
« le: décembre 19, 2023, 11:11:09 pm »
Pour ce qui est des timing indiqués je pense que tu as en tête cette source
https://www.opendcc.de/info/railcom/railcom_f.shtml
le mieux est toujours de partir du document officiel , mais ceci est en effet une source sérieuse
Par contre je ne savais pas  a quoi correspondaient les 40 + 40 + 13 ( ici 80+15)
je m'a gouré (pour constater que tu suis 8)) : on a , pour le canal 1 , une tempo de 80us , suivie d'une trame de 80us , ça fait 160us ; pour le canal 2 , la tempo est de 193 us : il faut donc attendre entre les 2 canaux , 193 - 160 = 33us (pas 13 ???)
La réponse ici :
"Durant la pause de transmission un décodeur peut émettre l'information de retour. La transmission de retour est effectuée en série, octet par octet. Ceux-ci sont codés en RS232, paramètres de transmission 250kBaud, 8 bits, 1 bit d'arrêt. A 250 kBaud un bit dure 4μs, et un octet 40μs y compris le bit de départ (= 0) et les bits d'arrêt (= 1)."
source:
https://www.opendcc.de/info/railcom/railcom_f.shtml

On est bien en format 8N1 de 10bits x4us = 40us. x 2 trames = 80us +15us? ( tempo?)
oui , comme on écrit les 2 octets ensembles , il faut attendre que l'USART les a transmis (40 + 40 = 80us) , tempo à laquelle on ajoute les les 33us

Finalement on aurait a attendre ce moment de 93/95us par déclenchement de l interruption du TIMERB0 pour "envoyer" ce que l'on aura prépare avant (les 2 bytes de data du CH1) (je pense que tu veux dire 193us) : non , car les interruptions doivent être coupées à ce stade , mais aussi oui , car on n'est pas obligé d'arrêter TIMB0 , on peut faire du polling pour voir s'il a atteint les 193us , puis envoyer le canal 2

Cela se ferait par le passage dans la valeur TCB0.CCMP = F_CPU/1000000 * 93 (ou 95) ce qui déclenchera l interruption au moment venu. A ce moment on peut basculer une variable qui autorise l envoi.. ou quelque chose qui y ressemble.
Toutefois pour passer a 193+15 comme on aura eu une interruption qui remettraTCB0.CNT = 0. j imagine qu'on devra les déduire 80 des 193?( mais on a utilement le TCB1.CNT qui continue de compter de son coté a la même vitesse que TCB0... donc on a une valeur auto incrémenté a laquelle on ajoute le timing de l interruption entre 26 et 32...
On bascule alors la valeur CCMP avec ce nouveau nombre ajusté pour bis émission des autres bytes ds le CH2 si requis. deviendra simple quand on aura compris

Bon encore un peu à moudre de ce cote la pour tout mettre au clair ...

Ltr

82
Vos projets / Re : Re : Décodeur de locomotive multifonctions
« le: décembre 18, 2023, 10:56:20 pm »
(...)
A ce stade ma crainte est que le serial.Write') soit altéré par l ISR de TCB0 et/ou à l inverse que l'émission sur TX face sauter des micocrseconds_ticks ce qui fausserait la précision et donc possiblement le résultat. Mais la c est plus costaud à construire ou à "compenser".
Laurent
amha ,
il ne faut plus utiliser TCB0 une fois que l'envoi des bytes railcom a commencé
il ne faut pas non plus utiliser de bibliothèque pour envoyer les bytes , mais le faire manuellement : on se prémunit ainsi des ennuis liés aux interruptions , qu'on aura désactivées au début ; j'imagine la séquence suivante
- désactiver les interruptions
- observer la fin de la tempo pour le début de l'émission railcom , via TIMB0
- écrire le 1er byte du canal 1 dans TXDATA
- écrire le 2ème byte du canal 1 dans TXDATA
- observer une tempo de 40+40+33us , via TIMB0
- écrire le 1er byte du canal 2 dans TXDATA
- écrire le 2ème byte du canal 2 dans TXDATA
- attendre DREIF par polling
- écrire le 3ème byte du canal 2 dans TXDATA
- attendre DREIF par polling
- écrire le 4ème byte du canal 2 dans TXDATA
- attendre DREIF par polling
- écrire le 5ème byte du canal 2 dans TXDATA
- réactiver les interruptions
- attendre TXCIF par polling
- reprendre le décodage des bits DCC

Citer
On pourra veiller à ce que les 2 PINS choisies soient idéalement sur le même port pour
il faudra aussi que ces broches puissent être lues par l'ADC pour les besoins de l'ABC

Edit : 40 + 40 + 33

83
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 16, 2023, 11:43:39 am »
Bonjour ,
je suis assez booké ces temps-ci , alors , pêle-mêle :
Citer
si on obtient un digitalread(PIN_X) == 0 et digitalread(PIN_Y)== 0
si les 2 entrés sont sur le même port , on peut faire : if (IN_portX & 0b00100100) , en plaçant les 1 sur les entrées ; on doit même avoir une option où IN_portX peut être lu en 1 cycle (pareil si on est pressé en écriture , utiliser SET_portX , ou CLEAR , ou TOGGLE)
utiliser EVCTRL est une autre option : (filter)CCL(NAND) -> EVCTRL(filter) -> CAPT ; ça aurait été mieux qu'Atmel mette un filtre programmable au niveau du CAPT , pour éliminer les parasites , mais aussi les dead-time du pont en H de la station , environ 1us où les 2 entrées peuvent êtres lues simultanément à LOW , en confusion avec le début d'un cutout
je me refuse d'indiquer une préférence entre le polling des entrées (on a tout le temps pour le faire) , et l'utilisation de CCL et des armes des nouveaux AVR : l'idéal serait de disposer d'un proto qui permet d'évaluer les 2 ...
concernant les ISR , tu découvres , c'est bien ; j'en profite pour faire noter une chose , qui a peut-être une certaine importance : avec les nouveaux AVR , on peut fixer une certaine priorité pour les ISR ; ce n'est certes pas une priorité de préemption comme pour les ARM , mais une priorité de queue ; cela signifie que si ton interruption prioritaire est déclenchée alors qu'une autre ISR est en cours , ton interruption ne pourra pas interrompre l'autre ISR (d'où  l'intérêt que les ISR soient le plus court possible) , mais elle sera prioritaire par rapport aux éventuelles autres interruptions en attente , c'est déjà ça
j'en suis réduit à la même réponse de Normand concernant l'utilisation du soft d'Aiko vs celui de lebelge2 (affaire interne au Benelux) ; par contre , je suis persuadé qu'il vaut mieux utiliser le hard de lebelge2 , beaucoup plus simple que celui , nippon (ni mauvais) de ton schéma ; donc en un 1er temps , concernant le cutout , pour simplifier et avancer , tu pourrais faire du lebelge2 intégral (un peu de rétroingénierie  sans doute) , puis quand ça marche , migrer progressivement vers la solution d'Aiko , afin d'utiliser les pouvoirs des nouveaux AVR ; en tous les cas je pense que la solution japonaise est à écarter , car trop compliquée et mal documentée

84
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 01, 2023, 11:45:30 pm »
il faudrait qu'on ouvre un nouveau topic : la présentation de lebelge2 est terminée et fonctionne , on est hors sujet depuis un moment

85
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 01, 2023, 11:25:48 pm »
Hello

J ai vu et je vais voir comment porter le truc sur le projet.
Je préférais ma solution avec le NMOS car dans ce cas on est moins dépendant des tensions de la voie au delà de celle de bascule du NMOS. Pour ce qui est de la gestion de l'ABC on a alors en effet besoin de deux IO supplémentaires qui sont sous numéraires sur notre CPU 1616...
alors il faudra les protéger par des npn

le BOD level va aussi devoir être abaissé sur la plage BODLEVEL0  pour 1,8V [1,7V; 2V] pour que toutes les tensions au dessus de 2,1V en gros soient considérées comme des 1 et 0 en dessous.
Dans le montage avec le NMOS on peut rester sur un BODLEVEL7 avec 4,3V. ([4,1V; 4,5V]
le BOD level (Brown Out , pas Block Occupency) ne joue que sur le reset

J ai aussi donc une adaptation à faire pour l'ABC. ( qui permettra aussi de détecter le sens de circulation en analogique je pense)

Pour le pont en H c est un peu une fausse impression bien que cela soit le plus imposant composant du montage. IL est encore acceptable en terme d épaisseur surtout.
L ayant déjà utilisé je le trouve "parfait pour le job" et donc tenir 1.5 A ne lui posera pas de problème si on doit monter jusque la.(même en pic)
Je n'utilise pas la fonction de mesure/limitation de courant dessus
je regarde si je trouve quelque chose

Pour le diviseur que tu proposes avec les 4 x 100K je me pose la question de savoir s il ne faut pas qu'il soit asymétrique pour couvrir sur les PIN_IN DCC_R et PIN DCC_L une plage de tension au delà de 10/12V (V/2 <= 5,5V )(et donc du double idéalement) et garantir le niveau de tension mini d entrée pour valider la bascule d'état, et protéger le CPU. On peut aussi ajouter une diode entre l'entrée CPU et le +5V.
(j'ai pas écrit 4x100K) ces entrées serviront aussi à la capture : après la capture et les opération qui s'en suivent , on bascule la broche en analogique et on mesure l'ABC ; sur l'autre entrée  il faudra une interruption en milieu de bit DCC pour mesurer l'autre alternance

Reprenons un peu les mappings d'usages des 20 I/O pour éviter tout oubli. On ciblera ensuite plus finement les attributions précises ( s il faut en revoir certaines)

1 I/O pour le traitement du signal DCC ( sur évent +  interupt de la lib AIKO PRAS) ( sur le TIMER B0) pas besoin
1 I/O pour détecter le cutout RC ( l'autre pole DCC?) ( sur le TIMER B1)pas besoin
2 I/O pour la détection ABC ( voir la mesure du level en entrée pour l analogique)
2 I/0 PWM pour piloter le pont en H ( pilotées par le TIMER A mod split en 8bits)
1 I/O pour l UDPI
1 I/O pour le +5V
1 I/O pour le GND
2 I/O pour le "serial" TX/RXrx pas besoin
2 I/O pour l I2C SDA SCL
7 I/O pour le pilotage des sorties amplifiées ( dommage une de plus nous aurait offert 8 sorties amplifiées mais il reste au pire RX...)
1 I/O  le Tx pour le railcom

Millis()/micros() tournera sur le TIMER D. (sur cette série)

Le passage sur le 1617/3217 force les choses vers le haut à défaut ca sera 6  sorties pilotables ( Rouges et blancs indépendants de chaque cote et 2 éclairage de cabines par exemple).

Et la il y en a un qui va lever la main et dire et pour les servos et le DF Player on fait comment?
tx software serial
Plusieurs  options: extension I2C ou passage sur un CPU plus fourni en I/O.

Why not?

Laurent

86
Vos projets / Re : Décodeur de locomotive multifonctions
« le: novembre 30, 2023, 01:32:29 pm »
- j'ai édité mon post précédent : voir pour les 4x 0402 en entrées , au besoin regarder comment a procédé lebelge2
 -le pont en H me paraît énorme comparé au reste : ne peut-on pas tabler sur un modèle + compact (genre DRVmachin) , qui pourraient aussi servir pour commander 2 sorties AUX , on serait paré au niveau des protections


87
Vos projets / Re : Décodeur de locomotive multifonctions
« le: novembre 29, 2023, 11:53:46 pm »
très bien
je viens juste de regarder ton schéma :
- pour l'entrée DCC , on se contentera d'une 100K 0402 (comme "tout le monde")
Edit : ben non , il faut pouvoir mesurer la tension des 2 rails pour l'ABC : il faut donc 2 ponts diviseurs sur chaque rail , reliés à 2 entrées ADC , sonc 4x 0402 en tout ; un des 2 ponts sera aussi relié (en interne ?) à l'entrée ICP d'un des 2 TIMERB
- je ne suis pas convaincu du circuit générateur railcom : si une tension DCC intempestive arrive sur le transistor en-bas à droite , alors qu'il est commandé , il fume (sa dernière cigarette) ; je pense qu'il faut un transistor en + pour le protéger , en occurrence celui en bas à gauche , qui sert de diode : on met une vraie diode à la place , et on le récupère pour protéger celui de droite
Edit : en fait , pour que la tension en DCC_L (~15v) puisse être dangereuse , il faut que que celle en DCC_R soit à ~0v (il faut que ça se reboucle) , or dans ce cas , le transistor de droite n'est plus commandé , il est donc protégé : on peut faire confiance à l'auteur de ce shéma
- pareil pour les dual mosfet , il faudra les protéger par des dual-npn
- il existe le MPM3506A , qui ne fait que 600mA , ça suffit , et qui ne coûterait que 2€50 ; il faudrait encore s'assurer de son comportement lors des arrêts de la tension d'entrée , vis-à-vis de craintes de lebelge2 (qui s'y connaît) ; j'ai regardé la doc , elle touffue , donc je n'ai pas pu avoir de certitude de ce point de vue ; toutefois , si ça fonctionne , ce serait en effet un bon plan malgré le prix , car ça nous enlève une épine du pied avec de + une empreinte minimale

88
Vos projets / Re : Décodeur de locomotive multifonctions
« le: novembre 29, 2023, 05:53:51 pm »
- pour le dc/dc et les mosfets , comment font les fabricants de décodeurs ?
- il n'y a pas besoin de Rx ; le Tx sert au railcom , mais il faut peut-être y accéder pour le débogage : si tu as une place qui traîne pour une pastille ...
- pour l'emplacement des entrées et sorties , je dirais qu'il faut les mettre sur des pastilles , de manière à pouvoir migrer facilement vers un connecteur normalisé par la suite
- pour le DFPlayer , (à vérifier) , on peut prendre une des sorties AUX en software serial (je crois qu'il n'y a pas besoin de Rx) : voyons comment lebelge2 a procédé
- pour l'I2C pareil , on fera en software (je vérifie que ça existe) , donc 2 sorties AUX banalisées ; bien entendu , si les lignes I2C et le Tx alternate sont dispos en AUX , on pourra utiliser les périphériques SERIAL et I2C hardware
- enfin , à faire tant , on peut envisager une interface pour un power-pack maison , dont la conception (et la réalisation) pourra être allégée puisque piloté par le MCU du décodeur ...

89
Vos projets / Re : Décodeur de locomotive multifonctions
« le: novembre 28, 2023, 05:49:09 pm »
En effet c est une autre approche.

A voir ou se situe "l'optimum" et les compromis.
Par exemple sur le TINY1616 on aurait le PWM sur le Timer A, le décodage DCC sur le Timer B0 et le B1 pour millis()... le hic si on a besoin d un timer supplémentaire ( comme semble l indiquer Aiko dans les commentaires de la librairie) pour Railcom on est trop court ( ou pour d autres usages)
On doit alors monter vers un AVR en 28 ou 32 broches pour  disposer de ces ressources en plus. Donc selon le cahier des charges retenu on doit cibler le CPU.
nope : If TCD is used as the millis timer - which is the default on any part that has a type D timer (in order to keep the timers that are more readily repurposed available

En la matière pour du DIY la fabrication est industrielle donc il reste surtout la partie soft à injecter post assemblage à priori avec un ATMEL-ICE ou un "bricolage" pour transformer un nano en programmateur. ( la solution ATMEL ICE reste préférentielle mais elle coute déjà a elle seule le prix d un lockprogrammer ESU!). Cela réduit déjà un peu le champs de pratiquants prêt à suivre ( mais des commandes groupées sont possibles)
et re nan : j'ai fait mon téléverseur /déboggeur avec un convertisseur usb-série (que tout le monde a , auquel j'ai juste ajouté une diode , ce que tout le monde peut faire

Donc il faut déjà se chasser de l'esprit que DIY = cout faible. Sans chasser l'idée de contenir le prix de la réalisation il y a un ticket d entrée à assumer et un cout marginal à trouver. L amortissement ne peut se faire que sur un volume.
tu n'auras pas de volume sans avoir fait la démo du bon fonctionnement de quelque proto : après , tu pourras tout envisager , mais un prix contenu restera un avantage déterminant

Si on dresse la cahier des charges en quelques lignes on a:
encombrement max 16x30 mm
connecteur normalisé PLUX22 ou 21MTC
composants dispo en volume à prix modéré
pour l'instant , ne pas se focaliser sur ces connecteurs : le + de l'ouvrage de lebelge2 , c'est une connectique adhoc qui permet de raccorder un module son et des afficheurs LCD , on peut garder cette exigence
 
Egalement à "trancher" à ce stade:
support Railcom? c'est l'objet du topic
support ABC? pareil
support I2C/SUSI? voir ci-avant
compatibilité analogique? à ta guise
extension pilotage module son type DFPlayer? voir ci-avant
Autres... ...


Laurent

90
Vos projets / Re : Décodeur de locomotive multifonctions
« le: novembre 28, 2023, 12:21:07 pm »
oui , mais là tu pars dans une réalisation du type commercial , tu vas perdre tout le monde d'un forum DIY en route, et tu t'approcheras du prix d'un lokpilot en restant loin de ses performances et de sa fiabilité
pour être cohérent avec un soft gratuit , forcément basique même s'il est joliment écrit , il faut un hardware du même niveau
donc amha , regarder ce qu'il y a chez jlcpb (par exemple ATTINY1616-MNR) , et prendre un maximum de composants "basic"
alors au lieu de faire , comme tu as appris : schéma → PCB → BOM , faire BOM → PCB → schéma !

Pages: 1 ... 4 5 [6] 7 8 ... 21