LE SYSTEME DOMOTIQUE DOMOCAN

PAR BIGONOFF

PRESENTATION GENERALE ET CARACTERISTIQUES Rvision 7

1. STRUCTURE DU SYSTME DOMOCAN...................................................................... 7 1.1 DESCRIPTION GNRALE .................................................................................................... 7 1.2 SYNOPTIQUE DUNE INSTALLATION DOMOCAN .................................................................. 9 1.3 LE CBLAGE PHYSIQUE SUR SITE ...................................................................................... 10 2. CONSTITUTION DES TRAMES CAN .......................................................................... 15 2.1 GNRALITS ................................................................................................................... 15 2.2 LES DIFFRENTS TYPES DE TRAMES CAN .......................................................................... 16 2.3 LA TRAME DATA ............................................................................................................ 16 2.3.1 Le champ darbitrage ............................................................................................... 17 3. CAN APPLIQU AU SYSTME DOMOCAN .............................................................. 19 3.1 LIDENTIFICATEUR ........................................................................................................... 19 3.2 PHILOSOPHIE DUN MESSAGE CAN ................................................................................... 19 3.3 STRUCTURE GNRALE DUN IDENTIFICATEUR DOMOCAN ............................................... 21 3.3.1 Les commandes broadcast .................................................................................. 21 3.4 LES COMMANDES COMMUNES .......................................................................................... 22 3.5 LES TRAMES DADMINISTRATION ..................................................................................... 24 3.6 LA TRAME DERREUR DOMOCAN...................................................................................... 24 3.7 PRIORITS DES TRAMES .................................................................................................... 26 4. GESTION PHYSIQUE ET CARACTRISTIQUES TECHNIQUES ......................... 27 4.1 CARACTRISTIQUES TECHNIQUES GNRALES ................................................................. 27 4.2 SUPPORT PHYSIQUE .......................................................................................................... 27 5. PARTICULARITS COMMUNES TOUTES LES CARTES .................................. 29 5.1 AVERTISSEMENT .............................................................................................................. 29 5.2 LE TYPE DE PIC............................................................................................................. 29 5.3 LA ZONE EEPROM 1 .......................................................................................................... 30 5.3.1 Len-tte.................................................................................................................... 30 5.3.2 La cible ..................................................................................................................... 31 5.3.3 Le mode de fonctionnement ...................................................................................... 31 5.3.4 La zone utilisateur .................................................................................................... 32 5.3.5 Le nom de la carte .................................................................................................... 32 5.3.6 Le nombre de fonctions gres ................................................................................. 33 5.4 LA ZONE EEPROM 2 .......................................................................................................... 33 5.4.1 La rvision software ................................................................................................. 34 5.5 LA ZONE EEPROM 3 .......................................................................................................... 34 6. LES ERREURS GNRALES......................................................................................... 35 6.1 TABLEAU DES ERREURS GNRALES RECONNUES............................................................. 35 6.2 DESCRIPTIF DES ERREURS GNRALES ............................................................................. 36 6.2.1 Err_G1...................................................................................................................... 36 6.2.2 Err_G2...................................................................................................................... 36 6.2.3 Err_G3...................................................................................................................... 36 6.2.4 Err_G4...................................................................................................................... 37 6.2.5 Err_G5...................................................................................................................... 37 6.2.6 Err_G6...................................................................................................................... 38 6.2.7 Err_G7...................................................................................................................... 38

6.2.8 Err_G8...................................................................................................................... 38 6.2.9 Err_G9...................................................................................................................... 39 6.2.10 Err_G10.................................................................................................................. 39 6.2.11 Err_G11.................................................................................................................. 39 6.2.12 Err_G12.................................................................................................................. 39 6.2.13 Err_G13.................................................................................................................. 39 6.2.14 Err_G14.................................................................................................................. 40 6.2.15 Err_G15.................................................................................................................. 40 6.2.16 Err_G16.................................................................................................................. 40 7. LES COMMANDES COMMUNES RECONNUES....................................................... 41 7.1 RAPPEL ............................................................................................................................ 41 7.2 TABLEAU DES COMMANDES COMMUNES .......................................................................... 41 7.3 DTAILS DES COMMANDES COMMUNES ............................................................................ 42 7.3.1 CC_OutBoot ............................................................................................................. 43 7.3.2 CC_WPtrF ................................................................................................................ 44 7.3.3 CC_RPtrF................................................................................................................. 44 7.3.4 CC_WFlash .............................................................................................................. 45 7.3.5 CC_RFlash ............................................................................................................... 45 7.3.6 CC_WEep ................................................................................................................. 46 7.3.7 CC_REep .................................................................................................................. 46 7.3.8 CC_RCarte ............................................................................................................... 47 7.3.9 CC_WZone................................................................................................................ 47 7.3.10 CC_RZone .............................................................................................................. 47 7.3.11 CC_WNameC.......................................................................................................... 48 7.3.12 CC_RNameC .......................................................................................................... 48 7.3.13 CC_WNewCible...................................................................................................... 48 7.3.14 CC_GoBoot ............................................................................................................ 49 7.3.15 CC_WModeC.......................................................................................................... 50 7.3.16 CC_Reset ................................................................................................................ 51 7.3.17 CC_Carte................................................................................................................ 51 7.3.18 CC_Eep................................................................................................................... 52 7.3.19 CC_PtrF ................................................................................................................. 53 7.3.20 CC_Flash................................................................................................................ 53 7.3.21 Cmd_Zone............................................................................................................... 54 7.3.22 Cmd_NameC........................................................................................................... 54 7.3.23 Cmd_NewCible....................................................................................................... 54 7.4 UN MOT SUR LES MASQUES ET FILTRES............................................................................. 55 8. FICHIERS DE BASE DUN LOGICIEL DOMOCAN.................................................. 61 8.1 LES FICHIERS NCESSAIRES .............................................................................................. 61 8.2 LE FICHIER DOMODEF.INC ................................................................................................ 62 8.3 LE FICHIER DOMOBOOT.INC ........................................................................................ 77 8.4 LE FICHIER CCOMMUNES.INC......................................................................................... 103 8.5 LE FICHIER PARCAN.INC ................................................................................................ 107 8.6 LE FICHIER CONFIGURATIONS.INC .................................................................................. 110 8.7 LE FICHIER FONCTIONS.INC ............................................................................................ 115 8.8 LE FICHIER BASE.ASM ............................................................................................... 120 8.9 ASTUCE DE PROGRAMMATION ........................................................................................ 149 A. ANNEXES........................................................................................................................ 153

A.1 TABLEAU DES TYPES DE CARTE ..................................................................................... 153 A.2 TABLEAU DES ERREURS RECONNUES ............................................................................. 153 A.3 LES FICHIERS ................................................................................................................. 154 9. UTILISATION DU PRSENT DOCUMENT .............................................................. 157

1. Structure du systme Domocan

1.1 Description gnrale Le systme domotique Domocan est un systme modulaire bas sur des cartes microcontrleur connectes sur un bus Can travaillant une vitesse paramtrable jusque 1Mbits/s. La vitesse par dfaut est de 500 Kbits/s, vitesse valide sur des bus dont les longueurs sont infrieures ou gales 100m. Lutilisateur est responsable de ladquation entre la vitesse choisie et les paramtres physiques de son rseau (dont la longueur). A titre dinformation, je teste chaque carte sur mon propre bus Domocan, dune longueur approximative de 120m, et rgl un dbit de 333Kbits/s. Je dcline toute responsabilit pour toute consquence directe ou indirecte rsultant de lensemble des documents, schmas ou tout autre document en rapport direct ou indirect avec le systme propos. Je conserve tous les droits pour une exploitation commerciale ventuelle. Une carte est une entit physique qui comprend au moins un microcontroleur et un accs au bus Domocan, et accessible par un identificateur de carte et un numro de carte. Chaque carte peut remplir une ou plusieurs fonctions et grer un ou plusieurs lments extrieurs. Le rseau pourra accueillir un maximum de 112 cartes sans ncessiter de rptiteur. Le systme pourra tre tendu plusieurs milliers de cartes en utilisant des rptiteurs Can standards ou lutilisation de cartes dinterfaces spcifiques. Si le besoin sen fait sentir, je proposerais la ralisation dun tel rptiteur, mais la carte dinterface Can/Ethernet disponible sur mon site permet dj lextension du systme. De ce fait, le systme Domocan peut tre utilis aussi bien en configuration domestique que pour des applications de plus grande envergure. Il ny a donc en pratique pas de limitation raliste de la taille du systme, autre que la saturation ventuelle du bus Can. A partir de la rvision 6 de ce document, la stratgie complte du systme a t repense, il nexiste plus de restriction quant au nombre de cartes gres par les diffrents logiciels. Domogest est donc en mesure de grer un rseau Domocan dans sa configuration maximale. De plus, toujours partir de cette rvision 6, les paramtres Can sont librement configurables par lutilisateur. A partir de la rvision 7, le document est recentr sur lutilisation des nouveaux PIC de type 18Fxx80, et plus particulirement des 18F2580, 18F4580, 18F2680, et 18F4680, et ce en remplacement des anciens modles obsoltes de type 18Fxx8 (18F248 et 18F258). Les cartes disposant danciennes versions de PIC continuent dtre supportes, excepte la carte dinterface Can/RS232, mais tout nouvel upgrade de ces cartes saccompagnera dun remplacement obligatoire du PIC par un des nouveaux modles prcits. Dit de faon plus explicite, il ny aura plus aucun fichier futur portant sur les anciens modles.

Le systme est prvu pour fonctionner de faon dcentralise, et ne ncessite donc aucune unit centrale (PC ou autre) pour fonctionner. Une unit centrale sera cependant ncessaire pour configurer le systme ou accder certaines fonctions de supervision. Il est cependant possible dutiliser une unit centrale reprenant tout ou partie du traitement des donnes. De ce fait, les cartes peuvent tre individuellement paramtres pour fonctionner soit en mode centralis, soit en mode dcentralis. Ceci permet donc une libert totale de conception du systme : Soit compltement dcentralis Soit compltement centralis Soit une combinaison des deux. Soit une commutation automatique entre les diffrents modes.

Par dfaut, les cartes sont configures en mode dcentralis, ce qui permet le maximum de fonctions locales. La commutation de mode seffectue de faon simple par lenvoi de commandes via le logiciel PC de gestion Domogest. Le systme Domocan ncessite une installation lectrique conue expressment, avec notamment la prsence dun bus. Ce systme est donc plus orient vers les nouvelles habitations ou les habitations sujettes forte rnovation du systme lectrique. La cration dun systme par courant porteur ou autre systme pour habitation existante aurait conduit la ralisation dun systme peu performant et avec un surcot important. Les applications commerciales de ce type ne manquent pas, et ne prsentent ds lors pour moi aucun intrt. Ceci sans compter que la lgislation de plusieurs pays interdit dinjecter des signaux sur les lignes lectriques sans homologation. Je rappelle ce sujet que les ralisations personnelles ne sont pas sujettes limposition de ltiquette CE pour autant quelles soient ralises pour compte propre et non commercialises. La loi (belge) permet lamateur de piloter son installation lectrique laide de ses propres cartes, pour autant quil respecte le Rglement Gnral sur les Installations Electriques (RGIE). Du reste, ma propre installation lectrique contenant mes cartes Domocan a t lgalement rceptionne sans aucun problme. Renseignez-vous cependant par tlphone avant de contacter une entreprise de rception, car daprs ma propre exprience, certains ingnieurs ont tendance refuser en bloc et sans raison lgale tout ce qui sort de linstallation lectrique classique. Les diffrents systmes de bus commerciaux actuellement disponibles sont pratiquement tous incompatibles. Chacun dveloppe son propre systme, sans aucune concertation. Partant de l, jai prfr mon propre systme adapt aux exigences dun amateur clair, plutt que de copier ce qui existe dj. Notez quil nest nullement ncessaire de lire et comprendre lintgralit de ce document pour utiliser Domocan. Toutes les explications dtailles vous permettront cependant de raliser vos propres cartes et applications sur base de Domocan si vous le dsirez. Une simple lecture est cependant conseille de faon comprendre les diffrents termes utiliss dans les autres documents et dans Domogest (logiciel de gestion PC de Domocan)

1.2 Synoptique dune installation Domocan Voici le schma de principe dune installation typique. Les lignes 220V ne sont pas reprsentes, et dpendent des cartes utilises.

Vous noterez la prsence de deux types de cartes, les cartes locales et les cartes centralises. Il est vident que du point de vue fonctionnel, ces cartes sont identiques, mais selon votre installation, il sera plus pratique dutiliser certaines dans le tableau lectrique (principal ou secondaire) ou directement sur le lieu de lapplication. Une carte qui comporte 16 entres, par exemple, sera place judicieusement dans une armoire centralise, les liaisons seffectuant vers les pices avec un simple multipaire de faible section. Par contre, une carte affichant lheure devra naturellement tre place sur le site concern, de mme quune carte pour touches sensitives murales, quil est impossible de centraliser par dfinition. Notez que chaque carte dispose au minimum dun connecteur Can 4 pins. Lordre de ces pins est standard pour toutes les cartes qui seront proposes, savoir : 1 : +12V non rgul 2 : CanH 3 : CanL 4 : Masse Lunit centrale naura pas besoin dtre connecte en permanence. Aussi, il peut tre judicieux de prvoir quelques points de connexion par connecteurs dans lhabitation pour y insrer PC ou carte dexprimentation. A moins que vous ne dcidiez dopter demble pour

la carte dinterface Can/Ethernet, ce qui vous permet daccder votre bus domotique partir de votre rseau local, et mme en Wifi. Si vous exprimentez une carte sur votre bureau, sans liaison avec le systme Domocan, et relie uniquement avec votre interface RS232 par exemple, noubliez pas de placer au minimum une rsistance de 120 ohms sur vos fils de transmission Can. Sans cette prcaution, votre carte ne pourra pas fonctionner. Sur site, une rsistance sera laisse en permanence chaque extrmit de votre cble Can, cest trs important.

1.3 Le cblage physique sur site Au niveau du cble Can, vous ne pouvez pas cbler en toile. Vous aurez donc un seul et unique cble Can sur lequel se connectent les cartes par un cble court (quelques cm). Scinder le cble Can vers deux directions diffrentes est interdit, vous devez vous arranger pour former une sorte de boucle non ferme, en traversant toutes les pices concernes de votre habitation. Sil tait ncessaire pour des raisons de distances deffectuer un montage en toile, il sera impratif dutiliser un rptiteur lendroit de la drivation, avec, de nouveau, une rsistance de 120 ohms chaque extrmit de la ligne ainsi cre. Vous pouvez aussi utiliser la carte dinterface Can/Ethernet pour crer plusieurs branches Can distinctes, distance ou en toile. Reportez-vous la documentation de cette carte pour savoir comment procder. Voici la faon la plus simple de raliser votre bus Can de faon correcte : Vous constatez sur ce schma de principe un seul cble Can, muni dune rsistance de charge chaque extrmit. Chaque carte est relie au cble Can avec une liaison de quelques cm maximum. Le cble ne comporte pas de drivation :

10

Voici maintenant une faon incorrecte de raliser votre bus. En imaginant lannexe distante du btiment principal, vous pourriez imaginer deffectuer un dpart spar, ce qui, par rapport au montage prcdent, vous vite un aller-retour vers lannexe :

11

Vous constatez cependant dans ce cas que vous avez une drivation de votre bus Can, ce qui vous place dans une impossibilit de ralisation correcte. En effet, si vous ralisez telle quelle cette installation, le cble Can qui se termine dans lannexe na pas de rsistance de charge. Vous allez donc avoir des rflexions parasites sur lextrmit du cble, ce qui risque fort dinduire un dysfonctionnement gnral du systme. Si, par contre, vous placez une rsistance de charge galement cet endroit, ladaptation dimpdance sera incorrecte, car les cartes verront une rsistance de charge supplmentaire. Cette solution nest pas autorise pour un bus Can. Si vous dsirez procder de cette faon, vous devez utiliser un rptiteur de bus Can, qui permet de charger chaque extrmit du nouveau cble sans perturber le cble principal. Cest ce que montre ce schma :

Notez que le cble allant vers lannexe dispose maintenant de sa rsistance de charge, laquelle nest pas vue par le cble principal, car isole par le rptiteur. La rsistance de charge de dpart du cble vers lannexe est incluse dans le rptiteur et existe de fait physiquement. Vous avez donc bien 2 cbles et 4 rsistances de charge. Notez galement que cette mthode vous permet dutiliser 112 cartes sur le bus principal, et 112 autres cartes sur le bus au dpart de lannexe. Cette mthode permet donc galement daugmenter le nombre de cartes autorises. Les rptiteurs se trouvent dans le commerce, je nexclus pas den raliser un. La section de votre cble Can sera videmment suffisante pour vhiculer lalimentation ncessaire lintgralit des cartes prsentes. Le cble sera prvu pour vhiculer des

12

informations haute-vitesse en mode diffrentiel. Jai pour ma part utilis 2 cbles simultanment : un simple cte cte pour lalimentation, et un cble de type FTP pour le bus Can en lui-mme. Note trs importante : Pour viter tout problme en cas de parasites CEM, et tout dgt occasionn par la foudre, vous devez respecter les rgles lmentaires de CEM. Pour ce faire : Connectez le 0V de lalimentation gnrale la masse du btiment en sortie dalimentation Connectez le blindage ventuel du cble la masse du btiment Connectez toutes les masses des cartes entre elles, et aux masses environnantes (botiers, armoires, etc.), elles-mmes interconnectes entre elles. Encastrez le cble autant que possible, en vitant les goulottes en plastique, surtout si le cble nest pas blind. Veillez ne pas interrompre le blindage du cble lorsque vous ajoutez une carte : reliez directement les blindages entre eux, sans utiliser de fil supplmentaire, reliez chaque fois que cest possible le 0V au blindage du cble. Utilisez des limiteurs de surtension chaque endroit stratgique, principalement sur les points dentre et de sortie sur le cble Can. Nhsitez pas relier la masse du cble et le 0V de lalimentation chaque structure mtallique de masse du btiment, chaque fois que cest possible.

Plus vos masses seront mailles, plus votre rfrence 0V sera quipotentielle, moindre sera le risque dune destruction en cas dorage, et moins vous mettrez de parasites dans votre environnement. Utilisez les structures mtalliques du btiment comme masses supplmentaires, reliez le tout au conducteur de protection (et de fait la terre) en un maximum dendroit, le 0V sera rfrenc la masse gnrale, et donc la terre de votre installation lectrique. Si votre bus joint deux btiments quips de mise la terre distinctes, vous devez interconnecter ces btiments laide dune liaison optocouple.

13

Notes :

14

2. Constitution des trames Can

Dans cette partie, je vais traiter de quelques gnralits du bus Can, sans entrer dans trop de dtails techniques. Je vous renvoie chez Bosch, inventeur du bus Can si vous souhaitez approfondir cette technologie. 2.1 Gnralits Toutes les trames utilises par le systme domotique Domocan, et donc par toutes les cartes qui le composent, sont des trames de type extended, comme dfinies dans la norme Can 2.0B. Ceci signifie simplement que les identificateurs des messages sont cods sur 29 bits au lieu de 11 pour les trames standard . Domocan nutilise de plus que des trames de type data , les trames remote ne sont pas utilises, mme si leur utilisation ne perturbe pas le bus existant. La norme Can prvoit deux sortes de niveaux sur les lignes : le niveau dominant, et le niveau rcessif. En raison de la technologie employe pour le Domocan les niveaux sont dfinis comme suit : Niveau dominant = niveau logique 0 Niveau rcessif = niveau logique 1

Ce systme de niveaux dominants et rcessifs permet dautoriser des collisions entre les messages sans que cela endommage le message le plus prioritaire. On appelle cela une collision non destructrice. Le premier intervenant qui constate quaprs avoir plac un niveau rcessif sur la ligne, sy trouve un niveau dominant, sait quun autre intervenant a plac ce niveau, et donc se retire immdiatement de la conversation. Lintervenant qui a plac le niveau dominant ne se rend mme pas compte quil y a eu une autre tentative dcriture. Un des grands avantages du bus Can, cest que le renvoi du message par celui qui a t interrompu est automatique, et gr hardwarement par le gestionnaire du bus Can (le PIC). Autrement dit, le logiciel du ct PIC na mme pas besoin de savoir ce qui sest pass. Le programme place la donne dans le registre concern, et lutilisateur est certain que sa donne arrive destination (sauf panne). Le hardware se chargera de rpter le message jusqu ce quil ne soit plus interrompu. En cas dimpossibilit, le programme se verra notifier le problme. Les trames comportent un systme automatique de vrification. Si une trame arrive endommage un destinataire, celui-ci le fait savoir automatiquement lmetteur, qui renvoie galement automatiquement la trame concerne. De nouveau, cest compltement transparent pour lutilisateur, qui est ds lors certain de la bonne rception de son message. Si une carte constate quelle a un problme permanent de communication Can, elle se coupe elle-mme automatiquement du bus, ce qui vite de causer une panne gnrale en bloquant le bus. De mme, un PIC en panne, qui imposerait un niveau dominant en permanence sur le bus, se verrait coup du dit bus automatiquement par le driver MCP2551, qui dispose de scurits hardwares ce niveau. Les probabilits dune panne locale entranant

15

une panne totale sont donc extrmement limites, ce qui contribue rendre ce systme trs performant et sr. Par contre, le Can nest pas dterministe, ce qui signifie quon ne peut jamais tre certain de linstant prcis o sera dlivr le message. Ca na aucune espce dimportance dans une application comme la ntre. Concernant les mcanismes derreur, sachez que la probabilit quune erreur ne soit pas dtecte est de 4.7 * 10 -11 Le bus Can est donc un bus trs fiable, ce nest pas pour rien quil est utilis en automobile (F1) mme pour des commandes critiques (gestion de lABS par exemple), et ce, quoi quen disent de prtendus spcialistes sur certains forums du web. De plus, le driver est protg aussi bien contre les surtensions que contre les courtscircuits et la surcharge thermique. Ajoutez ceci que votre systme Domocan est dcentralis, et, part le risque dune panne gnrale dalimentation, les chances de tomber en panne totale sont extrmement limites. Je proposerai en temps utile des schmas pour une alimentation de secours automatique.

2.2 Les diffrents types de trames Can La norme Can prvoit plusieurs types de trames : La trame DATA : celle dont nous allons parler : contient un message envoy depuis un expditeur vers lensemble des autres cartes. La trame REMOTE : Il sagit dune requte denvoi dune information spcifique. Les trames remotes ne sont pas utilises dans le Domocan, elles sont remplaces par des identificateurs diffrents concernant les requtes et les rponses. Cette mthode permet un gain de temps de traitement, par limination des trames non dsires de faon hardware. La trame ERROR : Gre automatiquement par le hardware, permet le renvoi automatique de trames errones. Rfrez-vous la norme Can pour plus dexplications. Cette trame est transparente au niveau de lutilisateur final, car elle est gre de faon automatique par le module Can hardware du PIC. En fait, peut vous importe donc comment elle est utilise, vous ne la voyez pas. La trame OVERLOAD : Sert crer un dlai entre des envois successifs de trames. De nouveau, cette trame est transparente pour lutilisateur final.

2.3 La trame DATA Comme nous venons de le voir, la seule trame dont doit soccuper le dveloppeur final Domocan est la trame de type Data . Une trame DATA extended est constitue de :

16

Un dbut de trame, ou SOF (Start Of Frame) : constitue dun unique bit dominant (0). Un champs darbitrage de 32 bits, que nous allons examiner en dtails. Un champs de contrle de 6 bits, dont les 2 premiers sont rservs et envoys comme bits dominants (niveau 0 dans notre cas). Les 4 derniers indiquent le nombre doctets de data prsents dans la trame (de 0 8 autoriss). Pour le cas dune trame remote, ce nombre indique combien doctets sont prvus en rponse. Nous nutilisons pas de trames de type remote, cependant, les diffrentes cartes dinterface proposes grent parfaitement ces trames, il ne sagit donc en rien dune limitation, mais juste dun choix. Un champ de data, constitu de 0 8 octets de data, selon la valeur indique dans le champs de contrle. Un champ de CRC (Code de Redondance Cyclique = dtection derreur), cod sur 16 bits, constitu de 15 bits actifs suivi par un bit de dlimitation. Un champ dacquittement de 2 bits. Un champ de fin de trame, constitu de 7 bits conscutifs rcessifs.

Plusieurs de ces bits sont pris en charge automatiquement par le gestionnaire Can intgr au PIC. Lutilisateur na donc pas sen proccuper. Nous verrons uniquement les informations dont nous devons tenir compte. Vu par lutilisateur final, une trame Can est ainsi constitue uniquement par : Un identificateur (ID) cod sur 29 bits spars en 4 registres de 8, 5, 8, et 8 bits Une valeur de 0 8 reprsentant le nombre doctets de data joints la trame. De 0 8 octets de data selon ce que prcise la valeur prcdente. Soit une trame de 5 13 octets en fonction du nombre doctets de data. Cest tout ce que lutilisateur doit prendre en compte une fois le bus paramtr de faon correcte. Or, le paramtrage fait partie des fonctions de base que je vous livre avec Domocan. Je vous donne les explications afin que vous sachiez comment tout ceci fonctionne, mais il nest pas impratif de tout comprendre. Notez quune trame Can permet de joindre un maximum de 8 octets de data. Ce bus est en effet conu pour lenvoi de messages courts, mais trs rapides, ce qui convient tout fait pour notre application.

2.3.1 Le champ darbitrage Le champ darbitrage contient lidentificateur du message. Or, cest dans ce champ que vont tre dfinis les diffrents types de messages utiliss. Cest le champ principal dont nous parlerons.

17

La partie qui nous intresse sappelle lidentificateur, ou ID. Cest en quelque sorte lentte de la trame, qui permet, comme son nom lindique, didentifier la trame, son contenu, sa signification. En Can, une trame est envoye tout qui en a besoin, il ny a pas de notion de destinataire de trame, lidentificateur permet uniquement didentifier la trame en elle-mme. Cependant, Domocan a besoin de pouvoir cibler des cartes prcises, et donc certains champs de lidentificateur permettent de sadresser une carte prcise en particulier, le destinataire est donc un concept Domocan. La norme Can prvoit deux longueurs possibles didentificateur : Soit une longueur de 11 bits (standard), soit une longueur de 29 bits (extended). Domocan utilise exclusivement des identificateurs de type tendu, portant de fait sur une longueur de 29 bits, et conformes la norme Can 2.0b. La construction de lID est en rapport avec lapplication, et est librement dfinissable par lutilisateur. Le principe dune liaison Can est denvoyer sur le bus un message dont la signification est indique par son identificateur. Chaque carte qui a besoin de ce message lintercepte, les autres lignorent.

18

3. Can appliqu au systme Domocan

3.1 Lidentificateur Le systme Domocan scinde par pure convention les 29 bits de lidentificateur en plusieurs groupes. Un identificateur (ID) dune carte Domocan sera toujours de la forme : ID : dddddddd ccccc nnnnnnnn pppppppp La sparation 8, 5, 8, 8 bits peut sembler curieuse, mais elle est due la faon dont les identificateurs sont stocks lintrieur du PIC. Cette faon de scinder lID facilite donc la gestion logicielle. Or, comme cest nous qui programmons, pourquoi nous compliquer la vie ? En rapport avec les noms des registres, vous trouverez dans les diffrents logiciels les suffixes suivants : SIDH : contient les 8 bits d . Cette zone sera appele : Destinataire SIDL : contient les 5 bits c . Cette zone sera appele : Commande EIDH : contient les 8 bits n . Cette zone sera appele : N de carte, ou Cible EIDL : contient les 8 bits p . Cette zone sera appele : Paramtre Notez sur dans un bus Can donn, lutilisateur est entirement libre dutiliser les 29 bits de lID comme bon lui semble. La norme Can nimpose rien, chacun rpartit donc ces bits en fonction de son application. Remarquez ainsi que lorsquun magasine dlectronique (jen connais) vous propose une superbe carte Can sans vous donner le rle des ID utiliss, vous ne disposez pas des informations ncessaires pour exploiter cette carte.

3.2 Philosophie dun message Can Il est important de comprendre quun message Can est mis sur le bus destination de qui veut bien le recevoir. Cest lID qui permet deffectuer lidentification du message. LID nest donc pas ladresse du destinataire, mais identifie le message. Pour tre certain de bien me faire comprendre : Avec un systme de type adresse, comme sur le RS485, on envoie un message destination dun destinataire. Avec un systme comme le Can, vous considrez le message comme un mail du type spam . Si votre bote est configure pour accepter ce type de message, vous le recevrez. Si vous utilisez un filtre anti-spam, vous recevrez vos mails en fonction des paramtres dfinis dans votre filtre. Cest exactement comme a que fonctionne le Can. A vous de configurer votre filtre pour recevoir tous les mails utiles (pour vous), et pour viter den recevoir des inutiles (ce qui vous conduirait devoir les lire avant de les jeter la poubelle, ce qui prend du temps). Il est important galement de comprendre que nimporte quelle carte peut mettre nimporte quel moment, le hardware se charge damener les trames bon port.

19

En effet, il ne sagit pas ici dune liaison entre un metteur et un rcepteur, mais dun message envoy par un metteur sur le bus, destination de qui en a besoin, et donc destination de qui est configur pour le recevoir (nous verrons comment dans les documentations spcifiques). Pour faire une analogie avec la vie courante, il sagit dun ensemble dinterlocuteurs dans lequel tout le monde peut parler quand il veut. Cest le message cri le plus fort (dominant) qui sera entendu le premier, les autres seront rpts par la suite. Notez que cest le message qui est dominant, et non celui qui lenvoie. Une mme carte peut donc envoyer des messages de priorit leve et dautres de faible priorit. Lmetteur ne sait pas forcment le nombre de cartes intresses par son message, et il na pas le savoir. Par contre, il faut au moins une carte autre que lui-mme prsente sur le bus (mme si le message ne lui est pas destin), sinon il rptera son message automatiquement indfiniment. Notez quun bus avec une seule carte na pas grand intrt, mais cest bon de le savoir en phase dessais au labo, jai dj reu plusieurs S.O.S dinternautes dsesprs en testant leur unique carte se bloquant systmatiquement, led Can allume. Imaginons par exemple une carte horloge mre qui envoie lheure et la date sur le bus Can toutes les secondes. Et bien, cette carte se contente denvoyer son message, sans se soucier de qui va le lire. Toute carte prsente sur le bus qui aura besoin de cette information pourra la lire sans problme. La slection des messages se fait de faon hardware par configuration du PIC, et un message qui ne concerne pas la carte nest tout simplement pas pris en compte, et ne consomme aucun temps CPU. Le filtrage est en effet assur de faon hardware par le module Can des PIC. Notez donc, si vous comprenez bien, que toute carte prsente sur le bus qui y envoie ou traite des informations particulires enrichit les fonctions du bus. Si, par exemple, vous crez une horloge mre qui envoie lheure toutes les secondes, vous pourrez crer ailleurs une carte minuterie qui utilisera lheure reue, ou une carte horloge esclave qui affichera lheure systme dans une pice donne. Si vous ajoutez lensemble une carte qui donne des informations mto, vous pourrez crer une fonction darrosage automatique sur une carte de sortie, en rcuprant les informations dheure et de mto en provenance des autres cartes.

20

3.3 Structure gnrale dun identificateur Domocan La structure, nous lavons dit, rpondra dans Domocan aux conventions suivantes (chaque lettre reprsente un bit) : ID : dddddddd ccccc nnnnnnnn pppppppp Nous retrouvons : dddddddd ccccc nnnnnnnn pppppppp : Type de destinataire, par exemple carte de type gradateur : Commande : Prcise la nature de la commande, ex : allumer une lampe : Numro de la carte cible : Exemple, carte n 8 : Paramtre complmentaire : dpend de la commande : exemple, lampe n5

Dans cet exemple, lID prcise : Sur la carte gradateur n 8, allumer la lampe n 5. La valeur de lintensit ainsi que la vitesse de variation seront dans ce cas prciss dans les octets de data accompagnant lidentificateur. Mais une commande peut fort bien se contenter dun unique identificateur sans octet de data. Notez galement que chaque carte reoit des commandes Can et en gnre elle-mme. Le destinataire identifi dans lID peut soit reprsenter la carte qui met la commande, soit la carte qui est sense utiliser la commande. En effet, quoi que le Can permette lmission de commandes vers lensemble des cartes, il faut pouvoir cibler une carte particulire sense excuter une action particulire. Si vous allumez la sortie 5 de la carte gradateur n 8, vous ne dsirez pas forcment allumer la sortie 5 des autres cartes gradateur. Pour respecter la norme Can, les 7 premiers bits de lidentificateur ne peuvent pas tous tre rcessifs (1 dans notre cas). Autrement dit, les valeurs autorises pour le paramtre Type de destinataire vont de B00000000 B11111101, soit 254 possibilits (0 253). Vous pourrez objecter quil nest possible que de coder 32 commandes par type de carte (ce qui nest dj pas mal). En ralit, nous le verrons, une astuce permet de dpasser (et de loin), cette limite.

3.3.1 Les commandes broadcast Vous noterez que, par convention dans le systme Domocan, le n de carte (nnnnnnnn) n 255 est un numro rserv. Ce numro, appel adresse broadcast , permet denvoyer la mme commande toutes les cartes dun mme type prsentes sur le bus. Si donc on envoie une commande une carte de 0 254, une seule carte sera concerne. Par opposition, si on envoie cette commande la carte n 255, toutes les cartes du type concern recevront la commande et la traiteront. Il est ainsi possible, par exemple, dteindre toutes les lampes dune habitation laide dune seule commande, mme sil y a plusieurs cartes gradateur.

21

Notez que toutes les commandes nacceptent pas le mode broadcast. Il est ainsi possible de modifier lclairage de faon gnrale, mais pas, par exemple, de donner simultanment toutes les cartes gradateur le mme nom (ce qui est logique). Si vous envoyez une commande non compatible broadcast avec le n de carte 255, chaque carte concerne vous renverra un message derreur stipulant que la commande nest pas valide en mode broadcast. Un observateur attentif verra de suite quil est thoriquement possible davoir sur un mme bus Domocan 255 cartes de 254 types diffrents, soit un total de 64770 cartes. En ralit, certaines combinaisons, nous le verrons, sont rserves. Ceci vous donne toutefois une ide de la puissance potentielle de Domocan, surtout si vous imaginez quune simple carte gradateur, par exemple, pilote jusque 16 sorties en 50 niveaux. En utilisant des cartes 16 entres ou 16 sorties, par exemple, a porte le nombre thorique dentres/sorties plus de 1.000.000, ce qui dpasse de loin les besoins dune simple habitation, et mme dun complexe important, voire mme dune petite ville. De plus, rien nempche de concevoir des cartes de plusieurs dizaines dentres/sorties, constatez vous-mme que la limite nest que thorique. Lutilisateur qui dsire participer laventure et crer ses propres cartes compatibles mises disposition de tout le monde, pourra me demander des numros de type de carte. Ainsi, tout le monde restera compatible et nous pourrons ensemble voluer vers un systme de plus en plus riche.

3.4 Les commandes communes Il sagit en ralit dune seule commande, dont les 5 bits sont placs 0. Cette commande est appele Cmd_Comm . Lopration raliser (donc la commande proprement dite) est passe dans le paramtre (pppppppp ou EIDL). En ralit, une seule commande se subdivise en 256 sous-commandes, ce qui montre les limites relles du systme, et correspond lastuce dont je parlais plus haut. Toutes ces commandes sont des n de commandes qui sont utilises par lintgralit des cartes prsentes sur le bus. De ce fait, elles sont standardises. Elles sont donc de la forme : ID : dddddddd 00000 nnnnnnnn pppppppp avec : dddddddd 00000 nnnnnnnn pppppppp : type de destinataire : exemple : carte gradateur : 0 = commande commune : n de la carte cible : paramtre qui reprsente la nature de la commande. Ex : passer en bootloader

Notez quil nest reprsent que les 5 bits utilisateur du n de commande. Au vu de la structure relle du registre concern du PIC, sur 8 bits videmment, un des 3 bits inutiliss

22

pour lID doit tre mis 1 (pour signaler quon travaille avec des ID sur 29 bits). Utilisez de ce fait plutt la dfinition CMD_COMM pour les logiciels pics plutt que 00000 , a vous vitera de faire des confusions, car CMD_COMM tient compte de lorganisation relle du registre concern, dont la valeur vaut en ralit : B'00001000' Pour insister et bien vous faire comprendre : Chaque carte est identifie par un n de type de destinataire correspondant sa fonction Chaque type de destinataire accepte 32 commandes (0 31) Chaque carte dispose dun n de carte en plus de son type

La combinaison : type de carte + n de carte identifie une et une seule carte sur le bus. Cette combinaison, identifie : Soit la carte qui a envoy la commande (pour les trames mises par la carte) Soit la carte qui est destine la commande (pour les trames reues par la carte)

Le numro de commande 0 est la commande dite commune . Elle est comprise de faon identique par nimporte quelle carte du bus Domocan. La valeur place dans pppppppp prcise lopration relle raliser. Il y a donc 256 commandes communes toutes les cartes possibles, tout en nutilisant quune seule des 32 commandes disponibles. Les numros de commande 1 31 sont utilisables librement pour chacun des types de cartes existant sur le bus. Evidemment, rien nempche dutiliser la mme technique pour une commande dune carte donne. Par exemple, la commande 1 pour les cartes de type gradateur pourrait tre scinde en 256 sous-commandes, ce qui rend en pratique le systme extensible volont, vous ne rencontrerez aucune limite dutilisation, dautant que vous disposez en plus de 8 octets de data disponibles. Une commande commune pourra par exemple tre de la forme : 128 00 08 102 Ce qui pourrait vouloir dire (exemple fictif) : Pour toutes les cartes qui grent les commandes des prises de courant (128) Utilisation dune commande commune (00) On sadresse la carte n 8 (08) On dsire faire passer la carte en mode bootloader (102 = 0x66 = Cc_GoBoot)

Les chiffres donns ne correspondent pas aux valeurs choisies en ralit pour les cartes, mais a vous montre le processus. Moralit, lorsque vous faites une modification de logiciel, par exemple, vous navez pas besoin davoir une quelconque adresse de carte. Il vous suffit de slectionner la carte du bon type, ainsi que son numro. Les cartes sont, grce la nouvelle stratgie, auto-dtectes par le logiciel PC Domogest, et disposent dun nom propre, ce qui permet dviter de devoir tenir jour un tableau des adresses comme ctait le cas avec les premires versions de Domocan.

23

Au niveau de Domogest, si vous voulez agir sur lclairage, par exemple, vous slectionnerez les paramtres des cartes gradateur. Ensuite, un menu droulant vous donnera la liste en clair des diffrentes cartes gradateur trouves sur le bus, chaque carte disposant dun nom. Une fois choisie la bonne carte, les 16 sorties de cette carte seront affiches en clair, chaque sortie de chaque carte disposant dun nom.

3.5 Les trames dadministration Ce sont simplement des trames rserves au systme. En ce sens, ce ne sont jamais que des commandes ordinaires, leur destination tant lunit centrale, plutt quune carte dapplication. La trame dadministration se distingue par son type de destinataire qui vaut 0xFE. LID est donc de la forme : ID : 11111101 ccccc nnnnnnnn pppppppp Le n de commande ccccc permet de dterminer le rle de la trame dadministration. Les autres paramtres nnnnnnnn et ppppppppp dpendent du n de commande. Notez donc que la trame dadministration est en fait destine une carte fictive de type 11111101. Le n de carte nnnnnnnn ne reprsente pas le n de carte, puisque la carte nexiste pas. Il est donc libre pour toute utilisation utile.

3.6 La trame derreur Domocan Attention, il ne faut pas confondre la trame derreur Domocan avec la trame ERROR du protocole Can (trame transparente pour lutilisateur). La seconde est gnre automatiquement par les modules hardwares des PIC, si une perturbation a empch la transmission correcte de la trame. Au contraire, la premire indique que la trame a bien t reue par la carte cible, mais que la ou les cartes cibles de la commande ont dtect un problme lors de lexcution de la commande. Un exemple simple est que si vous envoyez une trame qui demande de placer une sortie dclairage sur 120%, vous vous verrez gratifier en retour dune trame derreur Domocan. La commande est bien arrive la carte cible, mais celle-ci est dans limpossibilit dexcuter votre commande, et vous rpond donc avec une trame derreur Domocan. Une trame derreur Domocan est donc une trame de data comme les autres, avec son identificateur conforme nos conventions. Elle peut survenir par exemple si vous avez envoy une commande avec un nombre incorrect doctets de data, ou si le PIC cible dtecte une erreur de vrification dans son criture eeprom, etc.

24

Bref, il sagit dinformations lintention principalement dune unit de surveillance ou de paramtrage, comme le logiciel Domogest. La trame derreur Domocan est une trame dadministration. Elle se caractrise par son n de commande qui vaut 0x1F. Elle est de la forme : ID : 11111101 11111 00000000 eeeeeeee Notez que le numro de cible vaut toujours 0. Le paramtre (eeeeeeee), quant lui, contient le n de lerreur, de 0 255. Moralit, une trame derreur Domocan nest rien dautre quune commande n31, envoye la carte fictive de type Administration. Dit autrement, la trame derreur est une trame administration avec n de commande = 31. Notez 8 bits inutiliss 0, qui pourraient tre utiliss le cas chant comme poids fort de lerreur, ce qui donnerait 65536 codes derreur diffrents. On nen est pas l. Le numro de lerreur est un numro attribu par convention, et qui identifie le type derreur rencontre. Il y a donc 256 erreurs possibles. La trame derreur est toujours accompagne de 4 octets de data, pour lesquels le rle est fixe : D0 : Type de destinataire qui renvoie lerreur D1 : N de commande qui a provoqu lerreur D2 : N de carte qui renvoie lerreur D3 : paramtre qui a provoqu lerreur. En effet, il faut comprendre quune trame derreur ne peut tre gnre par une carte quen rponse une commande errone reue. Imaginons lexemple fictif suivant : Vous envoyez une commande de type : 35 12 34 50 La carte qui la rceptionne renvoie une erreur 13 Vous recevrez de ce fait la trame Can suivante : ID : 11111101 11111 00000000 00001101 D0 : 35 D1 : 12 D1 : 34 D2 : 50 : erreur n 13 : venant dune carte de type 0x35 : sur n de commande 0x12 : venant de la carte n 0x34 : le paramtre envoy valait 0x50

Vous pourrez donc interprter cette trame comme ceci : La commande n 0x12 envoye la carte de type 0x35 n 0x34 avec le paramtre 0x50 a renvoy une erreur n13.

25

Avec a, vous avez tous les renseignements utiles pour grer lerreur. Je sais que certains vont trouver tout a compliqu, mais en utilisant, a devient relativement simple. Dautant que le logiciel PC, qui voluera en mme temps que les cartes, prend tout a en compte de faon automatique, vous navez donc pas en ralit vous en proccuper pour utiliser le systme, les messages derreur ventuels seront affichs en clair. Les erreurs sont dclares dans le fichier domodef.inc . Le tableau complet se trouve au chapitre 6. A ces erreurs gnrales communes toutes les cartes, sajoutent des commandes spcifiques lies des cartes particulires, comme celles-ci ERR_H1 ERR_S1 0x90 0x98 Erreur H1 : horloge mre pas l'heure Erreur S1 : carte sensitive pas en mode superviseur

3.7 Priorits des trames Si vous avez tout compris, vous avez vu que lorsque deux trames sont mises en mme temps, celle qui prsente le premier un bit rcessif est suspendue. On a donc un systme de priorit bas sur lID. Autrement dit, plus un ID est petit (le 0 est le bit dominant), plus il est prioritaire en cas de collision. Comme lID commence, pour Domocan, par le type de destinataire, on pourra dire que plus le type du destinataire est petit, plus ce type est prioritaire. Bien que les collisions seront extrmement rares dans cette application, jai respect la logique des priorits, ce qui explique la rpartition des types choisis. Vous constaterez que les commandes de type administration sont les moins prioritaires, cest voulu, lunit centrale est de toute faon plus lente traiter les trames que les PIC. Il reste cependant possible daffecter un nouveau type de commandes administration hautepriorit dans les n infrieurs, si le besoin sen fait sentir. Par contre, des trames dinformations comme celles mises par la carte dhorloge mre saut hautement prioritaires, ce qui permet le minimum derreur sur les temps reus par les diffrentes cartes.

26

4. Gestion physique et caractristiques techniques

4.1 Caractristiques techniques gnrales Taille max. dune trame Can Dbit du bus Can Types de trames Can Charge maximale du bus Types de cartes Nombre de types de cartes Nombre de cartes Nombre de commandes Nombre de sous-commandes Driver physique Rsistance de charge Longueur maximale Type de cblage Dbit max. des trames : +- 120 bits Can (avec bits de gestion) : de 12.500 bits/s 1Mbits/s, 500Kbits/s par dfaut : tendues, conformes la norme Can 2.0b : 112 cartes de base + 112 par rptiteur : microcontrleurs PIC 18F 40Mhz : 253 thoriques (moins les types rservs) : 255 par type de carte : 31 par carte + 256 commandes communes : 256 possibles par commande : MCP2551 ou compatible : 120 ohms chaque extrmit de ligne : 100m sans rptiteur 500Kbits/s, 500m 100Kbits/s : en ligne ou boucle non ferme sans drivation : 4166 8929 trames/s selon nbre de data 500Kbits/s

Notez que mme avec des trames de longueur maximale, vous pouvez envoyer un maximum de 4166 commandes par seconde sur votre bus Can 500Kbits/s, ce qui vous laisse de la marge avant darriver saturation, mme si vous dcidez de transformer votre habitation en gigantesque jeu de lumires. De plus, les cartes sont conues pour limiter au maximum le trafic Can. Ainsi, par exemple, pour incrmenter un clairage partir dun bouton-poussoir, vous ne devez pas envoyer (mais vous pouvez) chaque valeur intervalles rguliers. En fait, vous envoyez une commande incrmenter clairage n xx avec une vitesse de yy), et puis stop lorsque vous relchez le bouton. Peu de systmes commercialiss permettent ce genre de souplesse.

4.2 Support physique Le pilote physique des lignes Can des cartes est le MCP2551 ou compatible. Celui-ci permet une capacit de 112 cartes sur chaque tronon de bus Can, avec une ligne de caractristiques et de longueur adaptes. Si lutilisateur dsire dpasser cette limite, un rptiteur correspond louverture dun nouveau tronon de 112 cartes. Il ny a pas de relle limite au nombre de cartes prsentes pour une installation raliste. En effet, la limite relle logicielle est de plusieurs dizaines de milliers de cartes, chacune pouvant grer toute une srie dentres ou de sorties. Je doute que vous soyez confronts ce genre de limite . Il semble daprs un rapide examen, que le PCA82C250 et le 82C251 (Philips) soient compatibles avec le MCP2551. Un internaute a du reste utilis avec succs le 82C251, fourni sur une carte dexprimentation. Dautres internautes me communiquent les quivalents suivants ( vous de vrifier le degr de compatibilit) :

27

Alcatel: MTC3054 Bosch: CF150B Texas Instruments: SN75LBC032 OU SN75LBC031 Maxims: Max 305x

28

5. Particularits communes toutes les cartes

5.1 Avertissement Chaque carte dispose dun ensemble de caractristiques communes, que nous retrouverons donc de fait sur chaque carte Domocan. Les cartes dinterface sont un peu particulires, tant donn quelles sont prvues pour tre commandes dune unit non Can , que ce soit partir de liaison RS232, dethernet, ou dUSB. Les caractristiques ne sappliquent donc pas ce type de carte particulier.

5.2 Le type de PIC Chaque carte possde un n de PIC, de 0 255, interrogeable distance, et qui identifie le type de PIC install sur la carte. Ceci est trs pratique pour effectuer des vrifications avant deffectuer une mise jour via le bus Can (technique du bootloader). En effet, il se peut fort bien que pour un mme type de carte, vous ayez dcid pour des raisons personnelles de placer diffrents types de pics. Une carte prvue pour travailler avec un 18F2580, par exemple, pourra fort bien recevoir un 18F2680. Ds lors, il est ncessaire pour le bootloader, lorsque vous effectuez une mise jour, de connatre le numro du pic pour savoir si le nouveau logiciel prend place dans le pic prvu, et pour assurer un minimum de vrification concernant la destination du fichier. Bien entendu, il vous faudra rassembler le programme en prcisant dans le fichier source quel type de pic vous avez utilis. Jexplique comment un peu plus loin. Les numros de pics, par convention, sont actuellement les suivants : 0 1 2 3 4 5 6 7 8 9/255 : N.U. : PIC 18F248 : obsolte, mais gr pour les cartes existantes : PIC 18F258 : obsolte, mais gr pour les cartes existantes : PIC 18F448 : obsolte, mais gr pour les cartes existantes : PIC 18F458 : obsolte, mais gr pour les cartes existantes : PIC 18F2580 : PIC 18F4580 : PIC 18F2680 : PIC 18F4680 : rservs pour utilisations futures

Jai dmarr le projet avec les 18Fxx8, les 18Fxx80 sont apparus en cours de dveloppement. Il est apparu un certain nombre de bugs dans les xx8, ce qui a conduit leur abandon. Je nutiliserai plus aucun source futur base de ces PIC, et ils seront remplacs progressivement dans les applications dj cres par des nouveaux modles. Il reste suffisamment de valeurs en rserve pour couvrir tous les besoins ventuels futurs.

29

Dans chaque fichier source de carte Domocan, vous inscrirez le numro du PIC utilis lendroit suivant :
TYPEPIC = 0x07 ; types de pic autoris = 18F2680

En gnral, je laisse prsent dans le source comme alternative les pics compatibles avec llectronique de la carte sous forme de commentaires :
TYPEPIC = 0x07 ; types de pic autoriss ; 0x07 = 18F2680 ; 0x05 : 18F2580

Le type de PIC est inscrit dans la partie bootloader du programme. Il est donc impossible de modifier cette valeur sans reprogrammer le PIC laide dun programmateur classique. Cette limitation est voulue, afin dviter les mauvaises manipulations. En effet, on ne peut changer de modle de PIC en effectuant une mise jour logicielle par bootloader, par dfinition (si vous y arrivez, expliquez-moi comment vous avez fait). Ceci ne peut se faire que par le remplacement du PIC, et donc sa programmation correcte. Si vous comprenez bien ceci, vous noterez que votre PIC contiendra ds lors : Une zone bootloader non modifiable sans reprogrammation par voie classique Une zone programme qui contient le programme spcifique la carte. Ajoutez a une zone programme protge pour des donnes spcifiques

5.3 La zone eeprom 1 Leeprom du pic est divise arbitrairement en zones dutilisations diffrentes. Les premires de ces zones contiennent des informations dont la localisation est commune toutes les cartes du systme. La premire zone, qui va de 0xF00000 0xF00015 nest pas accessible par le bootloader. De ce fait, vous ne pouvez pas leffacer en utilisant ce dernier.

5.3.1 Len-tte Les 2 premiers octets contiennent un identificateur constitu de 2 caractres ASCII : BG . Au dmarrage, si ces 2 octets sy trouvent, le pic se branche sur le programme principal. Au contraire, si au moins un des 2 octets est incorrect, le pic se connecte automatiquement sur la routine de bootloader. Le bootloader commence par effacer les caractres, met le logiciel jour, et ensuite rcrit les octets. Par ce mcanisme, si un problme survient lors de la mise jour, le bootloader reste oprationnel et permet de recommencer lopration. Il est donc hautement improbable que la carte excute un logiciel charg de faon partielle ou incorrecte. Pour le cas o le logiciel que vous chargez est lui-mme bugg, un jumper sur la carte permet de toutes faons

30

de la replacer en mode bootloader, mme si la carte ne ragit plus aux commandes suite au bug.

5.3.2 La cible Loctet suivant, ladresse 0xF00002, contient le n de la carte (cible) auquel celle-ci va rpondre. Loctet tant en zone 1 ne sera pas effac par une mise jour logicielle, on peut donc envoyer le mme fichier hex toutes les cartes sans devoir modifier pour chacune le n de carte, celui-ci tant invariable. En contrepartie, il est ncessaire de disposer dun mcanisme pour modifier ce n sur demande. Ceci seffectuera par le biais dune commande Can spcifique. Lorsque vous placez une nouvelle carte sur le bus, il suffit donc dy programmer la valeur par dfaut. La carte rpond alors au n de cible 254, il vous suffit ensuite de modifier cette valeur via Domogest. Evidemment, il ne faut placer quune seule nouvelle carte dun mme type la fois, pour viter de se retrouver avec 2 cartes contenant le mme numro.

5.3.3 Le mode de fonctionnement En 0xF00003 nous trouvons un octet dont chaque bit est un flag utilis dans le programme. Il est dconseill de modifier cette zone manuellement. A lemplacement en question, vous trouverez non pas la valeur immdiate, mais une constante, MODEDEF, qui reprsente la valeur par dfaut lors de la programmation de la carte. Si, cependant, vous dsirez modifier le mode de fonctionnement, agissez donc au niveau de lassignation de la constante, en dbut de programme :
MODEDEF EQU 0x04 ; ; ; ; ; ; ; ; mode de fonctionnement par dfaut b0 : mode normal(0) ou mode bootloader(1) toujours laisser 0 (gr en interne) b1 : centralisation (0=dcentralis) b2 : Fonctionnement Led Can (1 = en service) b3 : rserv pour utilisation future b4/b7 : spcifiques certaines cartes modifiables via Domogest

Cet octet indique le mode de fonctionnement de la carte. Certains bits ont une signification particulire en fonction du type de carte, le bit 1 indique le mode de centralisation :
b1 = 0 : mode dcentralis (par dfaut) b1 = 1 : mode centralis

Le bit 2, quand lui, indique si la led tmoin de trafic Can prsente sur la carte est en service ou non.
b2 = 0 : Led de trafic toujours teinte (sauf en mode bootloader) b2 = 1 : Led de trafic Can en service sur rception et mission de trames Can

31

Ce bit permet, via la commande approprie, dviter lallumage de la led de trafic lorsque ce nest pas ncessaire. Ceci permet de faire des conomies dnergie. Par exemple, pour une carte sensitive (encastre et donc invisible), vous mettrez la led en service en cas dintervention sur panne (pour voir le trafic), puis vous couperez la led en fonctionnement normal. Si vous dcidez que par dfaut toutes vos cartes fonctionneront en mode centralis par exemple, vous pouvez modifier directement la valeur dans la zone eeprom 1 via cette constante. Mais vous pouvez aussi le faire directement via le logiciel Domogest. La valeur de loctet concernant le mode de fonctionnement se modifie en cours de fonctionnement via la commande commune CC_WModeC . Par dfaut dans le fichier, cette constante indique quon travaille en mode dcentralis, et avec la led Can en service.

5.3.4 La zone utilisateur Nous trouvons ensuite, ladresse 0xF00004, 8 octets contenant 8 caractres ASCII formant un texte. Ce texte est dnomm zone utilisateur Domogest utilise cette zone comme zone de commentaire, les caractres grs sont donc dans ce cas des caractres ASCII. Cependant, rien nempche dutiliser cette zone pour dautres buts, la libert totale de lutilisateur. La zone peut tre modifie par trame Can. Par exemple, vous pourriez y inscrire plafond pour indiquer que cette carte se trouve dans le plafond. Il sagit en fait dune sorte de commentaire de la carte. Par dfaut, les fichiers sources contiennent une valeur par dfaut dans cette zone. Il est inutile de les modifier dans le source (mais cest autoris), car ces informations, comme je lai dit, se modifient aisment une fois la carte en place directement partir de Domogest.

5.3.5 Le nom de la carte Il est constitu galement de 8 octets. Lutilisation est strictement la mme que pour la zone utilisateur. Notez que le type de carte est dj identifiable via son ID. Vous pouvez ds lors utiliser un nom explicite, exemple : Etage . Dans cet exemple, vous indiquez que la carte est la carte de pilotage des clairages de ltage. De nouveau, il est inutile deffectuer la modification dans le source, le nom est modifiable par trame Can directement depuis Domogest. Depuis Domogest, si vous interrogez cette carte, vous disposerez donc des informations suivantes : Type de carte : Grad16

32

Nom de carte Zone utilisateur

: Etage : Plafond

A titre dinformation, pour une carte gradateur de ce type, vous disposerez galement du nom des 16 sorties, disponibles et modifiables depuis Domogest. Toutes les informations utiles sont donc lisibles en clair, nul numro retenir, dautant plus que la reconnaissance automatique des cartes prsentes fait apparatre le nom des cartes dans les menus droulants. Comme je lai expliqu, ces zones nont aucune influence sur le droulement du programme, cest un mini bloc-notes intgr dans le PIC. Je rappelle que ces informations ne sont pas affectes par une criture via le bootloader. Ceci vite quune mise jour dun logiciel nefface vos donnes utiles. Ce nest pas en effet parce que vous allez effectuer une mise jour du logiciel dune carte que vous dsirez perdre son nom ou autres informations utiles. Dans la zone eeprom 1 subsiste 1 octet inutilis, de rserve pour une ventuelle utilisation future.

5.3.6 Le nombre de fonctions gres A ladresse 0xF00014 se trouve une constante, NBGERE. Celle-ci peut avoir une signification un peu diffrente dune carte lautre, mais reprsente en gnral le nombre de fonctions gres par la carte. La valeur, comme pour la rvision, ne se modifie pas lendroit de la zone eeprom, mais directement en dbut de programme, dans les assignations :
NBGERE EQU 0x01 ; nombre gr, selon le contexte (nombre sorties par exemple)

A titre dexemple, la carte 16 entres aura une valeur de .16 (0x10) cet endroit. De mme pour la carte gradateur, pilotant 16 sorties. Une carte sensitive, prvue pour tre explicitement pourvue dun nombre de fonctions variables verra cette valeur passer de 1 .16 en fonction du type deeprom prsente sur la carte. Cette valeur est cependant accessible sous forme dune commande Can, vous pouvez donc envoyer le mme fichier hex toutes vos cartes dun mme type sans devoir chaque fois modifier cette constante. Vous pourrez le faire une fois le programme lanc, partir de Domogest.

5.4 La zone eeprom 2 Cette zone, qui stend de 0xF00016 0xF0001B, contient des donnes accessibles par le bootloader, donc modifiables lors dun update, mais dont les emplacements sont identiques pour toutes les cartes. Chaque carte Domocan dispose donc de ces emplacements contenant toujours les mmes informations.

33

5.4.1 La rvision software Afin de faciliter la mise jour software (bootload), chaque PIC dispose de 3 octets qui identifient la rvision du logiciel embarqu. La rvision est reprsente sous la forme : octet1.octet2.octet3 en hexadcimal. En eeprom, cette information se trouve aux emplacements 0xF00016 0xF00018
ORG 0xF00016 DE VER1,VER2,VER3 ; version soft.version2.version3

Par contre, vous voyez que le numro de version ny est pas indique en clair, mais en utilisant des constantes : VER1 VER3. Ceci permet de modifier le n de version plus aisment simplement en remplaant les valeurs de ces constantes en dbut de programme. Ne modifiez donc pas le n de version cet endroit, mais plutt ici :
VER1 equ 0x01 VER2 equ 0x00 VER3 equ 0x00 ; version software = 1.0.0

Dans cet exemple, la rvision est donc bien 1.0.0. Ce numro est interrogeable distance, et prsent dans le fichier .hex. De ce fait, lors du bootload, vous savez le numro de la version prsente dans le PIC et le numro de la version que vous allez envoyer. Ceci vous vite des erreurs, et des manipulations inutiles. De plus, la connaissance de votre rvision vous permet de suivre sur mon site lvolution des versions. Vous ne pouvez pas modifier la valeur de la rvision software autrement quen effectuant une mise jour par bootloader ou en reprogrammant le pic laide dun programmateur. Seul le bootloader peut accder cet emplacement en mode de fonctionnement normal. Il est donc impossible davoir un numro de version qui ne corresponde pas la version intgre, sauf reprogrammation volontaire. En fin de la zone 2 subsistent 3 octets rservs pour une ventuelle utilisation future

5.5 La zone eeprom 3 Cette dernire zone stend de 0xF0001C jusque la fin de la zone eeprom du pic concern. Cette zone est accessible par le bootloader, et librement utilisable pour chaque programme. Rien ny est dfini, le contenu dpend donc du type de carte Domocan.

34

6. Les erreurs gnrales

6.1 Tableau des erreurs gnrales reconnues Pour rappel, la trame derreur est de la forme : DEST_ADMIN CMD_ERR 00000000 eeeeeeee Soit : 11111101 11111 00000000 eeeeeeee 0xFD 0x1F 0x00 n erreur Le n du code derreur doit donc se trouver dans les 8 derniers bits de lID, que nous appelons le registre SIDL. Ce tableau reprend les erreurs gnrales gres par Domogest. Le tableau complet des erreurs est repris dans les annexes.

Nom Err_G1 Err_G2 Err_G3 Err_G4 Err_G5 Err_G6 Err_G7 Err_G8 Err_G9 Err_G10 Err_G11 Err_G12 Err_G13 Err_G14 Err_G15 Err_G16

Num 0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 0x8A 0x8B 0x8C 0x8D 0x8E 0x8F

Erreurs gnrales du systme Domocan Descriptif Nombre de data incorrect Valeur de data invalide Erreur d'criture eeprom Erreur du paramtre de lID Erreur dcriture en mmoire flash Pointeur flash non multiple de 8 Pointeur flash dans zone protge Pointeur flash hors limite PIC Pointeur flash non valide Tentative daccs bootloader en zone eeprom protge Erreur dcriture en eeprom externe (si elle existe) Erreur gnrale rserve pour utilisation future Commande illgale en mode broadcast Commande commune invalide en mode bootloader Commande commune invalide en mode normal Commande invalide pour la carte

Toutes les erreurs reconnues sont dcrites dans le fichier domodef..inc qui doit tre prsent dans le rpertoire contenant tous vos sources Domocan. Ce fichier est disponible sur mon site. Ce tableau est susceptible dvolutions ventuelles. Dans la colonne Nom , vous avez le nom symbolique de lerreur. Ce nom est le mme que celui utilis dans le logiciel PC. Ainsi, un changement ventuel ne se traduit que par la modification dune assignation, sans devoir reprendre lintgralit du programme.

35

Lorsque je parlerai dune erreur, jutiliserai toujours son nom symbolique, pour plus de facilit. La colonne Num indique le numro de lerreur. Cest le paramtre eeeeeeee que vous retrouvez dans la trame de type erreur, explique prcdemment.

6.2 Descriptif des erreurs gnrales Vous trouverez ici les explications dtailles des erreurs gnrales. Les erreurs spcifiques des cartes particulires sont reprises dans les documentations spcifiques de ces cartes. 6.2.1 Err_G1 Valeur Descriptif : 0x80 : Nombre de data incorrect

Survient lorsque le nombre de data de la trame Can ne correspond pas ce qui est attendu par la carte de destination. Le nombre de data peut varier de 0 8, et dpend de la commande envoye. Cette erreur intervient uniquement lors denvoi de commandes manuelles errones ou lors dun paramtrage incorrect dune carte. Les trames envoyes par Domogest (logiciel de configuration PC de Domocan) sont toutes correctes, cette erreur ne devrait donc pas se prsenter. Ceci est le cas de pas mal derreurs gnrales. 6.2.2 Err_G2 Valeur Descriptif : 0x81 : Valeur de data invalide

Intervient lorsque le nombre doctets de donnes est correct, mais pas leur valeur. Ceci peut survenir lorsque les octets de donnes doivent respecter un certain nombre de conditions de validit non respects. Un exemple simple est une demande de modification de luminosit de plus de 100% dune sortie dune carte gradateur. 6.2.3 Err_G3 Valeur Descriptif : 0x82 : Erreur dcriture en mmoire eeprom interne

Toute criture en eeprom est suivie automatiquement par une relecture. Ce processus est intgr toutes les cartes compatibles Domocan. Une erreur la vrification induit une erreur ErrG3. Cette erreur peut survenir accidentellement (parasite violent), mais, si elle se reproduit rgulirement, Il faut envisager de remplacer le PIC de la carte concerne (dure de vie de leeprom atteinte). Je doute cependant que ce cas arrive.

36

Vous devez donc toujours vrifier que la valeur crite est bien renvoye, pour viter quune coupure de tension, par exemple, ninterrompe le processus. Auquel cas, il vous faudra renvoyer la commande, et vrifier lintgralit des donnes contenues en EEPROM. Une coupure de tension durant une phase dcriture peut en effet provoquer une altration de zones eeprom non concernes. Rassurez-vous, la vrification automatique est intgre dans le programme de bootloader que je vous fournis, ainsi que dans le logiciel de gestion Domogest. Le nombre de cycles dcriture une adresse donne de leeprom est de 100.000 minimum et 1.000.000 typiques, entre 40C et 85C. Elle peut tre raccourcie dun facteur 10 en cas de sortie de ces limites. Je doute que votre habitation soit concerne, mais je vous signale que vous pouvez utiliser des cartes lextrieur de votre habitation (protges contre lhumidit, cela va de soi). En gnral, une erreur rptitive de ce type indique que leeprom a dpass sa dure de vie prvue. Dans ce cas, il conviendra de remplacer le PIC. Pour que a arrive, vous devrez forcment tre un manique des modifications, car typiquement a reprsente une modification toutes les heures durant 114 ans. Au bout de 10.000.000 daccs en criture nimporte quelle adresse en mmoire eeprom, il faut procder une rcriture de tous les paramtres contenus en mmoire eeprom (voir datasheet). Je doute que mme vos descendants doivent recourir cette pratique. Mais bon, si vous modifiez un paramtre toutes les 10 minutes jour et nuit, prvoyez un rafrachissement dans 190 ans par prcaution. Je nai pas intgr une fonction automatique qui le ralise pour vous. 6.2.4 Err_G4 Valeur Descriptif : 0x83 : Erreur de paramtre

Cette erreur survient lorsque vous envoyez une trame dont le paramtre contenu dans lID ne respecte pas certaines conditions relatives la commande envoye. Comme exemple, si vous savez que dans une carte gradateur, le n de la sortie concerne est contenue dans le paramtre, le fait de vouloir modifier la sortie n 17 sur une carte ne disposant que de 16 sorties gnrera cette erreur. 6.2.5 Err_G5 Valeur Descriptif : 0x84 : Erreur dcriture en mmoire flash

Une erreur est survenue lors de la vrification dune valeur inscrite dans la mmoire flash du PIC. Ceci peut se produire par exemple lors dune mise jour logicielle (update). La dure de vie de la mmoire flash est de minimum 10.000 cycles une t comprise entre 40C et +85C. La dure typique est de 100.000 cycles dans la mme gamme de t. Si le PIC est port une t suprieure 85C, lesprance de vie est diminue dun facteur 10.

37

Ceci vous laisse cependant une bonne esprance de vie de votre PIC, sachant que vous pourrez faire une mise jour journalire durant 270 ans typiquement. Je vous souhaite de vivre aussi longtemps, mais en cas de rclamation, je crains que vous ne deviez vous adresser quelquun dautre. ATTENTION : tant que la carte se trouve en mode bootloader, il est impossible de lutiliser normalement, seules les commandes relatives au mode bootloader seront acceptes. Domogest permet cependant dassurer la commutation automatique. 6.2.6 Err_G6 Valeur Descriptif : 0x85 : Pointeur flash non multiple de 8

La procdure dcriture en mmoire durant lupdate logiciel ncessite linitialisation dun pointeur. Les donnes sont crites par blocs de 8, le pointeur doit donc tre align sur un multiple de 8 octets. En cas de mauvaise initialisation du pointeur, lerreur ErrG8 sera renvoye. De nouveau, ceci est pris en charge automatiquement par le logiciel PC, lerreur nintervient quen cas denvoi de commandes manuelles ou par un logiciel de votre conception mal crit. 6.2.7 Err_G7 Valeur Descriptif : 0x86 : Pointeur flash dans zone protge

Vous tentez dcrire dans une partie de la mmoire flash non autorise. En fait, ceci constitue une protection pour viter dcraser accidentellement le bootloader intgr au PIC, ce qui conduirait une mise hors-service du composant. Remarque identique, la gestion du pointeur est gre par le programme PC fourni (Domogest). 6.2.8 Err_G8 Valeur Descriptif : 0x87 : Pointeur flash hors limite PIC

Vous tentez dcrire dans une zone mmoire flash qui se situe hors de lespace dadressage du PIC utilis. Lerreur peut se produire typiquement si vous avez remplac un pic par un autre modle, et que vous avez oubli de modifier le type de pic dans le fichier source. Un autre cas est lenvoi dun fichier non prvu pour le pic de destination.

38

6.2.9 Err_G9 Valeur Descriptif : 0x88 : Pointeur flash non valide

Tentative dcriture doctets en mmoire flash alors que le pointeur na pas t initialis. De nouveau, cette gestion du pointeur est prise en charge par le programme de bootloader, lerreur ne peut donc intervenir quen cas denvoi de commande manuellement ou en cas de conception dun programme personnel prsentant un dfaut. 6.2.10 Err_G10 Valeur Descriptif : 0x89 : Tentative dcriture en zone eeprom protge

Tentative dcriture dans la zone eeprom 1, qui est la zone eeprom protge. En effet, je vous ai dit que certaines zones eeprom ntaient volontairement pas accessibles. Le programme PC gre ces zones, mais si vous envoyez des commandes manuellement ou que vous avez crit un programme qui ne gre pas ces zones, vous risquez une erreur de ce type. 6.2.11 Err_G11 Valeur Descriptif : 0x8A : Erreur dcriture en mmoire eeprom externe.

Lcriture dans un botier eeprom externe a chou (erreur de vrification). Cette erreur nest possible que pour les cartes disposant de tels type deeprom, comme par exemple la carte dentre 16 boutons-poussoirs qui dispose dune eeprom 24C512. 6.2.12 Err_G12 Valeur Descriptif : 0x8B : Rserve pour utilisation future

Il sagit dun code derreur actuellement non utilis. 6.2.13 Err_G13 Valeur Descriptif : 0x8C : Commande illgale en mode broadcast

Cette erreur intervient si vous avez envoy une commande un type de carte en prcisant lintgralit des cartes comme cible de la commande (cible = 0xFF) alors que ce type de commande ne supporte pas ce mode. Exemple : Vous demandez crire un mme nom pour toutes les cartes gradateur simultanment.

39

6.2.14 Err_G14 Valeur Descriptif : 0x8D : Commande commune invalide en mode bootloader

Cette erreur est gnre si vous envoyez une carte se trouvant en mode bootloader une commande commune non supporte dans ce mode. Par exemple, vous tentez dcrire dans la zone utilisateur alors que la carte est en mode bootloader 6.2.15 Err_G15 Valeur Descriptif : 0x8E : Commande commune invalide en mode normal

Cette erreur est le contraire de la prcdente. Votre carte se trouve en mode de fonctionnement normal et vous tentez de lui envoyer une commande commune spcifique au mode bootloader. Un exemple typique est la tentative dcriture en mmoire flash alors que la carte est en cours de fonctionnement normal 6.2.16 Err_G16 Valeur Descriptif : 0x8F : Commande invalide

Cette erreur se produit si vous envoyez une commande non supporte une carte. Selon le paramtrage des filtres Can, une commande non supporte peut se traduire soit par une absence de raction de la carte cette commande, soit par lenvoi dune erreur Err_G16

40

7. Les commandes communes reconnues

7.1 Rappel Les commandes communes sont dclares dans le fichier domodef..inc qui doit tre prsent dans le rpertoire contenant tous vos sources Domocan. Ce fichier est disponible sur mon site. Elles sont traites dans le fichier CCommunes.inc , qui doit galement tre prsent dans le rpertoire de vos sources. Ces commandes sont toutes de la forme : dddddddd CMD_COMM nnnnnnnn pppppppp

Les 5 bits de la commande CMD_COMM sont tous 0. Le format est donc : dddddddd 00000 nnnnnnnn pppppppp

avec : dddddddd CMD_COMM nnnnnnnn pppppppp

: type de destinataire (carte gradateur, carte entre, etc.) : spcifie quil sagit dune commande commune : n de la carte cible par la commande : paramtre = type de commande

Il sagit donc dune application du fait quon puisse tendre le nombre de commandes, puisque toutes les commandes communes sont en fait une seule et mme commande (CMD_COMM) dont le rle est prcis par le paramtre. Noubliez pas que le registre contenant la commande contient 3 autres bits. Utilisez donc la constante CMD_COMM dans vos sources et non la valeur 0x00.

7.2 Tableau des commandes communes Le tableau donne plusieurs indications : La colonne Nom donne le nom symbolique de la commande commune. Par convention, toutes les commandes communes commencent par CC_ La colonne Par donne la valeur du paramtre de la commande : il identifie donc la commande commune La colonne D donne la direction de la commande : Un R indique que la carte cible reoit la commande, alors quun E indique que la commande est mise par la carte cible. La colonne B indique si la commande accepte ou non le mode broadcast. O indique le mode broadcast, N que le mode est refus. Le mode broadcast na videmment de sens que pour les commandes reues par les cartes. Une carte nmet jamais une rponse en mode broadcast.

41

La colonne M indique le mode de fonctionnement requis pour la commande. Un B indique que la commande concerne le mode bootloader, un N le mode normal, et un T nimporte quel mode. La valeur du paramtre est donne en hexadcimal. Tableau des commandes communes du systme Domogest Nom Par D B M Rle CC_OutBoot 10 R N B Sortir du mode bootloader CC_WPtrF 11 R N B Positionner le pointeur mmoire flash CC_RPtrF 12 R N B Demander la valeur actuelle du pointeur flash CC_WFlash 13 R N B Ecrire 8 octets en mmoire flash CC_RFlash 14 R N B Lire 8 octets en mmoire flash CC_WEep 15 R N B Ecrire un octet en mmoire eeprom CC_REep 16 R N B Lire un octet en mmoire eeprom 17/1F R N B Rservs pour utilisation future mode bootloader CC_RCarte 20 R O T Demander les informations de la carte CC_WZone 21 R N N Ecrire 8 caractres dans la zone utilisateur CC_RZone 22 R O N Lire la zone utilisateur CC_WNameC 23 R N N Ecrire les 8 caractres du nom de la carte CC_RNameC 24 R O N Lire le nom de la carte CC_WNewCible 25 R N N Ecrire le numro de cible de la carte CC_GoBoot 26 R N N Passer en mode bootloader CC_WModeC 27 R O N Modifier le mode de fonctionnement de la carte CC_Reset 28 R N N Resetter la carte 29/5F R N Rservs pour utilisation future CC_Carte 60 E - T Envoi des informations de la carte CC_Eep 61 E - B Envoi de loctet lu en mmoire eeprom CC_PtrF 62 E - B Envoi de la position actuelle du pointeur flash CC_Flash 63 E - B Envoi de 8 octets lus en mmoire flash 64/67 E - B Rservs pour utilisation future CC_Zone 68 E - N Envoi des octets de la zone utilisateur CC_NameC 69 E - N Envoi du nom de la carte CC_NewCible 6A E - N Confirmation du nouveau n de cible de la carte 6B/6F E - N Rservs pour utilisation future

7.3 Dtails des commandes communes Ne seront abordes ici que les explications concernant les commandes communes. Pour les commandes spcifiques, consultez la documentation de la carte concerne. Souvenez-vous que toutes ces commandes sont de la forme : dddddddd Destinataire 00000 Cmd_Comm nnnnnnnn N de cible pppppppp N de la commande commune

42

Je sais que je me rpte, mais si vous comptez dvelopper pour ce systme, a doit devenir un automatisme. Evidemment, si vous voulez simplement lutiliser, tout ceci sera transparent pour vous, et pris en charge par Domogest de faon automatique et symbolique. A ct de la zone erreurs , vous trouverez les erreurs possibles gnres en rponse la commande reue. Ceci na videmment de sens que pour les commandes reues. Il en va de mme pour le paramtre rponse , car on na videmment ni erreur ni rponse pour les commandes envoyes (en rponse une requte). Le type de destinataire complt par le n de cible identifie coup sr le destinataire de la commande commune. Pour faire une analogie avec les langages volus, on pourrait dire que le n de la commande est une mthode de lobjet identifi par son type et son n de cible. On pourrait alors dire que pour excuter une commande commune, il faut : Le type de destinataire (correspond un groupe de cartes) Le n de cible (identifie une seule carte dans le groupe) Laccs aux commandes communes, via CMD_COMM Le n de la commande commune excuter (paramtre = pppppppp) Ce qui pourrait se traduire par : destinataire.cible.commande_commune.num_commande Exprim de la sorte, de nombreux programmeurs voient immdiatement la philosophie utilise, les commandes faisant parties dune classe destinataire . Du reste, si vous analysez les sources de Domogest, vous y trouverez bel et bien une classe cartes contenant toutes les cartes prsentes sur le bus, et une classe carte identifiant une carte particulire.

7.3.1 CC_OutBoot Commande Paramtre Sens Broadcast Mode Rle Data : 0x00 (CMD_COMM) : 0x10 : Rception : Refus : Bootloader : Sortie du mode bootloader : 2 octets de data servant uniquement de confirmation la commande. D0 : 0x55 D1 : 0xA5 : CC_Carte : G1, G2, G3

Rponse Erreurs

Cette commande sera envoye par le logiciel de bootloader de lunit de contrle, aprs la fin de la procdure de mise jour. Avant de procder une mise jour, le logiciel de contrle procde une vrification du type de PIC et de destinataire.

43

Si vous crez votre propre programme, que vous ignorez la vrification, et que de ce fait, vous tentez volontairement denvoyer un logiciel ne correspondant pas lidentification de la carte, le logiciel entr erronment risque de ne pas fonctionner. Si la carte sort du mode bootloader et quil nest plus possible dy entrer (programme principal erron), chaque carte dispose dun jumper permettant de forcer le passage en mode bootloader mme si le logiciel principal ne rpond plus. Il vous suffit ds lors de positionner le jumper sur la carte et de gnrer un reset hardware, la carte repassera alors automatiquement en mode bootloader. Vous pouvez alors enlever le jumper et renvoyer le programme correct.

7.3.2 CC_WPtrF Commande Paramtre Sens Broadcast Mode Rle Data : 0x00 (CMD_COMM) : 0x11 : Rception : Refus : Bootloader : Positionne le pointeur en mmoire flash : 2 octets D0 : MSB de ladresse absolue D1 : LSB de ladresse absolue b2/b0 = toujours 0 : CC_PtrF : G1, G6, G7, G8

Rponse Erreurs

Permet de positionner le pointeur flash pour prparer une criture. Le pointeur doit pointer sur une zone autorise, ceci implique : Il ne doit pas pointer dans la zone du bootloader Il ne doit pas pointer hors de la zone programme du pic concern

De plus, le pointeur doit contenir une valeur multiple de 8, ce qui explique que les bits 0 2 de loctet de donne D1 doivent toujours valoir 0. Si vous ne respectez pas ces conditions, vous serez gratifis dun des messages derreur prvus. 7.3.3 CC_RPtrF Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreur : 0x00 (CMD_COMM) : 0x12 : Rception : Refus : Bootloader : Demande de la valeur du pointeur en mmoire flash :: CC_PtrF : G1

44

Permet dobtenir la valeur du pointeur actuel sur la mmoire flash, pour vrification ventuelle. Pour rappel, le pointeur pointe toujours sur le prochain groupe de 8 octets crire. La valeur sera retourne dans une trame CC_PtrF

7.3.4 CC_WFlash Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreurs : 0x00 (CMD_COMM) : 0x13 : Rception : Refus : Bootloader : Ecriture des 8 octets en mmoire flash : 8 octets de data D0 / D7 : 8 octets crire dans lordre. : CC_Flash : G1, G5, G6, G7, G7, G9

Permet dcrire en mmoire flash par groupe de 8 octets. Loctet D0 sera crit lemplacement point par le pointeur flash, les autres octets seront crits dans les adresses successives dans lordre croissant. Attention, tant donn le fonctionnement interne des PICs, toute criture une adresse multiple de 64 (dcimal) provoquera leffacement du bloc de 64 octets, via la routine dcriture contenue dans le programme du pic. Ceci est pris en charge automatiquement par le programme de bootloader, mais il faudra en tenir compte si vous ralisez votre propre bootloader, ou si vous envoyez des octets manuellement via cette commande. Toujours du fait du fonctionnement interne des PICs, il nest pas possible dcrire moins de 8 octets la fois. Cette mthode permet cependant de raliser des critures 8 fois plus rapidement que pour un pic ncessitant des critures octet par octet. Cest un choix du constructeur. Lcriture dun bloc de 8 octets provoque lincrmentation automatique du pointeur en mmoire flash. Pour le cas o cette incrmentation provoquerait un dbordement de la zone autorise, la prochaine criture renverra le message derreur appropri. 7.3.5 CC_RFlash Commande Paramtre Sens Broadcast Mode Rle Data : 0x00 (CMD_COMM) : 0x14 : Rception : Refus : Bootloader : Lecture de 8 octets en mmoire flash : 2 octets D0 : Adresse de lecture - MSB D1 : Adresse de lecture LSB : CC_Flash : G1

Rponse Erreur

45

Permet de lire 8 octets partir de ladresse spcifie. Ladresse na pas tre multiple de 8. Le pointeur nest pas utilis. Il est important de savoir que cette commande ne modifie la valeur du pointeur. En effet, une sauvegarde du pointeur est effectue dans la routine de traitement de cette commande, lutilisation ne perturbe donc pas une ventuelle opration dcriture. 7.3.6 CC_WEep Commande Paramtre Sens Broadcast Mode Rle Data : 0x00 (CMD_COMM) : 0x15 : Rception : Refus : Bootloader : Ecriture dun octet en mmoire eeprom : 2 octets D0 : adresse relative de lcriture D1 : Octet crire : CC_Eep : G1, G3, G10

Rponse Erreurs

Cette commande permet dcrire un octet dans la mmoire eeprom. Ladresse est prcise de faon relative, partir de lemplacement 0 jusque 255. Ladresse relle dans le pic est videmment de 0xF00000 0xF000FF. Le bootloader vrifie que vous ne tentez pas dcrire dans la zone protge, ce qui vous vaudrait un message derreur. La valeur renvoye par la rponse concerne loctet relu dans la mmoire eeprom. Il y a donc vrification systmatique aprs criture, comme pour la mmoire flash. 7.3.7 CC_REep Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreur : 0x00 (CMD_COMM) : 0x16 : Rception : Refus : Bootloader : Lecture dun octet en mmoire eeprom : 1 octet D0 : adresse relative de lecture : CC_Eep : G1

Cette commande permet simplement de relire un octet de la mmoire eeprom. Loctet de data 0 contient ladresse relative en mmoire eeprom, de 0 0xFF.

46

7.3.8 CC_RCarte Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreur : 0x00 (CMD_COMM) : 0x20 : Rception : Accept : Bootloader ou Normal : Demande des informations de la carte :: CC_Carte : G1

Grce cette commande, vous pouvez obtenir des informations sur la carte laquelle vous avez affaire. Le descriptif de ces informations est donn dans la commande CC_Carte. 7.3.9 CC_WZone Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreurs : 0x00 (CMD_COMM) : 0x21 : Rception : Refus : Normal : Ecriture des octets dans la zone utilisateur : 8 octets D0/D7 : Octets 0 7 dfinis par lutilisateur : CC_Zone : G1, G3

Cette commande permet denvoyer 8 caractres dans la zone prvue pour les commentaires utilisateur. Je rappelle que ces donnes nont aucune rpercussion sur le fonctionnement des cartes. Ces donnes sont bien entendu mmorises en eeprom, et rsistent de ce fait une coupure de tension. 7.3.10 CC_RZone Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreur : 0x00 (CMD_COMM) : 0x22 : Rception : Accept : Normal : Demande des octets de la zone utilisateur :: CC_Zone : G1

La commande permet dobtenir en retour les 8 octets de la zone utilisateur.

47

7.3.11 CC_WNameC Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreur : 0x00 (CMD_COMM) : 0x23 : Rception : Refus : Normal : Donner un nom la carte : 8 octets : D0/D7 : 8 caractres du nom de la carte : CC_ NameC : G1

Cette commande permet dattribuer un nom une carte. Le nom des cartes apparat en clair au niveau des menus droulants de Domogest, ce qui simplifie grandement la slection de la bonne carte, sans ncessit de recourir une table des numros de cartes Utilisez ds lors des noms clairs. 7.3.12 CC_RNameC Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreur : 0x00 (CMD_COMM) : 0x24 : Rception : Accept : Normal : Lire le nom de la carte :: CC_ NameC : G1

Permet dobtenir en retour le nom de la carte, en lappelant via son numro de cible. 7.3.13 CC_WNewCible Commande Paramtre Sens Broadcast Mode Rle Data Rponse Erreurs : 0x00 (CMD_COMM) : 0x25 : Rception : Refus : Normal : Modification du n de cible de la carte : 1 octet D0 : nouveau n de cible : CC_NewCible : G1, G2, G3

Cette commande modifie le n de cible de la carte. Le n de cible combin au type de carte doit identifier une et une seule carte. Veillez donc ne pas introduire de doublons en utilisant cette commande.

48

Si vous avez fait une fausse manuvre, et que vous avez plac deux cartes diffrentes avec le mme n de cible, il vous faudra dsactiver une des deux cartes (placer en mode bootloader via le jumper ou couper son alimentation) afin de pouvoir modifier nouveau le numro de cible sur la seule carte reste en service. 7.3.14 CC_GoBoot Commande Paramtre Sens Broadcast Mode Rle Data : 0x00 (CMD_COMM) : 0x26 : Rception : Refus : Normal : Passer la carte en mode bootloader, puis reset : 2 octets D0 : 0x55 D1 : 0xA5 : CC_Carte : G1, G2

Rponse Erreurs

Cette commande est utiliser avec prudence. Elle permet la carte de passer en mode bootloader. Dans ce mode, la carte est prte recevoir une mise jour logicielle. Elle sera cependant dans lincapacit dassurer son rle habituel tant quelle restera dans ce mode. Pour tre clair : une carte en mode bootloader est hors-service jusqu son passage en mode normal. Comme pour la commande CC_Reset, les 2 octets de data ne servent que de confirmation la commande. La commande provoque un reset de la carte, ce qui explique lmission de la commande CC_Carte gnre chaque reset de la carte. Cette commande permet du reste Domogest de sassurer que la carte a bien commut dans le bon mode.

49

7.3.15 CC_WModeC Commande Paramtre Sens Broadcast Mode Rle Data : 0x00 (CMD_COMM) : 0x27 : Rception : Refus : Normal : Modification du mode de fonctionnement : 3 octets D0 : bits forcer 1 b0 : toujours 0 b1 : forcer le mode centralis b2 : mettre la led Can en service b2/b7 : forcer bits 2 7 de D4 de CC_Carte D1 : bits forcer 0 b0 : toujours 0 b1 : forcer le mode dcentralis b2 : mettre la led Can hors-service b2/b7 : effacer bits 2 7 de D4 de CC_Carte D2 : bits inverser b0 : toujours 0 b1 : inverser le mode de centralisation b2/b7 : inverser bits 2 7 de D4 de CC_Carte : CC_Carte : G1, G2, G3

Rponse Erreurs

Cette commande permet de modifier le fonctionnement de la carte. Le bit 0 ne peut pas tre modifi par cette commande car il correspond au bit de passage en mode bootloader. Ce bit ne peut tre modifi que par les commandes spcifiques dentre et de sortie du mode bootloader, ce qui permet dviter des erreurs de manipulation. Le bit 1 permet de basculer la carte entre le mode centralis et le mode dcentralis. Ceci nest utile que pour les cartes ayant un comportement diffrent dans les deux modes. Par exemple, en mode dcentralis, la carte dentre 16 boutons-poussoirs enverra toutes les trames Can programmes par lutilisateur lors de laction sur un BP. Par contre, en mode centralis, elle enverra uniquement une trame signalant quune action a t effectue sur un BP. Lunit centrale se chargeant alors dagir en consquence en fonction du logiciel de lutilisateur. Pour rappel, le mode dcentralis (mode par dfaut) permet de se passer dune unit centrale (PC ou autre) durant lutilisation du systme. Le bit 2 permet de modifier le fonctionnement de la led de trafic Can. Vous pourrez de la sorte, par exemple, laisser teintes toutes les leds de trafic Can pour les cartes non visibles (encastres), lorsque vous navez pas besoin dy avoir accs. Ainsi, en cours dinstallation ou de dpannage, vous les mettez en service, et ensuite vous les coupez. Notez que dans le mode bootloader, la led Can reste de toutes faons allume en mode fixe.

50

7.3.16 CC_Reset Commande Paramtre Sens Broadcast : Mode Rle Data : 0x00 (CMD_COMM) : 0x28 : Rception : Refus : Normal : Reset de la carte : 2 octets D0 : 0xA5 D1 : 0x55 : CC_Carte : G1, G2

Rponse Erreurs

Cette commande provoque un reset du pic de la carte. Les deux octets de data ne servent que de confirmation, pour viter un reset non dsir en cas de fausse manipulation. Le reset de la carte provoque automatiquement lmission de la commande CC_Carte, qui intervient tout redmarrage ou mise sous tension dune carte. Ce nest donc pas proprement parler une rponse la commande, mais plutt une consquence de son action. 7.3.17 CC_Carte Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x60 : Emission : Normal ou Bootloader : Informations gnrales sur la carte : 8 octets D0 : type de pic sur la carte D1/D3 : rvision logicielle : D1.D2.D3 D4 : mode de fonctionnement b0 : 0 = mode normal, 1= mode bootloader b1 : 0 = mode dcentralis, 1= mode centralis b2 : 1 = Led Can en service b3/b7 : rservs pour applications futures D5 : Paramtre complmentaire 1 (en gnral NBGERE) D6 : paramtre complmentaire 2 (dpend du type de carte) D7 : paramtre complmentaire 3 (dpend du type de carte)

La commande permet didentifier la carte cible et certains de ses paramtres. On obtient le type de pic prsent, la rvision du logiciel prsent, le mode de fonctionnement de la carte, et dautres informations dont la signification peut varier dune carte lautre. Ces donnes sont lecture seule, les donnes sont modifies soit lors de la programmation initiale (type de carte, type de pic), soit lors de la mise jour (numro de version), soit enfin via des commandes spcifiques (entre en mode bootloader etc).

51

Cette commande permet dtablir une reconnaissance automatique du rseau. Il suffit denvoyer des commandes de requte CC_RCarte pour tout type de destinataire possible en mode broadcast pour obtenir le relev complet du systme. Notez que chaque carte met automatiquement cette commande lors de sa mise sous tension ou lors dun reset (permet de raliser un logiciel PC plug and play ). Les informations permettent galement de sassurer de la compatibilit du logiciel envoy lors dune mise jour via le bootloader, ceci complt par lindication du n de version. La version software est reprsente par 3 nombres, sous la forme : Version nombre1.nombre2.nombre3 Par exemple, si la version renvoye est 0x02, 0x04, 0x08, la version est : V2.4.8 Loctet D4 permet de dtecter ltat actuel de fonctionnement de la carte. Le bit0 indique que la carte se trouve en fonctionnement oprationnel ou en mode de bootloading. Ce bit ne peut tre modifi que par les commandes spcifiques dentre et de sortie du mode bootloader. Le bit1 indique si la carte est en mode dcentralis et donc envoie lintgralit des commandes paramtres par lutilisateur, ou si elle se trouve en mode centralis, la gestion seffectuant alors via un logiciel sur unit centrale. Ce bit na de sens que pour les cartes susceptibles de voir leur comportement varier en fonction de la prsence dune unit centrale. Cest le cas de la carte 16 entres, mais ce nest pas celui de la carte gradateur. Le bit 2 permet de savoir si la LED Can de la carte est oui ou non en service. Les autres bits ne sont pas actuellement utiliss. Dans les autres octets, nous trouverons des donnes spcifiques certaines cartes, comme le nombre dentres cbles, le nombre de fonctions disponibles, etc. Rfrez-vous la documentation de chaque carte pour obtenir les informations. De nouveau, Domogest prend tout en charge de faon symbolique. 7.3.18 CC_Eep Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x61 : Emission : Bootloader : renvoi de loctet lu en mmoire eeprom : un octet D0 : octet lu en mmoire eeprom

Renvoie loctet de la mmoire eeprom concern par la commande de requte.

52

7.3.19 CC_PtrF Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x62 : Emission : Bootloader : Indique la position actuelle du pointeur en mmoire flash : 2 octets D0 : MSB du pointeur actuel D1 : LSB du pointeur actuel : b2/b0 = toujours 0

Cette commande permet de vrifier que ladresse dans laquelle on crit correspond bien celle prvue. On ncrit en mmoire flash que par bloc de 8 octets, ce qui explique que b2 b0 sont toujours gaux 0. 7.3.20 CC_Flash Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x63 : Emission : Broadcast : Renvoie la valeur des 8 octets dsigns par le pointeur. : 8 octets D0/D7 : 8 octets de mmoire flash, dans lordre ascendant

Cette commande renvoie les octets lus. Elle est gnre sur requte spcifique, ou aprs une criture en mmoire flash. Etant donn quune criture provoque lincrmentation automatique du pointeur, les octets concernent le pointeur tel quil tait avant lordre dcriture. En dautres termes, si vous imaginez le pointeur ladresse xxx, vous envoyez un ordre dcriture de 8 octets : 1) 2) 3) 4) 5) Vous initialisez le pointeur ladresse xxx Vous envoyez 8 octets, le pointeur pointe sur xxx + 8 Vous recevez les 8 octets relus partir de ladresse xxx (donc ceux que vous avez crits) Si vous interrogez le pointeur, vous recevez la valeur xxx + 8 La prochaine criture portera sur ladresse xxx + 8 et ainsi de suite.

Notez que les octets renvoys ne sont pas ceux que vous avez vous-mme envoys, mais ceux relus effectivement dans lemplacement flash. Ceci implique que : La rponse nintervient quaprs le temps dcriture ncessaire (+- 5ms) La rponse est en fait une seconde vrification du bon droulement de lcriture

53

7.3.21 Cmd_Zone Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x68 : Emission : Normal : Envoi des 8 octets de la zone utilisateur : 8 octets D0/D7 : octets de la zone utilisateur

Les donnes contiennent les 8 octets de la zone utilisateur. Pour rappel, cette zone est librement utilisable par lutilisateur, qui en fait lusage quil dsire. Ces donnes sont bien entendu mmorises en eeprom, et rsistent de ce fait une coupure de tension. 7.3.22 Cmd_NameC Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x69 : Emission : Normal : Envoi des 8 octets du nom de la carte : 8 octets D0/D7 : octets du nom de la carte

Comme son nom lindique, cette commande permet de fournir le nom de la carte interroge. 7.3.23 Cmd_NewCible Commande Paramtre Sens Mode Rle Data : 0x00 (CMD_COMM) : 0x6A : Emission : Normal : Envoi du nouveau n de cible : 1 octet D0 : nouveau n de cible

Cette commande est un peu particulire. En effet, afin de permettre au logiciel de contrle de se reconfigurer en consquence de la modification, le logiciel doit connatre la fois lancien n de cible ainsi que le nouveau n correspondant cette mme carte. Pour ce faire, la commande est mise par la carte avec dans son champs Cible (nnnnnnnn) le n tel quil tait AVANT la modification. La commande contient alors le nouveau n dans son octet de data. A partir de ce moment, toutes les commandes mises par la carte le seront avec le nouveau n de cible.

54

La mthode consiste donc envoyer au gestionnaire : Lancienne carte n nnnnnnnn a dornavant le n0 D0 La carte rpond donc en ralit avec un n de cible qui nest plus le sien partir de la prise en compte de la modification. Cette mthode permet au logiciel de contrle connecter de faire la modification au vol , les trames de ce type tant interceptes et traites automatiquement. Prenons un exemple, soit une carte de type 0x35 qui possde un numro de cible = 0x10. Nous dsirons modifier pour que la carte obtienne le nouveau n de cible 0x20. Nous allons donc envoyer une trame de modification du n de cible

0x35 Type destinataire

CMD_COMM Commande commune

0x10 CC_WNewCible 0x20 Cible N commande C D0 = nouveau n

Ceci signifie : sur la carte de type 0x35 qui possde le n 0x10, remplacer ce n par le n 0x20 La rponse de la carte sera : 0x35 Type destinataire CMD_COMM Commande commune 0x10 CC_NewCible Cible N commandeC 0x20 D0

Vous voyez que la carte rpond avec le n de cible 0x10, alors que ce n a t modifi en 0x20. A partir de cet instant, la carte ne rpondra plus au n de cible 0x10, mais bel et bien au n de cible 0x20. Bien videmment, avant de lancer une procdure de ce type, assurez-vous que ce numro de cible est libre pour le type de carte concerne, par exemple en envoyant une commande CC_RCarte en direction du nouveau n de cible prvu. Si aucune carte ne rpond, cest que le numro est libre. Domogest gre de nouveau tout ceci automatiquement. 7.4 Un mot sur les masques et filtres Afin de faciliter votre comprhension du fonctionnement du module Can des pics 18F, je vous explique en quelques mots comment fonctionnent les masques et les filtres Can. En mode 0 (Legacy), qui est le mode par dfaut, et lunique mode des PIC munis dun module Can (18Fxx8), vous avez 6 filtres et 2 masques. Un filtre doit toujours tre associ un masque. Avec le mode 0, lassociation est fige : Les filtres 0 et 1 sont associs au masque 0 Les filtres 2 5 sont associs au masque 1

55

En mode 1 ou 2, disponibles uniquement sur les PIC munis de modules ECAN (comme les 18Fxx80), vous disposez de 15 masques et 2 filtres, plus au choix un masque ou un filtre supplmentaire. Ceci vous donne le choix entre : 16 filtres et 2 masques ou 15 filtres et 3 masques

En mode 1 (Enhanced Legacy ), ou 2 (FIFO) qui est celui que nous utiliserons, lassociation entre chaque filtre et chaque masque est configurable par logiciel. Les masques et filtres interviennent uniquement sur lidentificateur (ID) de la trame Can entrante lorsque nous travaillons en mode 0, ou si lidentificateur est sur 29 bits (notre cas). Si la combinaison masque/filtres permet daccepter la trame Can, alors elle est mmorise dans les registres correspondants du PIC. En mode 1 ou 2, si lidentificateur est cod sur 11 bits, vous pouvez galement utiliser le masque pour les 18 premiers bits de data, mais ce nest pas le cas de Domocan. Si la combinaison filtre/masque ne valide pas la trame, alors elle est simplement ignore, et le logiciel du PIC ne saperoit mme pas de son arrive. Corollaire : la rception dune trame Can non dsire ne consomme aucun temps CPU au niveau du PIC. Cest comme si la trame navait simplement pas exist. Tout comme dans votre bote mail, un message bloqu par votre filtre anti-spam vous vite davoir lire le spam en question. Le masque Can permet de dfinir sur quels bits portent les contrles de la trame entrante. Tout bit 1 indique un test excuter, tout bit 0 indique quon accepte la trame quel que soit le niveau du bit. Les masques et filtres sont donc cods sur les 29 bits utiles de lID, auxquels il faut ajouter un bit interne et 2 bits toujours 0. Ce bit interne (extended) vaut 1 si on travaille avec des identificateurs 29 bits, et 0 si on travaille avec des identificateurs 11 bits. Evidemment, il vaudra toujours 1 pour Domocan. Il est en fait inutile de prciser ce bit pour les masques, car bien que sa valeur soit 0 (read only), il est toujours considr en service. Inutile de vous proccuper pour a de toutes faons, je place ce bit dans les sources, mme sil nest pas rellement crit, uniquement par facilit de comprhension. Le suffixe de tous les registres rception, mission, masques, et filtres est toujours le mme. - xxxxSIDH - xxxxSIDL - xxxxEIDH - xxxxEIDL : concerne les 8 bits de poids fort de lID : concerne les 5 bits suivants, augment du bit extended et des 2 bits 0 : concerne les 8 bits suivants : concerne les 8 bits de poids faible.

56

xxxx est le prfixe qui dpend du type de registre (masque, filtre, buffer de rception, buffer dmission). Par exemple, le prfixe RXB0yyyy identifie le buffer de rception 0. En combinant les deux, nous obtenons ne nom du registre. Par exemple RXB0SIDH identifie donc les 8 bits de poids fort de lID de la trame prsente dans le buffer de rception 0. Si vous avez bien suivi jusqu prsent, la terminologie : - SIDH - SIDL - EIDH - EIDL : concerne le type de destinataire : concerne la commande : concerne la cible (n de carte) : concerne le paramtre (ou le n de commande commune pour les CMD_COMM)

Notez que pour des raisons de comprhension entre les identificateurs tendus (utiliss dans Domocan) et les identificateurs standards (sur 11 bits), le nom donn aux bits est un peu particulier : Les 11 premiers bits (poids fort) de lID sont dnomms SID10 SID0 (Standard ID) Les 18 bits suivants (poids faible) sont dnomms EID17 EID0 (Extended ID)

Ca ne change videmment rien pour nous, il ne sagit que dune dnomination dans les datasheets. Je prcise ici un petit dtail un peu ennuyeux, cest que la disposition des bits dans les registres SIDL est un peut particulire. Voici le contenu des registres :
SIDH SIDL EIDH EIDL : : : : SID10 SID2 EID15 EID7 SID9 SID1 EID14 EID6 SID8 SID0 EID13 EID5 SID7 0 EID12 EID4 SID6 EXIDEN EID11 EID3 SID5 0 EID10 EID2 SID4 EID17 EID9 EID1 SID3 EID16 EID8 EID0

Notez que les 5 bits de SIDL ne sont pas contigus, et quon y trouve le bit EXIDEN qui prcise quon travaille ou non sur des ID de 29 bits ainsi que 2 bits inutiliss. Dans les sources de Domocan, nous trouverons des sous-routines charges de remettre de lordre dans les bits au niveau des communications avec le bus Can, et notamment Domogest. Au niveau de Domogest, SIDL (n de commande) contiendra en fait une simple valeur sur 5 bits, de 0 31 (0x1F). En interne du programme PIC, lutilisation des CMD_xxx en lieu et place des valeurs 0 31 permet davoir les bits organiss de faon compatibles avec SIDL. Bref, revenons nos masques : tout bit mis 0 signale un bit automatiquement accept, tout bit 1 signale un bit qui sera test au niveau de lID. Nous allons tudier le cas dun filtre 0 et dun filtre 1 associs tout deux au masque 0. Sachant que notre masque 0 a comme prfixe le terme RXM0, nous avons donc : RXM0SIDH RXM0SIDL RXM0EIDH RXM0EIDL : masque 0 pour SID10 SID 3 = Type de destinataire : masque 0 pour SID2 SID0 + EID17 et EID16 = n de la commande : masque 0 pour EID15 EID8 = cible = n de la carte : masque 0 pour EID7 EID0 = paramtre 57

Evidemment, pour le masque 1, le prfixe sera RXM1. Nous avons ensuite exactement la mme organisation pour les filtres. Le prfixe du filtre 0 sera RXF0, et ainsi de suite. Pour quune trame Can soit accepte, il faut que CHACUN des bits de son ID soit accept par au moins une combinaison filtre/masque. Si un seul bit est refus, la trame entire est refuse. Par contre, il suffit dune seule combinaison filtre/masque valide pour accepter la trame. Pour quun bit dun ID soit accept, il faut : Soit que le bit correspondant du masque soit 0 Soit que le bit correspondant du filtre soit gal celui de lID de la trame

Dit de faon simple, on positionne 1 dans le masque tout bit quon veut tester, et dans le filtre on place la valeur que doit avoir le bit pour tre accept. Si on met 0 dans le bit du masque, ce bit sera automatiquement accept quelle que soit sa valeur. Si on prend comme exemple le bit SID2. Pour que le bit soit accept par la combinaison masque0/filtre0, il faut : Soit que le bit SID2 de RXM0SIDH = 0 Soit que le bit SID2 de RXF0SIDH = SID2 de lID de la trame reue.

Si vous voulez une formule dalgbre de Boole, on peut dire que pour tre accept, il faut que: MASQUE AND (ID reu XOR FILTRE ) = 0 Prenons donc quelques exemples :
RXM0SIDH RXM0SIDL RXM0EIDH RXM0EIDL RXF0SIDH RXF0SIDL RXF0EIDH RXF0EIDL RXF1SIDH RXF1SIDL RXF1EIDH RXF1EIDL = = = = = = = = = = = = B11111111 B11100011 : ATTENTION:b3(EXIDEN) vaut 0, MAIS est considr comme 1 B00000000 B00000000 B10100101 B00001000 B01010101 B00110011 B10100100 B11101000 B01101001 B11001010

Imaginons quon reoive une trame dont lID vaut : ID = 10100100 00000 10100111 10010001

Cet ID sera stock dans les registres de rception provisoires suivants : 58

SIDH SIDL EIDH EIDL

: 10100100 : 00001000 (3 bits dID, 0, bit EXIDEN, 0, 2 bits dID) : 10100111 : 10010001

Notez trame sera-t-elle accepte ou non ? Voyons le tableau rcapitulatif, en imaginant que EXIDEN vaudra toujours 1 pour Domocan :
Masque0 Filtre0 Filtre1 ID reu 11111111 10100101 10100100 10100100 11101011 00001000 11101000 00001000 00000000 01010101 01101001 10100111 00000000 00110011 11001010 10010001

On doit donc faire 2 tests, un avec le masque0 et le filtre 0, et un autre avec le masque0 et le filtre 1. Evidemment il faudra galement faire de mme avec chaque combinaison filtre/masque programme, mais vu que le mcanisme est identique, nous ne le ferons pas dans notre exemple : Si vous regardez la combinaison Masque0/filtre0/ID, et que nous indiquons F pour un bit refus et V pour un bit accept, nous avons :
Masque0 Filtre0 ID reu Rsultat 11111111 10100101 10100100 VVVVVVVF 11101011 00001000 00001000 VVVVVVVV 00000000 01010101 10100111 VVVVVVVV 00000000 00110011 10010001 VVVVVVVV

Jai indiqu en jaune les conditions dacceptation, et en vert les conditions de refus. Notez que tous les bits sont accepts SAUF 1. Autrement dit, la trame sera refuse par la combinaison masque0/filtre0, puisque tous les bits ne sont pas accepts. Si vous regardez ce qui cause le refus, il sagit de SID3, pour lequel le masque vaut 1, et pour lequel le bit du filtre nest pas gal celui de lID reu. Notez quil nest nul besoin de tester EIDH et EIDL (cible et paramtre), ils seront tous accepts car leur masque vaut 0. Voyons le second test :
Masque0 Filtre1 ID reu Rsultat 11111111 10100100 10100100 VVVVVVVV 11101011 11101000 11111100 VVVVVVVV 00000000 01101001 10100111 VVVVVVVV 00000000 11001010 10010001 VVVVVVVV

La trame sera donc accepte par cette combinaison, puisque tous les bits sont accepts. Puisque au moins une combinaison masque/filtre accepte la trame, la trame est accepte. Toute lastuce de la gestion des ID consiste donc jouer intelligemment avec les masques et les filtres. Nous pourrons ainsi aisment accepter les trames destines uniquement notre carte prcise, en imposant la correspondance pour SIDH et SIDL. Nous accepterons uniquement les commandes communes en acceptant uniquement la commande 0 et tous les paramtres (masque 0).

59

Nous accepterons toutes les commandes en plaant le masque SIDL 0. Nous pouvons accepter galement les commandes par groupe, en plaant certains bits du masque pour SIDL 0 et dautres 1. Une fois bien compris ce mcanisme, la quasi-totalit du secret du Can est perce. 7.5 Anomalie de fonctionnement Lors de lutilisation des PIC18Fxx8 dans nos sources, vous aurez constat que le bit SRR du registre SIDL vaut toujours 0 pour nos trames (extended, donc avec EXID=1) reues. Le datasheet confirme dailleurs ce point : SRR: Substitute Remote Request bit This bit is always '0' when EXID = 1 or equal to the value of RXRTRRO (RBXnCON<3>) when EXID = 0. Or, en faisant la migration sur les nouveaux xx80, plusieurs internautes mont fait part du fait que les applications ne fonctionnaient plus. Ceux qui disposaient dun debugger ont constat quen fait, malgr que le datasheet des xx80 soit identique sur ce point celui des xx8, le bit SRR sur ces PIC tait en fait positionn 1, ce qui fausse videmment tous les tests portant sur le traitement de la commande reue. Le document de migration entre xx8 et xx80 ne fait pas non plus allusion cette diffrence importante de comportement. En fait, pour les modules ECAN actuels, il savre que le bit SRR se retrouve 1 pour les trames Extended reues. Il convient donc dignorer ce bit pour conserver lquivalence entre xx8 et xx80. Interrog sur ce point, le service technique Microchip, qui semblait tout ignorer de ce problme ma, aprs vrification, indiqu que les nouveaux datasheets produits se verraient corrigs sur ce point prcis, pour correspondre la ralit. Selon votre version de datasheet, vous constaterez donc ou non une anomalie de fonctionnement. A lheure o jcris ces lignes, lerreur subsiste.

60

8. Fichiers de base dun logiciel Domocan

8.1 Les fichiers ncessaires Pour vous aider raliser un logiciel compatible Domocan par vous-mme, je vous fournis les fichiers de base qui sont utiliss pour chaque nouvelle application. Ils sont au nombre de 7 : 1) Base.asm : contient le squelette dune application Domocan. Il vous suffit de faire un copier/coller de ce fichier, et de lui donner le nom de votre futur programme. Ne vous reste plus, si jose dire, qu construire lapplication en elle-mme. 2) Domoboot.inc : contient la partie bootloader du programme et certaines fonctions de base communes toutes les cartes 3) Domodef.inc : contient les dclarations de base communes toutes les cartes Domocan 4) CCommunes.inc : contient la gestion des commandes communes. Ceci vite dencombrer le fichier base.asm, et donc au final le source de votre application, avec des routines reproduites chaque fois. 5) ParCan.inc : contient les paramtres de votre propre bus Can. Une fois ce fichier configur ventuellement avec vos propres paramtres, protgez-le en criture, afin quil ne soit pas cras lors du chargement dune nouvelle rvision des fichiers de base via mon site. 6) Configurations.inc : cest un nouveau fichier qui permet de sparer les configurations du PIC du fichier de base, le rendant plus clair. Les configurations dpendent du type de pic choisi via la constante TYPEPIC du fichier base.asm . La valeur du watchdog nest pas reprise dans ce fichier, car peut varier selon lapplication. 7) Fonctions.inc : Encore un nouveau type de fichier. Il contient une librairie de fonctions utilises dans la plupart des cartes Domocan, comme les lectures/critures en mmoire eeprom, etc. Pour pouvoir assembler un fichier source fourni, il est impratif que les 6 derniers fichiers se trouvent dans le mme rpertoire que le fichier source sur lesquels vous travaillez. Je vais analyser le contenu de ces fichiers, de faon vous expliquer comment fonctionnent les logiciels des cartes. Bien entendu, il nest nullement ncessaire de comprendre pour utiliser Domocan, mais a vous sera utile de toutes faons si vous dsirez poursuivre le dveloppement sur les pics. Il se peut que le contenu de ces fichiers diffre quelque peu de la version que vous aurez charge sur mon site, il mest difficile en effet de modifier les documents chaque modification mineure dun fichier. Les commentaires et lhistorique prsents sur chaque fichier vous permettront de comprendre les ventuelles modifications.

61

8.2 Le fichier domodef.inc Je commence par ce fichier, qui ne contient que des assignations et defines communs toutes les cartes, ainsi que quelques macros. Attention, la comprhension des explications ncessitent davoir un minimum de connaissances sur le fonctionnement des PIC en gnral, et des 18Fxx80 en particulier. Je vous renvoie ce sujet sur les cours PART1, PART2, et PART5 prsents sur mon site. Je vais procder lanalyse avec vous de son contenu.
;***************************************************************************** ; Dfinitions, assignations et macros pour le systme DOMOCAN * ; Une modification peut ncessiter de recharger les boots dans * ; les pics des cartes. * ; * ;***************************************************************************** ; * ; NOM : DomoDef.inc * ; Date cration : 12/08/2003 * ; Date modification : 13/03/2008 * ; Version : 3.0 * ; Circuit : * ; Auteur : Bigonoff * ; * ;***************************************************************************** ; * ; Historique * ; ---------* ; * ; V1.00 : 12/08/2003 : premire version oprationnelle pour mise en ligne* ; V1.10 : 23/11/2003 : modif mineure : rseau sur 4 bits, ajout d'un * ; paramtre complmentaire * ; modification de la numrotation des commandes * ; pour regrouper les trames mises et reues afin * ; d'optimiser la gestion des filtres et masques * ; * ; V1.11 : 17/11/2004 : Ajout d'un bit pour dcentralisation dans la * ; commande CMD_SOFTW * ; Ajout de la commande Cmd_WModeC pour entre autres * ; placer la carte en mode centralis/dcentralis * ; * ; V2.0 : le 08/09/05 : refonte totale pour modification de stratgie * ; sur les identifictateurs. Augmentation du nbre de * ; cartes possibles, suppression du n de rseau, * ; modification des trames, suppression des adresses * ; de carte * ; * ; V3.0 : le 13/03/08 : modifications suite l'utilisation des nouveaux * ; pics avec module ECAN. Les bits dans RXBxSIDL * ; ne fonctionnant pas comme prvu dans le datasheet * ;*****************************************************************************

Dans cette partie, selon mon habitude, vous retrouvez les informations principales. En cas dvolution, un coup dil sur cet en-tte vous permettra de savoir sil y a eu mise jour depuis votre prcdent tlchargement.

62

Remarquez que la rvision 3.0 marque le passage aux PIC18Fxx80, ainsi que pour les autres documents dont nous allons parler. Ensuite, nous trouvons une zone contenant les dfinitions gnrales, et tout dabord :
;***************************************************************************** ; DEFINITIONS ET ASSIGNATIONS * ;***************************************************************************** #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE #DEFINE TXBxCON TXBxSIDH TXBxSIDL TXBxEIDH TXBxEIDL TXBxDLC TXBxD0 TXBxD1 TXBxD2 TXBxD3 TXBxD4 TXBxD5 TXBxD6 TXBxD7 RXBxCON RXBxSIDH RXBxSIDL RXBxEIDH RXBxEIDL RXBxDLC RXBxD0 RXBxD1 RXBxD2 RXBxD3 RXBxD4 RXBxD5 RXBxD6 RXBxD7 RXB0CON RXB0SIDH RXB0SIDL RXB0EIDH RXB0EIDL RXB0DLC RXB0D0 RXB0D1 RXB0D2 RXB0D3 RXB0D4 RXB0D5 RXB0D6 RXB0D7 RXB0CON RXB0SIDH RXB0SIDL RXB0EIDH RXB0EIDL RXB0DLC RXB0D0 RXB0D1 RXB0D2 RXB0D3 RXB0D4 RXB0D5 RXB0D6 RXB0D7 ; pour viter les confusions quand on utilise ; l'access bank via WIN2/WIN0 de CANCON (mode 0) ; ou EWINx de ECANCON (mode 2)

; pour viter les confusions quand on utilise ; l'access bank via WIN2/WIN0 de CANCON (mode 0) ; ou EWINx de ECANCON (mode 2)

Ce sont en fait des alias qui permettent daccder en ralit au buffer de rception 0, RXB0xxx. Lexplication de ces alias demande un peu de dveloppement : Le problme est que seuls les registres concernant le buffer de rception 0 se trouvent en accs bank. Les autres registres auxquels on accde rgulirement ne sont donc accessibles quen changeant de banque, ou en utilisant ladressage indirect. Lastuce qu trouve Microchip est dutiliser le buffer de rception 0 un peu comme un registre dindirection. Selon la valeur affecte certains bits spcifiques, les registres RXB0 permettent daccder en ralit aux registres commenant par RXB1, TXB0 (buffer dmission 0), TXB1, etc. Voici comment tout ceci fonctionne : En mode 0 (legacy), qui est le mode par dfaut la mise sous tension, et galement lunique mode disponible dans les PIC pourvus de modules CAN et non ECAN, comme cest le cas pour un 18F258 par exemple, le registre qui contrle laccs est le registre CANCON.

63

Les bits WIN2 (b3) Win1 (b2) et Win0 (b1) indiquent quel registre vous dsirez accder en ralit. Ces bits sont mis 0 la mise sous tension, et les choix sont les suivants :
111 110 101 100 011 010 001 000 = = = = = = = = Receive Buffer 0 Receive Buffer 0 Receive Buffer 1 Transmit Buffer 0 Transmit Buffer 1 Transmit Buffer 2 Receive Buffer 0 Receive Buffer 0

Remarquez qu la mise sous tension, les bits sont 0, ce qui vous donne accs aux 13 registres du buffer RXB0. RXB0 pointe donc sur RXB0, pas de surprise. Si vous ne touchez jamais ces bits, chaque fois que vous accderez RXB0, vous accderez bien au buffer de rception 0. Par contre, pour accder aux autres buffers (mission et rception), tant donn quils se trouvent hors de laccess-bank, vous devrez soit changer de banque (noubliez pas de grer au niveau des interruptions), soit vous devrez utiliser ladressage indirect. Par contre, si vous utilisez ces bits, il faudra savoir que lorsque vous accderez aux emplacements du buffer de rception 0, vous accderez en fait au buffer point par les bits WIN2 WIN0. Petit exemple, soit ce code excut la mise sous tension :
movf bsf movf RXB0CON,w CANCON,WIN1 RXB0CON,w ; on charge le registre rel RXB0CON ; WIN = 010 ; on charge le registre rel TXB2CON

Remarquez quil est trs peu lisible de se rendre compte que RXB0CON ne concerne pas RXB0CON dans la ralit, le programme devient illisible. Cest pourquoi jai utilis lastuce des alias pour que le code soit plus clair. Lexemple prcdent deviendra :
movf bsf movf RXB0CON,w CANCON,WIN1 TXBxCON,w ; on charge le registre rel RXB0CON ; WIN = 010 ; on charge le registre rel TXB2CON

De cette faon, on voit immdiatement en relisant le source quon accde un registre dmission dont on ignore le numro, et donc on sait que ce numro dpend dautre chose (ici : CANCON). Dans notre programme, nous travaillons non pas en mode 0 (Legacy), mais en mode 2 (FIFO), mode qui nous donne plus de souplesse, mais qui nest disponible que sur les PIC munis de modules ECAN (18Fxx80 par exemple). Comme ce mode ncessite plus de registres, il y a plus de bits pour slectionner le registre rel de destination. La slection nest donc plus confie aux 3 bits WIN du registre CANCON, mais aux 4 bits EWIN du registre ECANCON. Moyennant quoi le principe est exactement le mme. EWIN4 est le bit 4, EWIN0 est le bit 0. Voici les 32 possibilits de ces 4 bits : 64

00000 = Acceptance Filters 0, 1, 2 and BRGCON2, 3 00001 = Acceptance Filters 3, 4, 5 and BRGCON1, CIOCON 00010 = Acceptance Filter Masks, Error and Interrupt Control 00011 = Transmit Buffer 0 00100 = Transmit Buffer 1 00101 = Transmit Buffer 2 00110 = Acceptance Filters 6, 7, 8 00111 = Acceptance Filters 9, 10, 11 01000 = Acceptance Filters 12, 13, 14 01001 = Acceptance Filters 15 01010-01110 = Reserved 01111 = RXINT0, RXINT1 10000 = Receive Buffer 0 10001 = Receive Buffer 1 10010 = TX/RX Buffer 0 10011 = TX/RX Buffer 1 10100 = TX/RX Buffer 2 10101 = TX/RX Buffer 3 10110 = TX/RX Buffer 4 10111 = TX/RX Buffer 5 11000-11111 = Reserved

Vous constatez quen plaant EWIN 10000 par exemple, vous accdez au registre de rception 0 (RXB0). Notez quil sagit galement de la valeur par dfaut la mise sous tension, donc, de nouveau, tant que vous ne manipulez pas ces bits explicitement, aucun risque de surprise. ATTENTION : En modificant les bits WINx (mode 0) ou EWINx (modes 1 et 2), vous accdez aux registres slectionns lorsque vous accdez aux emplacements de RXB0 indpendamment du mode daccs : access-bank, mode banked, ou adressage indirect. Dit de faon plus explicite, si vous modifiez les bits WIN ou EWIN (selon le mode) une valeur pointant sur autre chose que RXB0, vous navez plus aucun moyen daccder aux registres RXB0, sauf en replaant les bits WIN ou EWIN une valeur pointant sur RXB0. Si je complte le premier exemple (mode 0), voici ce que a donne :
movf bsf movf movff lfsr movff bcf movf movff lfsr movff RXB0CON,w CANCON,WIN1 RXB0CON,w RXB0CON,var FSR1,RXB0CON INDF1,var CANCON,WIN1 RXB0CON,w RXB0CON,var FSR1,RXB0CON INDF1,var ; ; ; ; ; ; ; ; ; ; ; on charge le registre rel RXB0CON WIN = 010 on charge le registre rel TXB2CON on copie bel et bien TXB2CON dans var on pointe sur ladresse de RXB0CON mais on copie bel et bien TXB2CON dans var seule faon de reprendre accs RXB0CON on charge alors RXB0CON on copie RXB0CON dans var on pointe sur ladresse de RXB0CON et on copie bel et bien RXB0CON dans var

Vient ensuite la ligne :

STARTP EQU 0x400 ; adresse dbut programme utilisateur

Qui donne ladresse de dpart de votre programme utilisateur. Les adresses prcdentes sont utilises par le bootloader. Notez que les adresses prcdentes recouvrent galement les

65

adresses de connexion des interruptions (0x04 et 0x08), qui sont rediriges par le programme bootloader vers votre programme utilisateur. Si vous modifiez cette ligne, ou un des paramtres de ce fichier, vous devrez rassembler vos fichiers sources et recharger les programmes via un programmateur classique. En effet, dans ce cas, les instructions de saut du programme utilisateur ne correspondront plus celles prsentes dans le bootloader. Donc, souvenez-vous que vous avez le droit, videmment, de modifier tout ce que vous voulez, mais toute modification sur les fichiers dcrits dans ce document risque dentraner lobligation de recharger le bootloader dans chaque pic de votre installation, ainsi que dimposer un rassemblage de votre application. Il est important de le comprendre. Il est probable galement que a ncessite des modifications logicielles au niveau de Domogest. Pas question donc de modifier ces informations puis denvoyer le nouveau fichier via le bootloader. Si vous ne comprenez pas tout parfaitement, alors vitez de modifier les fichiers .inc dont il est question dans ce document. Ensuite, je rappelle la structure des diffrents ID utiliss dans le bootloader du Domocan :
;============================================================================= ; COMMANDES Can = ;============================================================================= ; structure d'un ID gnral ; ------------------------; Identificateur : dddddddd ccccc nnnnnnnn pppppppp ; SIDH SIDL EIDH EIDL ; ; avec tttttttt : type de destinataire ; types de cartes, de 0x20 0xDF ; destinataires particuliers : le reste (heure, infos gnrales, etc) ; ccccc : N de la commande ; nnnnnnnn : N de cible = N de la carte ; de 0 254 : s'adresse une seule carte ; 255 : n broadcast pour toutes les cartes identiques ; pppppppp : paramtre complmentaire, dpend du contexte ; valeurs standard : ; -----------------CIB_BROAD EQU 0xFF

; cible pour broadcast

; valeurs standard du n de commande ; ---------------------------------; Structure de SIDL : b4 b3 b2 0 1 0 b1 b0

Vous trouvez ici ce qui a dj t expliqu dans le chapitre concernant lidentificateur Can sur Domocan. lID est un lment cl dans la gestion dun bus Can, il dtermine la faon dont sont conus tous les changes dinformations. Vous vous souviendrez galement que la commande, qui tait code sur 5 bits utiles dans les explications et dans Domogest, est en fait code dans un registre de 8 bits lintrieur du

66

pic. Cest pourquoi je vous ai expliqu que lorsque vous envoyez une commande, il ne faut pas utiliser la valeur immdiate, mais recourir aux assignations faites dans le programme. A titre dexemple, si vous voulez envoyer une commande n 12, soit 0x0C, votre vision de la commande est celle-ci :
0 0 0 0 0 0 0 b4 1 b3 1 b2 0 b1 0 b0

alors qu lintrieur du PIC (et donc au niveau du source asm), linformation envoyer est de la forme :
0 b4 1 b3 1 b2 0 0 1 1 0 0 0 b1 0 b0

Autrement dit, la valeur placer dans le bon registre est 0x68 au lieu des 0x0C prvus. Le bit continuellement 1 indique en fait quon travaille avec des ID sur 29 bits. Afin de vous faciliter la tche, jai converti toutes ces valeurs votre place. De ce fait, vous pourrez utiliser des noms symboliques au lieu de traduire toutes les valeurs. Cest ce qui est fait ci-dessous :
CMD_ERR CMD_COMM CMD_1 CMD_2 CMD_3 CMD_4 CMD_5 CMD_6 CMD_7 CMD_8 CMD_9 CMD_10 CMD_11 CMD_12 CMD_13 CMD_14 CMD_15 CMD_16 CMD_17 CMD_18 CMD_19 CMD_20 CMD_21 CMD_22 CMD_23 CMD_24 CMD_25 CMD_26 CMD_27 CMD_28 CMD_29 CMD_30 CMD_31 EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU EQU B'11101011' B'00001000' B'00001001' B'00001010' B'00001011' B'00101000' B'00101001' B'00101010' B'00101011' B'01001000' B'01001001' B'01001010' B'01001011' B'01101000' B'01101001' B'01101010' B'01101011' B'10001000' B'10001001' B'10001010' B'10001011' B'10101000' B'10101001' B'10101010' B'10101011' B'11001000' B'11001001' B'11001010' B'11001011' B'11101000' B'11101001' B'11101010' B'11101011' ; ; ; ; trame d'erreur (0x1F) pour trame d'administration) commandes communes commandes de 1 31 en tenant compte de la disposition de SIDL

67

Pour reprendre lexemple prcdent, si vous voulez envoyer la commande 12 dans un source asm, vous ne pouvez pas envoyer 0x0C, mais nul besoin non plus de traduire et denvoyer 0x68. Il vous suffit en fait denvoyer la commande CMD_12. Rien de plus simple, donc. Remarquez par exemple que les commandes communes sont directement appeles CMD_COMM, et non 0x00 . Idem pour la trame dadministration ou derreur, correspondant la commande n 31 qui est appele CMD_ERR. Notez bien que la commande derreur est identique la commande 31. En effet, une commande 31 peut tre envoye une carte en tant que commande spcifique. Par contre, si on envoie une commande 31 un type de destinataire = administration, alors il sagit bel et bien dune trame derreur (voir chapitre sur les trames derreur). Le rle dune commande, pour rappel, dpend bel et bien du type de destinataire qui on envoie la commande. Une commande 1 sur une carte gradateur ne produira pas le mme rsultat quune commande 1 sur une carte horloge. Au niveau des cartes spcifiques, des noms plus parlants seront assigns, en lieu et place des CMD_xx. Au niveau de lextrieur du pic, sur le rseau Can, donc vu par Domogest, lorganisation des bits ne se proccupe pas de lorganisation interne des pics (et cest heureux). Pour envoyer une commande 12, il suffit denvoyer 12 (0x0C) comme n de commande. Puisquon parle de destinataires, la plupart sont des types de cartes (gradateur, entre, horloge etc), mais dautres, comme nous lavons dj vu, sont des destinataires spciaux rservs par Domocan :
;============================================================================= ; destinataires spciaux = ;============================================================================= ;----------------------------------------------------------------------------; valeurs possibles de 0x00 0x1F et 0xE0 0xFF ;----------------------------------------------------------------------------DEST_INFO1 EQU 0x01 ; informations gnrales priorit 1 DEST_ADMIN EQU 0xFD ; destinataire pour trames d'administration

Vous retrouvez ici votre fameux destinataire ADMIN qui est un destinataire fictif destin recevoir diverses informations, comme les fameuses trames derreur. Le destinataire est le premier octet de lID, ds lors il dtermine la priorit de la trame Can. Le destinataire ADMIN, commenant par des 1 , qui est le niveau rcessif, est donc de basse priorit. Afin de permettre la circulation dinformations gnrales de haute priorit, jai rserv un autre type de destinataire commenant par des 0 , savoir DEST_INFO1. Et justement, puisquon en parle, en voici une :

68

;============================================================================= ; COMMANDES D'INFORMATIONS GENERALES = ;============================================================================= ;----------------------------------------------------------------------------; Trames destines donner des informations gnrales. ; Ces trames sont mises avec des n de destinataires figs, ce qui permet ; de dfinir des priorits particulires ;----------------------------------------------------------------------------CMD_CLOCK equ CMD_1 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Heure systme -E destinataire : DEST_INFO1 Cible : n de la carte paramtre : 0x00 octets de data : 6 ou 7 D0 : Anne + flag b7 : 0 = heure valide b6/b0 : Anne de 0 99 D1 : Mois et jour de la semaine + flag b7 : Emetteur principal (0) ou secondaire (1) b6/b4 : jour de la semaine (1=lundi, 7=dimanche) b3/b0 : mois de 1 12 D2 : jour du mois + flags b7 : heure d'hiver(0) ou d't(1) b6/b5 : type de jour 00 : jour ordinaire 10 : jour d'absence 01 : jour de cong 11 : rserv b4/b0 : jour du mois de 1 31 D3 : Heure + flags b7 : 1 = veille d'un jour de cong b6 : Heure de jour(0) ou de nuit(1) b5 : Rserv pour utilisation future b4/b0 : heure de 0 23 D4 : Minute + flag b7/b6 : rservs pour utilisation future b5/b0 : minute de 0 59 D5 : Seconde + flag b7/b6 : rservs pour utilisation future b5/b0 : seconde de 0 59 D6 : Nombre de min sans remise l'heure par DCF n'existe qu'en mode PCF

Vous constatez que cette trame sera mise comme trame dinformation, cest--dire avec un type de destinataire DEST_INFO1 tel que dclar prcdemment. Cest donc une trame de haute priorit. Elle sera mise toutes les secondes par notre carte horloge mre, dcrite dans un autre document. Vous voyez ainsi une utilisation typique dune trame dinformation, trame destine tout qui veut bien sen servir, et non lintention dun type de carte particulier.

69

;============================================================================= ; COMMANDES COMMUNES A TOUTES LES CARTES = ;============================================================================= ;----------------------------------------------------------------------------; Identificateur : dddddddd CMD_COMM nnnnnnnn pppppppp ; SIDH SIDL EIDH EIDL ; ; dddddddd : type de destinataire ; SIDL_COMMUN : 5 bits 0 = commande commune ; nnnnnnnn : n de la carte cible ; pppppppp ; opration effectuer ; ;-R : trames reues (vu par la carte) ;-E : trames mises (vu par la carte) ;----------------------------------------------------------------------------; trames communes reues en mode bootloader ; interdit en broadcast ; ----------------------------------------CC_OUTBOOT EQU 0x10 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; sortir du mode bootloader -R octets de data : 2 D0 : 0x55 (confirmation) D1 : 0xA5 (confirmation) rponse : CC_CARTE codes d'erreur : G1,G2,G3 positionner pointeur flash -R octets de data : 2 D0 : MSB adresse absolue D1 : LSB adresse absolue rponse CC_PTRF codes d'erreur : G1,G6,G7,G8 demande de la valeur actuelle du pointeur flash -R octet de data : aucun rponse : CC_PTRF code d'erreur : G1 criture de 8 octets en mmoire flash -R octets de data : 8 D0/D7 : 8 octets de data flash rponse : CC_FLASH codes d'erreur : G1,G5,G6,G7,G7,G9 lecture de 8 octets en mmoire flash -R octets de data : 2 D0/D1 : adresse de dbut de lecture rponse : CC_FLASH code d'erreur : G1 crire un octet en mmoire eeprom -R octets de data : 2 D0 : adresse d'criture D1 : octet crire rponse : CC_EEP codes d'erreur : G1,G3,G10

CC_WPTRF EQU 0x11

CC_RPTRF EQU 0x12

CC_WFLASH EQU 0x13

CC_RFLASH EQU 0x14

CC_WEEP EQU 0x15

CC_REEP EQU 0x16

; lire un octet en mmoire eeprom -R ; octet de data : 1 ; D0 : adresse de lecture

70

; rponse : CC_EEP ; code d'erreur : G1 ;0x17/0x1F ; rservs pour utilisation future mode bootloader

; trames communes reues en mode normal ; --------------------------------------CC_RCARTE EQU 0x20 ; demande des informations de la carte -R ; broadcast accept ; accepte aussi en mode bootloader ; octet de data : aucun ; rponse : CC_CARTE ; code d'erreur : G1 CC_WZONE EQU 0x21 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; placer octets dans la zone utilisateur -R broadcast refus octets de data : 8 D0/D7 : 8 octets dfinis par l'utilisateur rponse : CC_ZONE codes d'erreur : G1,G3 demande des octets de la zone utilisateur -R broadcast accept octet de data : aucun rponse : CC_ZONE code d'erreur : G1 criture du nom de la carte -R broadcast refus octets de data : 8 D0/D7 : nom de la carte rponse : CD_NAMEC codes d'erreur : G1, G3 demande du nom de la carte -R broadcast accept octet de data : aucun rponse : CC_NAMEC code d'erreur : G1 modification du numro de la carte -R broadcast refus octet de data : 1 D0 : nouveau n de cible de 0 254 rponse : CC_NEWCIBLE codes d'erreur : G1,G2,G3 Passage en mode bootloader puis reset -R broadcast refus octets de data : 2 - Confirmation D0 : 0x55 D1 : 0xA5 Rponse : CC_CARTE code d'erreur : G1,G2 Modification du mode de fonctionnement de la carte -R broadcast accept octets de data : 3 D0 : bits de D4 de EIDL_CARTE mettre 1 b0 : 0 : interdit de passer en bootloader par cette commande

CC_RZONE EQU 0x22

CC_WNAMEC EQU 0x23

CC_RNAMEC EQU 0x24

CC_WNEWCIBLE EQU 0x25

CC_GOBOOT EQU 0x26

CC_WMODEC EQU 0x27

71

; ; ; ; ; ; ; ; ; ; ; ; ; CC_RESET EQU 0x28 ; ; ; ; ; ; ;

b1 : 1= passer en mode centralis b2 : 1 = valider le fonctionnement de la led CAN b3/b7 : rservs pour utilisations futures D1 : bits de D6 de CMD_SOFTW mettre 0 b0 : 0 : interdit de sortir de bootloader par cette commande b1 : 1 = passer en mode dcentralis b2 : 1 = interdire fonctionnement de la led CAN D2 : bits inverser b0/b7 : idem que pour commandes prcdentes Les oprations sont faites dans l'ordre D0,D1,D2 rponse : CC_CARTE Codes d'erreur : G1,G2,G3 reset de la carte -R broadcast refus octets de data : 2 D0 : 0xA5 D1 : 0x55 rponse : CC_CARTE (envoy au dmarrage) codes d'erreur : G1,G2

;0x29/0x2F

; rservs pour utilisation future ; trames communes mises ; ----------------------

CC_CARTE EQU 0x60

; envoi des informations de la carte -E ; octets de data : 8 ; D0 : type de pic sur la carte ; D1/D3 : V D1.D2.D3 ; D4 : Mode de fonctionnement ; b0 : 0 = mode normal, 1 = mode bootloader ; b1 : 0 = mode dcentralis (par dfaut), ; 1 = mode centralis ; b2 : Led trafic CAN (1 = en service) ; b3/b7 : rservs pour utilisation future ; D5 : paramtre complmentaire: en gnral NBGERE ; D6 : paramtre complmentaire(dpend type carte) ; D7 : paramtre complmentaire(dpend type carte) ; renvoi de l'octet lu en mmoire eeprom -E ; octet de data : 1 ; D0 : octet lu ; position actuelle du pointeur flash -E ; octets de data : 2 ; D0 : MSB pointeur flash actuel ; D1 : LSB pointeur flash actuel ; valeur des 8 octets dsigns par le pointeur -E ; octets de data : 8 ; D0/D7 : 8 octets de data flash ; rservs pour utilisation future ; envoi des octets de la zone utilisateur -E ; octets de data : 8 ; D0/D7 : 8 octets dfinis par l'utilisateur ; envoi des 8 octets du nom de la carte -E

CC_EEP EQU 0x61

CC_PTRF EQU 0x62

CC_FLASH EQU 0x63

; 0x64/0x67 CC_ZONE EQU 0x68

CC_NAMEC EQU 0x69

72

; octets de data : 8 ; D0/D7 : 8 octets du nom de la carte CC_NEWCIBLE EQU 0x6A ; confirmation de modification du N de la carte ; octet de data : 1 ; D0 : nouveau n de cible ; la rponse se fait avec ancien N de cible dans EIDH ; rservs pour des applications futures

;0x6B/0x6F

Nous disposons donc au total de 256 commandes communes possibles, nous avons de la rserve. Attention, ne confondez pas : les valeurs indiques sont celles prsentes directement dans le registre concern. Ce registre utilise les 8 bits utiles, contrairement au registre des commandes qui contient 5 bits utiles quil faut convertir. Pour envoyer une commande commune, il faut donc : Placer le type de destinataire dans les 8 premiers bits : dddddddd Placer la commande commune dans les 5 bits suivants : CMD_COMM : ccccc Placer le n de la carte cible : nnnnnnnn Placer le n de la commande commune utilise : CC_xxx : pppppppp Nous arrivons ensuite aux assignations des codes derreur, dj expliqus :
;============================================================================= ; CODES D'ERREUR RECONNUS = ;============================================================================= ; Identificateur : DEST_ADMIN CMD_ERR 00000000 eeeeeeee ; SIDH SIDL EIDH EIDL ; ; ; ; DEST_ADMIN CMD_ERR 00000000 eeeeeeee : : : : 0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 0x8A 0x8B 0x8C 0x8D destinataire du code d'erreur = CPU administration 5 bits 1 sur destinataire administration = trame d'erreur pourrait tre utilis dans le futur comme poids fort d'erreur n de l'erreur ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; erreur erreur erreur erreur erreur erreur erreur erreur erreur erreur erreur erreur erreur erreur 1 : nombre de paramtres incorrect 2 : data incorrecte 3 : erreur d'criture eeprom 4 : Valeur de paramtre incorrect 5 : erreur d'criture flash 6 : ptr flash non multiple de 8 7 : ptr flash dans zone protge 8 : pointeur flash hors-limite PIC 9 : pointeur flash non valide 10 : zone eeprom protge 11 : err. criture eeprom externe 12 : rserve utilisation future 13 : cmd illgale mode broadcast 14 : cmd commune invalide en mode bootloader erreur gnrale 15 : commande commune invalide en mode normal erreur gnrale 16 : commande invalide gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale gnrale

ERR_G1 equ ERR_G2 equ ERR_G3 equ ERR_G4 equ ERR_G5 equ ERR_G6 equ ERR_G7 equ ERR_G8 equ ERR_G9 equ ERR_G10 equ ERR_G11 equ ERR_G12 equ ERR_G13 equ ERR_G14 equ

ERR_G15 equ 0x8E ERR_G16 equ 0x8F

73

Rien de neuf donc. Remarquez le rappel de la structure dune trame den-tte, selon mon habitude dans mes sources. Ceci concerne les erreurs pouvant tre mises par une carte quelconque. Reste les erreurs (susceptibles dvolution) relatives des cartes spcifiques :
ERR_H1 EQU 0x90 ERR_S1 EQU 0x98 ; Erreur H1 : horloge mre pas l'heure ; Erreur S1 : carte sensitive pas en mode superviseur

Ce sont 2 n derreurs particuliers, concernant chacun une carte spcifique. Leur utilit sera explique dans le document relatif chaque carte. Nous trouvons ensuite une srie de macros.
;============================================================================= ; MACROS = ;============================================================================= TESTCMD macro commande ; tester si la commande correspond movlw commande ; charger commande cpfseq cmdrec ; tester si correspond commande mmorise endm

La premire va tre utilise pour dtecter si la commande correspond celle attendue. On compare simplement le n de commande pass en paramtre ( commande ) celui reu via le bus Can par la carte ( cmdrec ). En suite de cette macro, dans le source, nous trouverons un saut vers le test suivant, du genre :
TESTCMD bra CMD_1 testsuivant ; tester si commande1 reue ; non, voir test suivant

puis nous avons :

TESTCC macro commande movlw commande cpfseq parrec endm ; tester si la commande commune correspond ; charger commande ; comparer avec paramtre reu = n commande commune)

Ce test est strictement identique, mais concernant le test dune commande commune. Souvenez-vous en effet que toutes les commandes communes sont une et une seule mme commande relle (CMD_COMM). Une fois dtect quil sagit bien dune commande commune ( TESTCMD CMD_COMM ), il nous faut encore savoir de laquelle il sagit. Cest le rle de cette macro, qui teste si le paramtre reu ( parrec ) via le bus Can correspond au n de commande commune dsir. Vous en verrez des exemples dans le fichier CCommunes.inc
TESTDAT macro nb IF nb == 0 tstfsz POSTINC0 ENDIF IF nb == 1 decfsz POSTINC0,w ENDIF IF nb > 1 movlw nb cpfseq POSTINC0 ENDIF ; tester nombre de data ; cas du test sur 0 octet ; tester si nbre data = 0 ; cas du test sur 1 octet ; tester si nbre data = 1 ; autres cas ; charger nbre octets de data prvus ; comparer avec nombre reu

74

goto endm

senderrG1

; nombre d'octets de data incorrects

Il sagit ici dune macro qui teste le nombre de data reus avec la trame Can. Comme vous lavez vu, si le nombre doctets de data ne correspond pas celui attendu, une erreur de type ERR_G1 est envoye. Cest exactement ce que fait cette macro. Notez que, pour optimiser un peu, la mthode de test est diffrente selon quon attend 0,1, ou plusieurs octets de data. Cest de nouveau une application de lassemblage conditionnel.
STARTINT macro bsf INTCON,GIEH bsf INTCON,GIEL endm ; lancer les interruptions (bug dans le pic) ; autoriser interruptions H.P. ; autoriser interruptions B.P.

Cette macro permet de lancer les interruptions de faon correcte lorsquon utilise les interruptions sur 2 niveaux. Ceci est la consquence dun bug dans les 18Fxx8, qui impose de lancer les interruptions haute priorit avant celles de basse priorit. Jai conserv cette mthode, au cas o, a ne change rien au niveau des performances de respecter cet ordre. Nous trouvons bien entendu la procdure correspondante, due au mme bug, pour couper les interruptions :
STOPINT bcf bcf endm macro INTCON,GIEL INTCON,GIEH ; stopper les interruptions (bug dans le pic) ; couper interruptions B.P. ; couper interruptions H.P.

Ensuite, nous avons nos macros Can :

SETCONFIG macro movlw B'10000000' movwf CANCON clrwdt btfss CANSTAT,OPMODE2 bra $-(2*2) endm ; ; ; ; ; ; passer le can en mode configuration prparer demande configuration et pointer sur buffer rception 0 effacer watchdog tester si passage effectu non, attendre passage effectif

Cette macro passe la module Can en mode configuration. Ceci est indispensable pour avoir laccs en criture aux principaux registres de configuration. Pour tre certain quon se trouve en mode de configuration, il convient encore dattendre la confirmation, ce qui seffectue par la boucle dattente de cette macro. Notez le *2 , qui rappelle que chaque instruction occupe 2 octets en mmoire programme, tout saut de ce type doit donc tre pair. La routine suivante permet de lancer le module en mode 2 (FIFO), qui est le mode que nous utiliserons avec nos nouveaux modles de PIC :
SETMODE2 macro movlw B'10000000' movwf ECANCON bcf OUTRS clrf CANCON clrwdt movf CANSTAT,w andlw 0xE0 ; ; ; ; ; ; ; ; passer le can en mode 2 demande de mode 2 FIFO dans registre de contrle MCP2551 en mode full speed requte de passage en mode normal effacer watchdog charger status actuel conserver mode en cours

75

bnz endm

$-(3*2)

; pas commut, attendre

Le principe est exactement le mme que pour le passage en mode de configuration, notez galement la boucle dattente de confirmation. Suivent ensuite une srie de petites macros de pointage : POINTRX0 macro movlw B'10010000' movwf ECANCON endm POINTRX1 macro movlw B'10010001' movwf ECANCON endm POINTTX0 macro movlw B'10000011' movwf ECANCON endm POINTTX1 macro movlw B'10000100' movwf ECANCON endm POINTTX2 macro movlw B'10000101' movwf ECANCON endm ; pointe sur buffer rception 0 ; configurer EWINx ; dans ECANCON

; pointe sur buffer rception 1 ; configurer EWINx ; dans ECANCON

; pointe sur buffer mission 0 ; configurer EWINx ; dans ECANCON

; pointe sur buffer mission 1 ; configurer EWINx ; dans ECANCON

; pointe sur buffer mission 2 ; configurer EWINx ; dans ECANCON

Ces macros permettent au registre RXB0 de pointer en ralit sur le registre prcis dans la macro, exactement comme je lai expliqu plus haut dans ce document.
LEDCAN_ON macro btfsc STLEDCAN IFDEF LEDCANREV bcf LEDCAN ELSE bsf LEDCAN ENDIF endm LEDCAN_OFF macro IFDEF LEDCANREV bsf LEDCAN ELSE bcf LEDCAN ENDIF endm ; ; ; ; ; ; allumer led si allumage si allumage allumer led si allumage allumer led trafic CAN demand sur tat bas sur tat haut

; ; ; ; ;

teindre led trafic CAN si allumage sur tat bas teindre LED si allumage sur tat haut teindre LED

Ces deux macros servent grer la led Can de chaque carte. Selon que la led sallume sur tat bas ou sur tat haut, la macro agira en consquence. La macro tient galement compte du fait que lutilisateur a paramtr sa carte pour grer ou non lallumage de la Led, nous en avons dj parl.

76

Ceci termine ltude de notre fichier dinclusion Domodef.inc . Vous voyez quil ny a rien de bien compliqu.

8.3 Le fichier domoboot.inc Ce fichier est plus complexe tudier, tout assimiler ncessite la bonne comprhension des mcanisme du Can tels que traits dans le PIC. Pour bien comprendre, ce fichier reprsente la partie qui sera fige dans votre PIC lors de la programmation. Depuis la rvision 4.0 de ce fichier, le programme principal nutilise plus des sauts vers les routines du bootloader, celui-ci devient donc compltement indpendant du module principal, afin dviter toute interaction pour les utilisateurs modifiant leur fichier domoboot.inc. Si vous comprenez bien, lorsque vous programmez pour la premire fois un PIC sur une carte Domocan, vous placez avec votre programmateur lintgralit de lapplication, savoir le rsultat de lassemblage, qui intgre le bootloader. Par contre, lorsque vous chargerez une mise jour, aprs modification et recompilation de votre source, vous nenverrez vers votre PIC que la partie concernant lapplication, lexception de la partie bootloader, qui, elle, est fige dans le PIC. Cest cette partie fige qui est dcrite ici. Le module Can sera paramtr, nous lavons vu, pour fonctionner en mode 2 (FIFO) dans lapplication principale. Par contre, en mode bootloader, le module sera configur en mode 0 (Legacy), car ce mode est largement suffisant pour dialoguer commande par commande avec le programme PC de bootloader.
;***************************************************************************** ; Bootloader inclure pour cartes DOMOCAN * ; Contient la partie du code fige dans le pic * ; * ;***************************************************************************** ; * ; NOM : DomoBoot * ; Date cration : 11/08/2003 * ; Date modification : 14/03/2008 * ; Version : 4.00 * ; Auteur : Bigonoff * ; * ;***************************************************************************** ; * ; Historique * ; ---------* ; V1.00 : Le 27/10/03 : Premire version compltement termine en ligne * ; * ; V1.01 : Le 03/10/03 : Modif mineure * ; * ; V1.02 : Le 11/01/04 : Report de la macro de test du bootswitch vers * ; les programmes principaux (modification possible) * ; Petites optimisations du code * ; Modification du comportement sur commandes non * ; autorises en mode bootloader (plus de rponse) * ; *

77

; V2.0 : le 28/06/04 : Modification suite la dcouverte d'un bug * ; dans les pics. Lorsque le registre BSR pointe * ; sur la banque 15 (ce qui tait le cas pour les * ; versions prcdentes), le pic a des * ; comportements erratiques en fonction de la valeur* ; des instructions (modifs de TRISE, problmes * ; EEPROM, effacement de la mmoire flash etc.) * ; Toutes les applications existantes ont t * ; modifies pour ne plus passer BSR en banque 15. * ; * ; V2.10 : le 10/10/04 : Correction d'un bug dans la commande * ; quelques optimisations * ; * ; V2.20 : le 17/11/04 : Ajout de la gestion de bits supplmentaires dans * ; la commande CMD_SOFTW, les variables locales * ; changent d'adresse suite la dcouverte d'un * ; nouveau bug dans les GFR 0x51 0x5D. * ; * ; V2.21 : Le 11/01/05 : Prise en compte d'un nouveau bug dans les pics * ; GIEL doit tre coup avant GIEH/GIE si on veut * ; couper les interruptions. * ; * ; V3.00 : le 01/03/05 : refonte totale pour modification de stratgie * ; sur les identifictateurs. Augmentation du nbre de * ; cartes possibles, suppression du n de rseau, * ; modification des trames, suppression des adresses * ; de carte. Augmentation du temps de propagation * ; aprs essais sur cble pair de 100 mtres. * ; Diminution du phase segment 2 pour conserver la * ; mme vitesse. * ; * ; V3.10 : le 02/03/06 : Prise en compte de paramtres personnels via le * ; fichier ParCan.inc pour paramtrer le bus CAN * ; en fonction des besoins de l'utilisateur. * ; * ; V3.11 : le 06/02/07 : Forcer le buffer de rception CAN en 0x100 pour * ; contrer problme si buffer dfinit dans le * ; fichier asm principal ne pointe pas sur un dbut * ; de banque. Tout fichier asm modifi au niveau * ; de "tramesbuf" doit avoir cette version de * ; bootloader -> reprogrammation par voie classique * ; * ; V4.0 : le 14/03/08 : Migration des 18Fxx8 vers les 18Fxx80 * ; Utilisation du module ECAN en mode 2 (FIFO) au * ; lieu du mode 0 (legacy) du CAN 18Fxx8 pour le * ; fonctionnement normal. Le mode bootloader reste * ; en mode 0 (rponse trame par trame) * ; A partir de cette version, aucune routine * ; bootloader n'est plus utilise par le programme * ; principal (limite le risque de mise jour du * ; bootloader * ;*****************************************************************************

Vous noterez galement qu partir de la rvision 3.10, le paramtrage complet du bus Can est possible, ce qui introduit du mme coup la prsence du fichier ParCan.inc . A partir de la rvision 4.0, on passe lutilisation des PIC de type 18Fxx80.
#include <ParCan.inc> ; paramtres du bus Can utilis

78

Vient ensuite le traitement par macros des paramtres utilisateur prsents dans le fichier ParCan.inc. Le but nest rien dautre que de transformer les choix en clair de lutilisateur en valeurs placer dans les diffrents registres de configuration. Notez galement la prsence de tests destins viter de traiter des valeurs incorrectes :
;----------------------------------------------------------------------------; CALCUL DES REGISTRES DE CONFIGURATION Can ;----------------------------------------------------------------------------; Calcul de BRGCON1 ; ----------------SETBRGCON1 macro ; macro de placement de la valeur LOCAL val1,val2 ; variables locales val1 = SJW ; Affecter SJW IF (SJW ==0) || (SJW > 4) ; vrification du SJW MESSG "SJW non compris entre 1 et 4, valeur 1 prise par dfaut" val1 = 1 ; valeur par dfaut ENDIF val2 = TQ ; affecter TQ IF (TQ ==0) || (TQ > 64) ; vrification du time quanta MESSG "TQ non compris entre 1 et 64, valeur 2 prise par dfaut" val2 = 2 ; valeur par dfaut ENDIF val1 = val1-1 ; valeur de 0 3 val2 = val2-1 ; valeur de 0 63 movlw (val1 * .64)+val2 ; valeur effective placer dans BRGCON1 movwf BRGCON1 ; placer dans registre de configuration endm ; fin de macro ; Calcul de BRGCON2 ; ----------------SETBRGCON2 macro ; macro de placement de la valeur LOCAL val1,val2 ; variables locales val1 = SEG1 ; Affecter phase segment 1 IF (SEG1 ==0) || (SEG1 > 8) ; vrification du phase segment 1 MESSG "SEG1 non compris entre 1 et 8, valeur 5 prise par dfaut" val1 = 5 ; valeur par dfaut ENDIF val2 = PROP ; affecter PROP IF (PROP ==0) || (PROP > 8) ; vrification du temps de propagation MESSG "PROP non compris entre 1 et 8, valeur 8 prise par dfaut" val2 EQU 8 ; Temps de propagation = 8TQ ENDIF val1 = ((val1-1)*8)+(val2-1) ; placer propagation et segment 1 val2 = SAMPL ; affecter sample IF SAMPL > 1 ; vrification du sample MESSG "SAMPL non compris entre 0 et 1, valeur 1 prise par dfaut" val2 = 1 ; 3 lectures sur porte majoritaire ENDIF IF val2 == 1 ; si 3 lectures demandes val1 = val1+.64 ; forcer bit SAM 1 ENDIF val1 = val1+.128 ; indiquer phase segment 2 programmable movlw val1 ; charger valeur calcule movwf BRGCON2 ; placer dans registre endm ; fin de macro ; Calcul de BRGCON3 ; -----------------

79

SETBRGCON3 macro ; macro de placement de la valeur LOCAL val1 ; variable locale val1 = SEG2 ; Affecter phase segment 2 IF (SEG2 ==0) || (SEG2 > 8) ; vrification du phase segment 2 MESSG "SEG2 non compris entre 1 et 8, valeur 6 prise par dfaut" val1 = 6 ; valeur par dfaut ENDIF movlw val1-1 ; charger valeur calcule movwf BRGCON3 ; placer dans registre endm ; fin de macro

Nous trouvons ensuite deux constantes :

;----------------------------------------------------------------------------; CONSTANTES DE VERIFICATION ;----------------------------------------------------------------------------; Ces deux informations seront crites toujours au mme endroit en mmoire ; flash. ; Ceci permet donc de vrifier si le fichier hex qu'on tente de bootloader ; correspond au pic et au type de carte de destination. ;----------------------------------------------------------------------------ORG 0x02 ; emplacement constant pour toutes les cartes DB DESTI,TYPEPIC ; type de destinataire et type de pic

Notez que ce sont des valeurs crites directement dans la mmoire programme du PIC, et dans la zone infrieure 0x400 (voir fichier domodef.inc), donc rserve au bootloader. Autrement dit, ces valeurs sont crites au moment de la premire programmation du PIC et ne seront jamais crases lors dune reprogrammation par bootloader. Vous devez donc charger votre programme de faon classique la premire fois avec ces valeurs correctement initialises. Ces 2 constantes reprsentent le type de carte dont il est question (immuable sur une carte donne par dfinition), et le type de pic plac sur la carte, galement immuable dans le programme charg. Il est vident, mais je le rappelle cependant, quil serait difficile de remplacer le PIC laide dune procdure de bootloader, cest pourquoi cette information peut tre fige dans le PIC sans problme. Ceci permet damliorer efficacement la scurit du bootloader, car a rend impossible la mise jour dune carte avec un logiciel qui ne lui est pas destin (erreur de fichier .hex). Viennent maintenant les redirections des vecteurs :
;----------------------------------------------------------------------------; VECTEURS ;----------------------------------------------------------------------------ORG 0x00 ; vecteur de reset bra bootloader ; tester si bootloader en cours (protg) ORG bra ORG 0x08 STARTP+ 0x0A 0x18 ; vecteur d'interruption haute priorit ; traiter la routine haute priorit ; vecteur d'interruption basse priorit

80

bra

STARTP+0x06

; traiter la routine basse priorit

Il sagit ici de vecteurs de reset et dinterruptions, afin de permettre le traitement aux endroits appropris. Tout dabord, volontairement, le bootloader nutilise aucune interruption. Il na rien dautre faire que dattendre les commandes Can, et, de plus, ceci permet de ne pas devoir traiter les interruptions deux endroits diffrents : dans le programme principal et dans la partie bootloader, ce qui ferait perdre du temps de raction au niveau du programme principal (indirection systmatique avec test du mode actuel). Vous voyez que le vecteur de reset envoie toujours le programme vers le bootloader (ORG 0x00 : bra bootloader) chaque reset. Dans cette partie, on teste si le PIC est en mode bootloader ou pas : Si oui, on reste dans lexcution du fichier dont nous sommes en train de parler Si non, on saute dans le programme principal dont ladresse STARTP a t dclare dans le fichier domodef.inc.

Le dbut de la routine bootloader prend en charge galement les initialisations de base, communes toutes les cartes. La configuration des paramtres Can en est un exemple. Notez, vu les diffrences dassignation des pins, que chaque bootloader est spcifique un type de carte. Vous ne pouvez pas placer, par exemple, un fichier .hex destin une carte gradateur dans une carte interrupteurs, puis procder aprs une mise jour par bootloader avec le logiciel adquat. Dans une carte gradateur, vous placez un fichier .hex destin une carte gradateur, et dans une carte interrupteur, un fichier .hex destin une carte interrupteur. Aprs, vous pourrez procdez aux mises jour ventuelles sans problme. Revenons nos vecteurs. On trouve galement les deux vecteurs dinterruption (les PIC grent les interruption sur deux niveaux : haute et basse priorit). En cas dinterruption, le programme se connecte sur 0x08 ou sur 0x18 pour traiter respectivement une interruption haute ou basse priorit (voir cours-part5). Les vecteurs ici prsents effectuent un saut vers deux emplacements fixes dans notre programme principal. Les contenus de ces routines pourront changer (puisque pas dans la zone bootloader) , mais dmarreront toujours aux mmes adresses. Pour lutilisateur, tout se passe comme si les vecteurs dinterruptions dorigine taient remplacs par deux nouvelles adresses. Vous allez objecter que cela retarde le traitement des interruptions, cause du saut. Il faut savoir quen gnral, linterruption haute priorit est celle qui doit tre traite le plus rapidement. Si vous examinez ce qui se passe, vous constatez que le traitement nest pas du tout retard (encore que sil ltait, ce ne serait pas de grand-chose, 40Mhz). Ceci peut sembler curieux, mais vous allez voir que cest exact. En effet, dans un PIC18F, on trouve deux adresses de destination pour les interruptions : 0x08 et 0x18. La mmoire est donc organise comme ceci :
ORG 0x08 Routine dinterruption haute priorit

81

ORG 0x18 Routine dinterruption basse priorit

Pour ma part, je pense que Microchip a fait une erreur en les disposant dans cet ordre, voyons pourquoi : imaginons que chacune de nos deux routines comporte 200 octets dinstruction :
ORG 0x08 Premire instruction de linterruption haute-priorit . . . . ; suite . . . . ; suite bra suite ; on na pas la place pour tout mettre ORG 0x18 Premire instruction de linterruption basse priorit . . . . . . . . retfie ; fin de linterruption basse priorit suite . . . . . . . . retfie FAST

; ici, on continue le traitement de linterruption ; haute priorit ; fin de linterruption haute priorit.

Si vous regardez ce qui se passe, moins que votre routine dinterruption haute priorit comporte moins de 16 octets, vous devrez faire un saut pour poursuivre ailleurs le traitement. Par contre, inutile de sauter pour linterruption basse priorit. Je ne sais pas ce que vous en pensez, mais moi, je trouve a illogique, puisque la routine haute priorit est sense ragir avec un temps minimum. Si vous examinez les nouvelles adresses que jai dtermines, il sagit de ladresse de dbut de la zone programme utilisateur +4 pour la routine basse priorit, et +8 pour la haute priorit. Lorganisation dans le programme principal sera donc de la forme :
ORG STARTP bra main ORG STARTP+4 bra intlp ORG STARTP+8 . . . . retfie FAST intlp . . . . retfie main . . . . ; traiter programme principal

; traiter interruptions basse-priorit

; on peut traiter directement la haute-priorit ici ; fin de linterruption haute priorit ; traitement de linterruption basse priorit ; in de linterruption basse priorit ; traitement du programme principal

Vous voyez que jai invers lordre. On ne doit plus sauter pour linterruption hautepriorit. Autrement dit, on a saut depuis le bootloader, mais on ne saute plus ensuite, on na donc rien retard du tout pour linterruption haute-priorit.

82

Vous pourriez penser quil suffisait de donner ladresse de destination directement dans le bootloader, savoir bra intlp par exemple, au lieu de bra STARTP+4), ce qui conomiserait un saut pour les interruptions basse-priorit. En fait, a ne fonctionnerait pas, car le bootloader est immuable, et les adresses resteraient figes lors dune mise jour. Or, si vous allongez la routine dinterruption haute-priorit pour une mise jour (rien ne vous en empche), alors ladresse intlp serait dplace et ne correspondrait plus celle inscrite dans le bootloader. La mthode utilise permet de saffranchir de cette contrainte, en ne perdant que 2 cycles, et ce, uniquement sur les interruptions basse priorit, ce qui na aucune espce dimportance dans notre cas. Maintenant, pourquoi un cart de 4 entre chacune des adresses ? Simple, cest pour permettre, dans le programme utilisateur, lutilisation dun goto en lieu et place dun bra pour le cas o les distances de saut seraient trop importantes. Pour rappel, les adresses sont codes par octet. Il faut donc 2 octets (16 bits) pour une instruction classique (bra), et 4 octets (32 bits) pour une instruction sur adresses longues, comme le goto . Nous trouvons ensuite quelques lignes permettant dindiquer lemplacement des variables utilises dans notre bootloader :
;============================================================================= ; VARIABLES POUR LE BOOTLOADER = ;============================================================================= bootloc01 EQU 0x4A bootloc02 EQU 0x4B bootloc03 EQU 0x4C bootloc04 EQU 0x4D comcom EQU 0x4E cderr EQU 0x4F flagsb EQU 0x50 cibleb EQU 0x51 ; ; ; ; ; ; ; ; variable locale bootloader variable locale bootloader variable locale bootloader variable locale bootloader commande commune reue code d'erreur flags divers cible de la carte

; DEFINES POUR FLAGS BOOTLOADER ; ----------------------------#DEFINE PTRFOK flagsb,0 ; pointeur flag correctement initialis

Remarquez que ces variables ne sont utilises QUE dans le mode bootloader, elles ninterfrent donc pas avec les emplacements des variables dclares dans notre programme principal. Lorsquon est en mode bootloader, on nest pas en mode de fonctionnement normal, on na donc jamais un double usage de la mme adresse. Entrons maintenant dans les initialisations :

83

;============================================================================= ; INITIALISATIONS = ;============================================================================= ;----------------------------------------------------------------------------; contient les initialisations non modifiables excutes lors d'un reset ; ---------------------------------------------------------------------------bootloader ; valeurs par dfaut sur les PORTs ; -------------------------------movlw VALPORTA ; valeur par dfaut PORTA movwf PORTA ; dans PORTA movlw VALPORTB ; valeur par dfaut PORTB movwf PORTB ; dans PORTB movlw VALPORTC ; valeur par dfaut PORTC movwf PORTC ; dans PORTC IFDEF PORTD ; si PortD existe movlw VALPORTD ; valeur par dfaut PORTD movwf PORTD ; dans PORTD ELSE ; sinon nop ; mme taille, par prcaution future nop ENDIF IFDEF PORTE ; si PORTE existe movlw VALPORTE ; valeur par dfaut PORTE movwf PORTE ; dans PORTE ELSE ; sinon nop ; mme taille, on ne sait jamais pour le futur nop ENDIF IFDEF PORTF ; si PORTF existe movlw VALPORTF ; valeur par dfaut PORTF movwf PORTF ; dans PORTF ELSE nop nop ENDIF IFDEF PORTG ; si PORT existe movlw VALPORTG ; valeur par dfaut PORT movwf PORTG ; dans PORT ELSE nop nop ENDIF IFDEF PORTH ; si PORT existe movlw VALPORTH ; valeur par dfaut PORT movwf PORTH ; dans PORT ELSE nop nop ENDIF IFDEF PORTJ ; si PORT existe movlw VALPORTJ ; valeur par dfaut PORT movwf PORTJ ; dans PORT ELSE nop nop ENDIF

En fonction des noms de registres rellement prsents dans le fichier P18Fxx80.inc, et donc en fonction du modle de PIC utilis, les ports seront initialiss leur valeur de

84

dmarrage voulue, pour mettre la carte en tat de repos. Cette mthode est plus efficace que lancienne (gestion en fonction de TYPEPIC), car a permet de prendre en compte un PIC non encore prvu lors de lcriture de ce bootloader, ainsi que tous les ports possibles dans la famille complte. Les initialisations en question sont excutes lors de lentre en mode bootloader, avant de rendre ventuellement la main au programme principal si le pic nest pas en mode bootloader. Bien que les assignations pour les ports (direction et valeur de dmarrage) se trouvent dans le programme principal, ces informations sont inscrites dans la partie bootloader du pic, et ne sont donc pas modifiables par mise jour via le bootloader. Cest logique, votre hardware na pas de raison de changer lors dune mise jour logicielle. Remarquez que ceci est toutefois possible, rien ne vous empche de modifier par la suite ces valeurs dans votre programme principal. Sachez cependant que ces registres auront dj t initialiss correctement. Viennent ensuite la configuration des entres/sorties de ces mmes ports :
; initialiser registres direction ; ------------------------------movlw ADCON1VAL ; fonctionnement des pins PORTA movwf ADCON1 ; dans registre de contrle movlw DIRPORTA ; valeur de direction PORTA movwf TRISA ; dans TRISA movlw DIRPORTB ; valeur de direction PORTB movwf TRISB ; dans TRISB movlw DIRPORTC ; valeur de direction PORTC movwf TRISC ; dans TRISC IFDEF TRISD ; si TRISD existe movlw DIRPORTD ; valeur de direction PORTD movwf TRISD ; dans TRISD ELSE ; sinon nop ; mme taille, par prcaution future nop ENDIF IFDEF TRISE ; si TRISE existe movlw DIRPORTE ; valeur de direction PORTE movwf TRISE ; dans TRISE ELSE ; sinon nop ; mme taille, on ne sait jamais pour le futur nop ENDIF IFDEF TRISF ; si TRIS existe movlw DIRPORTF ; valeur de direction PORT movwf TRISF ; dans TRIS ELSE nop nop ENDIF IFDEF TRISG ; si TRIS existe movlw DIRPORTG ; valeur de direction PORT movwf TRISG ; dans TRIS ELSE nop nop ENDIF IFDEF TRISH ; si TRIS existe movlw DIRPORTH ; valeur de direction PORT

85

movwf TRISH ELSE nop nop ENDIF IFDEF TRISJ movlw DIRPORTJ movwf TRISJ ELSE nop nop ENDIF

; dans TRIS

; si TRIS existe ; valeur de direction PORT ; dans TRIS

Vous allez me dire quon aurait pu viter de faire deux fois les tests, puisque si le port existe, son registre de direction galement. Mais en fait, il sagit ici de directives et non dinstructions, ces tests ne sont pas prsents dans le PIC, et donc ne consomment ni place, ni temps CPU. Par contre, cest plus clair prsent de cette faon. On commence ensuite avec du plus srieux :
; initialiser CAN de base ; ----------------------movlw B'10000000' ; prparer demande configuration movwf CANCON ; et pointer sur buffer rception 0 clrwdt ; effacer watchdog btfss CANSTAT,OPMODE2 ; tester si passage effectu bra $-(2*2) ; non, attendre passage effectif bsf bcf PORTB,2 TRISB,2 ; ligne au repos si pas de CAN ; CANTX en sortie ; ; ; ; ; placer paramtres utilisateur dans BRGCON1 placer paramtres utilisateur dans BRGCON2 placer paramtres utilisateur dans BRGCON3 niveau rcessif forc Vdd, pas de mode capture dans registre de contrle

SETBRGCON1 SETBRGCON2 SETBRGCON3 movlw B'00100000' movwf CIOCON

Le module CAN est simplement pass en mode configuration, puis configur correctement. Notez que la transformation des valeurs du fichier CanPar.inc en valeurs placer dans les registres seffectue par directives MPASM. Dans le PIC se trouveront donc charges directement les bonnes valeurs, sans aucun calcul. Attention que toute modification ultrieure de votre fichier ParCan.inc naura aucun impact sur les PIC dj programms, il vous faudrait donc dans ce cas tout reprogrammer manuellement, sans passer par le bootloader. Cest du reste logique, car il est de toutes faons impossible de faire fonctionner sur le mme bus des PIC dont le module Can serait configur diffremment. Par scurit, la ligne CanTX est force 1 si le module Can est mis hors service. En effet, cest le niveau rcessif, qui na donc aucune influence sur le bus. Notez cependant que si vous forciez volontairement la ligne 0 (dominant), la protection incluse dans le driver MCP2551 de votre carte la dissocierait de votre bus.

86

movlw rcall xorlw bnz rcall xorlw bnz

; tester si on est en mode bootloader ; ----------------------------------BOOT_EEP ; adresse de l'identificateur en eeprom readeepwb ; lire octet 1 'B' ; comparer avec "B" bootloadmode ; si pas gaux, mode bootloader readeepb ; lire octet 2 'G' ; comparer avec "G" bootloadmode ; si pas gaux, mode bootloader

On teste ici si on a demand pralablement le mode bootloader. Pour ce faire, le PIC vrifie len-tte de leeprom. Sil ny trouve pas les deux caractres BG , il considre que soit lutilisateur a demand explicitement le mode bootloader, soit quun dfaut grave de leeprom ncessite de passer dans ce mode.
; tester si B.P. bootloader enfonc ; --------------------------------bcf INTCON2,RBPU ; mettre rsistances pullup en service IFDEF DEBUG ; si mode debug bra STARTP ; bouton pas pouss (RB6 utilis par debugger) ELSE ; en mode normal clrf bootloc01 ; effacer variable locale testswbl btfsc BOUTON ; tester si bouton press bra STARTP ; non, sortir decfsz bootloc01,f ; tester si 256 tests effectus bra testswbl ; non, continuer ENDIF

Si tout est correct jusqu prsent, reste encore tester si lutilisateur na pas utilis la mthode de secours pour forcer le mode bootloader, savoir positionner le jumper boot sur la carte Domocan. Pour tre certain de ne pas entrer en mode bootloader par accident aprs une remise en service dune alimentation perturbe, il faut que le jumper ait t dtect prsent 256 fois de suite pour valider sa prsence. Si ce nest pas le cas, on passe la main au programme principal, qui poursuivra alors le reste des initialisations.
; oui, forcer le mode bootloader ; -----------------------------BOOT_EEP ; adresse validateur bootloader en eeprom EEADR ; dans pointeur d'adresse WREG ; rien mettre writeeepb ; effacer validateur writeeepb ; effacer 2 octets, pour tre certain

movlw movwf clrf rcall rcall

Cette routine efface len-tte de leeprom. De ce fait, si une coupure dalimentation intervenait durant la procdure de bootload, le PIC repasserait automatiquement en mode bootloader ds la tension rtablie, et ne tenterait pas dexcuter un programme incomplet. Cette partie de code termine les oprations pralables lexcution de la partie de code dsire. Nous entrons maintenant dans la routine de bootloader proprement dite :

87

;============================================================================= ;============================================================================= ;============================================================================= ; BOOTLOADER = ;============================================================================= ;============================================================================= ;============================================================================= ;----------------------------------------------------------------------------; Permet de modifier le logiciel embarqu directement depuis le bus CAN ; ; L'en-tte de l'eeprom doit contenir "BG" pour que le programme soit ; considr comme valide. S'il est diffrent, on arrive sur ce code ; ; Une fois qu'on arrive ici, l'en-tte a dj t effac. ; Celui-ci sera reconstitu une fois la commande de sortie du bootloader reue. ; Cette sortie s'effectue par un reset du pic aprs rcriture de BG ; ; A l'entre en mode bootloader, on envoie une trame d'identification qui ; indique qu'on se trouve en mode bootloader ; ; dans ce mode, seules sont acceptes les commandes communes bootloader ; ; ID : DESTI CMD_COMMUN CIBLE Ncommande Commune ; ; les numros de commande bootloader sont compris de 0x50 0x5F ; A a, il faut ajouter la commande 0x60 de requte d'identification de la carte ; ; On reoit les emplacements mmoire par paquet de 8 octets ; une fois programms, les 8 octets sont relus et renvoys sur le bus CAN ; La partie bootloader est protge contre les crasements ; ; Entre en mode bootloader : ; Soit l'identificateur de la zone eeprom est diffrent de "BG" ; Soit on reoit une commande CMD_GOBOOT ; Soit le jumper de forage bootloader est positionn au reset de la carte ; ; Sortie du mode bootloader : ; Rception de la commande commune CC_OUTBOOT ;-----------------------------------------------------------------------------

Selon mon habitude, une zone de commentaires prcise quelques notions importantes de ce qui va suivre.
bootloadmode ; initialisations ; --------------; si allumage ; allumer LED ; si allumage ; allumer LED

IFDEF LEDCANREV bcf LEDCAN ELSE bsf LEDCAN ENDIF

sur tat bas CAN sur tat haut CAN

Cette premire partie allume la led de trafic Can, indpendamment du choix de lutilisateur de mettre ou non cette led en service. Ainsi, une led constamment allume indique que la carte se trouve actuellement en mode bootloader, ce qui assure une vrification visuelle.

88

clrf

flagsb

; effacer flags

; copier les paramtres ncessaires de eeprom vers ram ; ---------------------------------------------------movlw CIBLE_EEP ; offset du n de la carte en EEP rcall readeepwb ; lire cible movwf cibleb ; sauver en RAM

On initialise ensuite nos variables principales, ce qui se limite effacer nos flags et amener le numro de la carte (cible) de leeprom vers la RAM. En effet, ce numro est constamment utilis, il serait improductif de lire sa valeur constamment partir de leeprom.
; paramtrer CAN en mode 0 ; -----------------------movlw B'01000000' ; messages extended seulement, pas de report sur RXB1 lfsr FSR2,RXB0CON ; pointer sur RXB0CON movwf INDF2 ; uniquement messages extended

Je rappelle que le module Can (Ecan) du PIC sera utilis en mode 2 (FIFO) dans le programme principal, et en mode 0 (Legacy) dans le module bootloader. Cette premire partie de linitialisation du module Can paramtre le buffer 0 pour la rception de trames de type extended. Nous avons le droit de paramtrer le buffer de rception 0 pour quun message arrivant sur ce buffer soit redirig vers le buffer de rception 1 dans le cas o le buffer 0 na pas encore t libr. Il faut savoir en effet quen mode 0 chaque masque est reli au buffer de rception du mme numro. Nous travaillons ici avec la combinaison masque 0/filtre 0, et donc avec le buffer de rception 0. Nous coupons donc la possibilit de redirection, car notre bootloader ne se sert que de lunique buffer de rception 0, ce qui facilite le traitement. Il est inutile de chercher vouloir stocker des commandes Can en mode bootloader, car le PC attend confirmation de la bonne excution de lordre avant de passer la commande suivante.
lfsr FSR2,RXF0SIDH bootload1 setf POSTINC2 btfss FSR2L,5 bra bootload1 ; pointer sur premier registre filtre CAN ; FF dans le filtre ou le masque ; tester si zone 0xF00 / 0xF1F termine ; non, registre suivant

Cette portion de code place par dfaut tous les bits de tous les masques et filtres 1. En mode 0, nous navons pas, contrairement aux autres modes, la possibilit de mettre hors service un filtre ou un masque. Jutilise donc lastuce suivante : En plaant 1 tous les bits du masque, je force la trame tre strictement identique la valeur des filtres associs, bit pour bit. En plaant 1 tous les bits de SIDL des filtres 1, je ne peux ds lors accepter que les trames de type 11111111. Or, par dfinition, en Can, une trame dont lID commence par 7 bits dominants est illgale.

Autrement dit, je positionne masques et filtres des valeurs telles quaucune trame lgale ne puisse tre reue, ce qui revient couper simplement les masques et les filtres correspondants.

89

A ce stade, aucune trame nest donc accepte par notre module Can. Il nous faut pourtant paramtrer notre combinaison masque0/filtre0, afin de recevoir les seules trames qui nous intressent dans le mode bootloader, savoir les trames de commandes communes. Ceci seffectue avec le code suivant :
; placer masque 0 ; --------------FSR2,RXM0EIDL ; pointer sur masque 0 EIDL INDF2 ; on accepte toutes les commandes communes

lfsr clrf

Pour rappel, une commande commune Domocan est de la forme :

Destinataire Cmd_Commun Cible n de commande

SIDH

SIDL

EIDH

EIDL

En annulant les bits EIDL du masque 0 (RXM0SIDL), nous acceptons toute trame dont SIDH SIDL et EIDH sont strictement identiques au filtre associ, mais pas contre si cette correspondance est tablie, nous acceptons toute trame quelle que soit son numro de commande.
; placer filtre 0 ; --------------FSR2,RXF0SIDH ; pointer filtre 0 SIDH DESTI ; charger type de destinataire POSTINC2 ; n'accepter que celui-l CMD_COMM ; charger commandes communes WREG,EXID ; commandes extended uniquement POSTINC2 ; n'accepter que les commandes communes cibleb,POSTINC2 ; N de la carte uniquement

lfsr movlw movwf movlw bsf movwf movff

Associ au masque prcdent, on programme pour le filtre 0 : SIDH SIDL EIDH EIDL : doit correspondre au destinataire de la carte : doit tre une commande de type commune : la cible doit tre cette carte : aucune importance, nest pas test par le masque, donc toute commande commune

Dit en bon franais, on acceptera toute commande commune destine cette carte-ci. Voyez donc comment il est ais dutiliser des masques et filtres pour ne recevoir que les trames qui nous arrangent.
; passer le CAN en mode actif ; --------------------------clrf ECANCON ; module CAN en mode 0 legacy bcf OUTRS ; MCP2551 en mode full speed clrf CANCON ; requte de passage en mode normal clrwdt ; effacer watchdog movf CANSTAT,w ; charger status actuel andlw 0xE0 ; conserver mode en cours btfss STATUS,Z ; tester si mode normal bra $-(4*2) ; non, attendre passage effectif

90

Nous terminons ici le paramtrage du module Ecan en le plaant en mode 0 (Legacy) et en validant la mise en service du MCP2551. Comme dhabitude, nous devons attendre confirmation du changement de mode avant de poursuivre. Jaurais pu utiliser les macros de domodef.inc, ainsi que pour le passage en mode configuration, mais jai prfr bien montrer que la partie bootloader tait spare du reste du programme, afin dviter toute confusion dinteraction.
; envoyer la rvision ; ------------------rcall waitbuf0 ; pointer sur buffer 0 et attendre libration rcall sendcarteb ; envoyer les informations de carte

A ce stade, le logiciel PC sattend recevoir de la carte la confirmation quelle se trouve bien en mode bootloader. Ceci seffectue par lenvoi dune commande commune de type CC_CARTE, ltat bootloader sera indiqu dans loctet de data D4 Can, conformment au rle de cette commande. De par cette commande, le PC est galement renseign sur le type de pic prsent sur la carte, et sur le numro de version de programme actuellement dans le PIC. Ceci permet au logiciel PC daffiner ses vrifications et dinformer lutilisateur. Notez quil faut au moins 2 cartes Domocan pour pouvoir dialoguer. Lorsque vous programmerez votre premire carte, il faudra la relier au moins une autre carte (ou votre interface Can/PC connecte et en service) sous peine de non-fonctionnement, la carte sacharnant en vain envoyer ses trames Can sans recevoir daccus de rception Can automatique. Dans ce cas, un oscillo vous confirmera que la trame est rpte sans fin sur le bus, bien que nulle part dans le logiciel il ny ait une rptition prvue. Ceci pour vous prouver que la gestion des erreurs est automatique et hardware, ce qui est un grand confort et une grande scurit. Puis on envoie la commande CC_Carte sur le bus Can. Remarquez donc que cette information sur la carte est envoye automatiquement au reset de la carte si on se trouve en mode bootloader. Vous constaterez plus tard que cest galement le cas lorsquon est en mode de fonctionnement normal.

91

;***************************************************************************** ;***************************************************************************** ; RECEPTION DE TRAMES CAN * ;***************************************************************************** ;***************************************************************************** ;----------------------------------------------------------------------------; Les trames reues en mode bootloader sont dans le buffer 0 ; Les trames sont sous la forme : ; identificateur : destinataire CMD_COMM cible N commande CC ; SIDH SIDL EIDH EIDL ; ; avec destinataire = constante DESTI dpendant de la carte ; CMD_COMMUN = N de commande correspondant aux commandes communes ; (5 bits identificateur 0 et bit extended 1) ; cible = valeur place en eeprom ; N commande cc = 0x10 0x1F pour les commandes bootloader ;-----------------------------------------------------------------------------

Cet en-tte indique que nous entrons dans la rception des trames Can proprement dites. Souvenez-vous quen mode bootloader la rception des trames ne fait pas appel des routines dinterruption, contrairement ce qui sera le cas en mode de fonctionnement normal du pic. Len-tte rappelle le format des trames attendues, sachant quen mode bootloader on ne reoit que des trames de type commandes communes . Ceci est logique, le bootloader fonctionnant de faon identique quel que soit le type de carte. Bien videmment, en mode bootloader on naccepte que les commandes communes relatives ce mode particulier, mais a, cest vrifi par software.
; attendre une commande ; --------------------bootloadnew clrf CANCON bcf RXB0CON,RXFUL bootwaitcom clrwdt btfss RXB0CON,RXFUL bra bootwaitcom rcall boottrame bra bootloadnew ; pointer sur buffer rception 0 ; buffer trait et vide ; ; ; ; ; effacer watchdog tester si reu une trame CAN buffer 0 non, attendre commande oui, traiter la trame reue et attendre trame suivante

Cette partie de code attend la rception dune trame valide sur le buffer de rception 0, en excutant simplement une boucle sans fin. Le programme attend donc simplement larrive dune trame. Lorsquil en reoit une, il la traite, rpond, et revient attendre la suivante. La seule faon de sortir du mode bootloader est de recevoir une commande valide de sortie. Cest logique, il ny aucune raison davoir une sortie de scurit, car si on veut repasser en mode normal, cest bel et bien que le PIC fonctionne correctement.
;============================================================================= ; TRAITER LES TRAMES = ;============================================================================= boottrame movff RXB0EIDL,comcom ; sauver commande commune reue lfsr FSR1,RXB0DLC ; pointeur sur nombre data reue lfsr FSR0,0x100 ; zone de stockage movlw 0x09 ; pour 9 octets movwf bootloc01 ; dans compteur de boucles

92

boottrameloop movff POSTINC1,POSTINC0 decfsz bootloc01,f bra boottrameloop clrf FSR0L

; ; ; ;

transfrer un octet CAN dcrmenter compteur de boucles pas fini, suivant pointer sur RXB0DLC stock

Cette routine ne fait rien dautre que recopier la commande commune, le nombre doctets de data reus, ainsi que les 8 ventuels octets de data (utiliss ou non). Certains utilisateurs attentifs vont penser que copier les registres dans des variables RAM est parfaitement inutile, il suffit d'utiliser les registres eux-mmes. En fait, souvenez-vous que le buffer rel point par RXB0 dpend du contenu de CANCON (en mode 0). Or, pour prparer la rponse de la commande, nous allons pointer sur le buffer dmission 0 (TXB0), les registres prcdents ne seront donc plus accessibles.
rcall waitbuf0 ; attendre buffer 0 libre et pointer dessus

Nous appelons ici une sous-routine qui attend que le buffer dmission 0 soit libre. En sortie, RXB0 pointe ds lors sur ce buffer, ce qui justifie la remarque prcdente. En mode bootloader, o les trames sont reues squentiellement avec accus de rception, il est inutile dutiliser plusieurs buffers dmission et de rception. Pire, a pourrait tre dommageable en inversant lordre de certaines trames. Nous recevons donc nos ordres sur le buffer de rception 0 et nous y rpondons sur le buffer dmission 0. Voyons maintenant le traitement de deux de nos commandes, titre dexemple. Tout dabord, la plus spciale, la commande de demande de sortie du mode bootloader :
;============================================================================= ; COMMANDE CC_OUTBOOT = ;============================================================================= ;----------------------------------------------------------------------------; CC_OUTBOOT : sortir du mode bootloader ; octets de data : 2 ; D0 : 0x55 (confirmation) ; D1 : 0xA5 (confirmation) ; rponse : CC_CARTE ; code d'erreur : G1,G2,G3 pour cette routine, et G4 si appele dans mode ; principal ;-----------------------------------------------------------------------------

Remarquez chaque fois un en-tte rappelant la syntaxe de la commande concerne. Par exemple la commande CC_Outboot doit tre accompagne de 2 octets de data de confirmation. Les codes derreur sont numrs galement.
boottrame1 ; tester si commande concerne ; ---------------------------movlw CC_OUTBOOT ; charger numro de la commande commune cpfseq comcom ; comparer avec commande reue bra boottrame2 ; pas la bonne, suivant

La mthode de test est simple. On aurait pu optimiser les tests laide dun saut calcul, mais cela nuisait la facilit de maintenance et la souplesse dordre de traitement. Cest pourquoi jai opt pour la mthode suivante : 93

Tester si cest la bonne commande. Non, test de la commande suivante Oui, gestion de la commande

Ca nous fait perdre au pire 3 ou 4 s pour les dernires commandes testes, mais cest drisoire compar au temps minimum sparant 2 trames conscutives (2s par bit multipli par le nombre rel de bits). Souvenez-vous que la diffrentiation de 2 commandes communes ne se fait pas sur le n de commande, mais sur la valeur du paramtre.
; vrifier nombre de data ; ----------------------movlw 0x02 ; nombre de data cpfseq POSTINC0 ; comparer avec nombre reu bra senderrbG1 ; pas bon, erreur G1

Nous testons ensuite si le nombre doctets de data reu est bien conforme celui attendu, sinon nous envoyons une erreur Err_G1.
; vrifier data ; ------------movlw 0x55 ; premier octet de donne cpfseq POSTINC0 ; comparer avec octet reu bra senderrbG2 ; pas bon, erreur G2 movlw 0xA5 ; second octet de donne cpfseq POSTINC0 ; comparer avec octet reu bra senderrbG2 ; pas bon, erreur G2

Si on a bien reu 2 octets de data, encore faut-il vrifier que ce sont les bons. Ce test effectue la vrification. Si elle choue, une erreur Err_G2 est envoye sur le bus.
; crire identifieur en eeprom ; ----------------------------movlw BOOT_EEP ; adresse de l'identifieur eeprom movwf EEADR ; dans pointeur d'adresse movlw 'B' ; premire lettre rcall writeeepb ; crire dans eeprom tstfsz cderr ; tester si code d'erreur bra senderrbG3 ; oui, envoyer erreur eeprom movlw 'G' ; seconde lettre rcall writeeepb ; crire dans eeprom tstfsz cderr ; tester si code d'erreur bra senderrbG3 ; oui, envoyer erreur eeprom reset ; non, resetter la carte = envoi de CC_CARTE

Ici nous effectuons le traitement de la commande proprement dit. Notez que pour repasser en mode de fonctionnement normal, il suffit de rcrire len-tte valide BG dans notre eeprom, et deffectuer ensuite un reset du pic. Bien entendu, lcriture en eeprom est suivie dune vrification. Si la vrification a chou, alors on envoie le code derreur Err_G3 au lieu de reseter.

94

Certains vont dire (si si) : Oui, mais si on resette accidentellement le pic alors quil y a eu une erreur dcriture, on va repasser en mode normal alors que lcriture ntait pas correcte . En fait, non. Si lcriture nest pas correcte, alors cest que BG ne se trouve pas crit correctement en eeprom. Autrement dit, si on resette accidentellement le pic, il va repasser automatiquement en mode bootloader, car il ne trouvera pas lidentificateur correct en eeprom.
;============================================================================= ; COMMANDE CC_WPTRF = ;============================================================================= ;----------------------------------------------------------------------------; CC_WPTRF : positionner pointeur flash ; octets de data : 2 ; D0 : MSB adresse absolue ; D1 : LSB adresse absolue ; rponse CC_PTRF ; codes d'erreur : G1, G4, G6, G7, G8 ; Le pointeur est plac directement dans TBLPTRH/TBLPTRL ;-----------------------------------------------------------------------------

Nous trouvons ici la suite, savoir le test sur la commande suivante, en loccurrence CC_WPtrF.
boottrame2 ; tester si commande concerne ; ---------------------------movlw CC_WPTRF ; charger numro de la commande commune cpfseq comcom ; comparer avec commande reue bra boottrame3 ; pas la bonne, suivante ; vrifier nombre de data ; ----------------------movlw 0x02 ; nombre de data cpfseq POSTINC0 ; comparer avec nombre reu bra senderrbG1 ; pas bon, erreur G1

Notez que la vrification est similaire celle de la commande prcdente.

; enregistrer le pointeur ; ----------------------movff POSTINC0,TBLPTRH ; transfrer MSB pointeur movff POSTINC0,TBLPTRL ; transfrer LSB pointeur bcf PTRFOK ; par dfaut, pointeur incorrect ; vrifier validit du pointeur ; ----------------------------rcall verifpflash ; vrifier pointeur flash tstfsz cderr ; tester code d'erreur bra sendcodeerreurb ; erreur, envoyer trame d'erreur

Ici nous enregistrons le pointeur, et nous vrifions si la valeur de pointeur arrive par les octets de data D0/D1 est valide. Pour ce faire, nous appelons la sous-routine verifpflash . Cette routine retourne le code derreur ventuel dans codeerreur , ou 0 si tout est correct.

95

Si on a une erreur, on renvoie le code derreur correspondant sur le bus Can.

; valider et envoyer rponse ; -------------------------PTRFOK ; indiquer pointeur valide mmoire flash sendptrf ; envoyer rponse

bsf bra

On termine en signalant via un flag que le pointeur est maintenant correct, et on envoie une trame de rponse via sendptrf . Suivent les traitements pour toutes les autres commandes. Je ne les dtaille pas ici, vous pouvez les examiner en dtails dans le fichier domoboot.inc , et leur mode de fonctionnement est toujours identique. Si la commande commune reue ne correspond aucune des trames attendues, nous arrivons ici :
;============================================================================= ; COMMANDE INCORRECTE = ;============================================================================= ;----------------------------------------------------------------------------; La commande reue n'est pas accepte en mode bootloader ;----------------------------------------------------------------------------boottrame9 bra senderrbG14 ; commandes invalide en mode bootloader

On arrive ici si, tant en mode bootloader, on a reu une trame Can qui semble valide, savoir : Trame destine ce type de destinataire Trame destine cette carte-ci Trame de type commande commune

Mais que le n de commande ne concerne pas une des commandes prvues pour le mode bootloader. Dans ce cas, on envoie une erreur de type Err_G14. Nous en arrivons maintenant traiter nos sous-routines :
;============================================================================= ;============================================================================= ; SOUS-ROUTINES BOOTLOADER = ;============================================================================= ;=============================================================================

Notez que, contrairement aux versions antrieures 4.0, plus aucune sous-routine de cette partie nest utilise dans le programme principal. Pour le programme principal, les sousroutines sont places dans le fichier fonctions.inc , ce qui permet de limiter les interactions entre les diffrentes routines, le programme final en devient un rien plus long, mais plus simple maintenir. Or, avec les nouveaux PIC, nous ne risquons gure de manquer de mmoire programme :

96

;============================================================================= ; VERIFIER VALIDITE POINTEUR FLASH = ;============================================================================= ;----------------------------------------------------------------------------; Le pointeur est dj plac dans TBLPTRH/TBLPTRL ; TBLPTRU est 0 ; Le code d'erreur est retourn dans cderr ;-----------------------------------------------------------------------------

Nous allons commencer par la routine de vrification du pointeur flash. Notez le rappel concernant TBLPTRU. Souvenez-vous que la mmoire de 64Ko max. de la famille 18Fxx80 implique un adressage pour lequel les bits de poids upper restent 0. 16 bits dadresse suffisent en effet pour adresser jusque 65K de mmoire :
verifpflash clrf cderr ; par dfaut, pas d'erreur

; vrifier qu'on pointe sur un multiple de 8 ; -----------------------------------------movf TBLPTRL,w ; charger LSB adresse pointe andlw 0x07 ; garder 3 bits lsb bz verifpflash2 ; si 0, test suivant movlw ERR_G6 ; non, erreur ERR_G6 bra verifpflasherr ; et sortir en erreur ; vrifier si on pointe sur adresses 0/STARTP ; ------------------------------------------verifpflash2 movlw HIGH(STARTP) cpfslt TBLPTRH bra verifpflash3 movlw ERR_G7 bra verifpflasherr ; ; ; ; ; charger numro de la page dbut prog comparer si pointeur < STARTP non, test suivant oui, erreur ERR_G7 et sortir en erreur

Cette sous-routine vrifie si le pointeur en mmoire flash pointe bien sur une zone o lutilisateur peut crire. Dans le cas contraire on retourne le message derreur (erreur Err_G8) dans WREG (quivalant du registre W des PIC16F). Pour rappel, le pointeur doit tre multiple de 8 (impos par le PIC), et ne peut ni pointer dans le bootloader (pas dcrasement), ni sortir de la zone mmoire programme du PIC concern.
; vrifier si dans les limites PIC ; les sources sont prvus pour max 64K ; -----------------------------------verifpflash3 IF PROGMEMORY == 16 btfss TBLPTRH,6 return movlw ERR_G8 ENDIF IF PROGMEMORY == 32 btfss TBLPTRH,7 return movlw ERR_G8 ENDIF ; ; ; ; si mmoire programme = 16K tester si adresse >= 0x4000 non, retour sans erreur oui, erreur ERR_G8

; ; ; ;

si mmoire programme = 32K tester si adresse >= 0x8000 non, retour sans erreur oui, erreur ERR_G8

97

IF PROGMEMORY == 48 btfss TBLPTRH,7 return btfss TBLPTRH,6 return movlw ERR_G8 ENDIF IF PROGMEMORY == 64 return ENDIF

; ; ; ; ; ;

si mmoire programme = 48K tester si adresse >= 0x8000 non, retour sans erreur oui,tester si adresse >= 0xC000 non, retour sans erreur oui, erreur ERR_G8

; si mmoire programme = 64K ; pas d'erreur, toute la plage valide

IFNDEF PROGMEMORY ; si pas dfini ERROR "Taille ROM du pic non prcis" ENDIF IF (PROGMEMORY != 16) && (PROGMEMORY != 32) &&(PROGMEMORY !=48) && (PROGMEMORY !=64) ERROR "Taille du pic non prvue" MESSG "UTilisez une taille de 16, 32, 48, ou 64" MESSG "Les sources ne sont prvus que pour des tailles <= 64K" ENDIF ; sortir avec code d'erreur ; ------------------------verifpflasherr movwf cderr return ; placer code d'erreur ; et retour

Notez que la zone valide dpend du modle du PIC. Prenez garde que les nombreux tests effectus ici ne sont pas des tests faits par le pic au moment de lexcution du programme, mais sont simplement des directives destines MPASM, qui nassemblera en fait que les lignes de programme correspondant au modle de PIC dtect. Toute la partie contenant les tests sera en fait remplace par 3 ou 5 lignes de code rel. Une autre routine intressante tudier est celle-ci :
;============================================================================= ; ECRIRE 8 OCTETS EN FLASH = ;============================================================================= ;----------------------------------------------------------------------------; Ecrit 8 octets points par FSR0 en mmoire flash ; Le pointeur est dj dans TBLPTRH/TBLPTRL et sa validit est vrifie ; on procde ensuite une vrification de l'criture, et le code d'erreur ; ERR_G5 est renvoy dans codeerreur si erreur de vrification ; Si on pointe sur la premire adresse d'un bloc de 64, on commence par procder ; l'effacement du bloc. ; ATTENTION, modifie plusieurs registres, ne pas utiliser en dehors du code ; bootloader ;----------------------------------------------------------------------------writeflashboot clrf cderr ; effacer code d'erreur ; vrifier si dbut d'un bloc de 64 ; --------------------------------movf TBLPTRL,w ; charger poids faible pointeur andlw 0x3F ; garder 6 bits lsb bnz writeflashboot2 ; si adresse pas muliple de 64, ne pas effacer

98

bsf bcf bsf bsf movlw movwf movlw movwf bsf nop

; effacer le bloc de 64 octets ; ---------------------------EECON1,EEPGD ; pointer sur mmoire flash EECON1,CFGS ; pointer sur zone programme EECON1,WREN ; autoriser criture EECON1,FREE ; autoriser effacement bloc 0x55 ; squence impose EECON2 0xAA EECON2 EECON1,WR ; lancer l'effacement des 64 octets ; une instruction non excute

Conformment au fonctionnement de lcriture flash sur les 18F, on doit effacer la zone crire avant lcriture. Toujours conformment ce fonctionnement, leffacement seffectue par blocs de 64 octets, alors que lcriture seffectue par blocs de 8 octets. Cette routine commence par effacer le bloc de 64 octets si on dtecte que lcriture concerne une adresse multiple de 64 (dbut dun bloc). Ceci implique que : 1) Lcriture par bootloader doit ncessairement commencer une adresse multiple de 64 2) Lcriture des octets doit seffectuer par ordre croissant. 3) Toute criture une adresse multiple de 64 implique leffacement du bloc. Pour le programme de bootloader, qui commence lcriture partir de ladresse STARTP (multiple de 64), et qui envoie les octets dans lordre incrmental, cette gestion est automatique. Par contre, si vous envisagez dutiliser les fonctions Can pour modifier un ou plusieurs octets en mmoire flash, vous devrez procder aux manipulations suivantes : 1) 2) 3) 4) Initialiser le pointeur au dbut du bloc de 64 octets concern Lire les 64 octets du bloc et les sauver Modifier dans le programme PC les octets remplacer Envoyer les 8 trames de 8 octets contenant les 64 octets concerns, avec les octets ventuels modifis
; Ecrire les 8 data en flash ; -------------------------writeflashboot2 movff TBLPTRH,bootloc02 movff TBLPTRL,bootloc03 tblrd*; sauver pointeur MSB ; sauver pointeur LSB ; ncessaire, car on doit terminer ; les tblwt en restant dans la page de 8 ; octet dans laquelle on veut crire ; effacer watchdog ; 8 octets transfrer ; dans variable locale ; ; ; ; charger premier octet, pointer sur suivant placer dans buffer d'criture, princrment dcrmenter compteur pas dernier, suivant

clrwdt movlw 0x08 movwf bootloc04 writeflashboot3 movff POSTINC0,TABLAT tblwt+* decfsz bootloc04,f bra writeflashboot3

99

bsf bcf bsf movlw movwf movlw movwf bsf nop

EECON1,EEPGD EECON1,CFGS EECON1,WREN 0x55 EECON2 0xAA EECON2 EECON1,WR

; ; ; ;

pointer sur mmoire flash pointer sur zone programme autoriser criture squence impose

; lancer l'criture des 8 octets ; une instruction non excute

Ici, nous utilisons une mthode dcriture identique celle dcrite dans le cours-part5. On procde auparavant une sauvegarde des pointeurs, nous en aurons besoin pour la vrification que voici :
; restaurer les pointeurs ; ----------------------movff bootloc02,TBLPTRH ; restaurer pointeur MSB movff bootloc03,TBLPTRL ; restaurer pointeur LSB clrwdt ; effacer watchdog ; vrifier les 8 octets crits ; ---------------------------movlw 0x08 ; pour 8 octets movwf bootloc01 ; dans compteur de boucles subwf FSR0L,f ; repointer sur premier octet crire clrf cderr ; pas d'erreur lfsr FSR1,TXBxD0 ; pointer sur D0 trame envoyer writeflashboot4 tblrd*+ ; lire un octet en flash movf TABLAT,w ; charger octet lu movwf POSTINC1 ; le placer dans la trame cpfseq POSTINC0 ; comparer avec celui qu'on devait crire bsf cderr,0 ; pas identique, erreur decfsz bootloc01,f ; dcrmenter compteur d'octets bra writeflashboot4 ; pas dernier, suivant movlw ERR_G5 ; code d'erreur vrification flash btfsc cderr,0 ; tester s'il y a eu erreur movwf cderr ; oui, placer code d'erreur return ; fin

On relit les 8 octets crits, et on les renvoie si tout sest bien pass. Dans le cas contraire, on retourne un code derreur. En sortie de la routine, le pointeur pointe sur ladresse des 8 prochains octets crire. Je passe plusieurs autres routines, qui se passent de commentaires, vous pouvez si vous voulez examiner le fichier source pour plus dinformations. Vient ensuite la petite routine qui attend la libration du buffer dmission 0 :
;============================================================================= ; ATTENDRE QUE LE BUFFER 0 SOIT LIBRE = ;============================================================================= ;----------------------------------------------------------------------------; En bootloader on ne communique en rception que sur le buffer 0 et en ; mission sur le buffer 0 ;----------------------------------------------------------------------------waitbuf0 movlw B'00001000' ; pour pointer sur buffer mission 0

100

movwf CANCON clrwdt btfsc TXBxCON,TXREQ bra $-4 return

; ; ; ; ;

modifier WIN0/WIN2 reset watchdog tester si TXB0 est vide non, attendre oui, fin

Notez que cette routine trs simple a deux effets : 1) Elle attend que le buffer dmission 0 soit libre (vide) 2) Ds lors, en sortie, CANCON permet RXB0 de pointer en ralit sur le buffer dmission 0 Voyons ensuite une autre sous-routine spcifique, celle charge de lenvoi de nos trames Can :
;============================================================================= ; ENVOI DES TRAMES = ;============================================================================= ;----------------------------------------------------------------------------; envoi d'une commande commune ; Le n de la commande commune est dj dans TXBxEIDL ; Le nombre d'octets de data est dans TXBxDLC ; Les octets sont dj en place ; SIDH contiendra le type de cette carte ; EIDH contiendra le n de cette carte ; Le n de commande est dans cmdrec ; La commande reue est dans comcom ; Le nombre d'octets de data est dans TXBxDLC ; Les octets sont dj en place ;---------------------------------------------------------------------------; envoi d'une commande commune ; ---------------------------sendtramecomb movlw CMD_COMM ; commande commune movwf TXBxSIDL ; dans SIDL movlw DESTI ; charger type de destinataire movwf TXBxSIDH ; dans SIDH movff cibleb, TXBxEIDH ; n de la carte dans EIDH bsf TXBxCON,TXREQ ; lancer la trame de rponse return ; et retour

Cette routine se charge denvoyer notre commande commune, en compltant les informations non places par la routine appelante, comme : La commande (CMD_COMM) dans le registre SIDL Le type de destinataire dans SIDH Le numro de cible dans EIDH

Toutes ces informations tant communes toutes les commandes renvoyes. Cette routine se termine en forant lmission via le bit TXREQ du registre de contrle du buffer dmission 0. Je termine avec la routine charge denvoyer les trames derreur :

101

;============================================================================= ; ENVOI DES TRAMES D'ERREUR = ;============================================================================= ;----------------------------------------------------------------------------; Envoie les diffrentes trames d'erreur ; ; identificateur : DEST_ADMIN CMD_ERR 00000000 eeeeeeee ; SIDH SIDL EIDH EIDL ; ; avec eeeeeeee : numro de l'erreur envoye ; 4 octets de data : ; D0 : SIDH qui a provoqu l'erreur (toujours DESTI) ; D1 : commande qui a provoqu l'erreur (cmdrec converti) ; D2 : EIDH qui a provoqu l'erreur (toujours cible) ; D3 : EIDL qui a provoqu l'erreur (contenu dans comcom) ; ; plusieurs points d'entre : ; senderrbGxx : envoi d'un code d'erreur spcifique ; senderrwb : envoi trame d'erreur avec code d'erreur dans W ; sendcodeerreurb : envoi d'une trame d'erreur avec code d'erreur dans cderr ; On pointe dj sur le bon buffer d'mission ;----------------------------------------------------------------------------; traiter erreurs spcifiques ; --------------------------senderrbG1 movlw ERR_G1 bra senderrwb senderrbG2 movlw ERR_G2 bra senderrwb senderrbG3 movlw ERR_G3 bra senderrwb senderrbG9 movlw ERR_G9 bra senderrwb senderrbG10 movlw ERR_G10 ; prparer erreur nombre de data incorrect ; et traiter ; prparer erreur data incorrecte ; et traiter ; erreur de vrification eeprom interne ; et traiter ; pointeur flash pas initialis ; et traiter ; pointeur eeprom dans zone protge

bra

senderrwb

; et traiter
; commande commune invalide en mode bootloader ; et traiter

senderrbG14 movlw ERR_G14 bra senderrwb

; traiter erreurs dans cderr ; -------------------------sendcodeerreurb movf cderr,w ; charger code d'erreur ; traiter erreurs avec code dans w ; -------------------------------senderrwb movwf TXBxEIDL movlw DEST_ADMIN movwf TXBxSIDH movlw CMD_ERR movwf TXBxSIDL clrf TXBxEIDH movlw 0x04 movwf TXBxDLC movlw DESTI ; ; ; ; ; ; ; ; ; placer code d'erreur dans EIDL trame destine l'administration dans SIDH commande = erreur dans SIDL EIDH = 0 4 octets de data dans DLC erreur provient de ce type de carte

102

movwf TXBxD0 movf andlw movwf movf andlw rrncf rrncf rrncf iorwf cmdrec,w 0x03 TXBxD1 cmdrec,w 0xE0 WREG,w WREG,w WREG,w TXBxD1,f

; dans D0 ; ; ; ; ; ; ; ; ; ; ; ; ; commande reue au format SIDL garder b17 et b16 sauver 2 derniers bits charger commande au format SIDL b20,b19,b18,0,0,0,0,0 0,b20,b19,b18,0,0,0,0 0,0,b20,b19,b18,0,0,0 0,0,0,b20,b19,b18,0,0 0,0,0,b20,b19,b18,b17,b16 : au format commande PC cible dans D2 commande commune reue dans D3 lancer la trame de rponse et fin

movff cibleb,TXBxD2 movff comcom,TXBxD3 bsf TXBxCON,TXREQ return

Cette commande renvoie lerreur en fonction du type derreur rencontre. Notez la partie de conversion, qui transforme le registre SIDL ayant provoqu lerreur en un numro de commande renvoy dans loctet de data D1 de la trame derreur. Ceci termine ltude de notre fichier Domoboot.inc.

8.4 Le fichier CCommunes.inc Ce fichier contient tout le traitement relatif aux commandes communes reues en mode normal (non bootloader). Les commandes communes sont donc dclares dans domodef.inc , mais traites dans CCommunes.inc . Ce fichier sera inclus lendroit appropri de base.asm (ou de votre fichier dapplication)
;***************************************************************************** ; Commandes communes toutes les cartes pour systme Domocan * ;***************************************************************************** ; * ; NOM : CCommune.inc * ; Date cration : 03/03/2005 * ; Date modification : 17/12/2007 * ; Version : 1.1 * ; Circuit : * ; Auteur : Bigonoff * ; * ;***************************************************************************** ; * ; Historique * ; ---------* ; * ; V1.00 : 03/03/2005 : premire mise en ligne, pour simplification des * ; fichiers sources. * ; * ; V1.10 : 03/03/06 : Ajout d'une temporisation sur le n de cible * ; pour permettre aux commandes CC_Carte d'arriver * ; dans l'ordre sur une requte broadcast * ; * ; V1.11 : 17/12/07 : Modification mineure suite la refonte des sources* ; lis l'utilisation des nouveaux modules ECAN * ; en mode 2 * ;*****************************************************************************

103

Comme dhabitude, un petit en-tte facilite la maintenance et la comprhension.

;***************************************************************************** ;***************************************************************************** ; GESTION DES COMMANDES COMMUNES * ;***************************************************************************** ;***************************************************************************** ;============================================================================= ;============================================================================= ; GESTION DES COMMANDES COMMUNES AVEC BROADCAST = ;============================================================================= ;============================================================================= ;----------------------------------------------------------------------------; Les commandes sont de la forme : DESTI CMD_COMM nnnnnnnn pppppppp ; destrec cmdrec ciblerec parrec ; avec : parrec = n de la commande commune ; ciblerec = n de la carte OU CIB_BROAD (0xFF) ; ; Les dfinitions des commandes sont dans Domodef.inc ;----------------------------------------------------------------------------commcb

De nouveau, du commentaire bien utile. La structure des commandes communes est ici rappele. Nous traitons ainsi les commandes communes arrivant soit avec le n de la carte comme cible, soit la valeur 0xFF (CIB_BROAD) indiquant une commande destine toutes les cartes prsentes du mme type.
; tester destinataire ; ------------------; charger identit de la carte ; comparer avec type de destinataire ; pas identique, refuser

movlw DESTI cpfseq destrec return

On commence par vrifier si la commande est bien destine la carte en question. Certaines cartes peuvent accepter des trames qui ne leur sont pas destines. Cest pourquoi cette vrification est obligatoire, mme si elle est inutile la plupart du temps.
;============================================================================= ; TRAITER COMMANDE COMMUNE CC_RCARTE = ;============================================================================= ;----------------------------------------------------------------------------; CC_RCARTE : demande des informations de la carte ; broadcast accept ; octet de data : aucun ; rponse : CC_CARTE ; code d'erreur : G1 ;----------------------------------------------------------------------------commcb0 ; tester commande commune ; ----------------------TESTCC CC_RCARTE ; tester si commande request carte bra commcb1 ; non, tester trame commune suivante TESTDAT 0 ; tester si 0 octet de data infsnz ciblerec,w rcall waitcible goto sendcarte ; tester si reu en mode broadcast ; oui, diffrer la rponse ; ok, envoyer informations de la carte

104

Lutilisation de macros raccourcit la longueur du source et augmente la clart. les macros TESTCC et TESTDAT ont t expliques au niveau de ltude de domodef.inc . Cette commande se contente de renvoyer la commande CC_Carte comme rponse. Notez que si la commande est reue en mode broadcast, la rponse est reporte dans le temps. Ceci permet dobtenir les rponses des cartes dans lordre de leur n de cible, ce qui permet Domogest de les trier efficacement lors de ltablissement automatique de la cartographie. Cest un luxe , car en ralit le systme fonctionne parfaitement sans ce dlai. Nous allons trouver de faon identique les commandes acceptes en mode broadcast. Je ne dtaille pas tout, je vous renvoie aux sources comments. Suivent les commandes communes qui refusent ce mode :
;============================================================================= ;============================================================================= ; GESTION DES COMMANDES COMMUNES SANS BROADCAST = ;============================================================================= ;============================================================================= infsnz ciblerec,w ; tester si cible reue = 255 (broadcast) goto senderrG13 ; oui, commande illgale en mode broadcast

On teste si le n de cible reu vaut 0xFF. Dans ce cas, cest que la commande a t reue en mode broadcast, ce qui nest pas permis pour toutes les commandes suivantes. On envoie dans ce cas une erreur Err_G13. Notez lastuce pour tester si la variable ciblerec contient 0xFF en une seule ligne. Comme quoi, vous avez bel et bien des commandes permettant de tester si une variable vaut 0xFF sans quelles ne soient explicitement cites. Idem pour tester si une variable vaut 0x01 (je vous laisse rflchir). Suivent ensuite les autres commandes communes, ce qui ne devrait poser aucun problme de comprhension, aprs ce que nous avons vu. La dernire ligne :
goto senderrG15 ; commande commune invalide

est excute si la commande commune reue et accepte ne correspond aucune des commandes prvues. Dans ce cas, une erreur Err_G15 est gnre. Notez que si vous envoyez une commande commune errone en mode normal, vous avez plusieurs ractions possibles du pic : Si la combinaison filtres/masques bloque la commande, vous naurez aucune rponse Si la commande est accepte et reue en mode broadcast, vous aurez une erreur Err_G13 Sinon, vous aurez une erreur Err_G15 Nous terminons par une petite sous-routine :

105

;============================================================================= ; ATTENTE EN FONCTION DU N DE CIBLE = ;============================================================================= ;----------------------------------------------------------------------------; Permet certaines trames d'arriver dans l'ordre des n de cible, afin ; d'avoir notamment les cartes dans l'ordre au niveau de Domogest ; une trame CC_Carte fait moins de 100 bits. Chaque bit dure entre ; 2 et 10s selon la vitesse du bus Domocan. ; La trame dure donc au maximum 1ms, soit 10.000 Tcy 40Mhz ; on attendra donc un peu plus de 10.000Tcy par numro de cible ; modifie local01 ;----------------------------------------------------------------------------waitcible incf cible,w ; charger n de cible + 1 waitcible1 clrwdt ; reset watchdog clrf local01 ; pour 256 boucles waitcible2 bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy bra $+2 ; 2 Tcy decfsz local01,f ; dcrmenter compteur de boucles bra waitcible2 ; (256 * (38+1+2))-1 = 10495 Tcy decfsz WREG,w ; dcrmenter n cible bra waitcible1 ; pas fini, on recommence 256 boucles return ; fini, fin

Cette routine permet dtablir un dlai dont la dure dpend du n de cible de la carte. Le dlai est calcul de faon tre suprieur au temps denvoi dune trame CC_Carte. Ds lors, lorsque les cartes sont interroges en mode broadcast, ou mises simultanment sous tension, les trames CC_Carte seront envoyes une par une, et dans lordre de leur n de cible. Ceci facilite la gestion par Domogest, pour qui les cartes sont ajouts la collection des cartes dans lordre de leur apparition sur le bus. Si vous supprimez cette routine, le systme fonctionne parfaitement, la seule diffrence est que les cartes ne seront pas tries dans lordre des n de cible au niveau des menus droulants de Domogest. Il ny a rien dautres dans ce fichier que ltude des commandes communes. Rfrez-vous aux commentaires de CCommunes.inc si vous voulez plus dinformations. Je nai pas

106

dtaill ici tout le traitement des commandes, cest suffisamment simple pour vous contenter du fichier source.

8.5 Le fichier ParCan.inc Dans ce fichier sont indiqus vos propres paramtres Can. Vous pouvez les modifier ou conserver les valeurs par dfaut, qui dterminent une vitesse de 500Kbits/s pour une longueur maximale du bus de 100m. Mon propre bus fonctionne un dbit de 333Kbits/s sur un bus de 120m. Je vous joins mon propre fichier ParCan.inc sous le nom de ParCan de Bigonoff.inc En gnral, vous ne modifierez que si votre bus est trop long ou de mauvaise qualit, afin de diminuer le dbit. Suivez dans ce cas les exemples indiqus dans le fichier, sauf si vos connaissances sur le Can vous permettent daffiner les paramtres.
;******************************************************************************* ; FICHIER INCLUDE QUI DETERMINE LA VITESSE UTILISEE PAR VOTRE RESEAU DOMOCAN * ; * ; Protgez ce fichier en criture pour viter de le remplacer par le fichier * ; par dfaut lors d'une mise jour par tlchargement * ; * ; Ce fichier contient les paramtres Can utiliss par votre rseau * ; Choisissez les valeurs utilise par votre systme en plaant les valeurs * ; adquates dans ce fichier * ; * ; La vitesse maximale permise dpend principalement de la longueur totale de * ; votre bus Can * ;******************************************************************************* ; * ; TQ : Temps lmentaire Can. Peut tre librement fix de 0.05s 3.2s * ; Synch : Dure de synchro en nbre de TQ. Toujours 1 pour les 18Fxx8 * ; Prop : Temps de propagation sur la ligne en nbre de TQ. Plus la ligne * ; est longue vitesse dfinie, plus Prop doit tre grand. * ; Peut varier de 1 8 TQ * ; Seg1 : Phase segment 1. L'chantillonnage du bit s'effectue entre la fin * ; du PS1 et le dbut du PS2. Peut varier de 1 8 TQ * ; Seg2 : Phase segment 2. Peut varier de 2 8 TQ et ne peut pas tre * ; infrieur PS1 * ; (Synch + Prop + Seg1 + Seg2) ne peut pas tre infrieur 8 * ; La dure totale d'un bit vaut (Synch + Prop + Seg1 + Seg2)*TQ * ; SJW : Synchronisation jump with time : Permet de rectifier les drives. * ; Peut varier de 1 4. Laisser 1 pour les composants pilots par * ; quartz. * ; SAMPL : Sample : indique si on mesure une seule fois le bit (0) ou 3 fois * ; avec dtection par porte majoritaire (1). * ; Peut tre librement choisi sans tenir compte des autres composants * ; du bus. "1" augmente la fiabilit au dtriment d'une lgre perte * ; de longueur admissible (avance du dbut de la lecture). * ; Dure d'un bit = Nominal Bit Time * ; Dbit = 1 / NBT * ;*******************************************************************************

Cet en-tte vous donne dj quelques indications sur les paramtres modifiables de votre rseau. Je vous donne quelques informations supplmentaires :

107

TQ est appel en Can le Time Quanta . Vous devez imaginer que chaque bit Can est scind en units lmentaires, quon pourrait comparer des sous-bits . Chaque unit lmentaire est appele Time Quanta . Tous les paramtres Can sont exprims en nombre de TQ. Le Temps TQ dfini dans ce fichier indique la dure de ce time quanta en multiples de 1 64 temps de 0.05s pour un 18Fxx8 cadenc 40Mhz. Synch est en ralit la synchronisation. Tout comme un octet en RS232 a besoin dau moins un start-bit, un bit Can a besoin dau moins un start-TQ . On retrouve donc au niveau du bit, en Can, ce quon trouve au niveau de loctet en RS232. Les 18Fxx80 ne travaillent quavec des synchronisations de 1TQ. Ce paramtre nest donc pas mofiable, il est donn titre indicatif. Prop est le temps de propagation de la ligne. Souvenez-vous que le Can procde des contrles automatiques de bits et rpond en cas de problme. Il doit donc connatre le temps maximal que met linformation parcourir la distance le sparant de toutes les cartes sur le bus. A 500Kbits/s sur des lignes de 100m, ce temps nest plus du tout ngligeable par rapport au TQ. Le temps de propagation est peut varier de 1 8 TQ. En gnral, TQ constant, plus la ligne est longue, plus le temps de propagation doit tre grand. Mieux vaut indiquer une valeur trop grande que trop petite, cette dernire risquant de conduire des erreurs de communication. Seg1 reprsente le phase segment 1 de 1 8 TQ. La lecture proprement dite dun bit Can intervient entre la fin du phase segment 1 et le dbut du phase segment 2. Seg2 reprsente le phase segment 2 de 1 8 TQ. Il correspond un peu au niveau du bit ce que reprsente le stop-bit au niveau de loctet en RS232. Bref, ce temps est le temps minimal durant lequel doit tre maintenu le bit avant de passer au bit suivant. Un bit est donc constitu de la sorte : Synchro 1 TQ Propagation 1 8 TQ Phase segment 1 | Phase segment 2 1 8TQ | 1 8 TQ Lecture du bit

La limite Phase segment 1 / phase segment 2 dtermine donc lendroit o le bit est lu. Par analogie, en RS232 le bit est lu la moiti de sa dure, pour le Can cest plus complexe et paramtrable, comme vous le voyez. Vous avez de plus 2 autres contraintes au niveau du phase segment 2 : Sa dure ne peut pas tre infrieure au temps de traitement interne du PIC. Pour un 18Fxx80, ce temps, dnomm IPT (Information Processing Time) est de 2 TQ. Vous ne pouvez donc pas utiliser un temps de phase segment 2 infrieur 2 TQ.

108

Sa dure doit tre suprieure ou gale la dure du phase segment 1, bien que jai fait des essais concluants sans respecter cette seconde contrainte (cest cependant vos risques et prils si vous passez outre de cette contraire).

La dure totale dun bit se nomme Nominal Bit Time . Fort logiquement, cette dure est la somme de toutes les dures dont nous avons parl multiplie par la dure effective du Time Quanta. Les valeurs par dfaut de Domocan sont : TQ = 2 Prop = 8 Seg1 = 5 Seg2 = 6 Le temps TQ vaut donc en ralit : 2 * 0.05s = 0.1s Le nombre de TQ dans le bit vaut : Synchro + Prop + Seg1 + Seg2 = 1+8+5+6 = 20 Le nominal bit time vaut donc : 20 * 0.1s = 2s. Le dbit thorique est naturellement linverse de la dure du bit, soit 1 / 2s = 500Kbits/s. Il nous reste deux concepts aborder. Tout dabord, SAMPL, pour Sample . Il sagit dun flag positionn 0 ou 1. Si vous le positionnez 0, la lecture du bit est faite comme expliqu prcdemment, entre le phase segment 1 et le phase segment 2. Par contre, si vous indiquez 1 , il sera effectu une triple lecture. Le rsultat de cette triple lecture sera pass par une porte majoritaire pour savoir si on considre le bit comme valant 1 (2 lectures au moins 1) ou 0 (2 lectures au moins 0). Ce paramtre ninfluence pas le nominal bit time, il sagit dune scurit que vous pouvez mettre ou non en service. La dernire valeur que vous pouvez (en principe) paramtrer est le SJW, pour Synchronisation Jump Width. Il vous faut pour a savoir que le Can est capable, en cas de drive des horloges des modules Can du bus, dappliquer un mcanisme de resynchronisation automatique. Pour ce faire, en schmatisant, il insre le SJW avant ou aprs le point de lecture du bit, afin dallonger ou de raccourcir sa dure effective. Il faut que ce SJW, pour tre efficace, soit dune dure (paramtrable de 1 4 TQ) qui soit quivalente lerreur de temps possible prsume. Or, toutes nos cartes travaillent avec des horloges quartz, et il faut, dans ce cas, paramtrer SJW pour une valeur de correction minimale, soit 1TQ. Vous navez donc en fait, dans la pratique, pas vraiment le choix au niveau de ce paramtre. Ce paramtre influence le dbit, dans le cas o des correctifs de synchronisation sont ncessaires. Il vous est extrmement difficile de le voir et de le prvoir, cest pourquoi, entre autres (collisions, bit-stuffing), on parle en Can de dbit thorique.

109

;******************************************************************************* ; QUELQUES EXEMPLES DE CONFIGURATION POUR Domocan : * ; * ; TQ Synch Prop Seg1 Seg2 SJW NBT Dbit Longueur max * ; ------ ---- ---- ---- --- -----------------* ; 0.1s 1TQ 8TQ 5TQ 6TQ 1TQ 2s 500Kbits/s 100m * ; 0.1s 1TQ 8TQ 8TQ 8TQ 1TQ 2.5s 400Kbits/s 125m * ; 0.2s 1TQ 8TQ 3TQ 3TQ 1TQ 3s 333Kbits/s 150m * ; 0.2s 1TQ 8TQ 8TQ 8TQ 1TQ 5s 200Kbits/s 250m * ; 0.5s 1TQ 8TQ 5TQ 6TQ 1TQ 10s 100Kbits/s 500m * ; * ; Valeurs donnes titre d'exemple, Domocan accepte toute configuration * ; valide entre 100 et 500Kbits/s * ; Valeurs par dfaut pour Domocan : 0.1s/1/8/5/6 -> 500Kbits/s * ;*******************************************************************************

Je vous donne ici, purement titre dexemple, quelques paramtres correspondant plusieurs vitesses utiles, ainsi que les longueurs maximales thoriques du bus correspondantes. Par dfaut, les paramtres sont fixs comme indiqus sur la premire ligne, mais si votre bus est long ou si vous rencontrez des erreurs de transmission (visibles lors de lanalyse de cartographie via Domogest), vous pouvez diter les paramtres votre convenance. Mais souvenez-vous : 1) Jamais deux cartes avec des paramtres diffrents sur le mme bus 2) La modification des paramtres impose la reprogrammation des PIC par voie classique (pas par bootloader)
TQ EQU 2 ; Temps lmentaire Can en multiples de 0.05s ; de 1 64 ; Temps de propagation de 1 8 ; Phase segment 1 de 1 8 ; Phase segment 2 de 2 8 (>= SEG1) ; Synchro jump width de 1 4 ; laisser 1 pour Domocan ; 3 lectures(1) ou lecture unique (0)

PROP EQU 8 SEG1 EQU 5 SEG2 EQU 6 SJW EQU 1

SAMPL EQU 1

Vous avez ici les valeurs utilises et modifiables. Modifiez ces valeurs ventuellement AVANT assemblage de vos fichiers .hex car les valeurs ne sont lues qu ce moment. Protgez ensuite votre fichier ParCan.inc en criture, ainsi il ne sera pas cras par le fichier par dfaut si vous rechargez une nouvelle rvision des fichiers de base sur mon site.

8.6 Le fichier Configurations.inc MPLAB 7 et suivants grent prsent les directives de configuration avec une nouvelle syntaxe, via la directive CONFIG en remplacement de lancienne __CONFIG . Voyez le cours-part5 pour plus dinformations. Sur la suggestion de Laurent, que je remercie au passage, jai profit de la rcriture de toutes les directives de configuration pour les placer dans un fichier spar, ce qui facilite la

110

lisibilit du fichier de programme principal. Ainsi, en indiquant simplement le type de pic dans votre fichier source, la configuration de votre carte Domocan sera faite automatiquement. Le fichier de dclaration Microchip P18Fxxx .inc sera galement slectionn de faon automatique par des directives incluses. Il vous restera uniquement qu prciser la dure du watchdog dans votre programme principal, vu que cette dure peut varier en fonction de lapplication. Notez que Configurations.inc gre galement les modifications lorsque vous travaillez avec votre debugger IC2, ainsi que les diffrentes tailles de mmoire acceptes.
;***************************************************************************** ; Fichier de configuration des pic pour DOMOCAN * ; * ; Merci Laurent pour sa participation active la migration vers les xx80 * ; * ;***************************************************************************** ; * ; NOM : configuration.inc * ; Date cration : 06/12/2007 * ; Date modification : 09/03/2008 * ; Version : 1.1 * ; Circuit : * ; Auteur : Bigonoff avec la participation de Laurent * ; Contacts : Bigonoff (bigocours@hotmail.com) * ; www.abcelectronique.com/bigonoff * ; www.bigonoff.org * ; * ;***************************************************************************** ; Historique * ; ---------* ; V1.00 : Le 14/02/08 : Premire version compltement termine en ligne * ; Permet la prise en compte des xx80 et * ; l'utilisation de la nouvelle directive config * ; * ; V1.10 : Le 09/03/08 : Ajout de la directive LIST dans le fichier * ;***************************************************************************** ; Types de pic reconnus par Domocan * ; --------------------------------* ; * ; 0x01 : 18F248 : Plus support * ; 0x02 : 18F258 : Plus support * ; 0x03 : 18F448 : Plus support * ; 0x04 : 18F458 : Plus support * ; 0x05 : 18F2580 : Support * ; 0x06 : 18F4580 : Support * ; 0x07 : 18F2680 : support * ; 0x08 : 18F4680 : support * ; * ;*****************************************************************************

Notre en-tte habituel prcise principalement les types de PIC supports par cette application. Notez la disparition des anciens 18Fxx8, devenus obsoltes car ces premires versions de 18F module Can contenaient de toute vidence trop de bugs. Vos cartes actuelles continuent cependant de fonctionner, le rpertoire archives vous permet de toujours pouvoir assembler vos anciens fichiers sources. Attention cependant, toute

111

volution ou toute modification future ne sera gre que pour les nouveaux PIC. Si vous voulez mettre vos sources jour partir de maintenant, il vous faudra remplacer les PIC des cartes concernes. Vous pouvez vous procurer pour ce faire des chantillons gratuits sur le site de Microchip, dautant plus que vous ntes pour rien dans ces bugs.
;============================================================================= ; TEST DE VALIDITE DES PIC = ;============================================================================= ;----------------------------------------------------------------------------; Teste la validit du pic ;----------------------------------------------------------------------------errorlevel -207 ; vite warnings (LASTRAM pas en colonne 0) ; tout en gardant le source align

IF (TYPEPIC < 5) ; pour les anciens pic ERROR "TYPE DE PIC PLUS SUPPORTE" MESSG "Lisez le fichier configurations.inc pour plus de dtails" ENDIF

La premire ligne coupe les warnings de position de ligne. Ca me permet dindenter les IF sans recevoir des warnings sur les dclarations non situes en colonne 0. Cest plus lisible de la sorte, et ne pose aucun problme particulier. Le type de pic est ensuite test. Si un ancien pic est dtect, une erreur est renvoye, avec un message explicatif, et le programme nest pas assembl.
;============================================================================= ; INCLUSION DU FICHIER DE DEFINITION = ;============================================================================= IF TYPEPIC == 5 #include <P18F2580.inc> #DEFINE PROGMEMORY 32 ; taille mmoire programme en Koctets ENDIF IF TYPEPIC == 6 #DEFINE PROGMEMORY 32 #include <P18F4580.inc> ENDIF IF TYPEPIC == 7 #DEFINE PROGMEMORY 64 #include <P18F2680.inc> ENDIF IF TYPEPIC == 8 #DEFINE PROGMEMORY 64 #include <P18F4680.inc> ENDIF

; taille mmoire programme

; taille mmoire programme

; taille mmoire programme

On procde ici simplement linclusion du fichier de dclaration correspondant au type de PIC choisi via lassignation TYPEPIC du fichier base.asm

112

;============================================================================= ; CONFIGURATIONS PIC18F2580/4580 = ;============================================================================= ;----------------------------------------------------------------------------; LASTRAM indique la dernire adresse valide pour le pic ; suivent les configurations pour ce type de pic ; Ensuite, les configurations spcifiques la mise en service ou non du ; debugger sur circuit ;----------------------------------------------------------------------------IF (TYPEPIC == 5)|| (TYPEPIC == 6) IF (TYPEPIC == 5) LIST p=18F2580 ELSE LIST p=18F4580 ENDIF CONFIG OSC = HSPLL CONFIG FCMEN = OFF pas) CONFIG IESO = OFF CONFIG PWRT = ON CONFIG BOREN = BOHW CONFIG BORV = 2 CONFIG MCLRE = ON CONFIG LPT1OSC = OFF consommation) CONFIG PBADEN = OFF numrique CONFIG XINST = OFF CONFIG BBSIZ = 1024 protection en service) CONFIG STVREN = ON CONFIG LVP = OFF CONFIG CP0 = OFF CONFIG CP1 = OFF CONFIG CP2 = OFF CONFIG CP3 = OFF CONFIG CPB = OFF CONFIG CPD = OFF CONFIG WRT0 = OFF CONFIG WRT1 = OFF CONFIG WRT2 = OFF CONFIG WRT3 = OFF CONFIG WRTB = OFF CONFIG WRTD = OFF CONFIG EBTR0 = OFF CONFIG EBTR1 = OFF CONFIG EBTR2 = OFF CONFIG EBTR3 = OFF CONFIG EBTRB = OFF IFDEF DEBUG LASTRAM = 0x5F3 CONFIG DEBUG = ON CONFIG WDT = OFF CONFIG WRTC = OFF ELSE LASTRAM = 0x5FF ; en fonction du type exact ; dfinir processeur

; Oscillateur PLL en service ; pas d'oscillateur de secours (le CAN ne permet ; ; ; ; ; ; pas de dmarrage avant HPLL prt Retard du dmarrage du pic la mise sous tension Reset harware si chute de Vdd reset si Vdd < 4.3V PIn MCLR en service, pas de RE3 Timer1 en fonctionnement normal (haute

; la mise sous tension, PORTB.4, .1, et .0 en mode ; jeu d'instruction standard ; taille du bootblock (non important, aucune ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Reset sur dbordement de pile pas de programmation basse tension block 0 non protg en lecture idem block 1 idem block 2 idem block 3 boot-block non protg en lecture EEprom non protge en lecture block 0 non protg en criture idem block 1 idem block 2 idem block 3 idem boot block Eeprom non protge en criture pas de protection lecture de table block 0 idem block 1 idem block 2 idem block 3 idem boot block configs particulires uniquement en mode debug dernire adresse RAM valide mode debugger en service couper watchdog en phase de debuggage pas de protection en criture des configurations

; configs particulires uniquement en mode non debug ; dernire adresse RAM valide

113

CONFIG DEBUG = OFF CONFIG WDT = ON CONFIG WRTC = ON ENDIF ENDIF

; mode debug hors-service ; valider watchdog en phase de fonctionnement rel ; registres de configurations protgs en criture

Cette partie contient les configurations pour un PIC18Fx580. Ils sont identiques except le nombre de pins. La dernire partie partie slectionne des configurationss diffrentes selon que lon soit en mode debugger (ICD2) ou en phase dapplication finale. Le choix seffectue partir du fichier base.asm, , nous en reparlerons. En mode debugger, on coupe le watchdog (impos par lICD2) et on valide le mode DEBUG, alors que cest le contraire pour lapplication finalise. En mode de fonctionnement normal, on protge les registres de configuration dune action bootloader, alors que tout type de protection semble perturber le fonctionnement de lICD2. Enfin, la dernire position RAM accessible par lutilisateur est calcule en fonction du type de PIC, et en fonction de la prsence ou non de lICD2, qui a besoin de quelques emplacements RAM en fin de mmoire pour son fonctionnement personnel (voir cours-part4 pour plus dexplications sur les debuggers sur circuit). La suite effectue les mmes oprations pour les autres types de PIC, savoir les 18F2680 et 18F4680, je ne recopie pas toute cette partie. Ce fichier se termine par :
errorlevel +207 ; remet les warnings en service

Cette directive remet les warnings sur les colonnes en service pour votre programme principal.

114

8.7 Le fichier Fonctions.inc Ce fichier contient tous les sous-programmes utiliss par la plupart des cartes Domocan. Ca vite dencombrer les fichiers dapplication, et a facilite la maintenance en vitant les redondances, souvent nfastes.
;***************************************************************************** ; Fonctions gnrales inclure pour cartes DOMOCAN * ;***************************************************************************** ; * ; NOM : fonctions.inc * ; Date cration : 07/12/2007 * ; Date modification : 15/03/2008 * ; Version : 1.00 * ; Auteur : Bigonoff * ; * ;***************************************************************************** ; * ; Historique * ; ---------* ; V1.00 : Le 15/03/08 : Premire version compltement termine en ligne * ; Extraction des fonctions non utilises par * ; le bootloader du module domoboot.inc * ; Rsulte du passage du CAN en mode 2 dans le * ; programme principal et maintien du mode 0 dans * ; le bootloader * ; * ;*****************************************************************************

Notre en-tte prcise galement que les routines qui servaient auparavant de faon partage entre la partie bootloader et le programme principal, sont maintenant compltement disjointes. Nous disposons en effet dassez despace de mmoire programme, mieux vaut privilgier la facilit de maintenance.
;============================================================================= ; INITIALISATIONS = ;============================================================================= ;----------------------------------------------------------------------------; Contient les initialisations communes toutes les cartes ;----------------------------------------------------------------------------initialise ; effacer la RAM banque 0 ; ----------------------lfsr FSR0,0x00 ; pointer sur la premire adresse qu'on peut effacer initl clrf POSTINC0 ; efface emplacement point, et incrmente pointeur btfss FSR0H,0 ; banque 0 termine? bra initl ; non, emplacement suivant

Cette sous-routine va excuter les initialisations qui sont communes toutes les cartes. On commence par effacer toute la RAM de la banque 0, pour partir sur de bonnes bases. Ainsi, toute variable non initialise par la suite aura doffice la valeur 0.
; copier valeurs eeprom en RAM ; ---------------------------movlw CIBLE_EEP ; offset du n de la carte en EEP rcall readeepw ; lire cible movwf cible ; sauver en RAM

115

movlw rcall movwf movlw rcall movwf

MODEC_EEP readeepw modefonct NBGERE_EEP readeepw cartenbr

; ; ; ; ; ;

offset du mode de fonctionnement lire le mode de fonctionnement placer en RAM nombre gr (dpend du contexte) lire le nombre en eeprom sauver en RAM

Dans cette partie, on copie les valeurs eeprom situes dans les emplacements communs toutes les cartes vers la RAM. Ca facilite le traitement par le programme principal.
; Initialiser CAN mode 2 ; Les dbits sont dj initialiss dans domoboot.inc ; Le module est dj en mode configuration ; -------------------------------------------------rcall setmasfil ; placer les masques et les filtres SETMODE2 ; can actif mode 2 (FIFO) return ; fin d'initialisation

Enfin, on termine dabord en positionnant les filtres et les masques Can pour lapplication finale, puis on lance le module Ecan en mode de fonctionnement 2 (FIFO).
;============================================================================= ; TESTER SI BUFFER EMISSION TXB0 LIBRE = ;============================================================================= ;----------------------------------------------------------------------------; le statut est renvoy dans le flag BFREE (1 si libre) ; En sortie, les bits EWINx de ECANCON pointent sur le buffer ;----------------------------------------------------------------------------istxb0free bcf BFREE ; par dfaut, pas libre POINTTX0 ; pointer sur buffer mission 0 btfss TXBxCON,TXREQ ; tester si buffer libre bsf BFREE ; oui, signaler buffer libre return ; et fin ;============================================================================= ; TESTER SI BUFFER EMISSION TXB1 LIBRE = ;============================================================================= ;----------------------------------------------------------------------------; le statut est renvoy dans le flag BFREE (1 si libre) ; En sortie, les bits EWINx de ECANCON pointent sur le buffer ;----------------------------------------------------------------------------istxb1free bcf BFREE ; par dfaut, pas libre POINTTX1 ; pointer sur buffer mission 1 btfss TXBxCON,TXREQ ; tester si buffer libre bsf BFREE ; oui, signaler buffer libre return ; et fin ;============================================================================= ; TESTER SI BUFFER EMISSION TXB2 LIBRE = ;============================================================================= ;----------------------------------------------------------------------------; le statut est renvoy dans le flag BFREE (1 si libre) ; En sortie, les bits EWINx de ECANCON pointent sur le buffer ;----------------------------------------------------------------------------istxb2free bcf BFREE ; par dfaut, pas libre POINTTX2 ; pointer sur buffer mission 2 btfss TXBxCON,TXREQ ; tester si buffer libre

116

bsf BFREE return

; oui, signaler buffer libre ; et fin

Ces trois routines oprent chacune pour un des 3 buffers dmission de base de la faon suivante : On teste si le buffer est libre, et on le signale via un flag On sort doffice en pointant sur le buffer quon vient de tester.

Les macros POINTTX0 et suivantes seront tudies dans ltude du fichier base.inc Ces trois routines sont utilises dans les programmes o on utilise un buffer particulier pour chaque usage. Cest le cas par exemple de la carte 16 entres.
;============================================================================= ; CHERCHE UN BUFFER EMISSION LIBRE = ;============================================================================= ;----------------------------------------------------------------------------; Cherche aprs un buffer d'mission libre ; positionne EWIN3/WIN0 pour accder au buffer depuis l'access bank (via RXB0) ; Donc, si buffer mission 1 trouv, accs RXB0CON donne accs TXB1CON ; Les defines permettent d'utiliser TXBxCON au lieu de RXB0CON pour viter ; de prter confusion et pour bien indiquer que le vrai registre point ; est variable. ;----------------------------------------------------------------------------cherchbuf clrwdt ; effacer watchdog POINTTX0 ; pointer sur buffer mission 0 btfss TXBxCON,TXREQ ; tester si buffer mission 0 vide return ; oui, OK incf ECANCON,f ; non, pointer sur buffer mission 1 btfss TXBxCON,TXREQ ; tester si buffer mission 1 vide return ; oui, OK incf ECANCON,f ; non, pointer sur buffer mission 2 btfss TXBxCON,TXREQ ; tester si buffer mission 2 vide return ; oui, OK bra cherchbuf ; non, on attend un libre

Ici, cest un peu le contraire. On a besoin dun buffer dmission quelconque, et on retourne le premier quon trouve libre. Si aucun nest libre, on attend quun le devienne. En sortie, on pointe sur le buffer quon a trouv.
;============================================================================= ; ENVOI DES INFORMATIONS DE LA CARTE = ;============================================================================= ;----------------------------------------------------------------------------; CC_CARTE : envoi des informations de la carte ; octets de data : 8 ; D0 : type de pic sur la carte ; D1/D3 : V D1.D2.D3 ; D4 : Mode de fonctionnement ; b0 : 0 = mode normal, 1 = mode bootloader ; b1 : 0 = mode dcentralis (par dfaut), 1 = mode centralis ; b2/b7 : rservs pour utilisation future ; D5 : nombre de fonctions gres par le type de destinataire ; D6 : paramtre complmentaaire (dpend du contexte)

117

; D7 : paramtre complmentaire (dpend du contexte) ;----------------------------------------------------------------------------; initialiser trame de rponse ; ----------------------------sendcarte movlw CC_CARTE ; N de la commande commune movwf TXBxEIDL ; dans EIDL movlw 0x08 ; 8 octets de data movwf TXBxDLC ; dans DLC ; placer les data ; ---------------TYPEPIC ; type de pic sur la carte TXBxD0 ; dans D0 SOFTW_EEP ; emplacement version en eeprom readeepw ; lire octet 1 rvision TXBxD1 ; dans D1 readeep ; lire octet 2 rvision TXBxD2 ; dans D2 readeep ; lire octet 3 rvision TXBxD3 ; dans D3 modefonct,TXBxD4 ; mode de fonctionnement dans D4 cartenbr,TXBxD5 ; placer D5 carted6,TXBxD6 ; placer D6 carted7,TXBxD7 ; placer D7 sendtramecom ; envoyer trame can commande commune

movlw movwf movlw rcall movwf rcall movwf rcall movwf movff movff movff movff bra

Cette routine envoie la commande commune CC_Carte, qui est une commande utilise par toutes les cartes Domocan. Je vous renvoie ltude de cette commande pour plus de prcision.
;============================================================================= ; ENVOI DES TRAMES = ;============================================================================= ;----------------------------------------------------------------------------; plusieurs points d'entre : ; ; sendtramecom : envoi d'une commande commune ; Le n de la commande commune est dj dans TXBxEIDL ; Le nombre d'octets de data est dans TXBxDLC ; Les octets sont dj en place ; ; sendtramecmd : envoi d'une commande normale ; SIDH contiendra le type de cette carte ; EIDH contiendra le n de cette carte ; le n de commande est dans cmdrec ; le paramtre est dans parrec ; Le nombre d'octets de data est dans TXBxDLC ; Les octets sont dj en place ; ; sendtramecmdw : idem avec n de la commande dans WREG ; ; sendtramedesti : envoi d'une trame avec SIDH/EIDH = cette carte ; SIDL et EIDL sont dj configurs ; Le nombre d'octets de data est dans TXBxDLC ; Les octets sont dj en place ; ; sendtrame : envoi d'une trame compltement initialise ;----------------------------------------------------------------------------

118

; envoi d'une commande commune ; ---------------------------sendtramecom movlw CMD_COMM movwf TXBxSIDL bra sendtramedesti ; commande commune ; dans SIDL ; envoyer la trame

; envoi d'une commande ordinaire ; -----------------------------sendtramecmd movf cmdrec,w sendtramecmdw movwf TXBxSIDL movff parrec,TXBxEIDL ; charger commande ; placer commande ; placer le paramtre

; envoi d'une trame avec SIDH = DESTI et EIDH = cible ; --------------------------------------------------sendtramedesti movlw DESTI ; charger type de destinataire movwf TXBxSIDH ; dans SIDH movff cible, TXBxEIDH ; n de la carte dans EIDH ; envoi d'une trame initialise ; ----------------------------sendtrame clrf TXBxCON bsf TXBxSIDL,EXIDE bsf TXBxCON,TXREQ LEDCAN_ON clrf cmpttrafcan return ; ; ; ; ; ; priorit = 0 trame en mode extended lancer la trame de rponse allumer led trafic CAN compteur allumage LED et retour

Cette sous-routine permet de complter et denvoyer des commandes normales ou communes, en partie ou compltement dj initialises. Les diffrents points dentre prcisent les oprations prliminaires restant effectuer avant lenvoi de la trame. Par prcaution, on prcise que la trame est de type extended avant lenvoi. Toute trame envoye par cette routine lest en priorit 0, et la led de trafic Can est allume si lutilisateur a demand cette option. Au sujet de la priorit, ne confondez pas cette priorit qui dtermine lordre denvoi des trames Can par le PIC lui-mme au niveau de ses buffers, avec la priorit des trames Can sur le bus, qui, elle, est un mcanisme hardware dpendant de lidentificateur Can. De faon simple, les trames sont envoyes par votre PIC en fonction de la priorit des buffers dmission (pour le cas o vous envoyez plusieurs trames simultanment dans diffrents buffers). Par contre, si deux cartes diffrentes tentent denvoyer une trame simultanment sur le bus, lID le plus prioritaire sera celui envoy en premier. La priorit place dans le buffer dmission ne donne donc pas votre trame plus de priorit sur le bus Can, a relve uniquement de la gestion de vos ID. La priorit du buffer relve juste de la soupe interne. 119

Restent ensuite les routines dcriture et deeprom interne, dont je ne parlerai pas, voyez les cours. La dernire routine gre les messages derreur, cest strictement identique ce que jai expliqu pour le fichier domoboot.inc, je ny reviendrai pas non plus. Nous avons maintenant vu tous nos fichiers dinclusion. Ne reste qu tudier le squelette dune application type, savoir le fichier base.asm .

8.8 Le fichier base.asm Nous allons maintenant examiner le fichier base.asm . Celui-ci contient les fonctions de base dune carte Domocan. Lorsque vous ralisez une nouvelle application, il vous suffit : 1) De faire un copier/coller de ce fichier et de renommer la copie en fonction de lapplication 2) De crer un nouveau projet avec ce nouveau fichier cr 3) Deffectuer les assignations diverses pour personnaliser le projet en fonction de votre nouvelle carte (type de carte, type de pic, ports etc.). Ensuite, vous avez deux options : Soit vous assemblez le fichier tel quel et vous le placez dans le PIC Soit vous ajoutez toutes les fonctions ncessaires et vous placez le fichier dans le PIC

Dans le premier cas, vous avez charg dans votre PIC un bootloader et un programme de base. Ceux-ci vous permettrons de placer la carte sur site, et doprer le chargement du logiciel via le bootloader Dans le second cas, votre carte est prte lemploi, et prte galement pour une mise jour ultrieure laide du bootloader. Il est vident que le fichier .hex complet de lapplication contient galement le bootloader, puisque celui-ci est forcment inclus dans le projet. Or, on ne peut pas envoyer le bootloader via une procdure de bootload, par dfinition. Ne vous inquitez pas, le logiciel PC se charge de slectionner les donnes valides envoyer. Nous allons commencer lanalyse de ce fichier, qui, je le rappelle, contient toutes les fonctions de base communes toutes les cartes (lexception tant les cartes dinterface)
;***************************************************************************** ; Fonctions de base pour carte DOMOCAN * ; * ;***************************************************************************** ; * ; NOM : Base-Can * ; Date cration : 20/06/2003 * ; Date modification : 15/03/2008 * ; Version : 4.0 * ; Circuit : * ; Auteur : Bigonoff (bigocours@hotmail.com) * ; www.abcelectronique.com/bigonoff * ; www.bigonoff.org * ; *

120

;***************************************************************************** ; Historique * ; ---------* ; V1.00 : Le 27/10/03 : Premire version compltement termine en ligne * ; * ; V1.01 : Le 03/10/03 : Modif mineure * ; * ; V1.02 : Le 11/01/04 : Report de la macro de test du bootswitch vers * ; les programmes principaux (modification possible) * ; Petites optimisations du code * ; Modification du comportement sur commandes non * ; autorises en mode bootloader (plus de rponse) * ; * ; V1.03 : le 02/06/04 : quelques modifications * ; V2.00 : le 28/06/04 : Modification suite la dcouverte d'un bug * ; dans les pics. Microchip indique qu'il faut * ; viter de pointer le registre BSR sur la banque * ; 15 (ce qui tait le cas des versions prcdentes * ; Toutes les applications existantes ont t * ; modifies pour ne plus passer BSR en banque 15. * ; * ; V2.10 : le 16/07/04 : Correction d'un bug pour les zones utilisateurs * ; apparu lors de la prcdente correction * ; * ; V2.20 : le 17/11/04 : Ajout de la gestion de bits supplmentaires * ; dans la commande CMD_SOFTW * ; Ajout de la commande CMD_WMODEC pour prise en * ; charge de diffrents modes de fonctionnement de * ; la carte. * ; * ; V2.21 : le 27/12/04 : modifications sur l'access-bank suite la * ; dcouverte d'un nouveau bug par Microchip * ; modification des variables du bootloader suite * ; au bug * ; Modification des routines d'interruption de * ; rception CAN suite la dcouverte d'un autre * ; bug. * ; Quelques autres modifications mineures. * ; * ; V2.22 : le 11/01/05 : Prise en compte d'un bug sur les pics. GIEL doit * ; tre coup avant GIE/GIEH si on veut interdire * ; les interruptions. * ; * ; Modification de commentaires * ; * ; V3.0 : le 16/09/05 : refonte totale pour modification de stratgie * ; sur les identificateurs. Augmentation du nbre de * ; cartes possibles, suppression du n de rseau, * ; modification des trames, suppression des adresses * ; de carte * ; * ; V4.0 : le 15/03/08 : Modifications importantes suite la migration * ; des 18Fxx8 vers les 18Fxx80. * ; Utilisation de la nouvelle directive CONFIG * ; Merci Laurent pour sa participation active lors * ; de la migration * ; * ;***************************************************************************** ; Fichiers requis: P18Fxx80.inc * ; Domodef.inc * ; Domoboot.inc *

121

; CCommunes.inc * ; Configurations.inc * ; ParCan.inc * ; Fonctions.inc * ; * ; * ; Frquence de travail : 40 MHz * ; Frquence du quartz : 10 MHz * ;***************************************************************************** ; Pins utilises : * ; ---------------* ; RA0 : * ; RA1 : * ; RA2 : * ; RA3 : * ; RA4 : Sortie LED message CAN ( adapter selon carte),actif bas * ; RA5 : * ; * ; RB0 : * ; RB1 : * ; RB2/CANTX : Sortie mission CAN * ; RB3/CANRX : Entre rception CAN * ; RB4 : * ; RB5 : * ; RB6 : Entre switch de forage en mode bootloader (au reset) * ; RB7 : * ; * ; RC0 : Sortie vers RS du MCP2551 ( adapter selon carte) * ; RC1 : * ; RC2 : * ; RC3 : * ; RC4 : * ; RC5 : * ; RC6 : * ; RC7 : * ;***************************************************************************** ; Fonctionne sous rseau CAN jusque 1MBits/s (333 ou 500 Kbits conseills) * ; Bootloader CAN intgr pour mise jour depuis le rseau * ; Commandes gnrales : Voir domodef.inc * ; * ; Le switch de forage en mode bootloader est dsactiv si on est en mode * ; debugger (ligne DEBUG EQU 0x01). En mode normal, un reset avec le jumper * ; positionn force le pic en mode bootloader. Ceci permet de toujours * ; pouvoir redmarrer mme si le programme utilisateur charg se plante. * ; * ; La sortie xx est mise hors service durant le debuggage * ; * ;*****************************************************************************

Rien de tel que len-tte pour avoir un aperu du contenu du fichier. Pour votre logiciel dapplication, vous effacerez videmment lhistorique, et remplacerez toutes les informations prsentes par celles effectives de votre carte.

122

;============================================================================= ; DEFINES ET ASSIGNS = ;============================================================================= DEBUG EQU 0x01 ; enlever le ";" en phase de debuggage ICD2 TYPEPIC EQU 0x05 ; type de pic ; 0x01 = 18F248 : plus support depuis V4.0 ; 0x02 : 18F258 : plus support depuis V4.0 ; 0x03 : 18F448 : plus support depuis V4.0 ; 0x04 : 18F458 : plus support depuis V4.0 ; 0x05 : 18F2580 : A partir de V4.0 ; 0x06 : 18F4580 : A partir de V4.0 ; 0x07 : 18F2680 : A partir de V4.0 ; 0x08 : 18F4680 : A partir de V4.0 ; non modifiable aprs programmation (logique)

Les dfinitions commencent par la ligne DEBUG . ATTENTION, vous placerez un ; devant cette ligne lorsque vous assemblerez votre programme de faon dfinitive. Labsence de ce point-virgule configure la carte pour le travail avec le debugger ICD2 Petite explication pour les utilisateurs novices de lICD2 : Lors du debuggage, vous enlevez le point-virgule, et, dans votre projet sous MPLAB, vous choisissez Debugger -> ICD2. Vous pouvez ensuite travailler avec votre debugger Pour lassemblage final, vous placez le point-virgule, sous slectionnez programmer>ICD2 (important), vous rassemblez le programme (important), puis vous chargez votre programme final dans le PIC. Ne vous reste qu dconnecter le debugger.

Si vous nutilisez pas lICD2, ou que vous ne debuggez pas, vous ne pouvez jamais enlever le point-virgule. Ensuite, vous avez lidentification du PIC selon la standardisation Domocan. Celui-ci est capable de grer 255 types diffrents, actuellement seuls les PIC indiqus ci-dessus sont reconnus.
DESTI EQU 0x61 ; type de destinataire (type de carte) de 0x20 0xDF ; non modifiable aprs programmation ; voir documents DOMOCAN pour l'attribution des destinataires

Cette ligne dtermine le type de destinataire de la carte. Une fois le PIC programm avec le bootloader, cette valeur ne peut plus tre modifie par la suite sans reprogrammation classique du PIC. Jai rserv les n 0x00 0x1F, ainsi que les numros 0xE0 0xFD (0xFE/0xFF sont illgaux en Can) pour de futures trames dinformation gnrale. Sachez que pour linstant, il ny a que 2 numros rservs utiliss, savoir : 0x01 : Dest_INFO1 0xFD : Dest_ADMIN : trame dinformation haute priorit : trames dadministration basse priorit (trames derreurs etc)

Si le besoin sen faisait sentir (plus de 192 types de cartes raliss) je pourrais dbloquer facilement dautres numros. Nous nen sommes pas l 123

CONFIG WDTPS = 128

; valeur postdiviseur watchdog (en ascii) ; 1, 2, 4, 8, 16, 32, 64, 128 (18Fxx8) ; jusque 32768 (xx80)

Il sagit de la valeur affecte au prdiviseur du watchdog. Prenez une valeur suffisamment petite pour que le watchdog soit utile, et une valeur suffisamment grande pour viter des resets intempestifs.
CIBLEDEF EQU .254 ; N de la carte de 0 .254 (255 = broadcast) ; modifiable via Domogest

Cest le numro de cible de la carte. Souvenez-vous que vous ne pouvez pas avoir 2 cartes de type identique rpondant au mme n de cible. Par contre, vous pouvez avoir deux cartes de types diffrents rpondant au mme n de cible. Par exemple, une carte gradateur n 0 et une carte entre n 0 sont permises (cest mme la bonne faon de procder). Par contre, deux cartes gradateur de n de cible 0 sont illgales. Vous devrez en dconnecter une et modifier un des deux n de cible. Par dfaut la carte reoit le numro 254, et vous pouvez modifier ce numro via Domogest. Inutile donc de modifier ici, sauf si vous placez simultanment plusieurs cartes identiques sur le bus. Je conseille plutt de laisser 254, de placer la carte sur le bus, puis de changer via Domogest le numro en commenant la numrotation 0. Attention : le numro 255 est illicite parce que ce numro est rserv aux envois de type broadcast (destin toutes les cartes dun mme type).
MODEDEF EQU B'00000100' ; ; ; ; ; ; ; ; mode de fonctionnement par dfaut b0 : mode normal(0) ou mode bootloader(1) toujours laisser 0 (gr en interne) b1 : centralisation (0=dcentralis) b2 : Fonctionnement de la led CAN (1 = en service) b3 : rserv pour utilisation future b4/b7 : spcifiques certaines cartes modifiable via Domogest

Vous retrouvez ici le mode de fonctionnement par dfaut de la carte lors de la premire programmation. Ensuite, ce mode pourra tre modifi par commande Can et sera mmoris en eeprom. Vous ne pouvez pas positionner le bit 0 1 pour ce mode, sous peine de fonctionnement erron du logiciel PC Domogest, qui risquerait dtre dans limpossibilit de dtecter que votre carte fonctionne en mode oprationnel. Le bit 1 place la carte par dfaut en mode centralis ou en mode dcentralis. Les applications typiques Domocan sont en mode dcentralis, sachant quil est toujours possible de modifier ce bit via Domogest une fois la carte sur le bus. Je vous dconseille de toucher la valeur indique, car tout est grable sans risque derreurs via le logiciel Domogest. Configurez plutt votre carte une fois celle-ci en service.

124

Quelques bits peuvent avoir un rle particulier pour certains types de cartes. Si cest le cas, les descriptifs se trouveront dans le fichier source relatif la dite carte.
NBGERE EQU 0x01 exemple) ; nombre gr, selon le contexte (nombre sorties par

Cette valeur nest modifier que pour les cartes grant plusieurs applications identiques (gradateur grant 16 sorties, carte dentre grant 16 entres, etc).
VER1 equ 0x01 VER2 equ 0x00 VER3 equ 0x00 ; version software = 1.0.0 ; modifiable par bootloader

Il sagit de la rvision software (version) du logiciel en cours dassemblage. Modifiez ce numro si vous faites des modifications dans votre fichier source. Ceci vous permettra de suivre lvolution via Domogest. Attention, si vous modifiez mes propres logiciels, utilisez des numros de version particuliers. Comme a, a vous vite de vous retrouver avec une version 1.2.0 crite par vous-mme et une version 1.2.0 crite par moi, ce qui rendrait vos mises jour dlicates.
#include <configurations.inc> #include <DomoDef.inc> ; inclure les configurations ; defines, assignations, et macros

On termine par linclusion du fichier de configuration et celui des dfinitions gnrales.

;============================================================================= ; DEPEND DU HARDWARE DE LA CARTE = ;============================================================================= ; Valeurs initiales des ports (seuls ceux qui existent sont utiliss) ; ------------------------------------------------------------------VALPORTA EQU B'00000000' ; valeur au dmarrage PORTA VALPORTB EQU B'00000100' ; valeur au dmarrage PORTB VALPORTC EQU B'00000000' ; valeur au dmarrage PORTC VALPORTD EQU B'00000000' ; valeurs au dmarrage PORTD VALPORTE EQU B'00000000' ; valeurs au dmarrage PORTE VALPORTF EQU B'00000000' ; valeurs au dmarrage PORTF VALPORTH EQU B'00000000' ; valeurs au dmarrage PORTG VALPORTH EQU B'00000000' ; valeurs au dmarrage PORTH VALPORTJ EQU B'00000000' ; valeurs au dmarrage PORTJ

Ici vous placez les valeurs que vous souhaitez forcer pour les sorties de votre PIC au moment de la mise sous tension. Placez ici des valeurs qui mettent la carte au repos et ninfluencent pas lenvironnement extrieur. Ne vous proccupez que des sorties, les entres ne sont pas prises en compte. Seuls les ports prsents rellement sur le PIC choisi en fonction de TYPEPIC sont pris en compte. Vous pouvez laisser les lignes inutilises, ou les effacer, votre guise, a ne change strictement rien au niveau du programme plac dans le PIC.

125

; direction des ports (seuls ceux qui existent sont utiliss) ; ----------------------------------------------------------DIRPORTA EQU B'11111111' ; Direction PORTA IFDEF DEBUG DIRPORTB EQU B'11101011' ; Direction PORTB en mode debug ELSE DIRPORTB EQU B'11101011' ; Direction PORTB en mode normal ENDIF DIRPORTC EQU B'11111011' ; Direction PORTC DIRPORTD EQU B'11111111' ; Direction PORTD DIRPORTE EQU B'11111111' ; Direction PORTE DIRPORTF EQU B'11111111' ; Direction PORTF DIRPORTG EQU B'11111111' ; Direction PORTG DIRPORTH EQU B'11111111' ; Direction PORTH DIRPORTJ EQU B'11111111' ; Direction PORTJ

Il est trs important de configurer ici les entres et les sorties de votre PIC. Attention, vous avez deux fois la direction du PORTB, une fois en mode normal, et une fois en mode debugger. En mode debugger, vous devez laisser RB6 et RB7 en entre, sinon vous risquez des problmes au niveau du debuggage, ne loubliez pas. Comme pour les valeurs des ports, seuls les registres de direction prsents sur le PIC sont pris en compte.
; autres assignations ; -------------------ADCON1VAL EQU 0x0F ; PORTA en mode numrique

Cette ligne dtermine comment fonctionne le PORTA. A la mise sous tension le port est en mode analogique. Par dfaut, cette ligne valide le port en mode numrique. A vous de modifier cette assignation si vous utilisez des entres analogiques. La valeur place ici est celle qui sera place dans le registre ADCON1 linitialisation de votre programme.
#DEFINE BOUTON PORTB,6 ; emplacement du BP de forage bootloader

Cette ligne indique sur quelle pin se situe le jumper (ou le bouton) de forage en mode bootloader. Noubliez pas que si le jumper est plac (ou le bouton enfonc) lors de la mise sous tension ou aprs un reset, la carte passera automatiquement en mode bootloader.
#DEFINE OUTRS PORTB,4 ; ligne RS du MCP2551

Cette ligne indique sur quelle pin est place la pin RS du driver Can MCP2551 ou compatible. Noubliez pas de lindiquer, sinon votre carte ne fonctionnera pas.
#DEFINE LEDCAN PORTC,2 ; LED trafic

Cette ligne indique sur quelle pin est relie la Led de trafic CAN.

126

;#DEFINE

LEDCANREV

; tat bas = allumage (; si le contraire)

Telle quelle, cette ligne est ignore cause du point-virgule. Dans ce cas, la led est considre allume si on envoie un niveau haut sur la pin indique la ligne prcdente. Si vous enlevez le point-virgule, le fonctionnement est invers, et la led sallume si le niveau est bas sur la pin indique. Si vous vous posez la question de lutilit dallumer la led sur niveau bas, sachez que par exemple la pin RA4 est incapable denvoyer un niveau haut. Vous pourriez aussi avoir besoin dune commande par niveau bas si la sortie led se retrouvait multiplexe avec une autre pin.
;============================================================================= ; COMMANDES CAN = ;============================================================================= ;----------------------------------------------------------------------------; Uniquement les commandes propres cette carte ; ; structure d'un ID gnral ; ------------------------; identificateur : dddddddd ccccc nnnnnnnn pppppppp ; SIDH SIDL EIDH EIDL ; ; avec : dddddddd : destinataire fig pour une carte donne (DESTI) ; ccccc : commande ; nnnnnnnn : n de la carte cible (255 pour broadcast) ; pppppppp : paramtre complmentaire (ou n de la commande commune) ; ; trame d'erreur ; -------------; identificateur : 11111101 11111 00000000 eeeeeeee ; SIDH SIDL EIDH EIDL ; ; avec : SIDH : DEST_ADMIN : trame destine au systme d'administration ; SIDL : CMD_ERR : commande d'erreur ; EIDH : 0 : rserv pour utilisation future ; EIDL : eeeeeeee : n du code d'erreur ; D0 : SIDH qui a provoqu l'erreur (toujours DESTI) ; D1 : commande qui a provoqu l'erreur ; D2 : cible qui a provoqu l'erreur ; D3 : paramtre qui a provoqu l'erreur ; ; trames pour commandes communes ; -----------------------------; identificateur : dddddddd 00000 nnnnnnnn pppppppp ; SIDH SIDL EIDH EIDL ; ; avec : SIDH : destinataire fig pour une carte donne (DESTI) ; SIDL : CMD_COMM : commande commune ; EIDH : ssssssss : n de la carte (255 pour broadcast) ; EIDL : pppppppp : n de la commande commune (voir domodef.inc) ; ; Les n de commandes sont encods comme suit dans SIDL : b4 b3 b2 0 1 0 b1 b0 ; ; pour les commandes suivante : -E = mission / -R = rception ;-----------------------------------------------------------------------------

127

On entre ici dans lanalyse des trames Can, len-tte rappelle les diffrents types de trames gres par la plupart des cartes Domocan.
; commandes spcifiques autorises ; -------------------------------; le n 0 reprsente une commande commune CMD_TEST1 EQU CMD_1 ; ; ; ; ; ; commande exemple 1 -R octets de data : D0 : D1 : rponse : CMD_REPONSE codes d'erreur : G1,G2,G3,G4

CMD_TEST2 EQU CMD_2

; ; ; ; ; ;

commande exemple 1 -R octets de data : D0 : D1 : rponse : CMD_REPONSE codes d'erreur : G1,G2,G3,G4

CMD_REPONSE1 EQU CMD_16

; commande exemple de rponse 1 -E ; octets da data : ; D0 :

Cette zone contiendra la dclaration de toutes les commandes acceptes et mises, via un nom symbolique. Regardez un fichier dune application existante pour avoir un exemple concret. Dans la maquette, jai simplement configur 2 commandes reues (CMD_TEST1 et CMD_TEST2), ainsi quune commande mise (CMD_REPONSE1). Notez sur lexemple quen gnral, par convention, je place les commandes reues sur les plus petits numros et les commandes mises sur les numros plus importants (b4=1). Ca na cependant rien dobligatoire. Il convient daffecter la commande symbolique une commande chiffre, en utilisant imprativement les noms CMD_1 CMD_31, et non les chiffres 1 31. Noubliez pas que la commande CMD_0 est en ralit la commande commune CMD_COMM, vous ne pouvez donc pas lutiliser. Vous navez pas non plus vous proccuper de la gestion de toutes les trames communes, qui sont dj traites dans le fichier ccommunes.inc Nous allons maintenant passer notre zone eeprom. Jen ai dj parl en dtails plus haut, mais je reprends les grandes lignes pour celui qui ne lirait que ce chapitre.

128

;============================================================================= ; ZONE EEPROM 1 = ;============================================================================= ;----------------------------------------------------------------------------; criture non autorise par le booloader ; contient de plus des zones qui sont identiques pour toutes les cartes ; il n'est pas autoris de dplacer ces donnes ;----------------------------------------------------------------------------ORG 0xF00000 DE "BG" ; en-tte pour vrification mode normal ; si pas "BG", on passe en bootloader ORG 0xF00002 DE CIBLEDEF,MODEDEF ; N de la carte ; suivi par le mode de fonctionnement ORG 0xF00004 DE "IN16 " DE "CARTE 01" ORG 0xF00014 DE NBGERE,0

; zone utilisateur (8 octets) ; nom de la carte (8 octets)

; Nombre gr, rserv

; OFFSETS ; ------BOOT_EEP EQU 0x00 ; offset du code de vrification CIBLE_EEP EQU 0x02 ; offset du n de la carte MODEC_EEP EQU 0x03 ; mode de fonctionnement de la carte ; b0 : toujours 0 (gr en interne) ; b1 : centralisation (0=dcentralis) ; b2 : Led trafic can en service (1) ; b3/b7 : rservs pour utilisation future ZONE_EEP EQU 0x04 ; offset de la zone utilisateur NAMEC_EEP EQU 0x0C ; offset du nom de la carte NBGERE_EEP EQU 0x14 ; nombre gr

Cette zone est volontairement rendue inaccessible par le bootloader. Dit autrement, les informations prsentes ici ne sont pas dtruites lorsque vous mettez votre programme jour via le bootloader de Domogest. La seule faon dy accder est de modifier explicitement leur valeur via le logiciel Domogest par exemple. Vous trouvez ici tout dabord lidentificateur BG qui permet au programme principal de savoir que le programme charg est valide (voir explications du fichier domoboot.inc). Ensuite, le numro de la carte et le mode de fonctionnement dont nous venons de parler. Suivent deux zones, contenant le nom de la carte ainsi quune zone de commenaire. On termine avec le nombre gr, dpendant, comme nous lavons dj expliqu, du type de carte. Le 0 termine avec un nombre pair doctets sur la ligne, si vous ne le mettez pas il sera ajout doffice par MPASM, et vous risquez de ne pas le remarquer. Les offsets reprsentent ladresse relative des diffrents emplacements eeprom. Lemplacement 0 correspond ladresse physique 0xF00000.

129

;============================================================================= ; ZONE EEPROM 2 = ;============================================================================= ;----------------------------------------------------------------------------; accs autoris par le bootloader ; contient des zones dont les adresses sont fixes pour toutes les cartes ; il n'est pas autoris de dplacer ces donnes ;----------------------------------------------------------------------------ORG 0xF00016 DE VER1,VER2,VER3,0 ; version soft.version2.version3, rserv ORG 0xF0001A DE 0,0

; rservs pour utilisation future ; OFFSETS ; ------; zone version logiciel

SOFTW_EEP EQU 0x16

La zone 2 contient des emplacements fixes, mais crasables par le bootloader. Vous trouvez ici le numro de version, qui est remplac lors dune mise jour du programme (cest la seule faon de modifier cette zone). Les experts me feront remarquer quil est inutile dinscrire la version en eeprom, on pourrait la mettre en mmoire flash, puisque fige avec le programme dapplication. Cest effectivement vrai, mais cet emplacement devrait tre un endroit fixe. Or, si on le met dans la partie bootloader, il sera impossible de modifier le numro de version, il faut donc choisir un emplacement fixe dans la mmoire programme du programme principal. Pour linstant, je nai pas eu besoin de rcuprer cette zone eeprom particulire, mais si le besoin sen faisait sentir je pourrais dplacer cette information de leeprom vers la flash. Attention que si vous le faites il vous faudra galement modifier Domogest, parce quil va rcuprer cette information lors de la procdure du bootloader directement dans le fichier .hex envoyer vers le PIC.
;============================================================================= ; ZONE EEPROM 3 = ;============================================================================= ;----------------------------------------------------------------------------; accs autoris par le bootloader ; contient des donnes variables selon le type de carte ;----------------------------------------------------------------------------ORG 0xF0001C

Le reste de leeprom est totalement libre pour chaque application spcifique. Il ny a rien de standard ce niveau et vous pouvez utiliser leeprom votre guise. Aprs la mmoire eeprom, passons la RAM :

130

;============================================================================= ; VARIABLES ACCESS RAM = ;============================================================================= ; zone de 96 octets ; ----------------CBLOCK 0x00 ; zone access ram de la banque 0 ; Variables toujours utilises ; ---------------------------cible : 1 modefonct : 1 ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; N de la carte mode de fonctionnement de la carte(pas effacer dans init) octet qui sera envoy comme D4 de la commande CC_CARTE b0 : laisser 0 = mode normal (1=bootloader) b1 : centralisation : 0=dcentralis, 1=centralis b2 : Led CAN en service (1) b3/b7 : rservs nombre gr pour la commande CC_CARTE octet D6 pour la commande CC_CARTE octet D7 pour la commande CC_CARTE flags b0 : Buffer d'mission test libre b1 : Valeur du bit GIEL restaurer b2 : Valeur du bit GIEH restaurer commande reue (SIDL) ou envoyer (pour sendtramecmd) paramtre reu (EIDL) destinataire reu numro de cible reu code d'erreur pour sous-routines compteur pour allumage LED trafic CAN pour vrification criture eeprom

cartenbr : 1 carted6 : 1 carted7 : 1 flags : 1

cmdrec : 1 parrec : 1 destrec : 1 ciblerec : 1 codeerreur : 1 cmpttrafcan : 1 eeptemp : 1 ptrr : 2 ptrt : 2 local01 : 1 local02 : 1

; pointeur sur prochaine trame recevoir (MSB/LSB) ; pointeur sur prochaine trame traiter (MSB/LSB) ; variable locale ; variable locale

Attention, toutes ces variables sont utilises par les programmes Domocan. Ne dtruisez pas ces variables sous peine dobtenir des erreurs lassemblage. Ncrivez pas non plus dans ces variables de faon inconsidre sous peine de risquer dobtenir des fonctionnements incorrects de votre programme.
; Variables de ce programme ; -------------------------local03 : 1 ; variable locale ENDC

Placez vos propres variables ici, pour plus de lisibilit. Il vous reste 77 emplacements libres en access-bank pour votre propre usage.
; DEFINES POUR FLAGS ; -----------------#DEFINE STLEDCAN modefonct,2 ; indique si Led CAN en service ou pas #DEFINE BFREE flags,0 ; Buffer test libre

131

#DEFINE GIELSET flags,1 #DEFINE GIEHSET flags,2

; statut actuel du bit GIEL ; statut actuel du bit GIEH

Ces defines donnent un nom symbolique aux diffrents bits utiliss de la variable flags . Je vous conseille cette mthode si vous utilisez des flags dans votre programme personnel.
;============================================================================= ; VARIABLES BANQUE 0 NON ACCESS = ;============================================================================= ; zone de 160 octets ; -----------------CBLOCK 0x60 wreg_lp : 1 ; sauvegarde W pour interrupts L.P. status_lp : 1 ; sauvegarde STATUS pour interrupts L.P. fsr0_lp : 2 ; sauvegarde pour FSR0 interrupts L.P. ecancon_lp : 1 ; sauvegarde de ECANCON interrupts L.P. wreg_hp : 1 status_hp : 1 ENDC ; sauvegarde W pour interrupts H.P. ; sauvegarde STATUS pour interrupts H.P.

Dans le reste de la banque 0, qui nest pas en access-bank, jai plac les sauvegardes des registres lors des diffrentes interruptions. Vous pouvez videmment dplacer ces variables nimporte o en RAM, en access-bank ou non, puisquelles ne sont accdes que par des instructions 32 bits de type movff (voir cours-part5). Si vos interruptions modifient dautres registres, noubliez pas dajouter les sauvegardes ncessaires. Vous disposez encore de pas mal demplacements libres dans cette zone, vous de voir en fonction de votre application.
;============================================================================= ; VARIABLES BANQUES 1 12 = ;============================================================================= ;----------------------------------------------------------------------------; 18Fx580 : jusque 0x5FF en mode normal et 0x5F3 en mode debugger ; 18Fx680 : jusque 0xCFF en mode normal et 0xCF3 en mode debugger ;----------------------------------------------------------------------------CBLOCK 0x100 tramesbuf : ; reste de la RAM utilise comme buffer CAN ; exemple. Mettre toujours tramesbuf en fin ; de RAM.

ENDC LASTT EQU LASTRAM - .12 ; dernier emplacement pouvant accueillir une ; trame de 13 octets ; voir configurations.inc

Dans cette zone, par dfaut, jai plac tout le buffer des trames Can reues. Vous pouvez videmment restreindre cette zone si vous avez besoin demplacements RAM supplmentaires.

132

Notez la dernire ligne, qui calcule le dernier emplacement utilisable pour sauver une trame Can (LASTT) en fonction de la taille RAM disponible (LASTRAM) calcule par notre fichier configurations.inc . On retire 12 du dernier emplacement parce quil faut 13 octets pour sauver une trame Can complte. Vu cette faon de calculer, laissez toujours le buffer Can software en fin de RAM, si vous avez besoin de RAM supplmentaire, utilisez les emplacements AVANT tramesbuf . Ceci est donc valide :
CBLOCK 0x100 Mavariable : 1 Monbuffer : .50 tramesbuf : ENDC LASTT EQU LASTRAM - .12 ; variable supplmentaire ; buffer personnel ; reste de la RAM utilise comme buffer CAN

; dernier emplacement pouvant accueillir une

Mais pas ceci :

CBLOCK 0x100 tramesbuf : Mavariable : 1 Monbuffer : .50 ENDC LASTT EQU LASTRAM - .12 ; dernier emplacement pouvant accueillir une trame ; reste de la RAM utilise comme buffer CAN ; variable supplmentaire ; buffer personnel

;============================================================================= ; MACROS POUR PROGRAMME UTILISATEUR = ;=============================================================================

Cette zone est libre pour ajouter vos propres macros.

;***************************************************************************** ;***************************************************************************** ;***************************************************************************** ; BOOTBLOCK - PROTEGE * ;***************************************************************************** ;***************************************************************************** ;***************************************************************************** ;============================================================================= ; PROGRAMME BOOTLOADER = ;============================================================================= #include <DomoBoot.inc> ; inclure bootloader

A cet endroit va sinsrer tout notre fichier domoboot.inc, qui prend videmment place au tout dbut de notre mmoire flash.
;***************************************************************************** ;***************************************************************************** ;*****************************************************************************

133

; ZONE NON PROTEGEE ;***************************************************************************** ;***************************************************************************** ;*****************************************************************************

Tout le code qui sera crit partir entre ladresse STARTP et ltiquette ZPR sera susceptible dtre cras lors dune procdure de mise jour.
;============================================================================= ;============================================================================= ; VECTEURS REDIRIGES = ;============================================================================= ;============================================================================= ;----------------------------------------------------------------------------; La modification de la valeur de STARTP impose le remplacement du ; bootloader ;----------------------------------------------------------------------------ORG STARTP start bra init ORG STARTP+4 DB HIGH(ZPR),LOW(ZPR) ORG STARTP+06 bra intlp ; vecteur de dmarrage du programme ; dmarrer le programme utilisateur ; indication de zone non crase ; dbut de la zone protge ; vecteur d'interruption basse priorit ; traiter interruptions basse priorit

Nous trouvons ici nos diffrentes adresses de dpart. Pour rappel : STARTP est une adresse multiple de 64 qui est le dbut de notre programme dapplication. Au dmarrage le programme teste si on est ou non en mode bootloader. Si ce nest pas le cas, on saute cette adresse. A lemplacement STARTP+4) se trouve un mot de 16 bits, qui est en fait ladresse de la zone protge en fin de mmoire programme. Dans cette zone vous pouvez mettre des informations qui ne doivent pas tre crases lors dune mise jour du logiciel par bootloader. Domogest utilise cette valeur pour savoir o il doit arrter lopration bootloader, laissant intacte toute informations situe aprs ltiquette ZPR de votre programme. La carte gradateur, par exemple, stocke ses mmoires dclairage dans cette zone, la zone eeprom ntant pas assez vaste. Placez votre tiquette ZPR assez loin de la fin de votre programme principal. En effet, dans le cas contraire lallongement de votre programme ncessiterait dcraser cette zone. Si cela devait tre le cas, vous allez me dire que cest impossible, puisque justement cette zone est protge de lcrasement. En ralit, vous avez une solution de secours : 1) Vous envoyer par bootloader le programme avec la zone ZPR modifie 2) Vous renvoyez une seconde fois le programme Lors de la premire criture, la valeur de ZPR en STARTP+4 sera modifie, mais le bootloader refusera dcraser la zone ZPR quil aura mmorise.

134

A la seconde tentative, la zone ZPR renseigne en mmoire flash du PIC aura t modifie, et donc le bootloader acceptera dcrire toute votre programme, jusque cette nouvelle zone. Evidemment, lissue de lopration, vous aurez perdu toutes vos donnes cet endroit. Cest pourquoi il est conseill de prvoir de la rserve. Pour terminer, en STARTP+6, vous trouvez ladresse de destination des interruptions basse priorit, aprs que celles-ci soient arrives leur emplacement dorigine, soit 0x18, ce qui se situe en plein dans la zone du bootloader.
;============================================================================= ;============================================================================= ; INTERRUPTIONS HAUTE PRIORITE = ;============================================================================= ;============================================================================= ;----------------------------------------------------------------------------; Suite des bugs frquents trouvs sur d'anciens pics, et des doutes ; sur la possibilit d'utiliser le mode FAST lorsqu'on debugge avec l'ICD2, ; on ne ressort pas de la routine d'interruption en utilisant le mode FAST ;----------------------------------------------------------------------------ORG STARTP+0x0A ; vecteur d'interruption haute priorit ; sauvegarde des registres utiliss ; --------------------------------movff STATUS,status_hp ; sauver manuellement STATUS movff WREG,wreg_hp ; ainsi que WREG

; restauration des registres ; -------------------------inthrest movff status_hp,STATUS movff wreg_hp,WREG retfie ; restaurer STATUS ; ainsi que WREG ; retour d'interruption

La routine dinterruption se traite directement ici. Dans la fichier de base, il ny a pas dinterruption haute priorit en service, jai donc juste plac le corps de la fonction. Notez que suite des dboires, jai renonc lutilisation du retour dinterruption FAST . Ce mode pose de plus apparemment problme avec lICD2, qui semble dj lutiliser pour son compte propre. Jai donc procd une sauvegarde manuelle des deux principaux registres. Ladresse STARTP+.10 est dtermine par un saut partir du vecteur dorigine 0x08 se trouvant dans le bloc bootloader. Comme vous le savez dj, a nallonge en rien lexcution de notre interruption haute priorit, qui est contrainte deffectuer un saut de toutes faons (espace insuffisant entre ladresse 0x08 et ladresse 0x18). Notez quil ny a aucun changement de banque dans tout le programme, ce qui vite de devoir soccuper du registre BSR.

135

;============================================================================= ;============================================================================= ; INTERRUPTIONS BASSE PRIORITE = ;============================================================================= ;============================================================================= ; sauvegarde des registres ; ------------------------intlp movff movff movff movff STATUS,status_lp WREG,wreg_lp FSR0H,fsr0_lp FSR0L,fsr0_lp+1 ; ; ; ; sauver manuellement STATUS ainsi que WREG sauver FSR0H et FSR0L

; scrutation des interruptions ; ---------------------------btfsc PIR3,RXBnIF ; tester si rception d'une trame CAN rcall intcanrec ; oui, traiter rception CAN

; non, traiter autres cas ; restauration des registres ; -------------------------intlrest movff fsr0_lp,FSR0H movff fsr0_lp+1,FSR0L movff wreg_lp,WREG movff status_lp,STATUS retfie ; ; ; ; ; restaurer FSR0H et FSR0L ainsi que WREG et STATUS puis, retour d'interruption

Notre routine dinterruption basse priorit aiguille vers la bonne procdure nos diffrentes sources dinterruption. Dans cette maquette nous traitons uniquement ce qui est indispensable : la rception des trames Can. Voyons maintenant notre routine de rception de trame CAN en mode 2. Pour ceux qui avaient tudi les prcdentes routines en mode 0, tout est ici modifi, il sagit dune nouvelle faon de procder.
;============================================================================= ; INTERRUPTION RECEPTION TRAME CAN FIFO (LP) = ;============================================================================= ;----------------------------------------------------------------------------; Rception d'une trame CAN dans la file FIFO (ECAN en mode 2) ; Les bits FPx de CANCON pointent sur l'actuel buffer lire ; On accde au registre concern avec les bits EWINx de ECANCON ; On copie la trame dans le buffer RAM : 13 octets par trame ; On utilise le buffer partant de l'adresse RAM tramesbuf jusqu' la fin ; de la dernire banque du pic utilis. La zone tient compte de la prsence ; ou non d'un debugger ICD2 ; LASTT indique le dernier emplacement valide pour sauver une trame ; la gestion est assure par 2 pointeurs circulaires ptrr (ptr reu) et ; ptrt (ptr trait). Si les 2 pointeurs pointent sur la mme valeur, alors ; c'est que toutes les commandes sont traites. ; Le dbordement du buffer RAM n'est pas gr, le pic est suffisamment ; rapide pour ne pas s'en proccuper, au vu des tches accomplir ; la structure en RAM est la suivante : SIDH,SIDL,EIDH,EIDL,DLC,DATA ; on doit sauver le destinataire car des cartes peuvent avoir besoin de ; commandes qui ne leur sont pas explicitement destines (trames clock etc) ;-----------------------------------------------------------------------------

136

Comme indiqu, en mode 2 chaque trame arrive dans un buffer dont lemplacement est indiqu par les 3 bits de poids faible du registre CANCON. Or, dans le mode 2, le registre rellement point lorsquon accde aux registres RXB0xxx dpend de la valeur prsente dans les bits EWIN4 EWIN0 du registre ECANCON, nous en avons dj parl. Les registres sont de la forme :
ECANCON ECANCON MDSEL1 REQOP2 MDSEL0 REQOP1 FOFIWM REQOP0 EWIN4 EWIN3 EWIN2 EWIN1 EWIN0 ABAT FP3 FP2 FP1 FP0

Et nous devons amener dans ECANCON la valeur suivante :

MDEL1 MDSEL0 FOFIWM 1 FP3 FP2 FP1 FP0

Pour accder au buffer de rception concern, il faut donc recopier les 4 bits de poids faible de CANCON dans le registre ECANCON, puis forcer EWIN4 1. Ceci permet de pointer sur le buffer de rception dont le numro est indiqu par CANCON, en accdant simplement aux registres RXB0xxx. (RXB0CON, RXB0SIDH, etc). On obtient ainsi une file FIFO dont le numro de la prochaine trame lire est indiqu par CANCON. Tout est donc automatique, et les trames sont traites dans leur ordre darrive. Les alias RXBx sont utiliss pour bien montrer quen fait on naccde pas forcment au registre RXB0 en lui-mme, mais en fait au registre point par ECANCON. Mais a aussi, jen ai dj parl. Voyons comment a se passe en pratique :
intcanrec ; initialisations ; --------------movff ECANCON,ecancon_lp ; sauver ECANCON

Puisquon modifie ECANCON dans la routine dinterruption, sa sauvegarde est videmment ncessaire. Pour raliser la manipulation de bits dcrite, la logique voudrait quon crive ceci :
; pointer sur le bon buffer de rception ; -------------------------------------intcanrecloop movlw B'11100000' ; prparer effacement bits EWINx andwf ECANCON,f ; effacer movf CANCON,w ; charger CANCON andlw 0x0F ; conserver pointeurs FIFO valides iorlw 0x10 ; forcer bit EWIN4 1 iorwf ECANCON,f ; pointer sur registre de rception en cours

On efface les bits quon va modifier de ECANCON, on charge CANCON dont on conserve les bits de FP insrer dans ECANCON, puis on force les bits EWIN avec un OR, aprs avoir forc le bit 4 1. Cest purement logique, mais linstinct du programmeur le titille lorsquil voit les deux and. En gnral, a doit vouloir dire quon peut ruser avec des xor .

137

Ds lors, que pensez-vous de cette mthode-ci ?

; pointer sur le bon buffer de rception ; -------------------------------------intcanrecloop movf CANCON,w ; charger registre CANCON xorwf ECANCON,w ; conserver tout bit diffrent de ECANCON andlw B'00001111' ; limiter la diffrences FPx xorwf ECANCON,f ; inverser les bits EWIN diffrents de FP bsf ECANCON,4 ; et forcer EWIN4 1

On ne gagne quune instruction, mais cest pour la beaut du geste. Lastuce est simplement de dtecter les bits diffrents entre CANCON et ECANCON laide dun xor. Une fois les bits diffrents conservs, on limine ceux quon ne veut pas modifier laide dun andlw (donc on na plus quun seul andlw, cest lastuce), puis on inverse tout bit diffrent dans ECANCON laide dun autre xor. Cette mthode peut souvent tre utilise, cest pourquoi je vous lexplique. Notez donc que laccs au bon buffer est enfantin et trs souple dutilisation.
; tester si message dans le buffer ; -------------------------------bcf PIR3,RXBnIE ; acquiter flag d'interruption btfsc RXBxCON,RXFUL ; tester si buffer plein bra intcanrec2 ; oui, continuer traitement movff ecancon_lp,ECANCON ; non, restaurer ECANCON return ; et terminer traitement (FIFO vide)

Nous commenons par tester si le buffer contient bien une trame. Vous allez me dire que cest forcment le cas, mais en fait ce nest pas si vident. Dune part, un bug dans certaines rvisions de picxx80 fait que vous pouvez recevoir une interruption, dans des conditions particulires, mme si le buffer est vide. Mais, de toutes faons, procder de la sorte est pratique. En effet, vous pouvez recevoir plusieurs trames lors de la mme rception (vu le mode FIFO) : il vous suffit donc de traiter chaque trame jusqu ce que vous trouviez un buffer vide, ce qui indique que la file FIFO est vide et que donc vous avez tout trait. La sortie de cette boucle est donc le return que vous avez ci-dessus, le test nest donc pas un test inutile, le bug ventuel subsistant ny change strictement rien.
; copier message dans buffer RAM ; -----------------------------intcanrec2 movff ptrcr,FSR0H movff ptrcr+1,FSR0L movff RXBxSIDH,POSTINC0 movff RXBxSIDL,POSTINC0 movff RXBxEIDH,POSTINC0 movff RXBxEIDL,POSTINC0 movff RXBxDLC,POSTINC0 movff RXBxD0,POSTINC0 movff RXBxD1,POSTINC0 movff RXBxD2,POSTINC0 movff RXBxD3,POSTINC0 movff RXBxD4,POSTINC0 ; ; ; ; ; ; ; ; ; ; ; ; pointer sur emplacement actuel idem LSB sauvergarder SIDH (destinataire) sauvegarder SIDL (commande) sauver EIDH (cible) sauver EIDL (paramtre) sauvegarder RXB1DLC (nombre de data) sauver data 0 sauver data 1 sauver data 2 sauver data 3 sauver data 4

138

movff movff movff bcf

RXBxD5,POSTINC0 RXBxD6,POSTINC0 RXBxD7,POSTINC0 RXBxCON,RXFUL

; ; ; ;

sauver data 5 sauver data 6 sauver data 7 librer le buffer de rception

Jai utilis une succession dinstructions plutt quune boucle. On ne manque pas de place en mmoire programme, et procder de la sorte est plus rapide, cest donc tout bnfice car en gnral dans les interruptions on cherche plus gagner du temps que de la place. Une fois point sur le bon emplacement du buffer software (RAM), on recopie simplement la trame cet emplacement. Notez donc que vous avez en fait deux niveaux de buffer : un premier niveau hardware constitu de la file FIFO de rception CAN, et un second gr par software, nous permettant de stocker nos trames pour traitement ultrieur. Ceci devrait nous mettre labri dventuelles saturations. La routine se termine en librant le buffer. A ce stade, si la file contient encore dautres trames non traites, le pointeur en CANCON est automatiquement modifi en consquence.
; grer le pointeur ; ----------------movlw 0x0D ; charger incrment pointeur addwf ptrcr+1,f ; pointer sur suivant clrf WREG ; pour report addwfc ptrcr,f ; ajouter report movlw HIGH(LASTT) cpfseq ptrcr bra intcanrecloop movlw LOW(LASTT) cpfsgt ptrcr+1 bra intcanrecloop movlw HIGH(canbufin) movwf ptrcr movlw LOW(canbufin) movwf ptrcr+1 bra intcanrecloop ; ; ; ; ; ; ; ; ; ; ; dernire banque valide tester si on est dans la dernire banque non, pas de problme, tester si autre trame prsente dbut de dernire trame valide tester si dpass non, c'est bon oui, banque du dbut du buffer dans pointeur haut poids faible dbut zone buffer dans LSB pointeur tester si autre trame dans FIFO

On termine en calculant le prochain emplacement disponible dans notre buffer software, puis on retourne au dbut voir sil y a encore des trames dans la file.
;============================================================================= ;============================================================================= ; INITIALISATIONS = ;============================================================================= ;============================================================================= ;----------------------------------------------------------------------------; contient les initialisations excutes lors d'un reset ; une partie des initialisations a dj eu lieu dans Domoboot.inc ; ----------------------------------------------------------------------------

On arrive ici dans les initialisations. Souvenez-vous quune partie des initialisations a dj eu lieu au niveau du bootloader (affectation des ports, configuration Can de base, etc).
init rcall initialise ; initialisations communes (CAN et autres)

139

Cette ligne excute la procdure dinitialisation commune toutes les cartes. Nous en avond dj parl dans ltude du fichier fonctions.inc .
; valider interruptions de buffers configurs en rception ; -------------------------------------------------------lfsr FSR0,BIE0 ; pointer sur registre BIE0 movlw (BSEL0-BIE0) ; offset entre les deux registres concerns bsf INDF0,RXB0IE ; valider interruptions RXB0 bsf INDF0,RXB0IE ; valider interruptions RXB1 btfss PLUSW0,B0TXEN ; tester si B0 en mission (voir setmasfil) bsf INDF0,B0IE ; rception : on valide interruptions btfss PLUSW0,B1TXEN ; B1 en rception? bsf INDF0,B1IE ; oui, valider interruption btfss PLUSW0,B2TXEN ; B2 en rception? bsf INDF0,B2IE ; oui, valider interruption btfss PLUSW0,B3TXEN ; B3 en rception? bsf INDF0,B3IE ; oui, valider interruption btfss PLUSW0,B4TXEN ; B4 en rception? bsf INDF0,B4IE ; oui, valider interruption btfss PLUSW0,B5TXEN ; B5 en rception? bsf INDF0,B5IE ; oui, valider interruption bcf bcf bsf PIR3,RXBnIF IPR3,RXBnIP PIE3,RXBnIE ; reset flag interrupt rception CAN ; interruption rception CAN basse priorit ; valider interruptions rception CAN (+ BIE0)

En mode 2, vous avez 2 buffers de rception et 3 buffers dmission, comme en mode 0. Mais en plus de ces buffers figs , vous avez le droit 6 buffers gnriques que vous pouvez configurer au choix et individuellement en tant que buffers dmission ou buffer de rception. Cette partie de code valide les interruptions de rception Can pour tout buffer configur en mode rception. Ensuite, les interruptions de rception Can sont valides en mode bassepriorit.
; initialiser variables ; --------------------HIGH(tramesbuf) ; banque du buffer CAN ptrr ; dans pointeur trame reue MSB ptrt ; et dans pointeur trame traite MSB LOW(tramesbuf) ; adresse basse buffer CAN ptrr+1 ; dans pointeur trame reue LSB ptrt+1 ; et dans pointeur trame traite LSB

movlw movwf movwf movlw movwf movwf

Ici nous initialisons notre pointeur (16 bits) sur le prochain emplacement libre dans lequel stocker la prochaine trame reue, ainsi que le pointeur sur la prochaine trame traiter.
; lancer les interruptions ; -----------------------bsf RCON,IPEN ; mettre les priorits d'interrupt en service STARTINT ; lancer les interruptions

Les interruptions sont ensuite mises en service.

; envoyer l'identification de la carte ; ------------------------------------

140

rcall waitcible rcall cherchbuf rcall sendcarte

; attendre en fonction du n de cible ; chercher buffer libre et pointer dessus ; envoyer informations de la carte

A chaque reset ou mise sous tension, la carte sidentifie sur le bus. Cest ici que a se passe. Avant de sidentifier, la carte attend un temps proportionnel son numro de cible. Ca permet en cas de mise sous tension gnrale, ou en cas de demande broadcast via Domogest, de recevoir les identifications de cartes dans lordre croissant de numro, le tri en est facilit. Aprs lattente, on cherche un buffer dmission libre et on envoie lidentification de la carte. Attention que si vous configurez des buffers gnriques en tant que buffers dmission, la routine cherchbuf nen tiendra pas compte, vous devez donc rcrire une autre routine de recherche spcifique (avec un autre nom) pour votre programme. Il se peut que je modifie par la suite un peu le fichier fonctions.inc pour en faire une srie de macros. Dans ce cas vous pourrez choisir les fonctions intgrer rellement dans votre source.
;***************************************************************************** ;***************************************************************************** ; PROGRAMME PRINCIPAL = ;***************************************************************************** ;***************************************************************************** main clrwdt ; effacer watchdog dcfsnz cmpttrafcan,f ; dcrmenter dure restante de led trafic CAN LEDCAN_OFF ; 0, teindre LED trafic CAN

On entre ici dans notre programme principal. Selon mon habitude, son rle principal est daiguiller vers les diffrentes fonctions, selon les vnements intervenus. La premire partie se rsume dcrmenter le compteur de dure dallumage de la led de trafic. Si le compteur arrive 0, on teint la led.
; grer buffer CAN ; ---------------movf ptrt,w ; pointeur MSB trame traite cpfseq ptrr ; comparer avec MSB trame reue bra main2 ; pas identiques, traiter movf ptrt+1,w ; pointeur LSB trame traite cpfseq ptrr+1 ; comparer avec LSB trame reue main2 rcall traitbuf ; pas identique, une trame traiter bra main ; retour au dbut

Au niveau de la maquette, on se contente de tester si on a une trame traiter. Si oui, on se connecte sur la sous-routine de traitement de trame Can. Pour savoir si on a une trame traiter, il suffit de comparer les deux pointeurs. Si le pointeur sur la prochaine trame recevoir nest pas identique celui sur la prochaine trame traiter, cest quune trame qui a t reue na pas encore t traite. Simple et efficace, sauf quon peut stocker une trame de moins que ne le prvoit le buffer (prenez un papier pour vrifier et vous en convaincre). Dans notre cas a na cependant aucune importance.

141

;***************************************************************************** ;***************************************************************************** ; GESTION DES COMMANDES RECUES * ;***************************************************************************** ;***************************************************************************** ;============================================================================= ; PREPARATION DU TRAITEMENT = ;============================================================================= ;----------------------------------------------------------------------------; Traite une commande CAN mmorise dans le buffer en RAM ; la trame est pointe par ptrt (16 bits) ; la structure est la suivante : SIDH,SIDL,EIDH,EIDL,DLC,DATA0,...,DATA7 ; ; durant le traitement, FSR0 pointe sur la trame reue, le buffer d'mission ; est transfr en access bank via ECANCON, et est accessible ; par RXB0xxx. Des defines TXBx.... sont utiliss pour viter de ; s'embrouiller entre buffers de rception et d'mission ;-----------------------------------------------------------------------------

On prpare ensuite le traitement de la dite trame. Chaque trame est stocke dans le buffer de rception comme indiqu dans len-tte. Il y a 13 octets mmoriss par trame.
traitbuf ; pointer sur la trame reue ; -------------------------movff ptrt,FSR0H ; initialiser pointeur MSB movff ptrt+1,FSR0L ; et LSB

On commence donc par pointer sur la trame traiter. Ca seffectue simplement en transfrant le pointeur sur la prochaine trame traiter dans le registre dindirection FSR0.
; sauver le contexte ; -----------------POSTINC0,destrec ; sauver destinataire reu POSTINC0,w ; charger commande reue B'11101111' ; liminer SSR cmdrec ; sauver commande reue POSTINC0,ciblerec ; sauver n carte reu POSTINC0,parrec ; sauver paramtre reu

movff movf andlw movwf movff movff

Puis on sauve lidentificateur, sous forme de 4 variables spares, avec un nom explicite.
; prparer mission de la rponse ; ------------------------------rcall cherchbuf ; chercher un buffer mission libre

En gnral les cartes rpondent une commande reue, pour rpondre il faut un buffer de rception. On cherche donc un buffer libre, et ds lors, RXB0 pointe en ralit sur le buffer slectionn.
; grer le pointeur ; ----------------movlw 0x0D ; charger incrment pointeur addwf ptrt+1,f ; pointer sur suivant clrf WREG ; pour report addwfc ptrt,f ; ajouter report movlw HIGH(LASTT) ; dernire banque valide

142

cpfseq ptrt bra traitbuf1 movlw LOW(LASTT) cpfsgt ptrt+1 bra traitbuf1 movlw HIGH(tramesbuf) movwf ptrt movlw LOW(tramesbuf) movwf ptrt+1

; ; ; ; ; ; ; ; ;

tester si on est dans la dernire banque non, OK dernier emplacement de dbut de trame possible tester si dpass non, OK oui, banque du dbut du buffer dans pointeur MSB offset du dbut du buffer dans pointeur LSB

Pour faciliter la fin du traitement, on va dj prparer le pointeur sur la prochaine trame traiter pour quil pointe sur la suivante. Pour ce faire, il suffit dajouter 13 octets la valeur pointe (sur 16 bits). Si on dborde de la zone attribue, on reprend au dbut, il sagit dun buffer circulaire.
; tester type de commandes ; -----------------------traitbuf1 movlw CMD_COMM cpfsgt cmdrec bra commcb ; pour commandes communes ; compararer avec commande communes ; commande commune, traiter

On spare ensuite le traitement ren deux possibilits. Soit il sagit dune commande commune, auquel cas on saute un emplacement spcifique, contenant notre fichier de traitement des commandes communes. Soit il sagit dune autre commande, et on poursuit le traitement.
;============================================================================= ;============================================================================= ; TRAITER COMMANDES SPECIFIQUES AVEC BROADCAST = ;============================================================================= ;============================================================================= ;============================================================================= ; TRAITER COMMANDE CMD_TEST1 = ;============================================================================= commsb0 movlw DESTI ; charger identit de la carte cpfseq destrec ; comparer avec type de destinataire bra tramesgen ; pas le bon, traiter commandes gnrales ; tester la commande ; -----------------commsbok TESTCMD CMD_TEST1 bra commsb1 TESTDAT 0 ; tester si commande 1 ; non, voir commande suivante ; tester si 0 octet de data

; suite du traitement

On commence par tester si la commande est bien explicitement destine cette carte. Si ce nest pas le cas, on traite les trames interceptes plus loin. Si cest le cas, on teste la commande, et si cest la bonne, on teste sa validit. Sinon, on teste si a correpond la commande suivante, et ainsi de suite.

143

;============================================================================= ; AJOUTER ICI COMMANDE SPECIFIQUE AVEC BROADCAST = ;============================================================================= commsb1

On va donc simplement ici sauter de commandes en commandes jusqu tomber sur la bonne. Une fois fait, on traite et on rpond, le pointeur dmission est dj prpar.
;============================================================================= ;============================================================================= ; TRAITER COMMANDES SPECIFIQUES SANS BROADCAST = ;============================================================================= ;============================================================================= commsc infsnz ciblerec,w ; charger cible +1 bra senderrG13 ; 255 = broadcast = illgal

Une fois passes en revues toutes nos commandes acceptant le mode broadcast, on teste si la commande reue ltait en mode broadcast. Si oui, vu quelles ont toutes t testes, cest que ce mode est illgal, et on renvoie une erreur G13 : commande illgale en mode broadcast.
;============================================================================= ; TRAITER COMMANDE CMD_TEST2 = ;============================================================================= commsc0 ; tester la commande ; -----------------TESTCMD CMD_TEST2 ; tester si commande 2 bra commsc1 ; non, voir commande suivante TESTDAT 0 ; tester si 0 octet de data ; suite du traitement

On saute alors de commande en commande, pour toute commande non broadcast, jusqu puisement de toutes les commandes reconnues.
;============================================================================= ; AJOUTER ICI COMMANDE SPECIFIQUE SANS BROADCAST = ;============================================================================= commsc1 bra senderrG16 ; commande invalide

Si la commande na pas t bloque par la combinaison masque/filtre et quelle ne correspond aucune commande existente, alors on renvoie lerreur G16.
;============================================================================= ; TRAMES GENERALES NON DESTINEES A CETTE CARTE = ;============================================================================= ;----------------------------------------------------------------------------; Placer ici les commandes traiter autres que celles destines cette carte ;----------------------------------------------------------------------------tramesgen return ; ne rien faire ( modifier selon application)

Ici nous traiterons toute commande intercepte par la carte et non destine cette carte en particulier. Cest le cas par exemple si une carte a besoin de lheure. Ou encore, par exemple,

144

nous avons la carte sensitive qui peut allumer ses leds tmoin en fonction des valeurs dclairages reues des cartes gradateur, et qui donc ne lui sont pas spcialement destines.
#include <CCommunes.inc> ; placer ici les commandes communes

On inclut notre fichier ici, ce qui place en fait ici le traitement de nos commandes communes. Notez quil ne faut pas toujours mettre un fichier include au dbut, il faut le mettre lendroit o vous auriez copi/coll le code quil contient. Cest important de le comprendre.
;***************************************************************************** ;***************************************************************************** ; SOUS-ROUTINES * ;***************************************************************************** ;***************************************************************************** #include <Fonctions.inc> ; fonctions communes toutes les cartes

Ici, vous placerez toutes les sous-routines ncessaires, sachant que vous disposez dj des routines du fichier fonctions.inc .
;***************************************************************************** ;***************************************************************************** ; EMISSION DE TRAMES CAN * ;***************************************************************************** ;***************************************************************************** ;============================================================================= ; ENVOI DE LA ZONE UTILISATEUR = ;============================================================================= ;----------------------------------------------------------------------------; CC_ZONE : envoi des 8 octets de la zone utilisateur ; octets de data : 8 ; D0/D7 : 8 octets dfinis par l'utilisateur ;----------------------------------------------------------------------------sendzone ; initialiser trame de rponse ; ----------------------------movlw CC_ZONE ; commande commune movwf TXBxEIDL ; dans EIDL movlw ZONE_EEP ; emplacement informations en eeprom sendzonea movwf EEADR ; placer dans registre d'adresse movlw 0x08 movwf TXBxDLC movwf local01 ; 8 octets de data ; dans DLC ; et dans compteur d'octets

lfsr sendzoneb call readeep movwf POSTINC0 decfsz local01,f bra sendzoneb goto sendtramecom

; placer les octets de data ; ------------------------FSR0,TXBxD0 ; pointer sur premier octet de data buffer mission ; ; ; ; ; lire octet sauver dans trame CAN dcrmenter compteur de boucles pas fini, suivant envoyer trame commande commune

145

;============================================================================= ; ENVOI DU NOM DE LA CARTE = ;============================================================================= ;----------------------------------------------------------------------------; CC_NAMEC : envoi du nom de la carte ; octets de data : 8 ; D0/D7 : 8 octets du nom de la carte ;----------------------------------------------------------------------------sendnamec ; initialiser trame de rponse ; ----------------------------movlw CC_NAMEC ; commande commune movwf TXBxEIDL ; dans EIDL movlw NAMEC_EEP ; emplacement informations en eeprom bra sendzonea ; mme traitement que pour commande prcdente

Vous placerez ici toutes les trames envoyes par votre carte. Jai plac titre dexemple lenvoi de la zone utilisateur, commune toutes les cartes, ainsi que lenvoi du nom de la carte. De toutes faons, ces commandes sont communes toutes les cartes (attention, commandes communes mises, et pas reues, do leur absence du fichier ccommunes.inc).
;***************************************************************************** ;***************************************************************************** ; SOUS-ROUTINES DIVERSES * ;***************************************************************************** ;***************************************************************************** ;============================================================================= ; PLACER LES FILTRES ET LES MASQUES = ;============================================================================= ;----------------------------------------------------------------------------; Place les masques et les filtres pour la rception CAN ; On accepte toutes les commandes dont ce type de carte est le destinataire ; On accepte galement toute trame gnrale dont on pourrait avoir besoin ; On est en mode 2 (FIFO) et on peut donc utiliser tous les filtres et masques ; Le modue CAN doit dj tre en mode configuration. ; Plutt que l'optimisation, la facilit de relecture a t mise en avant ;-----------------------------------------------------------------------------

Nous allons maintenant configurer notre filtrage Can. Tout dabord, attention, il y a dautres registres utiliss, mais vu que je les utilise avec leur valeur par dfaut la mise sous tension, je ny accde pas. Pour des configurations plus particulires, voyez ds lors le rle de ces registres.
setmasfil POINTRX0 lfsr FSR0,BSEL0 movlw B'00000000' movwf INDF0 ; ; ; ; ; ; ; pas d'indirection spcifique pointer sur registre concern Slection des buffers BxCON en rception (0) ou en mission (1) b2 = buffer 0, b7 = buffer 5 si on met en Tx, c'est imprativement de 5 vers 0 (impos par FIFO)

La premire chose est de dterminer si les buffers gnriques seront utiliss en tant que buffers dmission ou de rception. En gnral pour Domocan mieux vaudra affecter le maximum de registres pour la rception, surtout en mode FIFO, o lensemble des registres de rception forme une file dattente.

146

Pour rappel, FIFO signifie First In First Out , soit Premier entr, premier sorti . Ca correspond la file dattente dans un magasin, le premier arriv tant le premier servi. Cest pourquoi on parle de file . A contrario, LIFO signifie Last In First Out , ou Dernier entr, premier sorti . Ca correspond une pile dassiette dans une armoire, o la dernire avoir t place sur le tas sera la premire dont on se servira. Cest pourquoi on parle de pile . Il est rappel que la file FIFO est constitue des registres RXB0, RXB0, et tout registre gnrique Bx configur en rception jusqu trouver dans lordre croissant le premier registre gnrique configur en mission. Ds lors, si vous utilisez certains registres gnriques comme registres dmission, commencez par les dernier (B5) sous peine de perdre lutilisation des registres de rception restants pour la file.
; choisir les filtres en service ; -----------------------------FSR0,RXFCON0 ; pointer sur contrle filtre 0 B'00000011' ; b7 = filtre 7, b0 = filtre 0 POSTINC0 ; filtres 0 et 1 en service B'00000000' ; b7 = filtre 15, b0 = filtre 8 POSTINC0 ; dans registre de contrle

lfsr movlw movwf movlw movwf

En mode 2 nous avons le droit un maximum de 16 filtres. Pour chacun nous pouvons dterminer sil est utilis ou non. Cest ce que fait cette routine. Il y a un bit par filtre (1 = en service). RXFCON0 et RXFCON1 contiennent les 16 bits des 16 filtres.
;----------------------------------------------------------------------------; Faire correspondre les filtres et les masques. ; La correspondance est tablie pour chaque filtre avec 2 bits: ; 1 1 = pas de masque ; 1 0 = filtre 15 (comme masque) ; 0 1 = masque 1 ; 0 0 = masque 0 ; Chaque registre concerne 4 filtres (2 bits par filtre) ; Par exemple, MSEL0 concerne ; Filtre 3 filtre 2 filtre 1 filtre 0 ; b7 b6 b5 b4 b3 b2 b1 b0 ;----------------------------------------------------------------------------lfsr movlw movwf movlw movwf movlw movwf movlw movwf FSR0,MSEL0 B'11110000' POSTINC0 B'11111111' POSTINC0 B'11111111' POSTINC0 B'11111111' POSTINC0 ; registre de correspondance 0 ; ; ; ; ; ; ; ; filtres 0 et dans MSEL0 associations dans MSEL1 associations dans MSEL2 associations dans MSEL3 1 associs masque 0 filtres 7 4 filtres 11 8 filtres 15 12

En mode 2, chaque filtre peut tre associ un masque dtermin. On peut aussi nassocier le filtre aucun masque (dans ce cas la trame doit corrrepondre). Le filtre 15 peut tre utilis comme masque supplmentaire, ce qui explique les diffrentes possibilits. Cette routine affecte chaque filtre utilis au masque que lutilisateur a prvu. Plusieurs filtres peuvent videmment tre associs au mme masque, la rciproque nest pas possible.

147

;----------------------------------------------------------------------------; Commandes destination des cartes du mme type ; Filtres 0 et 1 lis au masque 0 ; Le filtre 0 ne laisse passer que les commandes destines cette carte-ci ; Le filtre 1 ne laisse passer que les commandes broadcast ;----------------------------------------------------------------------------; placer masque 0 ; --------------lfsr FSR0,RXM0SIDH ; pointer sur masque 0 setf POSTINC0 ; un seul type de destinataire accept movlw B'00001000' ; toutes les commandes (extended) acceptes movwf POSTINC0 ; dans masque SIDL setf POSTINC0 ; une seule cible accepte clrf POSTINC0 ; tous les paramtres accepts

Le masque 0 est utilis par dfaut dans notre fichier pour naccepter quun seul type de destinataire, toutes les commandes, et une seule cible. Donc, est accepte toute trame dont le destinataire et la cible correspondent celle dfinie dans le filtre correspondant
; placer filtre 0 ; --------------RXF0SIDH ; pointer filtre 0 DESTI ; Type de destinataire de cette carte POSTINC0 ; seul type accept B'00001000' ; toute commande en mode extended POSTINC0 ; en fait, seul un bit est test (masque) cible,POSTINC0 ; uniquement pour cette carte prcise POSTINC0 ; EIDL sans importance

lfsr movlw movwf movlw movwf movff clrf

Ce filtre est associ au masque 0. De ce fait, seules les valeurs affectes SIDH (destinataire) et EIDH (cible) importent, les autres champs sont ignors. Etant donn quon place ici comme destinataire le type de cette carte, et comme numro le numro de cette carte, seront acceptes toutes trames destination explicite de cette carte-ci
; placer filtre 1 ; --------------DESTI ; Type de destinataire de cette carte POSTINC0 ; seul type accept B'00001000' ; toute commande en mode extended POSTINC0 ; en fait, seul un bit est test (masque) POSTINC0 ; Accepter commandes broadcast POSTINC0 ; EIDL sans importance

movlw movwf movlw movwf setf clrf

Le filtre 1 est galement associ au masque 0, les mmes remarques sont dapplication. Etant donn quon place la valeur 0xFF dans le champ cible, seront acceptes les trames broadcast destination de ce type de carte-ci.
;----------------------------------------------------------------------------; A complter ventuellement en fonction des applications ; Le filtre 15 peut tre au choix un filtre ou un masque ;----------------------------------------------------------------------------return ; et retour

148

Vous placerez ici les combinaisons masque/filtre spcifiques lapplication. Il reste 14 filtres et 1 masque, ou 13 filtres et 2 masques, selon votre choix.
;***************************************************************************** ;***************************************************************************** ; ZONE NON ECRASEE PAR LE BOOTLOADER * ;***************************************************************************** ;***************************************************************************** ;----------------------------------------------------------------------------; Doit commencer par un multiple de .64 ; Placer suffisamment loin pour que ce ne soit pas cras par une future ; augmentation de la taille du programme ;----------------------------------------------------------------------------Org 0x2000 ZPR ; zone protge DB 01,02 ; titre d'exemple END ; fin de programme

Cette zone pourra contenir des donnes ne pouvant pas tre crases par le bootloader. Assurez-vous de placer le ORG assez loin de votre programme principal, pour laisser celui-ci la place pour stendre en cas de mises jour. Ladresse de la zone peut tre modifie en fonction du logiciel de la carte. Le contenu de la zone dpend donc du logiciel de la carte, il ny a rien dimpos ce niveau, except que ltiquette de dbut doit tre ZPR , et que ladresse prcise par le ORG doit tre un multiple de .64 (0x40), ceci pour des raisons de procdure deffacement de la flash spcifique au type de pic choisi.

8.9 Astuce de programmation Vous aurez remarqu quil marrive dutiliser des routines qui se terminent par bra au lieu de se terminer par return . Ca peut sembler compltement illogique. En fait, si vous rflchissez, et que vous imaginez une sous-routine X appele par la sous-routine Y, vous constaterez qucrire :
sousroutineY

. .
rcall sous-routine X return

Fonctionne au final de faon identique :

sousroutineY

. .
bra sous-routine X

Mais en plus performant. Ceci pour autant quil ny ait aucun saut dans la sous-routine qui permette dexcuter le return sans le rcall .

149

Ceci, par exemple :

sousroutineY

. .
btfss STATUS,Z rcall sous-routine X return

Ne peut pas tre remplac par

sousroutineY

. .
btfss STATUS,Z bra sous-routine X

Car lappel et le return de la fonction Y ne sont pas indissociables dans ce cas. La mthode peut tre extrapole si la sous-routine X peut elle-mme appeler une autre sous-routine. Par exemple, si vous avez :
main . . . . . . rcall . . . . . sousroutineX .

; appel de la sous-routine X

sousroutineX . . . . . . . . rcall sousroutineY return sousroutineY . . . . . . . . rcall sousroutineZ return sousroutineZ . . . . . . . . return

; appel de la sous-routine Y ; retour de sousroutineX

; appel de la sous-routine Z ; retour de la sousroutineY

; fin de la sousroutineZ

Et bien, a fonctionnera de faon strictement identique avec :

main . . . . . . . . rcall sousroutineX sousroutineX

; appel de la sous-routine X

150

. . . . . . . . bra sousroutineY sousroutineY . . . . . . . . bra sousroutineZ sousroutineZ . . . . . . . . return

; appel de la sous-routine Y

; appel de la sous-routine Z

; retour au main

Pas convaincu ? Essayez de suivre le trajet du programme dans les deux cas. Seule diffrence, cest plus rapide et a consomme moins de pile dans le second cas. Par contre, il faut tre beaucoup plus attentif dans la structure du programme, afin de ne pas se tromper dans la gestion des appels et des retours. Cest pourquoi jai vit de vous parler de ce genre de mthodes dans les cours de dbut dapprentissage. Les puristes spcialistes de la programmation structure vont hurler, mais lorsquon utilise un microcontroleur aux ressources limites, il faut parfois tricher un peu avec les rgles. Cest un des inconvnients des optimisations . Retenez quon peut en gnral remplacer un appel de sous-routine directement suivi par une instruction de retour par un simple saut vers la sous-routine. Cest un petit truc, mais si vous lutilisez, soyez trs prudent et surtout commentez votre source.

151

Notes :

152

A. Annexes
A.1 Tableau des types de carte Les types de carte vont tre (je lespre), en continuelle volution. Chaque cration dune nouvelle carte saccompagnera ainsi dune mise jour de ce tableau. Pour rappel, le type de carte est reprsent par les 8 premiers bits de lID des trames. La valeur est donne en hexadcimal dans le tableau. Pour linstant, les types reconnus sont :

Val 0 1 2 / 1F 20 21 / 4F 50 51 / 5F 60 61 62 / DF E0 / FC FD FE / FF

Type Rserv pour trame systme prioritaire urgente Dest_Info1 Trame dinformation priorit 1 Rservs pour trames gnrales zone haute priorit Dest_ClockM Horloge mre du systme Pour futures cartes dapplication Dest_Grad16 Carte 16 sorties gradateur Pour futures cartes dapplication Dest_In16 Carte 16 entres en tout ou rien avec fonctions supplmentaires Dest_InSens Carte 16 touches sensitives avec fonctions supplmentaires Pour futures cartes dapplication Rservs pour trames gnrales zone basse priorit Dest_Admin Trame dadministration ILLEGAL 7 premiers bits 1, illgal

Nom

La premire colonne indique la valeur des 8 bits de lID concernant le type de destinataire. Cette valeur ne vous sera utile que si vous crez vos propres logiciels, ou si vous entrez des trames Can manuellement partir de Domogest. La seconde contient le nom symbolique du destinataire, tel que vous le rencontrerez dans le logiciel Domogest. Dans ce logiciel, ce nom nintervient cependant que dans la ralisation du fichier source, au niveau de lutilisateur les noms sont indiqus en clair. La dernire colonne explique en quoi consiste le destinataire.

A.2 Tableau des erreurs reconnues Ce tableau reprend toutes les erreurs possibles sur le rseau Domocan. Il est donc susceptible dvolutions en fonction des nouveaux types de cartes que nous construirons.

153

Nom Err_G1 Err_G2 Err_G3 Err_G4 Err_G5 Err_G6 Err_G7 Err_G8 Err_G9 Err_G10 Err_G11 Err_G12 Err_G13 Err_G14 Err_G15 Err_G16 Err_H1 Err_S1

Num 0x80 0x81 0x82 0x83 0x84 0x85 0x86 0x87 0x88 0x89 0x8A 0x8B 0x8C 0x8D 0x8E 0x8F 0x90 0x98

Erreurs gnrales du systme Domocan Descriptif Nombre de data incorrect Valeur de data invalide Erreur d'criture eeprom Erreur du paramtre de lID Erreur dcriture en mmoire flash Pointeur flash non multiple de 8 Pointeur flash dans zone protge Pointeur flash hors limite PIC Pointeur flash non valide Tentative daccs bootloader en zone eeprom protge Erreur dcriture en eeprom externe (si elle existe) Erreur gnrale rserve pour utilisation future Commande illgale en mode broadcast Commande commune invalide en mode bootloader Commande commune invalide en mode normal Commande invalide pour la carte Horloge mre pas lheure Carte sensitive pas en mode superviseur

Toutes les erreurs commenant par ERR_G sont des erreurs gnrales. Ces erreurs sont donc susceptibles dtre mises par nimporte quelle carte du bus. A loppos, les autres erreurs (exemple Err_H1) nexistent que pour une ou plusieurs cartes bien spcifiques. Lerreur H1 indique que la carte horloge nest pas lheure, ce qui na aucun sens pour une carte gradateur, par exemple. La colonne Nom reprsente le nom symbolique de lerreur, dont le numro hexadcimal est donn dans la colonne Num . Fort logiquement, vous trouvez un descriptif rsum de lerreur dans la colonne descriptif . Vous avez des informations complmentaires sur les erreurs gnrales dans cet ouvrage, alors que les informations complmentaires sur les erreurs particulires sont donnes dans les ouvrages relatifs aux cartes concernes.

A.3 Les fichiers Contrairement la premire gnration de Domocan, lutilisation de Domogest sur plusieurs PC simultanment ne pose plus le moindre problme. Il nest plus ncessaire de faire le backup des fichiers contenus dans le rpertoire de Domogest, car toutes les informations utiles se trouvent maintenant sur les cartes ellesmmes. Domogest est donc parfaitement en mesure de reconstituer toutes les informations par

154

interrogation directe de lensemble des cartes, via sa fonction de cartographie (voir manuel de Domogest). Le rle des diffrents fichiers et leur structure est expliqu dans le fichier source de Domogest, principalement dans le module fichiers.bas , pour ceux que a intresse. ATTENTION : Les formats de certains fichiers varient avec les versions de programme. Ceci explique la prsence dune valeur de validit, destine viter quun ancien fichier de configuration non effac la rinstallation ne provoque des problmes dans le programme, du fait de la modification de lemplacement des donnes.

155

Notes :

156

9. Utilisation du prsent document

Communiquez lauteur (avec politesse) toute erreur constate afin que la mise jour puisse tre effectue dans lintrt de tous, si possible par mail. Pour des raisons de facilit de maintenance, jai dcid que cet ouvrage serait disponible uniquement sur mon site : www.abcelectronique.com/bigonoff ou www.bigonoff.org Aussi, si vous trouvez celui-ci ailleurs, merci de men avertir. Bien entendu, jautorise (et jencourage) les webmasters placer un lien vers le site, inutile den faire la demande. Je ferai de mme en retour si la requte men est faite. Ainsi, jespre toucher le maximum dutilisateurs. Le prsent ouvrage peut tre utilis par tous, la modification et la distribution sont interdites sans le consentement crit de lauteur. Tous les droits sur le contenu de cet ouvrage, et sur les programmes qui laccompagnent demeurent proprit de lauteur. Lauteur ne pourra tre tenu pour responsable daucune consquence directe ou indirecte rsultant de la lecture et/ou de lapplication de louvrage, des programmes, schmas, typons ou du matriel (liste non exhaustive). Si vous travaillez sur la tension secteur, assurez-vous que vous avez les comptences ncessaires, et soyez prudents. Comme pour toute ralisation personnelle, limposition de ltiquette CE nest pas obligatoire. Ceci ne vous dispense pas de devoir respecter la lgislation de votre pays au niveau des prescriptions lectriques (RGIE par exemple), ainsi que des prescriptions concernant la compatibilit E.M. Il vous appartient de vrifier que votre systme Domocan rpond aux rglementations en vigueur. Toute utilisation commerciale est interdite sans le consentement crit de lauteur. Tout extrait ou citation dans un but dexemple doit tre accompagn de la rfrence de louvrage. Si vous avez des applications personnelles, nhsitez pas les faire partager par tous. Pour ce faire, vous pouvez me les envoyer. Merci au webmaster de www.abcelectronique.com, pour son hbergement gratuit. Rvision bta 1 termine le 25/10/2003. Rvision bta 2 le : 06/11/2003 : Ajout dune note importante page 10, modifications du fichier domoboot .inc, passage la version 1.01 Rvision bta 3 le 12/11/2003 : Ajout du numro de rseau aux trames de type signal

157

Rvision bta 4 le 24/11/2003 : Ajout dun paramtre complmentaire dans EIDL, restriction du numro de rseau 4 bits. Modification des numros de commandes pour regrouper ensemble les trames mises et les trames reues. Rvision 1 le 09/06/04 : Modification des fichiers sources, ajout de nouvelles commandes Rvision 2 le 28/06/04 : Modification des fichiers pour prise en compte dun bug dans le pic lorsque BSR pointe sur la banque 15. Rvision 3 le 10/10/04 : Ajout dquivalents du MCP2551, correction dun bug dans le fichier base, correction dun bug dans le fichier bootloader, quelques modifications du fichier bootloader. Rvision 4 le 30/12/04 : Ajout dune nouvelle commande gnrale (Cmd_WModeC), ajout de bits supplmentaires la commande Cmd_Softw. Prise en charge de la carte horloge mre, prise en compte de bugs dcouverts par Microchip. Rvision 5 le 11/01/05 : Modifications suite la dcouverte dun nouveau bug dans les pics par Microchip. Rvision 6 le 19/03/06 : Rvision totale suite la refonte complte du systme Domocan. Rvision 7 le 15/03/08 : Modifications majeures suite lutilisation des PIC de gnration 18Fxx80.

Ralisation : Bigonoff Site : http://www.abcelectronique.com/bigonoff ou www.bigonoff.org Email : bigocours@hotmail.com ou claude@bigonoff.org

HT TH HT TH HT TH HT TH

158