Architecture d'interfaçage des E/S

[HertZ]

Bonjour à tous,

Réflexions sur l'architecture côté entrées et sorties. Pour l'instant j'utilise l'option 1 mais pas à grande échelle. J'en appelle à votre expérience et vous partage mes pistes de réflexion. Chaque option a ses avantages et inconvénients je pense. Le plus important pour moi c'est d'arriver à conserver des temps de traitement courts. Le plus de travail devrait alors être délégué au PC et les cartes d'interfaçage ne feraient que lire et écrire ses entrées sorties et les transmettres. Le logiciel permettrait de programmer qu'elles E/S affectent quelles variables du simu. Ce serait un peu réinventer la roue mais SIOC me parait un peu lourd et lent. Il y a mobiflight ou airmanager mais on est contraint d'utiliser un arduino mega alors que l'on a aujourdh'ui des microcontolleurs plus puissants et tout aussi abordables. En plus cela permettrait de se passer de FSUIPC et donc de pouvoir en changeant le soft sur l'ordi interfacer avec d'autres simus genre X-plane.Mais ça me parait être un gros projet.
C'est pour ça que les options 1&2 semblent plus simples même si moins optimisée et modulable. C'est la grande question aussi de savoir si on dote chaque panel d'un "cerveau" relié à un bus central (option 2) ou relié directement au pc chacun (option 1) ou alors des cartes IO qui seront partagées entre les panels (option 3).





Maxime

[lolosimule]

Le plus de travail devrait alors être délégué au PC et les cartes d'interfaçage ne feraient que lire et écrire ses entrées sorties et les transmettres.

Maxime moi, je pense plus à un system multitâche (a microcontrôleurs).
le but, c'est d'utiliser au minimum la puissance de calcul du PC
il a déjà beaucoup de chose à faire ...
et utiliser les microcontrôleurs pour des taches plus simples
(il sont fait pour ça je pense).
et aussi ne pas saturer de données inutile sur le bus USB ( qui ne change pas)!
c'est un beau projet . . .

[A320 hérétique]

Bonjour Maxime et Lolo,

Réflexion très interressante, je suis pour ma part arrivé à des conclusions un peu différentes :

1) la solution de type SIOC présente à la cpu du pc une charge absolument dérisoire : quelques centaines d'ES binaires, en mode évenementiel, et traitement réduit au plus simple ; sur ma conf 3pc, 3 vues externes, il y a un serveur fmgs et p3d qui affiche la vue de face, un client fmgs, et un client p3d qui affiche vues de droite et de gauche : initialement, sioc tournait sur le client fmgs, je l'ai transféré sur le serveur fmgs et p3d, et je n'ai sincèrement pas réussi à déceler le moindre impact - rien !
2) intégrer des capacités de traitement hors des pc, sur les panels eux mêmes ou sur des cartes annexes ? à mes yeux, le gros intérět est de simplifier le cablage et de faciliter la maintenance !
Donc mux/demux sur les panels, cables en nappe vers une électronique concentratrice (plus éventuel mini traitement) et liaison usb ou ethernet vers le pc,
Ou traitement directement sur les panels, et liaison usb ou ethernet directe au pc (via tout de même hub ou commutateur).

Donc en gros, la charge reste sur le pc via de l'évenementiel, et simplification du cablage d'une facon ou d'une autre.

Michel
Ps : et SIOC, c'est certes un peu rustique, mais tellement simple et efficace ...

[fab]

Même réflexion que Michel : Très peu d'impacte sur les capacités de nos machines actuelles.
Pas mal de monde travaille en port série RS232 sur Arduino et là on peu dire que ce n'est pas optimisé (utilisation de convertisseur USB/Série RS232)

Une connexion réseau peut réserver des prises de tête lors des paramétrages.

Ce qu'il faut favoriser c'est un câblage facile, attention au multiplexage qui, serte, fait gagner des IO sur un microcontrôleur mais rend le câblage délicat. L'utilisation de registres à décalages est une bonne solution.

