Antiath

Je partge tes frustrations ouai... Je crois que ce qui m'énerve le plus c'est cet encart sur leur stie : En particulier le point où on te dit de ne surtout pas réutiliser du code existant. Comme si tout le monde savait exactement quoi écrire rien qu'en lisant leur doc, certes extensive, mais obscure et totalement dépourvue d'exemple concret et de snippet de code. Ouai ben...je vais me gêner hein.

Haha, je suis aussi en train de développer un nouveau driver ASCOM en ce moment. Heureusement je suis habitué au C# ( et pas au C 😅, la distinction est importante) donc c'est moins douloureux mais ouai je n'ai pas particulièrement apprécié non plus les derniers changements effectués sur la chaine d'outils d'ASCOM depuis la version 7. Je n'ai pas de soucis en soi avec ALPACA, c'est très bien comme initiative parce qu'ils continuent de supporter le développement de drivers pour Windows. Par contre l'abandon des drivers DLL classiques pour ne supporter plus que les drivers à serveur local... Je trouve cela vraiment très mal avisé...ça rajoute de la friction supplémentaire au développement de petits drivers simples qui n'ont pas besoin des fonctionnalités d'un serveur local. Bref. Je vois que tu as finalement résolu tes soucis mais je me permet quand même quelques conseils: 1) si ce n'est pas déjà fait, passe en .NET framework 4.8 minimum. 2) pour débugger le driver, normalement avec un driver DLL tu devais dire au débuggeur quel executable lancer, typiquement tu ajoutais un client ASCOM à la solution pour ça et comme ça tu pouvais mettre des breakpoint dans ton driver. Pour le serveur local c'est un peu différent, tu n'as pas besoin de rajouter de client dans la solution. Le serveur/driver lui même est l'exécutable que le débuggeur pointera. Donc après avoir build la solution, et fait cette petite étape dand cmd.exe pour enregistrer le driver ( ...m'énerve aussi ce truc), tu lances l'execution dans Visual studio en pointant le projet du driver, il executera le serveur local et après celà tu ouvres à part, en dehors de Visual studio, n'importe quel client que ce soit NINA ou autre. et tu lui demandes d'ouvrir ton driver. Tes breakpoint fonctionneront sans problème. C'est finalement assez simple mais j'ai quand même buté là dessus pendant quelques heures. 3) Ils le précisent bien dans le readme mais je vais le répéter quand même : le seul fichier qu'il est réellement nécessaire de modifier c'est SwitchHardware.cs. Ton driver il est là dedans et sa structure est essentiellement la même que les drivers DLL classique. Le reste, à moins que tu ais besoin d'autre chose qu'un port série (qui est déjà implémenté dans Sharedressources), pas la peine d'y toucher. Donc au final une fois qu'on sait où on doit mettre notre code et comment débugger, c'est pas beaucoup plus difficile qu'avant.

