Le tableau de commande de Mars Bleu

[Mars Bleu]

      QUATRIÈME CHALLENGE: commander des leds à partir de Lua


Le premier challenge consistait à extraire des données d'Orbiter avec un script Lua. Ce challenge fait la deuxième partie du transfert de données vers la UNO elle-même programmée pour piloter les lumineux.

Le grand principe est qu'un script Lua doit fonctionner dans Orbiter, et échanger des données avec la UNO contenant le sketch qui les traite.

Il a fallu que je remette le nez dans le Web pour trouver quelque chose ("the nose buried in documentation" comme j'ai pu lire). C'est Widdernix dans le forum américain d'Orbiter qui m'a donné la solution dans le fil "talking with serial devices". Voir à: http://orbiter-forum.com/showthread.php?t=17847

Pour échanger des données, on a besoin d'une librairie, luars232.dll. J'ai cherché six semaines durant comment y accéder, avant de trouver qu'il fallait simplement mettre cette dll dans le répertoire d'Orbiter. Une fois cette dll bien positionnée, la commande rs232=require("luars232") ne faisait  plus planter le script Lua.
Nota: en ce qui me concerne, le plantage d'un script Lua sur Orbiter est tout à fait discret. En fait, on s'en aperçoit lorsque le défilé des note:set_text()ne fige plus à l'endroit du plantage présumé.

Après quelques mises au point, j'ai essayé le sketch Arduino suivant sur ce montage:

Code: [Select]

byte dataPin=2;
byte latchPin=3;
byte clockPin=4;
byte data=255;
byte byte1;


void setup()
  {
    pinMode (dataPin,OUTPUT);
    pinMode (latchPin,OUTPUT);
    pinMode (clockPin,OUTPUT);
    Serial.begin(9600);
  }
 
void loop()
{

    if (Serial.available()>0)
    {
    byte1=Serial.read();
    digitalWrite(latchPin,LOW);
    shiftOut(dataPin, clockPin, LSBFIRST, byte1);
    digitalWrite(latchPin, HIGH);

    }

   delay(150);
}

Le script Lua associé est le suivant:

Code: [Select]

note = oapi.create_annotation()
note:set_pos (0.35,0.1,0.8,0.95)
note:set_colour ({r=0.9,g=0.5,b=0.2})


rs232=require("luars232")
local port_name="COM4"
local e,p=rs232.open(port_name)
if e ~= rs232.RS232_ERR_NOERROR then
term.out('',string.format("can't open serial port '%s', error: '%s'\n", port_name, rs232.error_tostring(e)))
    return
end
-- set port settings
assert(p:set_baud_rate(rs232.RS232_BAUD_9600) == rs232.RS232_ERR_NOERROR)
assert(p:set_data_bits(rs232.RS232_DATA_8) == rs232.RS232_ERR_NOERROR)
assert(p:set_parity(rs232.RS232_PARITY_NONE) == rs232.RS232_ERR_NOERROR)
assert(p:set_stop_bits(rs232.RS232_STOP_1) == rs232.RS232_ERR_NOERROR)
assert(p:set_flow_control(rs232.RS232_FLOW_OFF)  == rs232.RS232_ERR_NOERROR)

byte1='U'
err, len_written = p:write(string.char(byte1))
  end

note:set_text('Longueur écrite='..len_written)
proc.wait_sysdt(1)

assert(p:close() == rs232.RS232_ERR_NOERROR)-- this closes the COM

note:set_text('End of program')
proc.wait_sysdt(1)
note:set_text('  ')
proc.wait_sysdt(1)

Et là, VICTOIRE, j'ai réussi à écrire dans le registre à décalage et à afficher un octet sur 8 leds. Le caractère 'U' correspondant à 85, c'est-à-dire 01010101 en binaire, soit une led sur deux. Changeons le contenu de la variable byte1, et les leds s'allumeront autrement.

Je vous laisse digérer tout ceci, avant de vous montrer un petit TP dont l'objet sera d'afficher le machmètre
d'un XR2.

[Mars Bleu]

Pour ceux qui suivent, et tous les autres qui dorment au fond de la classe  , voici le petit TP
que je vous annonçais il y a quelques jours:

Pour ce faire, j'ai étoffé mon montage provisoire en adjoignant une bredboard supplémentaire comprenant deux afficheurs 7 segments branchés sur un 4543 ( entrée 4 bits=>afficheur 7 segments). Avec ces deux afficheurs, je voulais donc avoir un machmètre, en allant chercher la valeur par:

                                                      m=v:get_machnumber()

Puis avec une mise en forme, l'envoyer  par le port USB à la UNO qui la renverrait aux registres de sortie.

Ci dessous, le script Lua:

Code: [Select]

function send_data(n1,n2)
  e,p=rs232.open(port_name)
  if e ~= rs232.RS232_ERR_NOERROR then
    term.out('',string.format("can't open serial port '%s', error: '%s'\n", port_name, rs232.error_tostring(e)))
      return
  end
  -- set port settings
  assert(p:set_baud_rate(rs232.RS232_BAUD_9600) == rs232.RS232_ERR_NOERROR)
  assert(p:set_data_bits(rs232.RS232_DATA_8) == rs232.RS232_ERR_NOERROR)
  assert(p:set_parity(rs232.RS232_PARITY_NONE) == rs232.RS232_ERR_NOERROR)
  assert(p:set_stop_bits(rs232.RS232_STOP_1) == rs232.RS232_ERR_NOERROR)
  assert(p:set_flow_control(rs232.RS232_FLOW_OFF)  == rs232.RS232_ERR_NOERROR)
  err, len_written = p:write(string.char(n2)..string.char(n1))
  assert(p:close() == rs232.RS232_ERR_NOERROR)-- this closes the COM
end

note = oapi.create_annotation()
note:set_pos (0.35,0.1,0.8,0.95)
note:set_colour ({r=0.9,g=0.5,b=0.2})


intro = "Machmètre sur 2 displays 7 segments"

note:set_text(intro)
proc.wait_sysdt(1.0)
v=vessel.get_interface('XR2-01')
rs232=require("luars232")
port_name="COM4"



repeat
  alt=oapi.get_altitude()
  mach = v:get_machnumber()
  mach_display=math.floor(10*mach)
  centaine=math.floor(mach_display/100)
  mach_display=mach_display-100*centaine
  dizaine=math.floor(mach_display/10)
  mach_display=mach_display-10*dizaine
  unite=mach_display
  char1=unite+16*dizaine
  char2=centaine
  note:set_text(char2.."  "..char1.."  "..centaine..dizaine..unite)
  if unite~=old_unite then
    send_data(char1, char2)
    old_unite=unite
  end
  proc.skip()
until alt>300000 -- sortie dès qu'on atteint 300 kms d'altitude

note:set_text('Longueur écrite='..len_written)
proc.wait_sysdt(1)


note:set_text('End of program')
proc.wait_sysdt(1)
note:set_text('  ')
proc.wait_sysdt(1)


Le sketch Arduino reçoit les données en boucle, envoyées par le script Lua, et les envoie dans les
registres à décalage pilotant les displays 7 segments par l'intermédiaire des 4553:

Code: [Select]

int dataPin=2;
int latchPin=3;
int clockPin=4;
int data=255;
byte octet1;
byte octet2;



void setup()
  {
    pinMode (dataPin,OUTPUT);
    pinMode (latchPin,OUTPUT);
    pinMode (clockPin,OUTPUT);
    Serial.begin(9600);
  }
 
void loop()
{

    if (Serial.available()>0)
    {
    octet1=Serial.read();
    octet2=Serial.read();
    digitalWrite(latchPin,LOW);
    shiftOut(dataPin, clockPin, LSBFIRST, octet1);
    shiftOut(dataPin, clockPin, LSBFIRST, octet2);
    digitalWrite(latchPin, HIGH);

    }

   delay(150);
}

On lance un SCN contenant l'ordre d'accès au script LUA, et on peut suivre la valeur des Machs
sur les deux afficheurs numériques 7 segments.

Envoyer des données d'Orbiter aux registres de sortie m'est désormais possible. Cela signifie aussi
que je peux synchroniser le simpit avec l'état du Xr2 au lancement du scénario.

Tout ceci est encore assez provisoire et expérimental. Dans mon prochain post, je vous exposerai comment j'ai optimisé ces bouts de code de façon simple.



 

[Bibi Uncle]

Continue Mars Bleu! Ton projet avance bien et j'adore lire les avancements au fur et à mesure!

Je suis plus ou moins sûr de comprendre la mise en forme que tu fais avant de l'envoyer à l'Arduino. Tu n'aurais pas pu faire un printf (ou la fonction équivalente en Lua, je n'ai jamais programmé avec ce langage) afin d'obtenir un string déjà formatée ? Ensuite, il suffirait d'envoyer les caractères les uns après les autres par UART et voilà. Dans ton code, tu sembles essayer de calculer manuellement les caractères nécessaires alors qu'une fonction standard aurait pu faire le travail à ta place.

