Étape 9: Programmer votre Arduino
Tout le code de source Arduino est attaché. Si vous n’êtes pas intéressé à modifier ou à apprendre comment il fonctionne, vous pouvez simplement télécharger et déployez-le. Si vous souhaitez voir comment cela fonctionne, lisez cette étape et puis parcourir le code.
À partir de evt_loop.cpp, le programme appelle d’abord evt_loop_init. Ensuite, il appelle à plusieurs reprises event_loop_proc indéfiniment, jusqu'à ce que l’Arduino perd de la puissance. En regardant ces deux fonctions, vous verrez que la plupart de l’Arduino code est centrée autour de l’idée de files d’attente . Files d’attente sont utiles dans les situations où un seul système a besoin de parler à l’autre de façon asynchrone. Dans notre situation, nous avons un modem Bluetooth qui peut recevoir des données à tout moment. En général, beaucoup de travail passe en veillant à ce que les données jamais se perdues, peu importe ce que l’appareil est fait quand le message arrive. Heureusement, l’Arduino Uno dispose d’un tampon de série de matériel intégré de 128 octets. Chacun de nos messages de Bluetooth étant 1 octet, cette zone tampon sera probablement plus que suffisant pour notre application. Alors notre application s’exécute en boucle, en attente d’un message viennent de Bluetooth. Dans un produit commercial, il est typique pour le microcontrôleur pour entrer dans un mode veille ici pour économiser l’énergie. Pour plus de simplicité, on n’a pas fait qu’ici (voir la fonction bt_wait_for_msgs de bt.cpp).
Lorsqu’un message arrive dans le Bluetooth en file d’attente (voir la fonction bt_check_for_msgs de bt.cpp), les données sont lues dans et ajoutées à une file d’attente dédiée au traitement des données en provenance du module Bluetooth. Nous faisons cela parce que nous voulions notre microcontrôleur à être libre de faire d’autres choses alors qu’il n'est pas traiter les messages. La file d’attente de message est comme une boîte aux lettres. La prochaine fois que le programme obtient une chance, il va vérifier la boîte aux lettres et voir si il n’y a aucun messages pour elle. Ne pas utiliser une file d’attente de messages est comme crier haut et fort d’à travers la pièce. Dans ce cas, tout devra arrêter et immédiatement la commande de service avant de revenir à ce qu’il faisait. La fonction msgq_push (définie dans msgq.cpp) renvoie à une variété de codes de réponse (défini dans msgq.h) qui indiquent un nombre différents de conditions de file d’attente. Par exemple, si le programme a jamais vérifié sa boîte aux lettres, il est possible pour cette file d’attente se remplit. Dans ce cas, la valeur de réponse indique que la file d’attente était pleine. Cela permet la gestion des erreurs, qui est un élément essentiel du développement de systèmes embarqués.
Retour à evt_loop_proc, le message est lu dans une variable locale. En outre, un pointeur vers un type de réponse est transmis en. L’esperluette (&) devant la variable rsp signifie qu’adresse r.e.r. dans la mémoire a été paseed en msgq_pop, par opposition à sa valeur. Si vous n’avez pas entendu parler de ce concept avant, IBM sait beaucoup à ce sujet, et qu’ils aimeraient utiliser ou divulguer ces renseignements pour vous. Ce pointeur indique msgq_pop un emplacement en mémoire où il peut mettre la valeur de la réponse. C’est un peu comme un moyen d’obtenir une fonction retourne deux valeurs--le message et l’État.
Après avoir pris le message de la file d’attente (semblable à la lettre de sortir de la boîte aux lettres), la réponse est vérifiée. Si l’opération n’a pas réussi, la file d’attente de message entier Bluetooth est réinitialisé, et le programme se poursuit. Il n’y a pas vraiment beaucoup d’autre que le programme pourrait faire dans cet État.
Si le programme rend après cela retour d’erreur, il ressemble à la valeur du message. Si le message était un « 1 », il gère un relais. S’il s’agissait d’un « 2 », il gère celle-ci. Autre chose et il ignore le message.
Notre dispositif n’a pas eu un manomètre, il n’y a aucun moyen pour l’application Android de savoir si les cartouches sont pressurisés ou non. En conséquence, compte tenu de l’air assez sous pression, il est possible pour là encore être suffisamment de pression à gauche pour tourner deux fois sans avoir à remplir le réservoir. Pour tenir compte de cela, l’Arduino se fermera automatiquement le relais une seconde après son ouverture. Ceci empêche l’air supplémentaire de gaspillée lorsque le tonneau est vide. Le code qui gère les relais de commutation est disponible en relay.cpp.
Pour gérer cette fermeture automatique, nous utilisons une minuterie. La plupart des microcontrôleurs ont minuteurs matériel de chronométrage de haute précision, donc cet exemple est une bonne introduction. Jetez un oeil à timer.h et timer.cpp si vous êtes intéressé à en apprendre plus sur le fonctionne de la minuterie. Après avoir reçu un message valide de Bluetooth, le relais correspondant est immédiatement fermé (fonction d’evt_loop_proc d’evt_loop.cpp), permettant aux actuels à l’écoulement de la batterie à la vanne d’arrosage. Ensuite, une minuterie qui doivent expirer en une seconde (1 000 000 microsecondes dans le code). Ensuite, la fonction de rappel est configurée pour être evt_loop_handle_timer, qui appelle le module timer une fois la durée spécifiée écoulée.
À l’intérieur de l’evt_loop_handle_timer, les deux relais sont ouverts, qui arrête le débit d’air de deux cartouches. Nous avons pensé que ce serait l’approche la plus simple à prendre. Une fois qu’une commande a été traitée, evt_loop_proc s’appelle à nouveau (à partir de cannon.pde) et le processus se répète.
Une fois votre Arduino est programmé, il démarrera automatiquement exécuter votre programme lorsque vous utilisez l’alimentation par une pile 9V.
