Antiath

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à