[Mars Bleu]

  Merci, Bibi Uncle pour tes encouragements.
 J'ai encore plein d'avancements en réserve, tout en continuant à souder, découper, assembler, programmer.

Pour la mise en forme, j'ai fait en mode "artillerie lourde". Pour être plus subtil, j'ai demandé à un de mes fistons de me faire quelque chose, et il m'a pondu un bout de code que je n'ai pas encore eu le temps de
décortiquer. Je te le poste dès que je rentre à la maison (je ne l'ai pas pour l'instant).

[Mars Bleu]

Complément d'information:
Le principe que je mets en oeuvre pour la mise en forme est le suivant: on a besoin de quatre bits
pour piloter un 4553. Quatre bits, c'est un demi-octet, donc, avec un octet, je peux piloter deux
4553. C'est pour ça que je mets les dizaines avec un coeff de 16 (décalage des bits de quatre rangs).
Ainsi, je transmets dizaine et unités dans un seul registre à décalage 74HC595.

Je ne sais pas si je suis bien clair....

[Bibi Uncle]

Ah d'accord je comprends. Ça me semble légitime comme technique

[Mars Bleu]

J'envoie un dernier chapitre sur la transmission des données entre l'ordinateur et la carte Arduino.
A mes yeux, c'est assez important, c'est pour ça que j'insiste un peu.

