Discussion :

[Delias]

Bonsoir Vincent

Pour la commande, il faut raccorder D0 à D8, A1 à A4, IOWR et IORD à l'Arduino. L'Arduino est capable de gérer directement la platine interface, mais pas avec un câble plus long que quelques dizaines de centimètre.
A5 et A7 à A11 sont raccordable directement à GND et A6 à Vcc (5V).
Pour le RST, c'est à commander depuis l'Arduino en différentiel.
Pour le Clk il générer une horloge en différentiel et au pif entre 1 et 5MHz, mais j'ai aucune idée de la fréquence idéale de ce montage.

Pour les signaux différentiels c'est soit deux signaux TTL/HC en opposition (quand un est à vrai soit environ 5V, l'autre doit être à faux soit environ 0V). Soit tu fixes l'un des signaux à 2.5V avec deux résistances, et l'autre est commandé directement en TTL/HC. Attention pour l'horloge, à 1MHz, le vrai différentiel est quasi obligatoire.
La clk devrait être générée séparément de l'Arduino. Ou récupérer le Clk de la puce et la diviser pour descendre en dessous de la limite de 5MHz. Je ne pense pas que la générer depuis l'Arduino par le code sera suffisamment précis.

Pour la commande, A4, A3, A2 définissent quel TMP est adressé. Avec une exception A4=0, A3=A2=1 qui permet de configurer les signaux BUSL (avec A0 et les Data)
A1 est l'entrée A0 des TMP, à 0 c'est des données, à 1 c'est des commandes ou la lecture des états qui sont envoyés ou reçus au/du TMS.
Avec IOWR (inversé c'est ce que signifie la barre au dessus) à 0 c'est l'écriture dans le TMS sélectionné qui est activé (donnée ou commande)
Avec IORD (idem) à 0 c'est la lecture depuis le TMS (Arduino en entrée sur D0-D7) sélectionné qui est activé (donnée ou état)

Ensuite il faut lire la doc du TMP, il y a une série de commandes à envoyer à la mise sous tension, puis les données pour l'activation des leds (à chaque écriture l'adresse interne du TMP est automatiquement incrémentée).
Pour connaître l'état des boutons c'est pareil en lecture.

Je te laisse le temps de lire la doc du TMP, pour trouver les détails.

Un seul Arduino suffira, le problème que je voyais c'est le nombre d'entrées/sorties. Ma 1ère réponse était pour le cas du remplacement des platines d'interfaces par des Arduino, et là un seul pouvait difficilement suffire au vu du nombre de signaux nécessaire.

Bonne suite

Delias

[vins86]

Bonjour Delias,

Merci pour toutes vos explications, même si beaucoup reste flou pour mon niveau.

Bonsoir Vincent

Pour la commande, il faut raccorder D0 à D8, A1 à A4, IOWR et IORD à l'Arduino. L'Arduino est capable de gérer directement la platine interface, mais pas avec un câble plus long que quelques dizaines de centimètre.

la nappe fait 40 centimètres. Est-ce de trop?

A5 et A7 à A11 sont raccordable directement à GND et A6 à Vcc (5V).
Pour le RST, c'est à commander depuis l'Arduino en différentiel.
Pour le Clk il générer une horloge en différentiel et au pif entre 1 et 5MHz, mais j'ai aucune idée de la fréquence idéale de ce montage.

Qu'entendez vous en parlant de différentiel?

Pour les signaux différentiels c'est soit deux signaux TTL/HC en opposition (quand un est à vrai soit environ 5V, l'autre doit être à faux soit environ 0V). Soit tu fixes l'un des signaux à 2.5V avec deux résistances, et l'autre est commandé directement en TTL/HC. Attention pour l'horloge, à 1MHz, le vrai différentiel est quasi obligatoire.
La clk devrait être générée séparément de l'Arduino. Ou récupérer le Clk de la puce et la diviser pour descendre en dessous de la limite de 5MHz. Je ne pense pas que la générer depuis l'Arduino par le code sera suffisamment précis.

Comment dois-je faire pour générer une clk séparément sans l'arduino? Il me faut un module?

Pour la commande, A4, A3, A2 définissent quel TMP est adressé. Avec une exception A4=0, A3=A2=1 qui permet de configurer les signaux BUSL (avec A0 et les Data)
A1 est l'entrée A0 des TMP, à 0 c'est des données, à 1 c'est des commandes ou la lecture des états qui sont envoyés ou reçus au/du TMS.
Avec IOWR (inversé c'est ce que signifie la barre au dessus) à 0 c'est l'écriture dans le TMS sélectionné qui est activé (donnée ou commande)
Avec IORD (idem) à 0 c'est la lecture depuis le TMS (Arduino en entrée sur D0-D7) sélectionné qui est activé (donnée ou état)

Ensuite il faut lire la doc du TMP, il y a une série de commandes à envoyer à la mise sous tension, puis les données pour l'activation des leds (à chaque écriture l'adresse interne du TMP est automatiquement incrémentée).
Pour connaître l'état des boutons c'est pareil en lecture.

Par contre, je suis vraiment navré, mais je n'ai pas du tout compris cette partie. De plus l'adresse interne du TMP est automatiquement incrémentée. C'est en interne ou dois-je l'effectuer avec l'arduino?


Merci beaucoup de votre aide.

Cordialement,

Vincent.

[Delias]

Bonsoir Vincent

Merci pour toutes vos explications, même si beaucoup reste flou pour mon niveau.

Alors il faudra progresser un minimum pour arriver au bout de ce que tu souhaites faire. D'autant que la réalisation d'une platine mère accueillant l'Arduino, le connecteur du bus et les deux/trois autres circuits nécessaires est quasi obligatoire. Une réalisation avec uniquement des fils prévu pour les breadboards sera quasi vouée à l'échec. (Contacts trop mauvais et trop grand captage des parasites.)