Pour le logiciel, SIOC est très efficace, complet, manque peut être le traitement des chaines de caractères, facilement adaptable et partageable sans des tonnes de DLL, bibliothèque, et autre compilateur.

J'ai facilement transférer mon hard d'une machine à l'autre 'une simple copie du répertoire avec les scripts) sans me dire qu'il me manquerai un truc pour l'installation.

Tu peux inventer un système, à base de simconnect ou du SDK de FSUIPC, mais là, c'est plus la passion de la programmation et de la conception/réalisation qui l'emportera.

Fabien

[HertZ]

Merci pour vos réponses déjà

et aussi ne pas saturer de données inutile sur le bus USB ( qui ne change pas)!
c'est un beau projet . . .

Je me demandais d'ailleurs si un microcontrôleur avec usb intégré permettrait de gagner en vitesse de manière conséquente par rapport à la liaison série.

Donc mux/demux sur les panels, cables en nappe vers une électronique concentratrice (plus éventuel mini traitement) et liaison usb ou ethernet vers le pc,

D'où mon idée d'un bus I2C commun à tout les panels pour envoyer les évenements vers la carte mère, mais à ce moment là la carte mère n'a pas a faire grand chose à part recopier les données du bus sur l'usb...

Même réflexion que Michel : Très peu d'impacte sur les capacités de nos machines actuelles.
Pas mal de monde travaille en port série RS232 sur Arduino et là on peu dire que ce n'est pas optimisé (utilisation de convertisseur USB/Série RS232)

Une connexion réseau peut réserver des prises de tête lors des paramétrages.

L'usb me semble une bonne solution. Le vrai protocol USB pas de port com virtuel, mais à ce moment là il faudrait l'avoir d'inclu de le microcontoleur pour ne tirer les bénéfices.

Ce qu'il faut favoriser c'est un câblage facile, attention au multiplexage qui, serte, fait gagner des IO sur un microcontrôleur mais rend le câblage délicat. L'utilisation de registres à décalages est une bonne solution.

Le multiplexage par registre à décalage me parait bien mais le temps de traitement des entrées m'interroge. Quelle fréquence d'horloge pour quelle nombre d'entrée sur les registres ? Puisque pour chaque I/O il faut un coup d'horologe pour le décalage , je ne sais pas combien de de coups pour la lecture digital de l'état, puis l'enregistrement dans une variable, et enfin la transmission. Sachant que un appui bouton prends 30ms au minimum environ, que j'ai calculé en liaison série 9600baud/s le temps de transmission de l'état d'une variable prends 10ms avec le protocol sioc par exemple, avec les focntions de base sur arduino la lecture se fera en 2ms (lent mais je ne sais pas quel temps cela prends en manipulant directement les ports). Dans ce cas si on compte une transmission suite à une detection puis le scan à nouveau de tout les bits des registres à décalages en série on a 10ms puis on a 20ms pour scanner avant un possible nouvel appui. Ce qui fait 10 bit seulement dans les registres à décalages... 10 entrées ce n'est pas terrible. Même si l'on réduit ce temps par 10 en manipulant diretement les ports cela donne 100 I/O max si il n'y a que un changement de variable par cycle. Et c'est sans compter sur la lecture des transmissions en réception aussi.

Donc je pense que je vais m'orienter vers un microcontrôleur type ESP32. Ils ne coutent pas très chers (autant qu'un arduino uno). 240Mhz d'horloge et surtout 2 coeurs à cette fréquence ce qui permet de dédier un aux transmissions et l'autre au balayage des I/O.

