Némésis : Présentation et évolution de mon projet perso :)

Bonjour,

Ça fait quelque temps que je potasse les ressources que Mr Bigonoff met en ligne ainsi que les datasheets de divers composants, je suis tout content d'avoir réalisé la première partie de mon projet alors je vais vous présenter de quoi il s'agit et je vais mettre les sources des projets MPLAB pour en faire profiter ainsi que pour recevoir des conseils sur l'utilisation du langage C.

Mon projet final est de contrôler informatiquement ma maison. J'aurai bien aimé installer DOMOCAN mais avant je veux comprendre comment ça marche dans les détails et étant donné que j'ai des besoins fixes, je sais pas si j'ai besoin d'un système aussi développé.

Bref, je me suis lancé dans mon truc et on verra bien si ça va marcher

Pour commencer, je me suis fixé quelques objectifs :

- Réaliser un programme basique en C pour PIC
- Étudier comment réaliser un bouton poussoir à 3 possibilités (impulsion, appuis court et appuis long)
- Étudier les bases du bus CAN
- Envoyer des trames avec mes boutons poussoirs
- Allumer des LED suivant les trames reçues

Voici une photo de mon installation



J'ai placé une LED de 5mm par lumière principale que je souhaite piloter.

Pour tous mes montages et projet j'utilise :

MPLAB
C18
18F2680
Quartz 4Mh

J'ai donc crée deux montages, le premier est une "carte capteurs" que je veux placer dans chaque pièce et le second allume ou éteint les lumières et sera placé dans mon cellier.

Pour l'instant je simule les lumières principale de la partie gauche de ma maison : salle, salon et cuisine et la lumière de l'entrée comme témoin de mes tests.

Je voulais que :

Une impulsion sur le BP0 inverse l'état actuel de la lumière 0
Une impulsion sur le BP1 inverse l'état actuel de la lumière 1
Une impulsion sur le BP2 inverse l'état actuel de la lumière 2
Une impulsion sur le BP3 inverse l'état actuel de la lumière 3

Un appuis court sur BP0 ou BP1 éteint les lumières 0, 1 et 2 uniquement

Un appuis long sur n'importe quel BP éteint toutes les lumières

J'ai réalisé une carte horloge avec un DS1307 mais avant de la publier je vais surement recommencer avec un DCF77, quand elle sera en service, une lumière principale devra s'éteindre toute seule 3 ou 4h après avoir été allumée.

La carte capteurs :

- 4 boutons poussoir maximum par pièce
- A venir contact de fenêtre et de porte
- A venir, mesure de température

source : C_carte_capteurs

La carte lumières :

- 4 sorties pour les tests

source : C_carte_lumieres

Ps : si quelqu'un connait un bon logiciel pour dessiner les schémas... ^^

Bonjour,



Sympathique ce projet.


Du point de vue programmation, je trouve qu’il y a
beaucoup trop de copier/coller dans ton code. Le traitement de chaque bouton
semble identique, il serait idéal de créer une méthode prenant par exemple le
numéro de bouton en argument.


Les arguments nécessaires à ton traitement sont un peu
éparpillés dans le code, il serait bon aussi de les regrouper dans une
structure SBOUTON par exemple, et on peut commencer à entrevoir comment bâtir
la méthode évoquée plus haut un passant un indice d’une table de structure
Bouton qui n’est autre que le numéro de bouton ou mieux un pointeur sur le bon
élément de cette table.


Sinon puisque je vois que tu utilises les interruptions
pour gérer le TMR0, moi je connecterais les 4 BP sur le PORTB (RB4 à RB7) et je
traiterais les événements appui et relâchement
par interruption (priorité basse).




Une autre remarque, les BP génèrent des rebonds il est
bon de les traiter pour blinder le code.




Voilà, bon courage pour la suite et n’hésite pas à poster
l’évolution de ton code.




Philippe

Salut Phil,

Je crois avoir compris, je modifie mon code et je te montre. Merci

A oui j'ai oublié, pour dessiner les typons il y a eagle

Et un petit tuto dans la langue de Molière

Salut Phil,

Ces petites modifs s'avèrent être plus compliquées que ce que je pensais mais je suis content car j'ai réussi

Au début j'ai crée ma structure, ma table et la méthode qui va bien. Ça compile, j'envoie le programme dans le PIC et là... rien...

