Kidule Dé/Allumer une Led (Sortie)
On va commencer par un tout petit programme qui allume la Led 0 du kidule Dé
#include "hardwareDe.h"
void loop ()
{
Led0=Allume;
}
Si cela te suffit comme explication, tu peux passer à la leçon suivante Kidule Dé/Tester si un Bouton est pressé (Entrée).
Comment fonctionne une Sortie
[modifier | modifier le wikicode]Pour qu'une pin (patte d'un composant) soit une sortie, on doit mettre un 0 dans le bit correspondant du registre TRIS, ce qui permet de connecter la sortie du Data Latch avec la pin (petit triangle colorié en vert).
On peut alors écrire ce que l’on veut dans LATx (en bleu) et à la fin de l'écriture, ce sera mémorisé dans le Data Latch et la sortie aura donc changé.
Pour écrire un 0 dans le bit 0 du PORTA, on peut écrire
PORTAbits.LATA0 = 0;
Lors de la définition des entrées sorties, faire attention avec un 18F2550 d’utiliser LATxxx pour les sorties et PORTxxx pour les entrées. En effet, si deux instructions assembleurs BCF ou BSF se suivent sur le même PORT, le résultat n’est pas prédictible !!! La doc du PIC est assez peu claire sur ces instructions dites "Read-Modify-Write", mais on peut très bien avoir un résultat erroné (p. ex. BCF PORTA,0 suivit de BSF PORTA,1 peut fort bien se terminer avec le bit 0 de PORTA qui clignote (passe à 0 lors du BCF, puis repasse à 1 lors du BSF de son voisin). En regardant bien le schéma, on comprend pourquoi: lorsque l’on écrit, la donnée que l’on veut est mise dans le Data Latch à la fin de l'écriture. Or la lecture d'une pin est "gelée" durant toute la lecture. Si deux instructions "Read-Modify-Write" se suivent, la première met la donnée sur la pin à la fin du Write. Comme il s'agit d'une pin, qui a un consommateur au bout, la tension ne va pas monter instantanément. Or l'instruction suivante est un "read-modify-write", qui s'il est fait sur PORTx et non sur Latx, va lire non pas le registre, mais la pin. Comme la tension sur la pin est en train de changer et que l’on gèle la lecture de la pin avec un Latch au début du cycle, on a en fait des risques de mémoriser l'état d'avant !!! d'où un comportement étonnant.
Ce problème est présent sur tous les PIC, mais l'avantage avec la famille 18Fxxxx est que l’on peut lire et écrire le registre LAT. Dans les premiers PIC, ce registre existe aussi, mais on ne peut pas le lire, on ne peut que l'écrire via PORT... le risque est alors grand, et il faut faire attention en écrivant le soft de ne pas faire 2 "read-modify-write" de suite.
En déclarant les bits comme c’est la cas ici, et contrairement à la pratique Pinguino qui consiste à utiliser la procédure DigitalWrite(), on améliore l’efficacité du code de manière drastique (au moins 1 à 20) et on est très proche de l'assembleur, mais du coup, on s'expose à ce problème !!! Il faut donc bien déclarer les IOs
Allumage d'une LED
[modifier | modifier le wikicode]Si on regarde le schéma, on voit que le fil de la LED0 est connecté à la patte RA0 du processeur et cette patte est elle-même connectée à une variable LATA0 qui se trouve dans le processeur. Pour être exact, le processeur a une variable LATAbits qui possède dedans 8 petites variables qui ne peuvent avoir que 1 ou 0. Lorsque l’on met un 0 dans cette variable, cela met 0 Volts sur la patte du processeur. Si on met un 1 dans cette variable, cela met 5 Volts sur la patte du processeur.
Comme la Led est reliée au 5 V, si on met 0 Volt (=un 0 dans RA0), la LED s'allume, car il y a du courant qui peut passer (comme un moulin avec de l'eau en haut d'un côté et de l'eau en bas de l'autre). Par contre si on a 5 Volts d'un côté et 5 Volts de l'autre, la LED ne s'allume pas (comme un moulin noyé dans l'eau)
Mais à la fin on se perd un peu! Non? Il faut mettre 0 pour allumer et 1 pour éteindre! alors que des fois on voit sur un interrupteur 1 pour allumer et 0 pour éteindre. c'est pour cela que dans le fichier hardwareDe.h on a aussi écrit
#define Allume 0
#define Eteint 1
Comme cela on peut écrire des choses que l’on arrive à lire facilement. Led0 = Allume; c’est beaucoup plus clair que PORTAbits.RA0=0