La nappe de 40 centimètres. Cela ira, mais il ne faudra pas forcer sur la fréquence de communication. Il faudra respecter les délais des TMP avec un peu de marge.

Qu'entendez vous en parlant de différentiel?

J'en ai parlé juste juste après la partie que tu as cité. "signaux différentiels" sur fourni ensuite bien des explications.
Tu peux aussi consulter la doc de l'AM26LS32 pour avoir plus de détail et des exemples de mise en œuvre.

Comment dois-je faire pour générer une clk séparément sans l'arduino? Il me faut un module?

Exactement, et il y a plusieurs méthodes pour cela, du module fournissant un signal d'horloge à l'utilisation simple d'un quartz et de son circuit oscillateur.

Par contre, je suis vraiment navré, mais je n'ai pas du tout compris cette partie. De plus l'adresse interne du TMP est automatiquement incrémentée. C'est en interne ou dois-je l'effectuer avec l'arduino?

As-tu lu et compris la documentation du TMP82C79P-2?

Une bonne suite

Delias

[vins86]

Bonsoir Delias,
Je tiens encore à vous remercier pour le temps passé à m'aider.

Alors il faudra progresser un minimum pour arriver au bout de ce que tu souhaites faire. D'autant que la réalisation d'une platine mère accueillant l'Arduino, le connecteur du bus et les deux/trois autres circuits nécessaires est quasi obligatoire. Une réalisation avec uniquement des fils prévu pour les breadboards sera quasi vouée à l'échec. (Contacts trop mauvais et trop grand captage des parasites.)

Je comprend que c'est un projet très ambitieux mais très intéressant. Je prévois des pins header male-male en direct sans fils pour gagner de la longueur.

J'en ai parlé juste juste après la partie que tu as cité. "signaux différentiels" sur fourni ensuite bien des explications.
Tu peux aussi consulter la doc de l'AM26LS32 pour avoir plus de détail et des exemples de mise en œuvre.

Si j'ai bien compris il faudra mettre 2 pins en opposition soit par exemple (digitalWrite(21, HIGH) et digitalWrite(22, LOW)) et sortir le signal sur 1 fils pour avoir 2.5V?

Exactement, et il y a plusieurs méthodes pour cela, du module fournissant un signal d'horloge à l'utilisation simple d'un quartz et de son circuit oscillateur.

Est-ce que le module Horloge DS3231 est adapté pour mon utilisation?

As-tu lu et compris la documentation du TMP82C79P-2?

Je vais être honnête avec vous, je ne comprend pas les différentes explications.

Je pensais que l' interfaçage allait être plus simple que çà.

J'aimerais pouvoir commencer les essais. Puis-je faire quelques câblages sans pour autant avoir le quartz et essayer d'allumer une LED?

Merci d'avance de votre aide pour la réalisation de mon projet.

Cordialement,

Vincent.

[Delias]

Bonsoir

Je prévois des pins header male-male en direct sans fils pour gagner de la longueur.

Le brochage de l'Arduino et du câble plat de 60 pôles n'est pas le même. Donc il faut donc plusieurs connecteurs: un pour le câble plat, les autres pour l'Arduino (une sorte de Shield, mais bien plus grand, donc c'est lui qui accueil l'Arduino et non l'inverse). Pour réaliser cela c'est un circuit imprimé spécifique à réaliser selon les règles de bonne facture. Dès le moment où on en fait un, autant ajouter le reste de la circuiterie nécessaire. Là je pense que l'on pense à la même chose.

Pour les signaux différentiel c'est le principe mais tu mélanges.
Il y a trois façons de faire:
- Une puce spécifique, comme la AM26LS31, complémentaire à la AM26LS32.
- Deux sortie en opposition comme ta proposition de code, sauf que les deux doivent être changé en même temps. C'est obligatoirement avec une instruction du type PORTX = UnByte; UnByte ayant été calculé au préalable.
- Un pseudo différentiel avec une ligne fixe à 2.5V (obtenu avec un diviseur de tension à résistance). Et une autre qui est pilotée par le micro. C'est une solution roue de secours que je ne recommanderais pas dans ce cas.

Pour l'horloge, non ce n'est pas du tout cela. C'est plutôt dans ce genre: https://www.distronic.fr/133-oscillateurs, C'était disponible et avec une large gamme de fréquence à l'époque où le circuit a été conçu. Actuellement et avec l'arrivée des microcontrôleurs, les gammes se sont réduites et on ne trouve moins facilement ceux à fréquence faible.

La partie sur la doc du TMP, c'est dans un deuxième temps, pour le programme de l'Arduino.

Bonne suite

Delias

[Guesset]

Bonjour,

Effectivement, c'est bien le pupitre BKDS-8010 de Sony.
...
Le mélangeur DVS-8000 est en SD et ne fonctionne pas, on veut modifier le pupitre pour piloter notre mélangeur 8k via un arduino par exemple.

S'il faut seulement remplacer le DVS-8000 par un mélangeur 4K et que le clavier fonctionne toujours, ne serait-il pas plus facile de faire une migration inter-protocoles entre le clavier et le mélangeur ? La difficulté propre à cette approche est de connaître (ou retrouver) le protocole du DVS-8000. En revanche, la sollicitation des entrées-sorties d'un microcontrôleur devrait rester très limitée.

Bon courage.

[vins86]

Bonjour Guesset,

