Étape 5: Intro du logiciel
À la fin de la session de jam Arduino, le logiciel pour le radiogoniomètre est un work in progress. Éléments de base ont travaillé et ont été testées : la matrice de Led, la « vague mexicaine » self test, la connexion en série à un module GPS, extraction de latitude et longitude, de stocker et d’extraire des types de données float dans l’EEprom. En outre, travail a été commencé à télécharger Waypoints de Google maps.Depuis lors, j’ai mis beaucoup de travail dans l’élaboration de deux esquisses distinctes pour le jeu géocache inverse :
-un croquis de l’éditeur de waypoint piloté par menu : Geocache_menu
-le jeu sketch : géocache
Voir les prochaines étapes.
Combinant les deux croquis dans un sketch unique serait possible, mais j’ai gardé les séparés pour les raisons suivantes :
- les deux croquis sont déjà assez gros (12 à 15 Ko)
- complexité inutile s’ajouteraient
- les croquis sont exécutés par des personnes différentes en tout cas.
Car les deux programmes ont près de 400 lignes, j’ai séparé les en parties plus petites et faciles à gérer.
Par exemple, l’esquisse de la géocache a une partie de la logique de jeu, une partie de la gestion des LED, un gestionnaire de mémoire waypoint, un gestionnaire de module GPS.
Écriture et débogage les croquis a été réalisé méthodiquement :
- Une petite esquisse a été préparée pour chaque élément sub
- Beaucoup de messages de contrôle Séris ont été incluses pour suivre le déroulement du programme, vérification des variables d’entrée et de sortie etc.
- Toutes les valeurs d’entrée possibles ont été présentés à l’esquisse et la réaction a été évaluée
- L’esquisse a été en cours de débogage jusqu'à ce que le résultat a été jusqu'à l’attente
Ensuite, j’ai intégré les parties séparées, une par une dans le croquis général, tester et déboguer que j’avançais.
Enfin, le produit fini a été « testé sur le terrain ».
Cela fait toujours apparaître des lacunes, par exemple réaction sur les changements de direction était trop lente (j’ai dû augmenter le taux de rafraîchissement GPS--retour à la planche à dessin).
J’ai enlevé la plupart des choses débogage et ajouté des commentaires pour la facilité d’entretien.
Je ne cherchais pas à optimiser les croquis pour la vitesse, la taille de la mémoire ou beauté générale.
Environnement : Arduino 1.0
Les bibliothèques suivantes ont été incluses :
SoftwareSerial.h, utilisé pour l’interface série à la GPSmodule, à côté de l’interface série standard pour le PC.nmea.h pour la collecte d’informations GPS.
Cette bibliothèque offre plus de possibilités que celui plus simple TinyGPS bibliothèque. En particulier la méthode de « course_to » est avéré nécessaire de clalculate le titre d’une donnée de la latitude et la longitude.
La bibliothèque n’a pas fonctionné comme tel. Un patch est nécessaire pour utiliser WProgram.h. Après que le patch de Bill Ho a été introduit en nmea.h et nmea.ccp, l’esquisse mise à jour OK. Réf : http://arduino.cc/forum/index.php?action=profile;u=11017;sa=showPosts
EEPROM.h pour stocker les informations de point de cheminement dans l’EEprom de l’Arduino.
Les informations de point de cheminement, consistant en une latitude, longitude est disponible en types de données float. Dépecer un flotteur pour stocker et reconstruire après avoir récupéré de l’eeprom est avéré pour être une affaire compliquée. Un spécialiste en SW Arduino, C / C++, devaient être appelés à nous aider.