Je pense créer une carte d'interfaçage unique avec 3 esp32,(ou 2 qui regroupent les 2 première fonctions j'hésite encore) un pour les entrées (256 devraient aller), un pour les sorties (256 aussi) plus une carte d'extension pour les 7 segments, et le dernier pour les entrées "rapides" pour des encodeurs qui doivent utiliser 2 broches avec interruptions notamment (ce qui donne la possibilité d'avoir 13 encodeurs).
Je me demande si pour les registres à décalage il y a une différence de vitesse de lecture entre en avoir 8 en série sur un GPIO par exemple ou alors 2 sur 4 GPIO différents ?
Donc au final 3 connections USB (mais virtualisation série quand même malheureusement) jusqu'à un logiciel. Ce logiciel sera en charge de n'envoyer que les événements correspondant à chaque esp32 et fait la passerelle avec le simulateur , simConnect ou autre pour X-plane, FFA320.

Pour finir j'ai fait pas mal d'approximation pessimiste dans mes calculs précédents mais les entrées sont un domaine plutôt critique et puisque aujourd'ui on a mieux que des arduinos pour le même prix autant changer. Ce qui m'embête c'est le manque de liaison usb directe même sur les esp32. J'ai cherché rapidement mais pas trouvé de multi-coeurs à ce niveau de prix avec usb, si vous en connaissez je voudrais bien savoir.

Maxime

[lolosimule]

Maxime juste pour info!
je ne sais pas si tu connais le bus "Arinc"
c'est un Protocol série utiliser en aéronautique!
je pense, il y a une de tes solutions qui s'y rapproche!
il faut savoir aussi que pour le soft FMGS de JL
"on à des limitations des offset non accessibles"
pour les nouvelles générations de composants de yP.
alors que par "SIOC" ils ont moins de limitation.

https://fr.wikipedia.org/wiki/ARINC_429

[HertZ]

Merci pour l'info , j'avais vaguement entendu parlé mais du coup en regardant de plus près ça demande un circuit récepteur sur chaque module donc trop couteux je pense. L'architecture avec un bus central me parait trop couteuse et complexe par rapport à une carte I/O générale.
Pour connecter la carte mère au carte d'extension ce pourrait être une piste comme le protocole CAN supporté par l'esp32 mais ils demandes des tensions particulières avec donc des circuits d'adaptation , le UART devrait faire l'affaire.

Pour les limitations du soft de JL je ne m'y connais pas du tout , j'ai déjà interfacer quelques parties du FCU avec notamment le principe de pipeline mais ça ne m'avait pas posé de problèmes. Quelles sont exactement ces limitations ?
(Aujourd'hui il y a aussi FFA320 comme utilisé par Homecockpits qui à l'air pas mal, j'ai juste un doute sur la possibilité de mettre le pfd,nd, etc... sur d'autres écrans)

Maxime

[mameloose]

Ah non tout est deportable sans probleme.
On a choisi de tout centraliser sur des cartes mere mux ethernet.
Chaque panneau indépendant puis connecté a une grosse carte io en gros.
On travail actuellement sur toliss également.
Les produits hc seront entièrement compatible et plug and play sur ff et toliss

[lolosimule]

Maxime,
tu pourrais peut-etre avec le bus I²C les composants ne coute presque rien
il sont utiliser avec Arduino.
moi, je m'orienterais plus vers un FPGA (la carte PCB n'est pas simple a realiser)
donc un très gros travail (en attente).

pour les limitations soft j'ai le RMP, ACP, Horloge . . .etc
même si j'ai pu realiser de façon à le rendre indépendant du soft
le RMP et fonctionnel sans aucune interaction avec le soft est dommage!
de même pour l'horloge. . .
il manque aussi quelques affichages et voyants, je n'ai plus en tête. . .

nota : Jean-Luc n'est pas contre une ouverture aux offsets "manquant" pour les Arduino via une dll. . .

[HertZ]

Utiliser un bus commun couterait trop cher finalement si il doit y avoir des microcontroleurs sur chaque panel. Mais j'avoue que l'idée d'un fpga travaillant avec un microcontroleur sur la carte I/O m'a traversé l'esprit. Cependant les fpga sont encore chères pour l'instant comparativement à des microcontôleurs assez puissants...