Bon, après quelques minutes, je me rend compte que ma structure n'était pas liée avec mon bouton poussoir, avec la méthode simpliste que j'ai utilisé, j'ai du créer une copie de l'état de ma broche à un instant T et donc que c'était impossible de lire l'état de mon bouton...

J'ai lu qu'il était impossible de pointer directement sur un bit donc j'ai crée un pointeur vers mon port que je stocke dans ma structure et après il faut manipuler les bits

Actuellement ça marche avec un code qui ressemble à ça :

Code:

if ((*BPtable[0].PORT) & 0x02){
        LED0 = 1;
    }else{
        LED0 = 0;
    }

Je dois faire du ménage dans mon programme et je te post la source complète bientôt, en tout cas merci de m'avoir orienté vers ces améliorations car j'ai beaucoup appris

Pour le logiciel, c'est pas pour les typons que je cherche mais pour dessiner les schémas de mes montages.

µA++

Hellow,

On ne peut effectivement pointer sur un bit, mais admettons que ta struture BPx ressemble à ceci

Code:

typedef struct SBPx
{
    unsigned cpt:4;
    unsigned flag:1;
    unsigned etat:1;
 } SBPx;

Tu alloues ta table et tu peux très bien faire dans ton code

Code:

SBPx BPtable[4];

BPtable[0].etat = PORTBbits.RB4;

Et tu utilises le bit etat dans l'interruption de TMR0

Ca peut même être mis dans une boucle et ta routine d'interruption ressemble à ceci

Code:

void HighHandler(void)
{
    if(INTCONbits.TMR0IF){
        int i;
        for(i = 0; i < NB_BP; i ++)
        {
            if(BPtable[i].flag)
            {
                if(!BPtable[i].etat)
                {
                    if(BPtable[i].cpt > 0)    --BPtable[i].cpt;
                }
                else
                {
                    . . .
                }
                BPtable[i].flag = 0;
            }
        }
        INTCONbits.TMR0IF = 0;
    }
}

Et ton code va largement maigrir

Mais ce n'est qu'une idée A+

C'est ce que j'avais tenté au début mais malheureusement, ça ne marche pas chez moi.

Ça compile sans erreur mais il ne se passe rien.

J'ai une led sur RC2 configurée, si je fais :

Code:

BPtable[0].etat = PORTCbits.RC2;
BPtable[0].etat = 1;

Il ne se passe rien non plus

Pour m'en sortir j'ai été obligé de faire :

Code:

typedef struct
{
    unsigned char CPT;                // Compteur
    unsigned FLAG:1;                // Flag
    volatile unsigned char* PORT;    // Port à utiliser
    unsigned char PIN;                // Pin à utiliser
}BP;

BP BPtable[4];                    // BP        : Contient la structure des 4 BP

BPtable[0].CPT = 0;
BPtable[0].FLAG = 0;
BPtable[0].PORT = &PORTA;
BPtable[0].PIN = 0x02;

if ((*BPtable[0].PORT) & BPtable[0].PIN){
  LED0 = 1;
}else{
  LED0 = 0;
}

Bizarre, tu as inspecté ta structure au débugger ?

Cette syntaxe me surprend aussi *BPtable[0].PORT

Normalement c'est (*BPtable[0]).PORT ce qui s'écrit plus simplement BPtable[0]->PORT

Le test avec ce masque (*BPtable[0].PORT) & BPtable[0].PIN fonctionne ?

Dans PIN tu as 0x02 soit b00000010 donc le résultat du masque est 2 ou 0, il faut décaler de 1 vers la droite pour obtenir 1 ou 0

Je dois avouer que je sais pas me servir du debugger encore, c'est un des trucs que je dois étudier dès que j'ai du temps libre, je crois que Mr Bigonoff en parle dans un de ses cours.

J'ai commencé à utiliser View > Watch et je rentre certains registres mais ça ne marche pas comme je croyais ou il y a un truc que je fais mal.

A aucun moment j'ai utilisé *BPtable[0].PORT, j'ai utilisé soit BPtable[0].PORT car je me suis dit que les types de ma structure étaient déjà définit donc je ne pouvais placer qu'un pointeur dans ce champ ou alors j'ai utilisé (*BPtable[0].PORT).

Si j'ai bien compris, les parenthèses servent à signaler au compilo que je souhaite utiliser la donnée pointée et non le pointeur.

De cette logique, (*BPtable[0]).PORT me choque car BPtable est juste un lieu de stockage et c'est toujours PORT qui contient le pointeur donc ça me plaisais bien de l'inclure dans les parenthèses ^^

