aircockpit.com

Bonjour,

(je vais essayer d'être clair )
j'essaie de développer mes propres applis de gestion du cockpit (ex. gestion des 3 radios de l'A320), et j'essaie de séparer la partie "gestion" (par exemple lien avec FS et interaction entre les radios, logique de fonctionnement) de la partie hardware (affichage et transmission à la partie gestion des commandes). Dans ce modèle, le hard doit être "le plus bête possible" et l'intelligence est dans la partie gestion.

La partie gestion serait connectée à FS via FSUIPC et posterait des offsets utilisables par la partie hardware, mais dans FSUIPC il y a plein d'offsets et on est jamais sûr qu'on est bien seul sur l'offset (unofficial) qu'on s'est attribué. En plus on poste plein de requêtes qui ne sont pas destinées à FS.

J'arrive à ma question : existe t'il un soft qui puisse fournir à la demande une page d'offsets, non partagée avec FS, qui serve de zone d'échange entre une partie gestion et une partie hardware. Chaque partie gestion pourrait donc créer sa propre page d'offset pour mettre à disposition ses sorties (et recevoir ses commandes), une partie gestion pouvant "taper" dans plusieurs pages (ex: une page ADIRS, une page Radio, une page FIRE, etc.). Les requêtes FSUIPC ne serviraient qu'aux échanges avec FS.

Si ce soft pouvait aussi centraliser et optimiser les requêtes FSUIPC des différentes parties gestion en servant de proxy, ça serait parfait...

Quelqu'un aurait'il vu un soft qui fasse ça? Si non, un tel soft aurait il un intérêt pour les programmeurs de hardware et de logiques?

merci.

tf.

Ouh là...
Je sais pas pourquoi mais je sens que tu vas t'entendre avec Jeehel et Guda toi...

FiX a écrit:Ouh là...
Je sais pas pourquoi mais je sens que tu vas t'entendre avec Jeehel et Guda toi...

Vois pas de quoi tu parles

Déjà, la réponse simple et brute à ta question, telle qu'elle est posée, est non.

Bon sinon très bonne question que tu poses là. Pour les non-initiés ET non-intéressés par la programmation, mieux vaut passer votre chemin, ça va être technique là .

Comment marche FSUIPC? Il s'agit d'une DLL (placée dans le dossier "modules" de FS) et chargée par FS qui crée un fichier mappé en mémoire qui prend la modique place de xFF80 octets (soit 65408 octets, pour les non-initiés intéressés ).