En fait, j'ai repris ce qui figure dans mes précédents posts, mais avec un peu de mises en forme,
et de séparation des éléments principaux.

En Lua, on doit en premier lieu ouvrir le port. J'ai appelé cette fonction: widdernixopen()

Code: [Select]

function widdernixopen()
     e,p=rs232.open(port_name)
      if e ~= rs232.RS232_ERR_NOERROR then
  note:set_text('Problème...')
  proc.wait_sysdt(1.41)
              return
      end
  -- set port settings
    assert(p:set_baud_rate(rs232.RS232_BAUD_9600) == rs232.RS232_ERR_NOERROR)
    assert(p:set_data_bits(rs232.RS232_DATA_8) == rs232.RS232_ERR_NOERROR)
    assert(p:set_parity(rs232.RS232_PARITY_NONE) == rs232.RS232_ERR_NOERROR)
    assert(p:set_stop_bits(rs232.RS232_STOP_1) == rs232.RS232_ERR_NOERROR)
    assert(p:set_flow_control(rs232.RS232_FLOW_OFF)  == rs232.RS232_ERR_NOERROR)
end

En deuxième lieu, la fermeture du port:

Code: [Select]

function widdernixclose()
    assert(p:close() == rs232.RS232_ERR_NOERROR)-- this closes the COM
end

Entre les deux (ouverture et fermeture) Lua doit envoyer les données vers Arduino. Elles soit sont contenues dans un tableau, ou bien en valeurs discrètes. Dans le cas d'un tableau, j'ai mis au point:

Code: [Select]