Sinon oui, mon test fonctionne très bien, j'ai au total 4 BP et il n'y en a qu'un seul qui fait réagir ma led (RA1)

Je pense que tu as raison pour le masque mais dans une condition en C, il n'y a que le zéro qui retourne faux, si j'ai 1,2,4 ou 8, ma condition retourne vrai et du coup, le décalage n'est plus indispensable pour ce que je veux faire.

J'ai compris comment utiliser les interruptions RB4->7 (c'est nouveau pour moi ^^), comment choisir ma priorité, il faut encore que je travaille mon anti rebond et je te montre mon code complet.

Merci de t'intéresser à ce que je bricole
µA++

Pour le pointeur je me suis planté sorry, ce que j'ai écrit est valable pour un pointeur de structure, toi tu as un pointeur dans une structure, ce qui est différent bien sur . . .

Pour utiliser le debugger tu dois te mettre en mode DEBUG (Project->Build Configuration->Debug ou tu le sélectionnes dans dans la Combo de la barre d'outil)

Ensuite Debugger->Select Tools->PicKit3

Attention à l'alimentation de ton Pic, normalement il l'est, sinon tu dois l'alimenter (Debugger->Settings onglet power tu coches Power Target

Tu compiles en mode Debug

La tu peux mettre des Points d'arrêt par double click dans la marge face à la ligne de code ou tu souhaite arrêter le programme et dans la fenêtre Watch tu pourras inspecter tes variables.

Pour activer les priorités tu fais un truc comme ça

Code:

   
    OpenPORTB(PORTB_CHANGE_INT_ON | PORTB_PULLUPS_OFF);
    INTCON2bits.RBIP = 0;        // Priorité basse
   
    INTCONbits.GIE = 1;        // Autorise les interruptions générales
    RCONbits.IPEN = 1;          // Activer les niveaux de priorité sur les interruptions
    INTCONbits.GIEL = 1;          // Autoriser les interruptions de priorité basse
    INTCONbits.GIEH = 1;        // Autoriser les interruptions de priorité haute

Quel quille, je viens de me rendre compte que je n'avais pas compris ce qu'était un rebond exactement...

Je croyais que c'était en rapport avec la vitesse d’exécution du µC alors qu'en fait il faut le considérer comme une phase de mauvais contact du coup il faut que je modifie encore un peu mon programme.

Pour le mode debug j'étais pas loin, c'est ce que j'avais tenté mais j'avais pas compris les points d'arrêts, je vais essayer ça ce week end. Sur mon µC, j'ai un fusible DEBUG, il faut que je l'active aussi ?

Au sujet de l'alimentation du circuit, oui j'utilise le pickit pour alimenter mais comme je commence à avoir du composant (actuellement 3 pic, 3 MCP2551, un LCD et bientôt un DCF77 et quelques capteurs), j'envisage une alimentation externe.

Je pense utiliser un transfo 220AC/12DC puis utiliser un régulateur de tension (j'arrive pas à lire sa référence, il fait trop sombre ^^) pour revenir en 5v avec si mes souvenirs sont bon, un condensateur et une diode.

J'avais un peu peur d'utiliser une alimentation externe et le pickit en même temps, je ferai quelques recherches car je sais pas si je dois connecter vdd et vss du pickit si j'alimente autrement.

En parlant du pickit, maintenant, j'utilise RB4 à RB7 pour mes boutons poussoirs (j'ai connecté que RB4 pour l'instant), en sachant que j'utilise PGD (RB7), PGC (RB6) et PGM (RB5) pour le pickit, es ce que ça pose problème d'utiliser ces broches comme une entrée de bouton poussoir (ou autre) et donc de brancher d'autres composants en même temps sur ces broches pour le montage final ?

Autre chose, dans ton exemple, tu as mis PORTB_PULLUPS_OFF, moi j'ai mis sur ON et donc j'ai enlevé ma résistance de pull up, normalement c'est la même chose ?

Pour le mode Debug bien sur dans ton fusible.h tu mets la directive #pragma config DEBUG à ON. Tu peux d'ailleurs passer en Release en la laissant sur ON ca marche aussi.

Pour l'alim, bah rien à changer pour l'instant

Pour les poussoirs tu ne peux donc plus utiliser RB5->RB7, mais il y a aussi RB0->RB2, ces trois pins possèdent aussi une interruption, mais elles fonctionnent différemment car elles sont plus complètes. Tu déclenches les interruptions sur un front montant ou descendant et elles ont chacunes leurs fonctions d'ouverture. Tu seras donc amené à coder quelque chose comme cela

Code:

    OpenRB0INT(PORTB_CHANGE_INT_ON & RISING_EDGE_INT & PORTB_PULLUPS_OFF & PORTB_INT_PRIO_HIGH);

    OpenRB1INT(PORTB_CHANGE_INT_ON & FALLING_EDGE_INT & PORTB_PULLUPS_OFF & PORTB_INT_PRIO_LOW);
   
    OpenRB2INT(PORTB_CHANGE_INT_ON & RISING_EDGE_INT & PORTB_PULLUPS_OFF & PORTB_INT_PRIO_LOW);

et dans le service d'interruptions

    if(INTCONbits.INT0IF)
    {
        INTCONbits.INT0IF = 0;
    }
   
    if(INTCON3bits.INT1IF)
    {
        INTCON3bits.INT1IF = 0;
    }
    if(INTCON3bits.INT2IF)
    {
        INTCON3bits.INT2IF = 0;
    }

Pour les pull_up pas de soucis c'est à ton choix

J'ai encore quelques difficultés avec les interruptions.

Je pense avoir isolé/corrigé quelques une de mes erreurs et j'ai quelques bizarreries. Mon anglais est pas top et dans mes recherches, il y a des gens qui donnent de bonnes réponses et des guignols qui m'embrouillent si bien que je ne suis jamais certain de ce que je découvre...

1. Quand une variable est utilisé dans le main et dans une interruption, on doit utiliser "volatile" pour déclarer la variable. (Je pense que c'est vrai)

2. J'ai commencé à étudier les PIC en ASM, je me souviens que lors d'une interruption, on doit sauvegarder au minimum SFR et W en début d'interruption et les restaurer à la fin pour reprendre le déroulement du programme dans l'état ou il était avant l'interruption. (Je pense qu'en C c'est fait automatiquement, je me trompe ?)

3. J'ai lu qu'on ne pouvais pas désactiver une interruption dans une routine d'interruption sous peine d'avoir un comportement aléatoire du PIC, ce que j'ai lu parle de GIE. ( Je pense que c'est vrai et que le fait de désactiver GIE dans une interruption ne restaure pas les registres automatiquement sauvegardés ~si ils sont bien sauvegardés~) Es-ce que je peux désactiver l'interruption RB dans la routine d'interruption RB (INTCONbits.RBIE = 0) ?

4. PORTB_INT_PRIO_LOW ne marche pas chez moi, je l'utilise comme ceci :

Code:

OpenPORTB(PORTB_CHANGE_INT_ON & PORTB_PULLUPS_ON & PORTB_INT_PRIO_LOW);

J'ai été obligé d'utiliser INTCON2bits.RBIP = 0; pour placer mes interruptions RB en priorité basse.

Voici la nouvelle version de ma carte capteur

Il y a encore quelques petits trucs qui m’échappent comme par exemple déclarer la variable i dans la routine d'interruption me provoque une erreur de compilation (O_o) (Syntax error, je comprend pas et j'ai été obligé de la déclarer en globale)

Pour utiliser une variable dans plusieurs fichiers (BPtable), j'ai été obligé de la déclarer 2x, une fois normalement dans mon main et une fois dans le fichier qui l'utilise avec "extern" devant (je crois que c'est normal)

Je crois que j'abuse de "volatile" aussi.

J'ai été surpris de ne pas avoir utilisé #include "contacts.c" pour que ce fichier soit pris en compte dans mon programme mais apparemment c'est normal.

Bref, j'ai encore quelques petites choses à approfondir mais dans l'ensemble, je suis content de mes modifications (Merci Phil pour ton aide).

Voici la source : C_Carte_Capteurs_V1

J'ai décidé de rester sur RB4->7 mal grès que certaines PIN sont utilisés par le pickit, je connecterai BP1->3 quand j'aurai terminé mon développement car ça me gêne d'utiliser des interruptions différentes pour 4 boutons exactement identiques.

Sinon pour la suite, je pense passer du temps à étudier le mode DEBUG, je veux apprendre à utiliser les interruptions CAN, les filtres etc

µA++

1. Grosso modo, le mot clé " volatile " indique au compilateur que la variable peut être modifiée par un évènement extérieur à ton programme.

Pour optimiser le code, lors de l’appel d’une routine, les compilateurs mettent généralement les variables dans des registres, ils travaillent donc avec des copies. Si tu affectes ta variable du mot clé " volatile ", cette étape ne se fait pas et à chaque appel à ta variable, le programme ira lire sa valeur directement en mémoire, ce qui est plus long mais t’assure d’avoir toujours sa dernière valeur.
Si on en revient à notre PIC, des variable typiquement " volatile " sont les registres, par exemple PORTA, ils peuvent être modifiées par ton programme et aussi par les modules internes de ton PIC, c'est pourquoi dans le .h de ton PIC tu trouves :

Code:

extern volatile near unsigned char      PORTA;

Maintenant, si tu as une variable globale dans ton programme, utilisée dans le main() et dans une routine d'interruption ou autre, elle n'est modifiée que par ton programme et non par un évènement extérieur à ton programme (ta routine d'interruption, appartient à ton programme et à lui seul). Tu n'as donc pas besoin du mot clé " volatile ".

J'espère avoir été clair, car ce n'est pas facile à expliquer.


2. En C, on ne s'occupe pas d'empiler et dépiler. Ces opérations sont assurées par le code généré par le compilateur. Le seul soucis en C Microchip, c'est que l'on à pas l'équivalent de l'instruction assembleur RETFIE qui permet la sortie de l’interruption le retour au point ou le programme principal a été interrompu. C'est pourquoi on saute dans les routines interruptions par une instruction assembleur insérée dans le code C.

Code:

void low_interrupt(void)
{
    _asm GOTO LowHandler _endasm
}

3. En fait c'est le PIC qui gère. Dans le principe et sans utilisation des niveaux de priorité, lorsqu'une interruption est générée, le PIC positionne le bit INTCON.GIE à 0, ce qui t'assure de ne pas être interrompu en cours d'interruption. A la fin de la routine d'interruption, il remet le bit INTCON.GIE à 1 et se rebranche au point ou le programme principal à été interrompu. Mais dès l'instant ou le bit INTCON.GIE est positionné à 1, il ne faut pas être à nouveau interrompu avant le retour effectif au programme principal et c'est le RETFIE qui nous l'assure.
Si on écrit

Code:

INTCON.GIE = 1;
return;

on peut être interrompu entre les deux instructions.
Donc, on ne touche pas à INTCON.GIE dans une routine d'interruption



4. PORTB_INT_PRIO_HIGH n'est pris en compte que dans OpenRB0INT, OpenRB1INT et OpenRB2INT. Ca fait partie des illogismes de la sauce Microchip . . .

D'accord, je comprend mieux.

Donc je peux supprimer tous les volatile que j'ai utilisé et même sur la propriété PORT de ma structure puisque j'utilise un pointeur vers PORTB et non PORTB directement.

Oups c'est la réponse à ton avant dernier post.

J'ai très rapidement regardé ton source, il ne compile pas. Apparemment je n'ai pas le bon contact.c.

Les volatiles sont à mon avis inutiles, je te ferai une réponse plus détaillée en soirée ou demain.

Punaise, il était arrivé dans le dossier du dernier projet que j'ai ouvert...

Désolé, je viens de mettre à jour l'archive, c'est complet maintenant.

Salut,

Aujourd'hui j'ai cherché un moyen de connecter mon pic avec mon ordinateur, j'ai hésité entre le port série, l'usb ou ethernet.

Pour le port série, j'ai tous les composants mais j'ai plus de port série sur mon pc. Pour le port usb, ça a l'air pas mal et assez simple, j'essayerai pour le fun car j'ai pas trouvé de PIC qui fait USB et CAN. Du coup je me suis pris un EZL-50 pour l'ethernet, des quartz de 10Mhz et de 20Mhz pour tester différentes choses et les condensateurs qui vont bien

Pour la carte capteurs, je vais lui rajouter une sonde de température. J'en ai une qui fait I²C, ça peut être sympa.

Pour ma carte lumières, je vais modifier la réception CAN pour utiliser les interruptions et étudier un peu comment ça marche. Je vois pas bien l’intérêt d'utiliser les interruption pour envoyer une trame, je sais pas si j'en ai besoin pour l'instant.

J'ai refais un plan plus réel de mes circuits lumières, j'étudie mes besoins aussi car je cherche à optimiser notre façon de consommer plutôt que d'avoir un truc entièrement programmable.

Je vous tiens au courant, µA++