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 [4] 5 6 ... 19
46
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 29, 2023, 11:33:59 am »
ici , c'est sur le rail gauche qu'on a l'impulsion tronquée à 29us , dont on va capturer le front montant , qui sert de base aux timings du cutout ; c'est aussi sur ce rail qu'on va devoir vérifier que la tension est bien revenue à 0v , au bout de 29us , pour lancer le canal 1
d'où la nécessité de choisir le "bon" rail , parmi les 2 , en entrée du comparateur

47
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 29, 2023, 11:27:24 am »
les tensions vues sur le rail de droite sont l'inverse de celles du rail de gauche
j'ai représenté une différence entre les 2 tensions , on est donc sur une section dont l'ABC est actif
l'ADC mesure chaque rail après son front montant , on peut donc déterminer si on est en ABC actif , ou pas

le comparateur va voir la même chose :

48
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 29, 2023, 11:08:59 am »
la contrainte , c'est qu'il faut choisir 2 pins qui peuvent être reliées à la fois à l'ADC et à un comparateur , mais il y a moult combinaisons possibles , à déterminer lors du dessin du PCB
à vérifier , mais rien ne semble empêcher que les 2 périphériques puissent être reliés simultanément , donc en permanence , aux 2 pins : cela simplifie bien l'analyse
pour que tout le monde comprenne , détaillons un peu  ; le décodeur est aimenté par un pont de Graetz , qui fixe peu ou prou le GND du décodeur à la tension du rail négatif (ce qui fait que du GND du décodeur est également proche du GND de la station DCC)
vu du décodeur , les tensions sur les 2 rails ont donc cette allure :


49
Vos projets / Re : Décodeur de locomotive multifonctions
« le: décembre 29, 2023, 10:42:20 am »
au temps pour moi , j'ai indiqué le principe pour des AVR classiques , ce qui t'a confusionné ...
les comparateurs des nouveaux AVR disposent de leur propre MUX d'entrée , donc le principe est le suivant :
PRINCIPE POUR LES NOUVEAUX AVR :

50
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

51
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é
 

52
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 :

53
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




54
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 !

55
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

56
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

57
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

58
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

59
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

60
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


Pages: 1 2 3 [4] 5 6 ... 19