function init_data(data,start,width)
for i=start,width do
high_byte=math.floor(data[i]/256)
low_byte=data[i]-high_byte*256
err,len_written=p:write(string.char(high_byte)..string.char(low_byte))
end
end
J'ai mis dans ce tableau les valeurs donnant la position des auxiliaires dits APU (gear, airbrake,
baydoors, etc...). Cela permet de transmettre leur état, que ce soit en position déployée, rétractée ou intermédiaire, en vue de synchroniser les lumineux pilotés par l'Arduino et l'état logique de  l'engin chargé dans le fichier .scn.

Il y a bien sûr des données additionnelles (de plus en plus, à mesure que le cockpit s'amplifie). Pour les transmettre, j'ai écrit la fonction: init_status()
Pour l'instant, il y a trois valeurs int à transmettre, soit 6 octets supplémentaires:

Code: [Select]

function init_status()

        --envoi sur deux octets de la valeur SIPOstatus contenant l'état des 12 switches APU (dont l'APU lui même)
high_byte=math.floor(SIPOstatus/256)
low_byte=SIPOstatus-high_byte*256
err, len_written = p:write(string.char(high_byte)..string.char(low_byte))

        --envoi sur deux octets de la valeur SIPOtransit_status contenant l'état de position des 12 auxiliaires APU
high_byte=math.floor(SIPOtransit_status/256)
low_byte=SIPOtransit_status-high_byte*256
err, len_written = p:write(string.char(high_byte)..string.char(low_byte))

        --envoi sur deux octets de la valeur Miscstatus contenant l'état logique des RCS (OFF/ROT/LIN), ainsi que l'état
        Docké ou non du XR2. Il reste encore 13 bits dispos dans cette valeur
high_byte=math.floor(Miscstatus/256)
low_byte=Miscstatus-high_byte*256
err, len_written = p:write(string.char(high_byte)..string.char(low_byte))
end

Dans le script Lua, toutes ces fonctions sont appelées par:   
   widdernixopen()
   init_data(position,3,18)—transmission du tableau position[]
   init_status()
   widdernixclose()

Du côté de l'Arduino, , on doit recevoir ce qui est en provenance du sketch Lua. Un tableau de valeurs:

Code: [Select]

for (byte i=3;i<19;i++)
   {
//réception des données envoyées par Orbiter/Lua-----2*16=32 octets--------
      data=get_data(data);
      Pos[i]=data;
   }
Les données additionnelles:

Code: [Select]

//réception des données envoyées par Orbiter/Lua-----2 octets+les 32 déjà extraits---34 octets
    data=get_data(data);
    Switch_status=data;
 
//réception des données envoyées par Orbiter/Lua-----2 octets+les 34 déjà extraits---36 octets
    data=get_data(data);
    Transit_status=data;

//réception des données envoyées par Orbiter/Lua-----2 octets+les 36 déjà extraits---38 octets
    data=get_data(data);
    Miscstatus=data;
La fonction de réception et de transformation en int est:

Code: [Select]

  unsigned get_data(unsigned int value)
  {

    // réception des deux octets:
    byte high_byte=Serial.read();
    byte low_byte=Serial.read();

    //reconstitution de la valeur sur 2 octets
    value=256*high_byte+low_byte;
    return value;
  }//fin get_data()

J'ai dû me pencher sur la fonction réciproque: c'est-à-dire faire envoyer des données de l'Arduino vers Lua. En effet, le buffer d'entrée de la Leonardo ou de la Uno n'est que de 64 octets, ce qui n'est pas beaucoup. Si on a des paquets de données supérieurs à 64 octets, l'idée est de pouvoir envoyer un premier paquet, attendre une réponse, puis d'envoyer la suite.

Pour ce faire, dans le script Lua, j'initialise une variable: data_read="Z", et j'ai écrit une nouvelle fonction, la fonction copythat()

Code: [Select]

function copythat()
read_len=1
err, data_read, size=p:read(read_len)
end

Cette fonction va lire un octet en provenance de la carte Arduino. La valeur data_read ne va plus contenir "Z", mais la valeur envoyée par la carte Arduino, donnant un signal pour remplir de nouveau le petit buffer de l'Arduino avec de nouvelles données.