Pour te connecter à FSUIPC, en fait pour ouvrir le fichier mappé, et en extraire des "vues", tu vas devoir donc retrouver la trace du-dit fichier (les headers exemples fournis avec FSUIPC sont généralement bien commentés, tu devrais t'y retrouver rapidement).

Avec le handle du mappedfile, tu ne pourras pas encore faire tout ce que tu veux. Comme le même fichier est ouvert en lecture par au moins deux process différents (la DLL et ton appli), il faut une bonne discipline pour gérer l'écriture et éviter les collisions, qui donnent des valeurs incohérentes.
Donc, côté appli, il y a 3 fonctions à utiliser (c'est comme ça que les fichiers SDK fournis fonctionnent tous):
-FSUIPC_Read
-FSUIPC_Write
-FSUIPC_Process

Dans les fonctions _Read/_Write, tu en fait ne lis ni n'écrit quoi que ce soit. Tu fais une demande de lecture et/ou écriture, en fournissant les pointeurs vers les variables de réception/émission. La lecture/écriture effective sera en fait effectuée dans l'appel à la fonction _Process, en une seule fois, pour éviter de pénaliser le temps d'ouverture côté appli du fichier mappé.


Voila pour les bases de FSUIPC. Alors pourquoi non à ta question:
- Tu ne peux pas aller au delà des xFF80 octets en rajoutant tes propres pages, car soit cela changerait la taille du fichier mappé, et là la DLL n'apprécierait sûrement guère, soit tu écrirais dans la RAM au-delà du fichier, et là ton OS n'apprécierais guère...
-Tu peux écrire dans les offsets persos sans trop de craintes, essaye de prendre des plages aléatoires et ça va le faire.
-Ou demander à P.Dowson une attribution (gratuite) d'offsets fixés à ton nom.
-Le temps supplémentaire pour écrire/lire quelques offsets en plus est négligeable (mon soft lis/écris toutes les 50 à 100 ms plus de 200 offsets)
-Si tu veux gérer du hardware sans passer par FSUIPC, regarde SIOC, qui permet facilement de modifier/lire des variables SIOC (et donc hardware) par un simple protocole TCP/IP.

j'espère avoir été clair


@+
JeeHell

JeeHell a écrit:

FiX a écrit:Ouh là...
Je sais pas pourquoi mais je sens que tu vas t'entendre avec Jeehel et Guda toi...

Vois pas de quoi tu parles

Déjà, la réponse simple et brute à ta question, telle qu'elle est posée, est non.

Bon sinon très bonne question que tu poses là. Pour les non-initiés ET non-intéressés par la programmation, mieux vaut passer votre chemin, ça va être technique là .

[..]

j'espère avoir été clair


@+
JeeHell

ouais, c'est technique...

Merci pour le cours sur FSUIPC , c'est en effet ce qui ressort de la lecture du code source du SDK (en particulier IPUser.c), d'ailleurs c'est la dll qui écrit (et lit) dans le mappedfile du client qui appelle FSUIPC_Process() : le client poste sa requête de Process par SendMessage et le serveur répond dans le mappedfile.

C'est vrai qu'en faisant _Read/_Write on écrit pas ou ne lit pas, mais si on fait 10 fois le même _Read (je sais c'est pas très malin), ces 10 requêtes seront inscrites dans le mappedfile, et lorsque que tu appelleras Process(), la partie serveur exécutera 10 fois la même requête sauf s'il y a des optimisation inconnues puisqu'on a pas accès au code de la dll. Mais c'est peu être négligeable...

Mon idée n'était pas d'aller au delà des offsets FSUIPC (toutes les chances de tout faire planter), mais de créer un ou plusieurs nouveaux mappedfile dédié aux échanges "locaux" entre le hard et sa logique sans passer par FS (mais je ne sais pas si ça ferait gagner vraiment quelquechose).

a+
tf.

togafan a écrit:Mon idée n'était pas d'aller au delà des offsets FSUIPC (toutes les chances de tout faire planter), mais de créer un ou plusieurs nouveaux mappedfile dédié aux échanges "locaux" entre le hard et sa logique sans passer par FS (mais je ne sais pas si ça ferait gagner vraiment quelquechose).

Ben disons que je ne pense pas que tu puisses adapter une 'interface hard <-> FSUIPC préexistante pour permettre d'écrire dans d'autres mapped file que celui par défaut (en spécifiant par exemple un offset au delà du range max de FSUIPC de base). Donc à partir de là, l'option FSUIPC elle-même ne sert pas si tu ne veux vraiment passer par là (ce que je comprends, j’abhorre FSUIPC en vrai, c'est lent, coûteux en ressources FS, bref nul et préhistorique comparé à X-plane et ses datarefs par exemple). Encore que comme je le disais c'est pas quelques writes/read toutes les 50ms en plus qui vont changer quoi que ce soit. Crois moi, mon soft en fait en pagaille
Et donc si tu veux vraiment passer par une autre IPC entre ton soft et ton hard, tout dépend du hard. Quelle cartes I/O utilise-tu ou prévois-tu d'utiliser?

JeeHell a écrit:

togafan a écrit:Mon idée n'était pas d'aller au delà des offsets FSUIPC (toutes les chances de tout faire planter), mais de créer un ou plusieurs nouveaux mappedfile dédié aux échanges "locaux" entre le hard et sa logique sans passer par FS (mais je ne sais pas si ça ferait gagner vraiment quelquechose).

Ben disons que je ne pense pas que tu puisses adapter une 'interface hard <-> FSUIPC préexistante pour permettre d'écrire dans d'autres mapped file que celui par défaut (en spécifiant par exemple un offset au delà du range max de FSUIPC de base). Donc à partir de là, l'option FSUIPC elle-même ne sert pas si tu ne veux vraiment passer par là (ce que je comprends, j’abhorre FSUIPC en vrai, c'est lent, coûteux en ressources FS, bref nul et préhistorique comparé à X-plane et ses datarefs par exemple). Encore que comme je le disais c'est pas quelques writes/read toutes les 50ms en plus qui vont changer quoi que ce soit. Crois moi, mon soft en fait en pagaille
Et donc si tu veux vraiment passer par une autre IPC entre ton soft et ton hard, tout dépend du hard. Quelle cartes I/O utilise-tu ou prévois-tu d'utiliser?

J'écris le soft et ai fait le hard I/O (voir mon post sur le forum http://www.aircockpit.com/viewtopic.php?f=93&t=2312&p=25039#p25039) c'est donc pas un pb de recompiler... Je regardais si cela avait un intérêt d'écrire un "serveur de mappedfile" avec une API qui surcharge celle de FSUIPC cote client (pour pas avoir à changer tout le code) mais qui aille un peu plus loin en fonctionnalités.

a+

tf.

Ahhh mais ça change tout
Juste une question, c'est pour utiliser mon logiciel A320 au final ou pas? (ou entre autres?)
Si c'est le cas, il y a (beaucoup) mieux que FSUIPC pour dialoguer avec mon soft. Envoies moi ton mail par MP et je te filerais de la doc.

JL

Etben voilà, j'le savais... (que vous alliez vous entendre...)

Celà dit ce post est excellent pour ceux qui comme moi ont un peu de mal à s'endormir le soir...