L'avantage si tu fais le client toi même et que tu éxecutes tout au sein même de VS en cliquant sur le triangle vert, si il y a un bug, VS va s'arrêter sur la partie problématique, pointer la ligne de code et afficher la sortie du debugger.. Tu peux même utiliser des breakpoint ( en cliquant sur le côté d'une ligne de code pour faire apparaitre un cercle rouge) où le code pausera et tu pourras examiner le contenu des variables. C'est magique.

Oh et une chose à faire une seule fois avant de tester le driver et de le compiler. Dans l'explorateur, cliques droit sur le projet ( jusque en dessous de la solution..désolé le vocabulaire de VS est particulier ...) , puis propriétés. Sur l'onglet Générer ( Buil en anglais chez moi), tu pourras lui préciser quelle plateforme viser. Par défaut ce sera probablement x86. Il vaut mieux mettre en x64 si ta machine a un processeur x64. Nina sera pas content sinon et je pense que les autres clients non plus.

Si tu penses pouvoir tester le driver, et bien le plus simple c'est de le compiler. Dans VS, cliques sur Générer puis Nettoyer la solution, puis une fois fini, Générer la solution. S'il n'y a aucun problème de compilation, alors le driver est automatiquement créé et enregistré par ASCOM sur ce pc. Il te suffit d'ouvrir ton client favori, genre NINA par ex et d'aller le trouver et te connecter. C'est le plus simple mais comme ça, ça t'aidera pas si il y a un bug ( et il y en aura avec ce que tu as actuellement écrit). Pour mieux débugger, le mieux c'est de faire un client toi même dans la même solution que le driver et demander à VS d'éxécuter la solution en pointant ce client. Tu va dans l'explorateur de la solution, cliques droit sur la solution, Ajouter, Ajouter un projet, choisir un template ASCOM Windows form et là tu devras te débrouiller pour faire l'interface graphique, mettre des boutons, des zones de textes et du code qui appèlera le driver et affichera tes données. C'est trop long pour tout expliquer ici, il y a pléthores de tutoriels pour apprendre à faire ça sur VS, et probablement même des tuto spécialisé pour ASCOM qui expliquent exactement ça. C'est exactement ce que j'expliquais plus haut. Comme ça, plus besoin d'envoyer GETDATA.

Si tu mets arduinoport.Write("GETDATA") dans la fonction arduinoport_DataReceived, à chaque fois que tu vas recevoir des données , il va renvoyer " GETDATA" à l'arduino. Je crois pas que ce soit le comportement que tu souhaites. Ca va saturer sur le port série. Je vois dans ton firmware arduino que tu attends cette requête "GETDATA" pour répondre, donc effectivement de cette manière là, il faut que cette requête soit envoyée régulièrement par le driver. Il faut savoir à quel endroit l'exécuter. Cela doit être fait à intervalle régulier... - faut-il mettre en place un timer alors qui enverra la requête tous les x milisecondes ? Comment on fait ça en c# ?( jamais fait ça donc j'ai pas la réponse mais ça doit être possible) - ou est-ce qu'on peut profiter du fait que le client va interroger le driver de façon régulière pour envoyer GETDATA à chaque fois ? Par exemple, le client va appeler régulièrement la fonction Temperature pour avoir la dernière valeur. Est-ce qu'on peut pas mettre la un arduinoport.Write("GETTEMPERATURE") ? Et si on fait ça est-ce qu'on bloque le driver tant que la réponse est pas arrivée ? Si oui comment ? Si non, que faire à la place ? Faut répondre à tout ça pour savoir quoi faire... Perso je trouve ça trop compliqué pour pas grand chose ... Une autre stratégie c'est de simplement dire à l'arduino d'envoyer ses données tous les x secondes ( tu remarqueras que ASCOM prévoit une grandeur nommée AveragePeriod...peut etre on peut se servir de ça pour déterminer la fréquence à laquelle envoyer les données ?) . Côté driver, on se contente de récupérer ça dans arduinoport_DataReceived, de stocker les valeurs dans des variables non statiques et de dire au driver de retourner ces variables quand le client l’interroge. On a plus à se demander comme ça comment gérer les timing depuis le driver, quelle fonction est bloquante ou non, c'est l'arduino qui mène la dance. Bien plus facile. Par exemple private void port_DataReceived(object sender, SerialDataReceivedEventArgs e) { string a = port.ReadLine(); //Supposons que le string soit juste constitué de la température, rien que le nombre, aucun autre charactère. Pour simplifier _temperature= double.Parse(a); } private double _temperature =0; //j'initialise à 0. Cette variable me sert à sotcker la dernière valeur de température. port_DataReceived la met à jour à chaque fois que l'arduino lui envoie une valeur. /// <summary> /// Temperature at the observatory in deg C /// </summary> //Cette fonction est déjà incluse dans le template, il suffit d'enlever les lignes qui disent que c'est pas implémenté et mettre ton code à la place //C'est elle qui est appelée par le client quand il veut savoir la température. internal static double Temperature { get { return _temperature; } }

Et concernant la gestion du port Série, il te faudra probablement un EventHandler ( je sais pas si ça existe en VB) qui permettra d'appeler une fonction dès que de nouvelles données sont reçues sur le port Série. Perso j'instancie le port Série dans la méthode Connected ( la partie set pour être précis), plutôt dans le constructeur de la classe comme toi. Et juste après ça, tu va utiliser l'EventHandler du port "DataReceived" et le faire pointer vers une fonction à toi ( chez moi je la nomme port_DataReceived). public bool Connected { get { LogMessage("Connected", "Get {0}", IsConnected); return IsConnected; } set { tl.LogMessage("Connected", "Set {0}", value); if (value == IsConnected) return; if (value) { connectedState = true; LogMessage("Connected Set", "Connecting to port {0}", comPort); port = new SerialPort(comPort, 9600);//Set your board COM port.DataReceived += new SerialDataReceivedEventHandler(port_DataReceived); port.Open(); } else { connectedState = false; LogMessage("Connected Set", "Disconnecting from port {0}", comPort); port.Close(); } } } Et ensuite la fonction callback "port_DataReceived", elle sera comme cela par exemple private void port_DataReceived(object sender, SerialDataReceivedEventArgs e) { string a = port.ReadLine(); //Et là à toi de voir comment manipuler le string pour en sortir tes données, c'est toi qui décide comment c'est mis en forme dans l'arduino. }

Concernant VS2022, si tu n'as pas envie de faire un driver en mode "local server" comme ASCOM veut nous forcer à faire maintenant (😒 )... tu peux toujours installer VS2019 et là tu pourras faire une driver classique. C'est à toit de voir ce dont tu as besoin. Si tu as besoin du serveur local, je pourrai pas aider là là dessus. J'ai jamais eu à implémenter cela dans mes drivers ASCOM. Si je dois faire un petit driver, je le crée sur VS2019 et après j'en fais ce que je veux. Néanmoins, si je créée rapidement un driver Observing conditions sur VS2022, je vois dans l'explorer un dossier "ObservingConditionsDriver" avec deux fichiers .CS dedans. En regardant les commentaires dans le code, ils disent clairement qu'il veut mieux ne pas toucher à "ObservingConditionsDriver.cs" et que tu dois juste implémenter tes fonctions principales dans "ObservingConditionsHardware.cs". Donc si on ouvre ce dernier, tu peux déployer les sections pour avoir accès à ce que tu as besoin avec tous les fonctions typiques qu'on retrouverait dans un driver ASCOM à l'ancienne. Entre autres, la région "IObservingConditions Implementation" expose toutes les grandeurs que tu veux utiliser ( des choses comme la température, la pression, l'humidité etc, à toi de voir) et c'est ça que le client appellera pour récupérer ses données ou en envoyer à l'appareil. Donc ce fichier se code comme un driver ascom normal à priori. Voilà