Voilà, voilà, j'espère que vous n'êtes pas trop J'ai essayé de faire léger!!

Dans un prochain post, je vous parlerai de l'assemblage de mes modules Parallel Input Serial Output. Il y aura plus d'illustrations!!

[jacquesmomo]

Voilà, voilà, j'espère que vous n'êtes pas trop J'ai essayé de faire léger!!

[Mars Bleu]

 JacquesMomo:

J'aime bien la Coccinelle, même quand elle est vaseuse!
Et aussi les smiley "hors forum" que tu nous déniches

[Mars Bleu]

CINQUIÈME CHALLENGE: construire les cartes PISO et les circuits d'élaboration de signal

Etant donné le nombre de raccourcis clavier du Xr2, et la nécessité d'être à l'aise, j'ai assemblé deux cartes, l'une supportant six circuits 74HC165, et l'autre douze circuits 74HC165. Cela me donne une capacité de traitement de 8x18=144 switches et boutons poussoirs.
Associées à ces deux cartes, les circuits d'élaboration de signal permettent d'envoyer 0 ou 5volts aux entrées des 74HC165:
                                Pas pu faire mieux pour le shéma...

Si l'interrupteur est ouvert, pas de tension, la sortie Signal PISO est à zéro volts.
Si l'interrupteur est fermé, on a 5 volts aux bornes de la résistance, parcourue par un courant de 0.5 mA. La sortie Signal PISO est à 5 volts.

Assembler de telles cartes est plus vite écrit que fait, car c'est un travail minutieux de soudage et, surtout, de vérifications (câblage correct, continuités électriques). Du boulot de neurochirurgien. Tout n'a pas été évident dès  le départ et il a fallu faire des changements d’organisation en cours de route.

Ensuite, une fois toutes les vérifications effectuées, j'ai fait les premières mises sous tension. Bien entendu, rien ne marchait comme prévu. De plus, en cas de disfonctionnement, il faut toujours se poser la question: est-ce mon montage, ou bien le programme qui l'anime?

Ci-dessous, la carte à douze 74HC165 et quatre groupes de 24 circuits d'élaboration de 5 volts. On relie l'ensemble avec des nappes à 26 pôles.

               