S'il faut seulement remplacer le DVS-8000 par un mélangeur 4K et que le clavier fonctionne toujours, ne serait-il pas plus facile de faire une migration inter-protocoles entre le clavier et le mélangeur ? La difficulté propre à cette approche est de connaître (ou retrouver) le protocole du DVS-8000. En revanche, la sollicitation des entrées-sorties d'un microcontrôleur devrait rester très limitée.

Le pupitre fonctionne (DVS-8000), mais nous n'avons pas le protocole de transmission. Nous souhaitons pouvoir piloter notre mélangeur avec le pupitre justement.

Delias informait qu'il pouvait surement envisageable de le faire avec un microcontrôleur (atmega), Mais avec un circuit spécifique.

Il y principalement des boutons, des leds et quelques potentiomètres. J'ai les informations à transmettre au mélangeur.

Nous avons déjà un pupitre avec un arduino. Mais pas de la même marque et donc pas les mêmes protocoles.

Dans l'attente.

Cordialement,

Vincent.

[Delias]

Bonsoir

Avec les connaissances nécessaires et un peu de temps c'est réalisable.

Comme il faut à priori en plus une horloge entre 200kHz et 5MHz et un driver de ligne différentielle (pour quelque chose de sérieux), et vu mon expérience je serais parti sur un microcontrôleur nu et une platine avec le tout. Un gros avantage car l'alimentation est commune et très probablement l'horloge également. L'ATMega c'est mon choix car c'est la famille que je maitrise le mieux (et je n'en fais pas assez pour me lancer dans d'autres). Cette conception également est mon choix car j'ai les connaissances pour.

Maintenant sans cette base, vous pouvez essayer, mais contrairement à la programmation, l'électronique ne pardonne que très rarement les erreurs. Un faux branchement et pschitt c'est cramé. On ne peut pas revenir en arrière. Cramer un TMP et bye-bye le pupitre, vu que trouver un TMP de remplacement c'est quasi impossible.

Bonne suite, ou pas

Delias

[vins86]

Bonjour,

Je me permet de revenir vers vous avec quelques jours d'absence.

J'ai travaillé avec les différents éléments que vous m'avez communiqué.

d'après d'autres réseaux, il m'a été conseillé de garder mon arduino mega2650 dans la phase de développement et de test afin d'éviter de faire des plaques inutilisables.

Je me suis permis de faire un plan de câblage avec les différentes informations récupérées et j'ai fait l'achat de AM26LS31CN

Une personne à fait un projet dans les mêmes besoins que moi, mais avec un rapsberry : https://gitlab.ags.etc.tu-bs.de/eggert/dvs8000

Dans l'attente de vous lire avec de bon conseil.

Cordialement,

Vincent.

[Delias]

Bonjour Vincent

Si on prend le schéma de l'Arduino Mega, les lignes D0 à D7 ne proviennent pas du même Port du micro. Voir le schéma du Mega disponible sur le site Arduino.
Or pour une grosse facilité de programmation les lignes D0 à D7 du bus (câble) devraient être reliées sur un seul port du micro, par exemple le port C pattes 30 à 37 du Mega. Cela permettra d'écrire ou de lire les 8 lignes de donnée du bus en une instruction (écriture avec PortC = xx;, lecture avec xx = PinC;).

Pareil avec les 4 lignes d'adresses, idéalement les 4 bits faible d'un port.

Pour le signal de reset c'est en ordre, mais pour celui d'horloge c'est courageux (ou pas très réfléchi) de le mettre sur la patte que tu as choisi. Il faudra générer une horloge d'au moins 200kHz par le code uniquement (car toute variation de la fréquence sera néfaste au fonctionnement des TMP). Le faire par le code au début c'est envisageable, mais c'est très contraignant. Il est par exemple illusoire de le faire avec des digitalWrite dont le temps d'exécution est de l'ordre de 3us. Soit 6us pour l'écriture haut puis bas, ce qui donne une fréquence inférieure à ce qui est nécessaire. Il serait bien mieux de le mettre sur une sortie PWM et commandée par un Timer qui n'est pas utilisé par la base de l'Arduino (notamment les fonctions de mesure du temps). Puisque cela permettra de générer le signal d'horloge au moyen d'un PWM à 50% à la bonne fréquence. Mais cela c'est de la programmation de l'AVR avec écriture directe dans les registres, pas avec une lib Arduino. 200kHz c'est les 16Mhz de l'Arduino diviser par 80, c'est jouable avec un timer et la génération PWM.

