Décodeur de locomotive multifonctions

[laurentr]

Re

J ai achevé la partie de traitement de l'ADC pour les 3 types ( MEGATINY Série 0 et 1 et ATMEGA x8 x9(Type1), AVRDx (type 2), AVR Ex et TINY série 2 (type3)) et pour 2 config d'attribution de broche sur chaque CPU!

Le mode en  lecture simple est retenu pour les mesures.
La vitesse de l'ADC est comprise entre 1 et 1,5Mhz selon les vitesses des CPU et diviseurs applicables ( un choix de cible 1Mhz quasi constant était aussi possible sur de nombreuses implémentations, non retenu pour aller au plus vite selon les cas jusqu'à 1.5Mhz) ( 1.5Mhz @24Mhz 1.250@20Mhz , 1Mhz@16Mhz 1.250@10Mhz et 1.2Mhz@8Mhz)
On reste toutefois sur des optimums pour chaque cas.

La compilation passe!
Les tests à suivre...

Il reste toutefois un point:

La restitution est pour les types 1 et 2 encodée sur 10BITS (dans un uint16_t)
MAIS le type 2 sort sur 12 BITS. ( toujours dans un uint16_t) ( pas de problème de contenant)

Pour une exploitation simplifiée je pense que la mise en forme va devoir être opérée par une "règle de trois" afin de lisser à 10 BITS toutes les valeurs reçues et ensuite appliquer les mêmes paramètres d'utilisation.

Des avis?

Laurent

[laurentr]

Bonsoir

Premiers tests globaux en cours

Premier constat un soucis de compilation avec les AVR EA EB ( lib event en cause à priori) mais ces séries sont encore en support non complet via DX_CORE.

Une solution de "contournement" est de ne pas s'appuyer sur la librairie EVENT fournie et de se "tarter à la mano" les settings, comme j'ai pu le faire pour intégrer l'ARDUINO NANO EVERY ( sans MEGATINYCORE) afin de s'appuyer sur la fonctionnalité EVENTSYS (sur laquelle s'appui EVENT).

A voir donc mais pour le moment c est la seule série de CPU qui se montre rebelle.

Atmega x08 et x09 = OK (MEGACOREX)
NANOEVERY = OK
MEGATINY Série 0 1 2 = OK (MEGATINYCORE)
AVR DA DB DD = OK (DXCORE)
AVR EA EB = KO (DXCORE)


Laurent

[laurentr]

Suite des tests

Il semble que le "bug" pour les CPU AVR EA & EB soit sur DXCORE... issue ouverte pour analyse.

En effet la compile "accroche" sur EVENT et COMPARATOR. (pb de { }, de valeur de variables... etc.)
Le fait de rentrer "à la mano "les éléments bloque sur les erreurs contenues dans les fichiers en question.

Peut être une prochaine MAJ de la lib pour corriger le tout. ?
En attendant pas de CPU Ex de dispo pour ce projet.

A noter que leur "cousins" de la série MEGATINY2 ne rencontrent pas le soucis de leur coté.

Laurent

[laurentr]

Bonsoir

Petit update. Les tests se sont poursuivis et le soucis rencontré avec les CPU de type AVR EA et EB est à present resolu.

Toutes les familles sont de nouveau supportées.

A présent d autres tests vont se poursuivre.


Laurent

[laurentr]

Bonsoir

Les tests se poursuivent bien pour éprouver les nombreuses combinaisons d'options de compilation( avec ou sans RAILCOM, avec ou sans les composants hardware sur les différentes familles de CPU).
J'ai toutefois réduit certaines possibilités pour gagner et garder une certaine cohérence.

J'obtiens de fait "un arbre de décisions multiples" incluant les fichiers concernes pour les combinaisons, rejetant ceux non pris en compte. ( Grace aux directives #if #elif #else et de nombreux #if defined() ou #if !defined().

Avant de passer dans une autre phase de test à l'aide du hardware associé, y a t il des volontaire pour y jeter un oeil?

@Trimarco Peut etre? Mais je te sais aussi tres occupé par ailleurs...

Laurent

[laurentr]

Bonjour

Nouvelle étape en cours de franchissent.
L initialisation des broches.

Pour memo nous sectionnons 2 broches qui soient adressable simultanément par le comparateur (AC0) et l ADC ( ADC0)

Fixons PD2 et PD3 pour cela pour les AVRx

Sur l ADC on doit par recommandation des datasheet procéder à l annulation de la mise en buffer du mode digital.

On definit au préalable les inputs

Code: [Sélectionner]

PORTD.DIRCLR = PIN2_bm | PIN3_bm; //SET PIN_PD2 and PIN_PD3 as INPUT resp A1 & A0 on NANOEVERY

Qui sont ensuite affinés pour le mode analogique via ces commandes:

Code: [Sélectionner]


                //SET PINS:
                //PIN PD2:
                PORTD.PIN2CTRL &= ~PORT_ISC_gm;
                PORTD.PIN2CTRL |= PORT_ISC_INPUT_DISABLE_gc;

                //PIN PD3:
                PORTD.PIN3CTRL &= ~PORT_ISC_gm;
                PORTD.PIN3CTRL |= PORT_ISC_INPUT_DISABLE_gc;


Cependant le Comparateur AC lui a besoin d avoir 2 inputs.
Pas de soucis pour nos broches PD2 et PD3 deja selctionnées et communes.

Toutefois le fait de désactiver le digital buffer rend impossible ( datasheet à la clé) le lecture d état du port par une instruction de type
PORTx.IN & zzzz est non opérationnel

On devra donc s en passer.

Ce que je n'ai pas encore identifié c est le possible impact sur le comparateur avec ce buffer de désactivé.
Je n'ai rien trouve/lu à ce sujet...

@Trimarco, des avis/idées sur le sujet?

Laurent

[trimarco232]

Bonjour , (désolé pour le silence , j'étais ... ailleurs)
je ne comprends pas bien ta question , il n'y a pas de mode digital ici
c'est normalement le comparateur qui fonctionne (sur le rail qui vabien) , et de temps en temps l'ADC (rapidement sur 1 rail puis sur l'autre)
peux-tu préciser le souci ?

[laurentr]

Bonsoir

D'après mes lectures des datasheet comme indique ci avant pour l ADC on désactive le buffer digital ce qui a pour effet de rendre inactif la commande PORTx.IN

Je ne sais pas si le comparateur va apprécier ou pas cette configuration.

Rien vu dans les docs à ce sujet.

Ltr

[trimarco232]

les entrées d'un comparateur analogique sont analogiques