aircockpit.com

Bonjour,

un sujet un peu technique : je suis en train de mettre au point la motorisation de mon throttle A320, ça commence à tournicoter, mais ça n'est pas clean ...

Ce que je fais : un Arduino est en charge de faire tourner le moteur pas à pas du trim ; il dialogue avec LUA/FSUIPC pour lui demander à quelle position il faut positionner le trim, et compare ensuite cette valeur avec la position physique du trim, qu'il acquiert en recopiant la valeur d'un potentiomètre qui tourne avec le trim ; après avoir vérifié que l'avion n'est pas en vol, l'Arduino envoie au moteur les ordres de mouvement qui vont bien, et ainsi de suite.

Pour communiquer avec LUA/FSUIPC, je suis pratiquement contraint d'utiliser les bibliothèques LUA qui viennent avec FSUIPC - au détour, documentation extrêmement minimaliste en matière de com ! et grosses instabilités lors des tests ; mais bon, la logique est validée en environnement 32 bits, il me reste à passer en 64 bits et surtout à rationaliser et blinder les codes Arduino et LUA.

Maintenant, 2 questions :
1) Débuguer du LUA/FSUIPC ça n'est pas vraiment de la tarte, car les bibliothèques LUA/FSUIPC sont intégrées à la dll FSUIPC : ça veut dire que pour faire tourner le code LUA il faut faire tourner FSUIPC, donc faire tourner FSX ou P3D ; et quand on "kill" les process LUA, FSX se met très rapidement à genoux, c'est hyper pénible.

Je m'y prends ainsi : développement du code Arduino avec Programino, l'Arduino est connecté au PC par USB ; Arduino se sert de cette liaison pour communiquer avec LUA, donc pas moyen de voir ce qu'il se passe sur le moniteur série, j'ai donc connecté un afficheur LCD sur l'Arduino pour pouvoir tracer un peu les choses - OK

Coté LUA, développement du code avec sciTE, sauvegarde du code dans le répertoire Modules de FSX ; j'ai attaché le code sur un bouton d'un joystick via FSUIPC, ainsi que la macro 'killall LUA" sur un autre bouton ; pour suivre ce qui se passe au niveau LUA, je trace à l'écran à l'aide d'ordres ipc.display (ça marche quand ça va bien, parfois plus rien ne s'affiche alors que je vois sur Arduino que ça tourne - mais c'est un autre sujet).

Donc pour tester, je charge Arduino, je lance fsx, et j'appui sur le bouton du joystick pour lancer le script LUA ; quand je veux arrêter pour apporter des modif, j'appui sur le bouton killallLUA ; mais au bout de 3 ou 4 fois, FSX se vautre !

La (en fait les) questions :
1a - comment vous organisez-vous pour ce type de devts ?
1b- y-a-t 'il un autre moyen de faire tourner un script LUA embarquant des fonctions fournies par les bibliothèques spécifiques FSUIPC que de le faire tourner sous FSUIPC/FSX (par exemple en disposant des bibliothèques FSUIC à part) ?

2) Et la dernière question : évidement je ne développe pas directement sur le simu, je suis sur un autre PC, avec une licence FSX dédiée - tout va bien ; maintenant, il faut que je passe en 64 bits pour P3Dv4.1, mais là, je n'ai pas de licence spécifique (j'en ai 2 pour le simu, ç'est déjà pas mal) ; j'ai bien le FSUIPC 5 pour 64 bits, avec le LUA à niveau, mais pour faire tourner ce FSUIPC il faut un P3Dv4.1 !!! coincé ! pensez-vous que je puisse utiliser une des licences du simu ("déontologiquement" ça ne me gênerait pas, mais le fait de faire ça ne risque-t-il pas de me désactiver le P3D dont j'aurais utilisé les codes ?)

Bien ennuyé, et un peu dépité par les faiblesses de certaines des fonctions LUA spécifiques FSUIPC ...

J'espère que certains auront eu le courage de tout lire !

Michel

J'ai tout lu !

Je ne sais pas du tout comment sont gérés les thread LUA dans FSX, à priori très mal

Pour ma part, je me contente d'une bibliothèque C fourni dans le SDK FSUIPC qui ouvre la connexion vers FSUIPC, donne quelques inof de version, lit et écrit les offsets.

Ce qui fait que, lorsque je quitte mon appli, les threads de lecture/écriture s'arrête aussi ...

Fabien

Bonjour Fabien,

Ah, je n'avais pas regardé dans cette direction ! Je vais m'y pencher, même si je n'abandonne pas la solution LUA car je n aime pas rester sur un demi échec ...

Je présume qu'il y a, côté C, ce qu'il'faut pour gérer une com série avec Arduino ?

Michel

EDIT : bon, je viens de regarder un peu la com série avec Arduino, en C ou C++ sous Windows, à fortiori W 64, intense surprise, ça à l'air d'être une affaire d'hyper spécialiste ... tu as de ton côté une solution accessible ?

Non, je n'ai rien fais avec les com car j'utilise l'USB, comme toi avec l'arduino

https://www.codeproject.com/Articles/1244702/How-to-Communicate-with-its-USB-Devices-using-HID

Edit : Je crois que je viens de comprendre ... tu utilises l'arduino en USB/série et non en USB natif

Il me semble que le port série se traite en C comme un fichier, comme au bon vieux temps du DOS

https://cpp.developpez.com/faq/vc?page=Reseau-et-Communications#Comment-travailler-avec-le-port-serie

Tu parles d'échec, je ne trouve pas, car cela fonctionne, c'est juste pas pratique !

Oui, mais,
Le premier lien c'est du C#, et je ne sais pas comment mais j'ai perdu mon visual c# ( j'adorai), mais je n'arrive plus à le re- installer...( en version gratuite, bien sur).

Et le second, ce doit être basé sur l'api win32, je trouve ça plutôt très lourd ... Bon, Tu me diras qu'il faudrait que je sache ce que je veux ! Ben juste un truc léger comme sur l'arduino

Donc, je n'abandonne pas lua : ce qui me gène vraiment c'est que la bibliothèque com de fsuipc est vraiment sous documentée,
J'ai mis en place un handshaking, mais je n'arrive pas à comprendre comment évolue le buffer d'entrée au fil des envois de l'arduino et des lectures du code lua ... et puis cette hyper lourdeur pour le debuging ...

Michel