Étape 4: logiciels
Le code source dans le 12F609 est vraiment compliqué. J’utilise jamais dernier emplacement de mémoire ! Tous les 64 octets ont été consommés par mon code. J’ai un énorme 32 octets de gauche flash plus comme pièce de rechange. Donc, j’utilise 100 % de la RAM et 97 % de l’éclair. Toutefois, il incroyable de voir combien la fonctionnalité vous obtenez pour tout ce que complexité.
Communication à chaque lampe est archivée en envoyant des paquets de données de 8 bits. Chaque paquet de données se termine par une somme de contrôle - si vraiment, il y a sept octets de données, plus une somme de contrôle final. À 9600 bauds, un paquet de données prend un peu plus de 8 milli-secondes pour arriver.
L’astuce consiste à effectuer plusieurs tâches tandis que le paquet d’octets est arrivée. Si une des LEDs est active avec un signal PWM, la sortie PWM doit se tenir à jour alors même que la réception de nouveaux paquets octet. C’est le truc. Il m’a fallu semaines et des semaines pour régler cette question. J’ai passé énormément de temps à travailler avec mon Logiport LSA essayant de suivre chaque bit. Il s’agit du code plus complexe que j’ai jamais écrit. C’est parce que le micro est tellement limité. Sur les micros qui sont plus puissant, il est facile d’écrire du code en vrac/facile et avoir le prompt rip micro à travers elle sans se plaindre. Avec le 12F609, n’importe quel code lâche avec vous coûte beaucoup. Tout le code source micro est écrit en C, à l’exception de la routine d’interruption du service.
Pourquoi avoir ces paquets de données volumineuses, que vous pouvez demander. Eh bien, parce que nous voulons avoir la rampe de LEDs haut et en bas de leur propre gré. Une fois un profil de la rampe est chargé, la LED peut s’éteignent et commencer la montée en puissance tout en recevant de nouvelles commandes pour une autre LED. Chaque feu doit recevoir et décoder tous les trafic de paquets de données même si le paquet n’est pas conçu pour elle.
Un profil de LED se compose d’un niveau de démarrage, démarrage habiter temps, vitesse de montée, haut niveau, haut temporisation, taux, niveau bas de rampe. Voir le schéma joint. Wow, c’est beaucoup pour une LED. Maintenant, il faut multiplier qui multiplié par le nombre de LEDs. Il devient trop - je pourrais seulement garder une trace de trois LEDs avec des profils de rampe complète. Le quatrième (blanc LED sur la platine de dev) a uniquement rampe de/à capacité. Il s’agit d’un compromis. Jetez un oeil à la photo ci-jointe d’un profil de la rampe.
Le signal PWM est généré une minuterie qui exécute à 64uS par tick. La minuterie de huit bits survole chaque 16.38mS. Cela signifie que le signal PWM est en cours d’exécution à 61.04 Hz. Ce n’est pas bon pour le taraudage vidéo ! Donc, j’ai utilisé un truc logiciel et sauté quelques chefs d’accusation supplémentaires dans la minuterie pour s’allonger à 60Hz. Cela rend les écoutes vidéo ressemblent beaucoup beaucoup mieux.
Sur chaque renversement de la minuterie PWM (16.67mS) mettre à jour les profils de la rampe. Par conséquent, chaque graduation de rampe/habiter est 1/60 de seconde ou 60Hz. Le plus long segment de profil (à l’aide d’un comte de 255) aura dernières secondes 4,25 et le plus court (en utilisant un compte de 1) dure 17ms. Cela donne une belle gamme de travailler au sein. Jetez un oeil à la photo ci-jointe de l’analyseur logique. Pour vraiment voir le détail sur la photo, ouvrir la photo en mode haute résolution. Cela prend quelques clics supplémentaires sur le site web instructable. Il y a aussi un dessin d’un profil indiqué ci-dessous.
Documenter le protocole de commande est sur ma liste de todo. J’ai l’intention d’écrire un type de feuille de données du document pour décrire pour protocole complètement. J’ai commencé une feuille de données de la puce - une version préliminaire est sur mon site web maintenant.