Une fois ce montage effectué, je me suis aperçu qu'il fallait installer les prises 26 pôles sur le fond du module, afin de pouvoir brancher/débrancher plus facilement. J'ai donc rajouté le petit panneau du fond, et les câblages qui vont bien (là, c'est mon montage à six 74HC165):

               

Une fois repliées, les deux platines forment un module que je peux installer dans un rack de hauteur 3U.
Si les modules dont on a besoin ne tiennent pas dans un seul rack, on peut en empiler autant qu'on veut pour faire une baie qu'il faudra ventiler.

Dans la mise au point de mes cartes PISO, j'ai eu pas mal de galères qui consistaient essentiellement en des soudures sèches (ne laissant pas passer le courant). J'ai eu aussi un tout petit morceau de métal qui s'était coincé entre une piste 5 volts et une autre piste LATCH. LATCH étant toujours à HIGH, plus moyen de lire les registres qui restaient verrouillés en permanence. J'ai passé un Dimanche après midi dans son entièreté à chercher avant de finir par trouver.
Ce n'est pas parce qu'une carte fonctionne correctement toute seule qu'elle marchera correctement associée à une autre carte du même type. Par exemple, si l'on inverse LATCH et CLK sur deux cartes, le fonctionnement des deux cartes va être parfaitement erratique.

Attention au sens de montage des circuits intégrés. A la mise sous tension, le fusible 5 volts a sauté immédiatement. Une mesure d'intensité avec un seul circuit 74HC165 a donné 2,4 Ampères! Après investigation, je me suis rendu compte que je les avais mis à l'envers sur leur support. Une fois tout remis comme il fallait, l'intensité absorbée était infiniment moins importante, tout à fait compatible avec le calibre du fusible.

Une fois mes 18 registres PISO correctement câblés, il a fallu mettre en place le sketch Arduino pour cadencer la scrutation des 144 entrées, et mettre les valeurs binaires associées dans un tableau[ ] afin de pouvoir les exploiter. (Cf #17)

[Kerguelen]

Jolie travaille ! Je soutiens ton projet, j'avais une idée un peu semblable pendant une certaine période mais, décidément, j'imagine que mon apprentissage en elec n'est pas assez poussé ahah... 
Bon courage pour la suite! 

[Mars Bleu]

 Merci, Kerguelen, et bienvenue sur le fofo!
J'alimente ce fil pour donner des idées aux "simpinautes".

Bon courage pour la suite! 

Oui, des fois, ya besoin. En ce moment, je peine sur des circuits
comprenant des encodeurs rotatifs.

[nulentout]

Hé bé, tout ce PATAKÈSSSS me rappelle l'époque où je créais mon propre tableau de bord. Disposer de 255 entrées/sorties posait les mêmes problèmes de connectique et surtout d'encombrement. Je vois que notre copain avance de façon magistrale, et je m'en réjouis. Il démontre une fois de plus le plaisir qui émerge forcément d'un projet aussi ambitieux, quand on arrive à faire "tourner" des solutions qui après coup peuvent sembler à certains évidentes, mais qui imposent au concepteur des heures de recherche. 
Félicitations cher copain, tes élucubrations vont certainement inciter des internautes à te suivre sur cette voie passionnante de la création.  Chapeau bas ... je le pense vraiment : Môamôa.

[jacquesmomo]

200 ^ème karma pour Nulentout (donné par moi !)  ^{Bien mérité !!!}

[nulentout]

HHHYYYYYOOOOUUUUUPPPPPYYYYYY, ça fait un compte rond !
Plus que 32 de retard, je vais te rattraper à donf Môamôa ! 

[Mars Bleu]

Merci à tôatôa, Nulentout pour ton élogieux #37.
Et aussi:

...quand on arrive à faire "tourner" des solutions qui après coup peuvent sembler à certains évidentes, mais qui imposent au concepteur des heures de recherche. 

Ah oui, alors; je viens de passer un mois de recherches pour une solution technique( ) . Et, enfin
                                          j'ai pu aboutir!
                                                                Ça fait du bien!

Du coup, ça va me faire une réserve supplémentaire d'"élucubrations" que je vous garde bien au chaud
avant de servir...

Et puisqu'on parle de karmas, voici pour Nulentout (comme ça, plus de compte rond avant 300 , eet aussi pour Jacquesmomo, un autre karma. Làààà...

[Mars Bleu]

Il est grand temps de continuer mes élucubrations: on s'accroche, les gars!

Avant de parler des modules SIPO, il faut que j'évoque l'ensemble des servitudes liées à la bonne marche de mon environnement. Il fallait bien sûr que ces servitudes soient mises en rack, tout comme les autres modules.


                PREMIÈRE SERVITUDE: L'ALIMENTATION ELECTRIQUE

Dès que j'ai eu plus d'un module à alimenter électriquement, j'ai vu qu'il fallait une alimentation électrique digne de ce nom. Il me fallait du 5 volts pour les modules PISO et SIPO, et du 8 volts pour la carte Arduino. J'ai trouvé que la meilleure alim était celle d'un PC, qui fournit du 5 volts et du 12 volts. Il a simplement fallu changer la petite prise fournissant le 12v et le 5v afin de pouvoir connecter cette alim de PC à mon répartiteur d'alimentation.

Le 12 volts passant par un L7808 est mis à 8 volts, ce qui est tout à fait convenable pour alimenter la carte Arduino.

J'ai utilisé une plaque 100x160 mm à bandes de cuivre pour pouvoir faire une bonne répartition du 5 volts pour chacun de mes modules. J'ai bien sûr installé des fusibles tant pour le 5 volts que pour le 12 volts. A juste raison, car il est arrivé souvent que je les transforme en chaleur et en lumière…



Leur emplacement est à revoir, car situés sur la carte, il faut tout débrancher et extraire la carte du rack pour pouvoir les remplacer. Je songe à des porte-fusibles en face avant.

Pour avoir une référence de clignotement de environ 1hz, et aussi me donner la possibilité de multiplexage, j'ai réalisé des petits circuits oscillants avec des 555. Le 1hz servira à piloter le clignotement de certaines leds, en fonctions des besoins. Le but étant de simplifier le sketch tournant dans l'Arduino. J'ai installé cette petite carte sur la carte d'alimentation pour gagner de la place dans mon rack.

Pour la face avant des modules, j'ai fait des projets que je voudrais faire réaliser en fablab, avec gravure laser, de façon à faire du rétroéclairé. Mais ça sera traité plus tard...

Dans un prochain post je vous expliquerai comment j'ai installé la petite carte Uno, (remplacée ensuite par une Leonardo) dans mon rack.

[Mars Bleu]

Scusez, j'ai pas eu le rythme, ayant dû m'éloigner  quelques jours....

Il est temps d'aborder la....

                   DEUXIÈME SERVITUDE: LE SUPPORT POUR LA carte Arduino.

On peut y installer indifféremment une UNO ou une Léonardo. L'avantage de la Léonardo est qu'elle permet
d'envoyer des caractères sans configuration particulière, contrairement à la UNO.


J'avais donc besoin d'un support facile à utiliser pour la Leonardo, qui est assez petite. J'ai trouvé une solution qui m'a a parue pratique, en soudant des broches sur une plaque 100x160 à pastilles de cuivre aux bons endroits pour pouvoir enficher la Leonardo dessus. Ça forme un module que je peux ensuite installer dans mon rack.

Les broches au-delà de la broche 13 m'on donné du fil à retordre, car l'espacement par rapport aux autres broches n'est pas du 2,54 mm.
Il restait à réaliser le câblage rampant et à souder les connecteurs pour relier la Leonardo à son alimentation électrique et aux modules supportant les registres à décalage.

Sur la face avant de ce module, j'ai mis, outre des leds matérialisant la présence du 5 et 8 volts, des groupes de leds pour LATCH, CLK et DATA SIPO/PISO, figurant la circulation des données et la pulsation commandant les registres. Pour ralentir tout cela afin de le rendre visible, j'ai ajouté six circuits décompteurs CD 4020 dans un coin de la carte supportant la Léonardo.

                           Ci dessous, la carte supportant le microcontrôleur Arduino:


Les fils bleus sont DATA, jaunes=>LATCH, gris=>CLK. J'ai choisi ces couleurs au hasard, mais je m'y tiens.


Dans un prochain post, je reprendrai le cours de mes constructions en vous parlant de mes modules SIPO, utilisant des 74HC595, afin de multiplier les sorties. Bonne lecture!

[antoo]

Génial!

[jacquesmomo]

Captivant.... (chuis jaloux !) 

[Mars Bleu]

Merci, les gars. Ça fait plaisir d'avoir du retour. Je vois aussi le compteur des vues qui tourne,
donc il y a du monde qui vient voir, même s'il ne dit rien.

J'ai trouvé un site qui permet de dessiner des schémas en ligne. C'est : https://easyeda.com/
Je le trouve bien fait. Il faut juste ouvrir un compte si on veut sauvegarder ses créations.
Ça va me permettre de documenter tous mes circuits.

Allez, je retourne à la préparation de mes élucubrations....

[jacquesmomo]

Merci, les gars. Ça fait plaisir d'avoir du retour. Je vois aussi le compteur des vues qui tourne,
donc il y a du monde qui vient voir, même s'il ne dit rien.

Voui, je suis tout ça...

C'est bien qu'il y ait encore des passionnés comme toi (et nous) car il me semble que ça devient plus rare.... 

[antoo]

Ouép, je confirme. Ça s'endort un peu...

[Mars Bleu]

C'est un peu pour ça que je me suis décidé à partager l'ensemble de mes travaux:
pour donner envie, avec quelques solutions techniques qui peuvent être autant de
pistes de réflexion pour faire mieux.
Faisons vivre Orbiter avec de beaux add-on et/ou de belles réalisations!!

[jacquesmomo]

  C'est mon avis et je le partage !!!!