Ce qui est caché dernière ce message. La matériel doit anticipé les contraintes de code. Un raccordement optimisé permet de réduire drastiquement le code et garantir la vitesse d'exécution. A l'inverse un raccordement au bol compliquera le code voir rendra la réalisation impossible. (Ici c'est presque le cas pour le clk).

Bonne suite

Delias

[vins86]

bonjour Delias,

Merci pour votre réponse.

Effectivement, je suis en train de refaire les différents câblages en fonction des ports.

Je ne sais pas si vous avez eu l'occasion de lire le programme fait sur le lien précédent envoyé. Mais il à mis ce bout de code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        /* set prescaler so that internal freq is 100kHz
         * clk out is 500kHz => prescaler 5 */
		 //#define I8279_CMD_SET_PRESCALER         (1 << 5)
        write_cmd( I8279_CMD_SET_PRESCALER | 5 );

Donc je suppose que c'est la fréquence qu'il faut pour l'horloge?

Dans le fichier main, il initialise le panel avec ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
void init_panel(){
    DDRB |= 0x07; // address bits for chip selection 0b00000111
    DDRC = 0xFF;  // address bits for board
 
    DDRB |= (1<<3); // A0 out 0b00111000
 
    DDRD |= (1 << 5); //clk out (to 422)
 
 
    // RD & WR lines
    DDRD |= (1 << 3) | (1 << 2);
    PORTD |= (1 << 3) | (1 << 2);
 
    PORTC = (1 << 1);
 
    setup_clk_out();
 
    init_me_buttons();
    init_transition_buttons();
    init_wipe_buttons();
 
    for(uint8_t i=0; i < 4; i++){
        write_d4701a_reset(encoders_rst[i], 0x00);
        write_d4701a_reset(encoders_rst[i], 0xFF);
    }
 
    // support legacy chicp_select()
    // is going to be removed
    PORTC = (1 << 1);
 
}

Je pense que nous pouvons avoir plusieurs informations avec ce code au niveau des ports.

Après le code est prévu pour un programme sur Raspberry, hors je suis plus partie sur un Arduino me semblant plus logique.

Dans l'attente.

Cordialement,

Vincent.

[Delias]

Bonjour Vincent

Non je n'ai lu que la description du projet, pas le code.
Ce n'est pas du Raspberry, mais un STK500 qui est une platine de développement pour les différents microcontrôleurs AVR. On peut entre autre y mettre les différentes tailles de microcontrôleur en boitier DIL de 8 à 40 pattes, la connectique y est mieux foutue et la programmation se fait par ISP ou programmation parallèle ce qui ne nécessite pas un bootloader pré-chargé dans le micro. Matériellement parlant Arduino au départ c'est une version cheap de ces platines en rognant sur la flexibilité.

Le code d'initialisation de l'horloge c'est l'initialisation du TMP en division par 5 car il lui fournis une horloge à 500kHz. Le TMP doit avoir une horloge interne à 100kHz (recommandé) et il divise l'horloge qu'il reçois entre 2 et 50 en fonction d'une valeur qu'on lui donne par cette ligne de code. La génération du signal d'horloge à 500kHz par l'AVR n'est pas indiqué plus que cela. Il y a éventuellement DDRD |= (1 << 5); //clk out (to 422) qui y contribue d'après le commentaire, c'est le début et ce n'est pas suffisant. La suite doit être dans setup_clk_out(); au vu de ce que suggère le nom de la fonction.

L'initialisation des ports c'est ce que je t'explique, c'est du code pour AVR pas pour Pi. En l'état pas utilisable sans modification car les ports utilisés ne sont pas disponible au complet sur les connecteurs de l'Arduino.

Delias

[vins86]

Bonjour Delias,

Merci encore pour vos réponses très précieuses.

Ce n'est pas du Raspberry, mais un STK500 qui est une platine de développement pour les différents microcontrôleurs AVR. On peut entre autre y mettre les différentes tailles de microcontrôleur en boitier DIL de 8 à 40 pattes, la connectique y est mieux foutue et la programmation se fait par ISP ou programmation parallèle ce qui ne nécessite pas un bootloader pré-chargé dans le micro. Matériellement parlant Arduino au départ c'est une version chape de ces platines en rognant sur la flexibilité.

Je ne connaissais pas. Je vais y aller doucement dans le projet. Sinon je vais me perdre. Mais si le projet fonctionne je passerais par un atmega.

Je vais commencé par refaire mon schéma de câblage pour y voir un peu plus clair sur les ports.

La fonction me semble pas très clair. J'ai trouver ce lien : https://www.electronique-mixte.fr/wp...cesseur-78.pdf. Il parle de timer1.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
void setup_clk_out(){
    TCCR1A = (0<<COM1A1)|(1<<COM1A0);
 
    TCCR1A |= (0<<WGM11)|(0<<WGM10);
    TCCR1B |= (0<<WGM13)|(1<<WGM12);
 
    TCCR1B |= (0<<CS12)|(1<<CS10);
    OCR1A = 15;
}

Merci d'avance.

Cordialement,

Vincent.

[Delias]

Bonjour Vincent

L'Arduino Uno utilise un ATMega328, c'est un DIL à 28 pattes qui est aussi utilisable avec le STK500.
L'Arduino Mega 2560 utilise un ATMega2560 qui n'existe pas en DIL car il a trop de pattes (100 au total, le DIL est généralement limité à 40).
L'autre projet, je ne sais pas quel ATMega il utilise, probablement un 40 pattes au vu de l'initialisation des ports.

Après c'est une famille. Le code est très souvent utilisable sur tous avec les adaptations nécessaire. -> donc oui le projet est transposable sur Arduino Mega 2560 (et éventuellement tout juste sur Uno)

Le code de la fonction c'est la configuration du timer1 interne et du module de génération du PWM.
C'est de la programmation AVR, basée directement sur les spécifications des ATMega, comme celle-ci: https://ww1.microchip.com/downloads/..._datasheet.pdf. Le document que tu as en est une explication partielle, il n'y a que les modes PWM de base par rapport à ce que je connais.

Attention ce type de programmation est moyennement compatible avec la surcouche Arduino, car le timer1 est déjà utilisé par la couche logiciel Arduino et il y aura des conflit d'utilisation. Si tu touches à ces registres (TCCR1A, TCCR1B, OCR1A) certaines fonctions Arduino ne fonctionneront simplement plus correctement. Mais le Mega2560 à 4 timers identiques séparés, on peut en utiliser un autre.

La ligne 2 choisi le 2ème mode de la table 17-3. La sortie A du timer 1 va s’inverser à chaque comparaison. Elle perd sa commande par le registre PORTB.
Les lignes 4 et 5 activent le mode 4 "CTC" de la table 17-2, le compteur croit jusqu'à arriver à la comparaison puis est reseté.
La ligne 7 défini la division avant le compteur à 1 (donc compteur actif à la même fréquence que le clk de l'AVR), à chaque clk, la valeur du compteur est incrémenté de 1.
La ligne 8 défini la valeur de comparaison à 15.

La fréquence de sortie est donc de 1/32ème de celle de l'AVR. (1/16 par la comparaison à 15, une division par deux par l'inversion à chaque clk).

Ce code appliqué à l'ATMega2560 fait que c'est la patte PB5 qui recevrait le signal d'horloge ainsi généré. Si on veut aller sur une autre patte, il faut choisir le timer et le comparateur adapté. Chaque timer à 3 comparateurs, donc 12 pattes où cela est possible au total, plus éventuellement celle du timer0 qui est plus simplifié.

Programmation Arduino, versus programmation AVR c'est ma façon de dire que l'on utilise la couche Arduino respectivement que l'on programme directement sur l'AVR sans la couche logiciel Arduino. La programmation AVR est décrite dans les tutos Arduino et le langage C (sauf le premier).

Bonne suite

Delias

[vins86]

Bonjour Delias,

Je ne vais pas cacher que tu m'as perdu.

J'aimerais pouvoir avancer un peu sur les essais. Par où dois-je commencer?

Je refais le schéma de câblage avec

• D0-D7 vers pins 30 à 37 du Mega
• A1-A4 vers pins 22 à 25 du Mega (4 bits faible du port A).
• Pour le clock (+ et -), 2A du AM26LS31CN vers pins 11 (PB5) du Mega.
• Pour le RST (+ et -), 1A du AM26LS31CN, je ne sais pas sur quel pin du Mega est plus adapté.

Dois-je vraiment faire la configuration suivante pour mon projet ou puis-je faire plus simple :

Attention ce type de programmation est moyennement compatible avec la surcouche Arduino, car le timer1 est déjà utilisé par la couche logiciel Arduino et il y aura des conflit d'utilisation. Si tu touches à ces registres (TCCR1A, TCCR1B, OCR1A) certaines fonctions Arduino ne fonctionneront simplement plus correctement. Mais le Mega2560 à 4 timers identiques séparés, on peut en utiliser un autre.

La ligne 2 choisi le 2ème mode de la table 17-3. La sortie A du timer 1 va s’inverser à chaque comparaison. Elle perd sa commande par le registre PORTB.
Les lignes 4 et 5 activent le mode 4 "CTC" de la table 17-2, le compteur croit jusqu'à arriver à la comparaison puis est reseté.
La ligne 7 défini la division avant le compteur à 1 (donc compteur actif à la même fréquence que le clk de l'AVR), à chaque clk, la valeur du compteur est incrémenté de 1.
La ligne 8 défini la valeur de comparaison à 15.

La fréquence de sortie est donc de 1/32ème de celle de l'AVR. (1/16 par la comparaison à 15, une division par deux par l'inversion à chaque clk).

C'est vraiment très technique. Est-ce que la pratique ce fait au niveau code ou électronique? Est-ce qu'il configure les informations par rapport à son installation ou dois-je le faire aussi pour l'arduino?


J'ai l'impression que le clk n'est pas utilisé par les led, mais pour les boutons, les potentiomètres et les displays.

Je suppose que les leds sont génréer avec ce code (sauf erreur de ma part) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
#define DVS8000_ME_COLOR1 0x26
#define DVS8000_ME_COLOR2 0x27
 
void write_color(){
    addr_select(DVS8000_ME_COLOR1);
 
    PORTA = color & 0x3F;
    DDRA = 0xFF;
    PORTD &= ~(1 << 2); //WR
    _delay_us(1);
    PORTD |= (1 << 2); //WR
    DDRA = 0x00;
    _delay_us(2);
 
    addr_select(DVS8000_ME_COLOR2);
    PORTA = (color>>6) & 0x1F;
    DDRA = 0xFF;
    PORTD &= ~(1 << 2); //WR
    _delay_us(1);
    PORTD |= (1 << 2); //WR
    DDRA = 0x00;
}

est-ce que j'ai fait le bon choix des ports?

Dans l'attente.

Cordialement,

Vincent.

[Delias]

Bonsoir Vincent

Je ne suis pas étonné de te perdre. Les explications font appel à la mécanique profonde des micros (le plus proche du matériel) qui est caché par Arduino. Pour ces timers, au lieu de mettre en lumière leur contrôle, les concepteurs d'Arduino ont choisi une configuration et c'est fini on en parle plus.

Une explication pas trop mal ici: LOCODUINO - Les Timers (I)
En fait le cours d'électronique mixte que tu indiquais n'est pas si mal (je l'avais lu trop vite) et il explique le fonctionnement CTC.

Pour les branchements c'est plutôt bon, c'est ce que j'indique plus haut. Mais cela signifie que tu comptes utiliser le timer 1 pour générer la clk. Le Reset sur une sortie il n'y a pas vraiment de préférence.
Le problème c'est que je n'ai jamais réussi à trouver une explication claire de ce qui est utilisé en configuration normale sur ce timer par la couche Arduino et donc ce qui ne marchera plus correctement en configurant autrement le timer 1.

J'ai une habitude, c'est de regrouper les fonctions par port, donc c'est un demi-port qui contrôle A1 à A4, j'aurais mis IOWR, IORD, RST et si possible la CLK sur l'autre moitié du même port. Mais ce n'est pas une obligation.
Il faut aussi prendre en compte les autres E/S dont on a besoin dans le projet pour des connections spécifiques (comme les ports série, SPI, I2C, etc.) Ici c'est à minima la communication de débogage et l'interface future.

Pour la partie que tu indiques très technique, à ce niveau là c'est obligatoire de comprendre sinon la puce ne fait se que l'on souhaite. C'est l'interface entre le code et l'électronique interne du microcontrôleur.
Un microcontrôleur c'est un cœur d’exécution du programme et des périphérique (les ports, les timers, les modules de communication série, le convertisseur ADC etc.). Sur la majorité des périphériques il y a plusieurs fonctionnement possible utilisant les circuits prévus. Le cœur accède à des registres qui sont des sortes d'emplacements mémoires et qui agissent sur la configuration des périphériques.

La fonction setup_clk_out() configure le timer 1 pour diviser l'horloge de l'Arduino par 32 (donc 16MHz / 32 = 500kHz) et le sortir sur la patte ayant la fonction OC1A. Mais en jouant sur les valeurs on peux changer la division, la source de l'horloge (sur certain timer on peut prendre un signal externe), faire du PWM différent etc... Par défaut dans Arduino le timer 1 est configuré en PWM à environ 500Hz dont la valeur est donnée par la fonction analogWrite() soit quelque chose qui peut paraître très différent mais qui au final utilise le même circuit de la puce.
La clk est nécessaire au TMP y compris pour gérer les leds. Car il fait du multiplexage.

Pour le code, c'est là où je décroche, pas que le code soit compliqué, mais c'est qu'il est nécessaire d'avoir l'entier du schéma et des docs sous les yeux, pas le temps ni la motivation de passer tout cela au détail. C'est où il faut commencer à avoir des notes sous la main: PortA c'est ci, Port B c'est cela, le registre xyz du TMP c'est ça, etc.

Ta dernière question, je ne suis pas sur de comprendre, mais si c'est est-ce que le bout de code correspond avec ton branchement. Ce n'est pas le cas.

Ne pas oublier encore le condo de découplage sur le AM26LS31CN (100nF céramique au plus proche des alimentations du circuit)

Bonne suite

Delias

[Jay M]

Le problème c'est que je n'ai jamais réussi à trouver une explication claire de ce qui est utilisé en configuration normale sur ce timer par la couche Arduino et donc ce qui ne marchera plus correctement en configurant autrement le timer 1.

Salut @Delias,

Sun un UNO La puce 328P contient 3 timers (Timer0, Timer1, Timer2) qui sont utilisés au niveau matériel aussi pour contrôler le PWM.
Timer0 contrôle le PWM des pins 5 et 6, Timer1 (16 bits) les pins 9 et 10, Timer2 les pin 3 et 11

Sur une Mega, basée sur un ATmega2560 (et donc différente des ATmega328P des cartes Uno) on aura 6 timers.
Timer0 contrôle le PWM des pins 4 et 13
Timer1 contrôle le PWM des pins 11 et 12
Timer2 contrôle le PWM des pins 9 et 10
Timer3 contrôle le PWM des pins 2, 3 et 5 (16 bits)
Timer4 contrôle le PWM des pins 6, 7 et 8 (16 bits)
Timer5 contrôle le PWM des pins 46, 45 et 44 (16 bits)

(d'autres cartes ont d'autres timers, donc faudra regarder les spécificités)

Pour comprendre ce qu'il se passe il faut regarder la fonction main() standard d'un programme généré par l'IDE.

On voit qu'on importe Arduino.h et que le main() commence par appeler la fonction init() puis initVariant();

Pour la configuration des timers, tout se joue dans cette fonction init() qui est dans le fichier wiring.c. Si vous allez voir le code de cette fonction init(), vous verrez (il y a plein de tests sous formes de directives de compilation pour s'adapter aux différents processeurs) que l'environnement Arduino de base configure les timers de manière minimale:
-> Il initialise le pre-scaler des 3 timers pour diviser l'horloge par 64
-> Timer 0 est configuré en "Fast PWM" alors que Timer1 et Timer 2 (et les autres) sont initialisés en PWM dit "Phase Correct" (ce choix a été fait car il donne une ondulation uniforme).

Pour tout ce qui touche au temps, on dépend (vu l'import) aussi du fichier Arduino.h et d'un paramètre "magique" F_CPU que vous pouvez voir défiler dans la compilation sur l'IDE et qui passera au programme la fréquence d'horloge utilisée.

dans Arduino.h on voit cette définition:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define clockCyclesPerMicrosecond() ( F_CPU / 1000000L )
#define clockCyclesToMicroseconds(a) ( (a) / clockCyclesPerMicrosecond() )
#define microsecondsToClockCycles(a) ( (a) * clockCyclesPerMicrosecond() )

Elle utilise donc le define F_CPU (fréquence d'horloge en MHz) et définit deux macros qui sont ensuite reprises dans les fonctions de timing de base genre millis() ou encore delay(). Par exemple dans le code de wiring.c on va voir cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// the prescaler is set so that timer0 ticks every 64 clock cycles, and the
// the overflow handler is called every 256 ticks.
#define MICROSECONDS_PER_TIMER0_OVERFLOW (clockCyclesToMicroseconds(64 * 256))

// the whole number of milliseconds per timer0 overflow
#define MILLIS_INC (MICROSECONDS_PER_TIMER0_OVERFLOW / 1000)

-> On voit donc bien que 64 est codé en dur et qu'on dépend bien du débordement à 256 ticks pour le temps. On est donc dépendant directement de Timer0 et de sa configuration (horloge à 1/64 et "Fast PWM" ) pour tout ce qui touche au temps et donc il est conseillé de ne pas modifier sa configuration.

Pour le reste, vous connaissez donc la configuration de départ et vous êtes libre de modifier cela comme il vous chante, tout en comprenant bien que si vous modifiez la comportement des timers significativement vous allez alors impacter aussi le PWM ou les librairies qui attendent cette configuration.

En effet, les libraires ne se gênent pas pour utiliser ces autres timers, par exemple:

- Si vous importez la bibliothèque standard "Servo" sur un UNO vous pouvez voir dans le code source que c'est ce timer1 qui est utilisé en premier sur un UNO ou matériel à base de ATmega32U4, mais si vous regardez pour la MEGA on voit que le premier timer utilisé est Timer5

- Si vous utilisez la libraire "Tone", vous pouvez voir dans le code source que le timer utilisé sera Timer2 (à part sur ATmega32U4 où on prend Timer3)

Donc en gros, quand vous utilisez une librairie il est bon de comprendre si elle a des dépendances aux timers. La grande majorité des librairies ne touchent pas à Timer0 puisque l'environnement en a besoin mais peuvent éventuellement modifier la configuration de base des autres Timers ou attendre cette configuration de base. Le programmeur doit donc comprendre les conséquences que cela peut avoir sur le PWM, sur le bon fonctionnement des autres librairies et conflits éventuels.

j'espère que ça clarifie un peu ce qu'il se passe...


PS: Si vous êtes curieux vous pourriez aussi vous demander comment se fait-il que le PWM fonctionne correctement avec un duty cycle de 0 sur les pins 5 et 6 puisque Timer0 contrôle ces pins et qu'il a été réglé en Fast PWM. La réponse c'est que la fonction analogWrite() prend cela en compte et quand le duty cycle est 0 (ou 255) au lieu d'utiliser le PWM le code met directement la pin à LOW ou HIGH.

[vins86]

Bonjour Delias,
Bonjour Jay M,

Je vous remecie de vos réponses.

Pour les branchements c'est plutôt bon, c'est ce que j'indique plus haut. Mais cela signifie que tu comptes utiliser le timer 1 pour générer la clk. Le Reset sur une sortie il n'y a pas vraiment de préférence.
Le problème c'est que je n'ai jamais réussi à trouver une explication claire de ce qui est utilisé en configuration normale sur ce timer par la couche Arduino et donc ce qui ne marchera plus correctement en configurant autrement le timer 1.

J'ai une habitude, c'est de regrouper les fonctions par port, donc c'est un demi-port qui contrôle A1 à A4, j'aurais mis IOWR, IORD, RST et si possible la CLK sur l'autre moitié du même port. Mais ce n'est pas une obligation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
void setup_clk_out(){
    TCCR1A = (0<<COM1A1)|(1<<COM1A0);
 
    TCCR1A |= (0<<WGM11)|(0<<WGM10);
    TCCR1B |= (0<<WGM13)|(1<<WGM12);
 
    TCCR1B |= (0<<CS12)|(1<<CS10);
    OCR1A = 15;
}

D'après les explications de Jay M, le timer1 est bien sur les pins 11 et 12 et la partie de code précédente fait une modification sur le pin 12 (OC1A). Donc dois-je pas mettre le CLK sur PB6 au lieu de PB5 et modifier le pin de IOWR? Je suppose qu'aucune librairie du programme utilisera ou modifiera le timer1. Jay M dit bien de vérifier les librairies importées et je le ferais.

Je pense avoir compris le fait de regrouper les fonctions par port. j'ai donc refait mon schéma de câblage en tableau avec les différentes informations communiquées et analysées. Par contre, est-ce que le fait de mettre le IOWR (pin 12 : PB6) pose problème avec le timer1?



Je comprend également que la fonction setup_clk_out() permet de configurer le timer1 avec les informations attendues du TMP, sauf erreur de ma part.

Je reste dans le flou concernant les ports dans le code envoyé précédent le init_panel().

En théorie, peut-on prétendre que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 DDRB |= 0x07; // address bits for chip selection 0b00000111

correspond à la nappe D0-D7 et que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRC = 0xFF;  // address bits for board

correspond à A1-A4 ou pas du tout?


Je suis actuellement en train d'analyser le code faite pour son AVR et mon câblage.

Ne pas oublier encore le condo de découplage sur le AM26LS31CN (100nF céramique au plus proche des alimentations du circuit)

Effectivement, je vais les commander (Est-ce obligatoire pour faire les essais ?) . Au passage, y a t-il des achats à prévoir en plus pour la réalisation du projet?

Je n'ai pas compris cette partie:

Il faut aussi prendre en compte les autres E/S dont on a besoin dans le projet pour des connections spécifiques (comme les ports série, SPI, I2C, etc.) Ici c'est à minima la communication de débogage et l'interface future.

En plus de la connexion de la nappe, il y aura un seulement un shield Ethernet. Mais on verra en deuxième phase.

Pour le code, c'est là où je décroche, pas que le code soit compliqué, mais c'est qu'il est nécessaire d'avoir l'entier du schéma et des docs sous les yeux, pas le temps ni la motivation de passer tout cela au détail. C'est où il faut commencer à avoir des notes sous la main: PortA c'est ci, Port B c'est cela, le registre xyz du TMP c'est ça, etc.

Y aura-t-il une possibilité de faire essai de code de façon individuel pour savoir? Par exemple, faire sur les Datas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
0b00111111, // 0
    0b00000110, // 1
    0b01011011, // 2
    0b01001111, // 3
    0b01100110, // 4
    0b01101101, // 5
    0b01111101, // 6
    0b00000111, // 7
    0b01111111, // 8
    0b01101111 // 9

Dans l'attente de vous lire.

Cordialement,

Vincent.

[Delias]

Bonsoir Vincent

D'après les explications de Jay M, le timer1 est bien sur les pins 11 et 12 et la partie de code précédente fait une modification sur le pin 12 (OC1A). Donc dois-je pas mettre le CLK sur PB6 au lieu de PB5 et modifier le pin de IOWR? Je suppose qu'aucune librairie du programme utilisera ou modifiera le timer1. Jay M dit bien de vérifier les librairies importées et je le ferais.

Moi sur le schéma de l'Arduino Mega je lis, OC1A -> PB5 -> Arduino 11 et OC1B -> PB6 -> Arduino 12.

Je pense avoir compris le fait de regrouper les fonctions par port. j'ai donc refait mon schéma de câblage en tableau avec les différentes informations communiquées et analysées. Par contre, est-ce que le fait de mettre le IOWR (pin 12 : PB6) pose problème avec le timer1?

Tant que le comparateur n'est pas activé (COM1B1 = 0, et COM1B0 = 0), la sortie PB6 / 12 est indépendant du timer.

Je comprend également que la fonction setup_clk_out() permet de configurer le timer1 avec les informations attendues du TMP, sauf erreur de ma part.

Elle ne fait que configurer la génération du signal d'horloge à 500kHz pour le signal clk. La configuration du TMP (la division par 5) est réalisé par cette ligne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        /* set prescaler so that internal freq is 100kHz
         * clk out is 500kHz => prescaler 5 */
		 //#define I8279_CMD_SET_PRESCALER         (1 << 5)
        write_cmd( I8279_CMD_SET_PRESCALER | 5 );

En théorie, peut-on prétendre que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 DDRB |= 0x07; // address bits for chip selection 0b00000111

correspond à la nappe D0-D7 et que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DDRC = 0xFF;  // address bits for board

correspond à A1-A4 ou pas du tout?

// address bits for chip selection est à ma compréhension les lignes A1-A4. DDRC = 0xFF; // address bits for board 8 bits donc la seule chose qui correspond est D0-D7, mais cela ne correspond pas à l'extrait de code du message #55, serait-ce autre chose que le projet fait (ou alors il y a plusieurs nappes de fils pour les différentes partie du pupitre ?)

Oui le condensateur de découplage est obligatoire même en test (et généralement il est plus important en test qu'en montage final du fait des connections électriques sont souvent plus longues et avec plus de connectique).

Le shield Ethernet va utiliser quelles connexions de l'Arduino ? Il serait mal venu que les lignes utilisées le soit également pour la communication avec le bus.

Pour l'essai de code cela serait celui du message #55 dont il faut vérifier la concordance avec la doc du TMP et ajuster les ports selon les réalisations. PORTA -> PORTC; PORTD &= ~(1 << 2). //WR -> PORTB &= ~(1 << 6); //WR, etc.
EDIT: je me demande si ce code du message 55 n'est pas celui qui gère les signaux BUSL que j'indiquais dans le message #41 et qui d'après les indications de l'auteur du l'autre projet sert au contrôle de la couleur les leds utilisées (par groupe correspondant à 1/2 TMP) soit l'une soit l'autre sur un groupe, mais pas de mélange ou les deux couleurs en même temps.

Bonne suite

Delias

[vins86]

Bonsoir Delias,

Moi sur le schéma de l'Arduino Mega je lis, OC1A -> PB5 -> Arduino 11 et OC1B -> PB6 -> Arduino 12.

Effectivement, c'est une erreur de ma part. A force, je me suis perdu.

Tant que le comparateur n'est pas activé (COM1B1 = 0, et COM1B0 = 0), la sortie PB6 / 12 est indépendant du timer.

D'accord, je ne l'activerais pas.

// address bits for chip selection est à ma compréhension les lignes A1-A4. DDRC = 0xFF; // address bits for board 8 bits donc la seule chose qui correspond est D0-D7, mais cela ne correspond pas à l'extrait de code du message #55, serait-ce autre chose que le projet fait (ou alors il y a plusieurs nappes de fils pour les différentes partie du pupitre ?)

D'accord, non, c'est toujours la même nappe de 60pins, j'ai modifier mon schéma en fonction des différentes remarques.

Oui le condensateur de découplage est obligatoire même en test (et généralement il est plus important en test qu'en montage final du fait des connections électriques sont souvent plus longues et avec plus de connectique).

Je vais les commander, il en faut combien approximativement?

Le shield Ethernet va utiliser quelles connexions de l'Arduino ? Il serait mal venu que les lignes utilisées le soit également pour la communication avec le bus.

Les shield internet, utilise les connexion 50,51,52 sur le Mega, et on ne doit pas utiliser le pin 10 :

Arduino communicates with both the W5100 and SD card using the SPI bus (through the ICSP header). This is on digital pins 10, 11, 12, and 13 on the Uno and pins 50, 51, and 52 on the Mega. On both boards, pin 10 is used to select the W5100 and pin 4 for the SD card. These pins cannot be used for general I/O. On the Mega, the hardware SS pin, 53, is not used to select either the W5100 or the SD card, but it must be kept as an output or the SPI interface won't work.

Note that because the W5100 and SD card share the SPI bus, only one can be active at a time. If you are using both peripherals in your program, this should be taken care of by the corresponding libraries. If you're not using one of the peripherals in your program, however, you'll need to explicitly deselect it. To do this with the SD card, set pin 4 as an output and write a high to it. For the W5100, set digital pin 10 as a high output.

Donc il va falloir que je modifie encore mon schéma, mais on verra plus tard. pour l'instant, j'en ai pas besoin.

je me demande si ce code du message 55 n'est pas celui qui gère les signaux BUSL que j'indiquais dans le message #41 et qui d'après les indications de l'auteur du l'autre projet sert au contrôle de la couleur les leds utilisées (par groupe correspondant à 1/2 TMP) soit l'une soit l'autre sur un groupe, mais pas de mélange ou les deux couleurs en même temps.

Je suis d'accord, il peut y avoir qu'une seul couleur d'allumée soit jaune ou rouge.

Dans l'attente.

Cordialement,

Vincent