Électronique et domotique libre - partie 2 : interfaces pour la programmation et l'identification
Le module que nous avons créé dans l'article précédent nous fourni une base pour le développement avec le micro-contrôleur LPC1224, mais son utilisation nécessite de disposer d'une interface de programmation externe, ce qui est parfois casse pied, et nécessite plein de fils, câbles, alimentation, bref un beau bordel sur la table. Noua ajouterons aussi un élément spécifique aux modules pour le projet DomoTab, à savoir une eeprom qui servira à l'identification du module sur le système, et pourra stocker des données utilisateur le reste du temps. Chaque élément pourra être mis sur une feuille séparée pour permettre le partage avec d'autres schémas.
Paru dans le numéro 8 du magazine Open Silicium.
Programmation facile
Pour faciliter l'utilisation de notre module de développement nous avons prévu d'intégrer un convertisseur "USB-to-UART" qui nous apportera à la fois simplicité de connexion avec le PC de développement et source d'énergie. Notre micro-contrôleur se programme avec une simple liaison série, j'ai donc sélectionné le composant FTDI le plus simple possible parmi ceux proposant une interface série : le FT230X. C'est la solution avec l'empreinte la plus petite et le coût le plus bas que j'ai trouvé (2.20€ à l'unité chez Farnell), et elle ne nécessite aucune programmation pour être fonctionnelle.
Une fois le composant FT230X ajouté à notre bibliothèque (attention, l'ordre des pattes n'est pas le même pour les deux types de boîtier, nous utiliserons le boîtier "SSOP", qui est un peu plus gros, mais plus simple à souder), nous pouvons l'ajouter à notre nouvelle feuille.
Pour créer le schéma autour du FT230X je me suis basé sur le schéma d'exemple proposé au chapitre "6.1 USB Bus Powered Configuration" de sa documentation, avec plusieurs modifications :
Remplacez le condensateur de 4.7uF par un condensateur de 10uF pour limiter le nombre de références de composants.
Supprimez le condensateur de 10nF entre les pins 1 et 4 du connecteur USB, ainsi que les résistances de 27 Ohms et les condensateurs de 47pF. Ils servent à filtrer les parasites lors de l'utilisation d'un (très) mauvais câble USB. La perle de ferrite (Ferrite Bead, boîtier "0603") est déjà la pour filtrer ceux de l'alimentation, et le signal utilise une paire différentielle, très peu sensible aux parasites.
La dernière modification concerne l'ajout d'un connecteur micro-USB type AB (MUSB dans la bibliothèque domotab) en plus du connecteur USB type A mâle. Un seul des connecteurs sera soudé, mais les deux options seront possibles. La patte "ID" du connecteur micro-USB doit être laissée non connectée (nous ne l'utilisons pas).
Nous devons maintenant relier le tout au reste du schéma. Pour l'alimentation il faut faire attention, car celle qui provient du connecteur USB est en +5V, et notre module fonctionne en +3.3V. Le FT230X fourni une alimentation de 3.3V stabilisée sur sa patte 10. L'alimentation VCC du FT230X est à relier seulement à la broche V+ du connecteur USB (en passant par la perle de ferrite, comme indiqué sur le schéma d'exemple), et surtout pas à notre alimentation +3.3V.
Occupons nous ensuite des LEDs pour indiquer l'activité de la liaison série, puisque le FT230X a deux pattes prévues à cet effet dans sa configuration par défaut. Cette fois, nous utiliserons des LEDS simples en boîtier "0603". Attention, la documentation indique que le signal est actif bas, c'est à dire que les pattes sont mises "à la masse" lorsqu'il y a de l'activité sur la liaison série, il faut donc relier les bornes '-' (cathodes) des LEDs aux pattes du FT230X, et les bornes '+' (anodes) à la tension d'alimentation "+3.3V" en prenant bien soin d'intercaler des résistances (270 ohms en boîtiers "0603") pour limiter le courant dans les LEDs.
Et enfin, pour les signaux qui nous intéressent le plus, à savoir "RxD" et "TxD", j'ai ajouté des jumpers (au pas de 2mm, JP3X1 dans la bibliothèque domotab) pour permettre de croiser les lignes "Rx" et "Tx". Cela permettra de choisir entre notre micro-contrôleur et la liaison série qui vient du connecteur UEXT.
Vos papiers !
Pour permettre d'identifier les modules connectés sur un DomoTab ou un DTPlug, et surtout sur quel connecteur UEXT ils sont connectés (le DomoTab et le DTPlug disposent de 4 connecteurs UEXT chacun) j'ai prévu un mécanisme d'identification par lecture d'une eeprom I2C, activée par le chip select du SPI de chaque module. Cette eeprom aura aussi la possibilité de stocker le code spécifique pour le module, qui sera lu par le DTPlug et évitera ainsi de devoir mettre à jour le DTPlug lorsque l'on change les modules UEXT utilisés.
Puisque la sélection des eeprom des modules se fait en fonction du chip select, toutes les eeprom d'identification des modules devraient avoir la même adresse. Cependant les eeprom de microchip en boîtier MSOP n'utilisent pas toutes tous les bits d'adresse pour coder l'adresse du composant. Les eeprom de moins de 2Ko se servent des trois bits de poids faible pour coder l'adresse de la page, et ignorent donc l'état des pattes d'adresse (A0, A1 et A2), répondant sur 8 adresses différentes (voir encart). Inversement ces pattes d'adresse sont actives pour les eeprom de plus de 2Ko, et celles-ci décodent l'offset de lecture/écriture sur deux octets, ce qui nous oblige à trouver un mécanisme pour différentier la taille des eeprom. Pour ce faire, la patte d'adresse “A2” sera systématiquement à “1” (car en fait, seule A2 est active pour les boîtiers MSOP), ce qui sélectionnera l'adresse “10101xx0/1 (0xA8/0xA9)” et empêchera les “grosses” eeprom de répondre à l'adresse “10100000/1 (0xA0/0xA1)”, permettant ainsi d'identifier les “petites” eeprom et de sélectionner le nombre d'octets pour coder l'offset de lecture/écriture.
Toujours pour minimiser la taille du circuit j'ai sélectionné les eeprom Microchip en boîtiers MSOP-8, qui occupent 3mm x 5mm, et permettent de disposer de 1K octets pour 40 centimes ou 16Ko pour 1 euro ce qui est très raisonnable.
- --
- Encart : Adressage I2C et identification des modules
- La majorité des composants I2C disposent de pattes “d'adresse” qui servent à coder les bits de poids faible de l'adresse du composant I2C. Cela permet de mettre plusieurs composants identiques sur un même bus I2C, ou d'éviter les conflits d'adresse entre deux composants différents, puisque l'adresse d'un composant I2C est sur 7 bits, ce qui limiterait drastiquement le nombre de composants existants (le huitième bit est le bit de lecture/écriture).
- Cependant certains composants ne disposent pas de ces pattes, ou les ignorent pour certains boîtiers, et répondent donc sur plusieurs adresses.
- --
L'eeprom est disponible dans la bibliothèque DomoTab sous le nom "EEPROM_ID". Reliez les pattes de sélection d'adresse "A0" et "A1" à la masse avec la patte "GND", et la patte "A2" à l'alimentation "+3.3V" avec la patte d'alimentation "VCC" (voir encart). La patte "SDA" qui correspond au signal de données du bus I2C est reliées au label global correspondant. Il nous reste deux pattes non connectées, "WP" et "SCL".
"WP" correspond au signal "Write Protect", qui empêche les accès en écriture s'il est mis à "1" (relié à "VCC" ou "+3.3V" à travers une résistance de "Pull-Up"). Pour que l'eeprom n'en devienne pas inutile il est important de prévoir aussi un mécanisme pour permettre son écriture. Un jumper permettra d'annuler la protection en écriture facilement chaque fois que l'on en aura besoin (intéressant pour un module de développement), mais on peut vouloir un mécanisme de protection plus "permanent", et une résistance "0 ohms" (un fil, de la soudure, ...) que l'on pourra placer pour la programmation de l'eeprom puis enlever ensuite sera toute indiquée. Il sera bien entendu toujours simple de contourner cette protection en ressoudant cette résistance. Il est bien entendu possible de ne pas vouloir activer ce mécanisme, il suffit alors de relier la patte "WP" à la masse de façon définitive, ce qui prend moins de place et coûte moins cher :)
La dernière patte de notre eeprom, "SCL", est le signal d'horloge du bus I2C. Pour une utilisation classique, comme notre capteur de température, il suffirait de connecter cette patte au label correspondant. Pour l'utilisation spécifique du DomoTab, nous avons besoin d'une porte logique qui permettra d'inhiber le signal d'horloge si le module n'est pas sélectionné par le biais du signal "Chip Select" du bus SPI du connecteur UEXT. En effet, sur le DomoTab et le DTPlug le signal "Chip Select" peut être commandé indépendamment, cependant ce signal est actif niveau bas, ce qui nous empêche de simplement utiliser une porte logique "Et". Il nous faut au préalable inverser ce signal avec une porte "Non". Deux portes logiques pourraient nous imposer deux composants, mais c'est sans compter sur les portes multi-fonctions configurables. Derrière ce nom compliqué se cache une porte de la série 74xx (comme les portes plus classiques, "Et", "Ou", "Non-Et " ("Nand"), "Non-Ou" ("Nor"), ...) mais qui a trois entrées au lieu de deux, et comporte 6 portes logiques en interne. Bien entendu il en existe plusieurs différentes, fournissant une table de vérité différente, et j'ai donc sélectionné la porte "58" en configuration "2-Input AND Gate with A Input Inverted". Le signal "Chip Select" sera sur l'entrée A (patte 1 - "In1"), et l'horloge du bus I2C sur l'entrée B (patte 6 - "In2"), tandis que la troisième entrée "In0" (patte 3) sera reliée à la masse pour obtenir un "0" logique. Le composant est disponible dans la bibliothèque domotab sous le nom 74xx1G58, et correspondra à la référence 74LVC1G58DW-7 de Diodes-Inc (boîtier SOT363, un peu petit, mais encore utilisable).
Un point technique
J'ai volontairement rendu invisibles les pattes correspondant à la masse et à l'alimentation de la porte logique dans la bibliothèque domotab pour aborder un dernier point concernant l'éditeur de schémas de KiCad (Eeschema), qui concerne les composants "multipart".
Les composants "multipart" servent dans deux cas de figure. Le premier cas correspond aux composants qui ont trop de pattes pour tenir sur une seule feuille de schéma, et qui sont donc découpés en blocs, le plus souvent avec les signaux regroupés par fonction, comme par exemple pour les gros micro-contrôleurs ou les processeurs, comme vous pouvez le voir sur les schémas des beagleboard et pandaboard. Dans ce cas je n'ai jamais vu de pattes masquées.
Le second cas est celui des composants regroupant plusieurs portes logiques identiques, et qui ont dans ce cas plusieurs blocs identiques fonctionnellement, mais utilisant des pattes différentes. Dans ce cas, les pattes d'alimentation, qui sont communes à tous les blocs, et souvent au nombre de deux pour tout le composant, ne sont pas affichées. Il est cependant nécessaire d'alimenter le composant, sans quoi il ne fonctionnera pas (et l'étape de vérification indiquera une erreur car certaines pattes n'ont pas été connectées, sans symbole de non connexion). Pour résoudre ce problème, les noms des pattes d'alimentation de ces composants "multipart" correspondent aux noms de symboles d'alimentation, le plus souvent "VDD" et VSS", et ces pattes sont identifiées comme "power input". Il faut donc placer ces deux nouveaux symboles d'alimentation sur le schéma, et les relier aux autres par des fils, "VDD" à "+3.3V" et "VSS" à "DGND". Attention, cela implique de ne pas avoir utilisé ces symboles d'alimentation pour une autre tension que celle avec laquelle vous voulez alimenter vos portes logiques.
Note 1 : Lorsque vous placez un composant "multipart", il a une référence de la forme "U?A". le "A" est l'identifiant du bloc sélectionné, appelé "unité" sous kicad. La sélection de l'unité d'un composant "multipart" se fait après le placement du composant [RefCard-2.22].
Note 2 : Il peut arriver que vous vouliez placer plusieurs composants "multipart" identiques sur un même schéma, mais avec des tensions d'alimentation différentes, ou isolées l'une de l'autre. Pour cela il vous faudra copier le composant dans votre bibliothèque, et changer le nom de ses alimentations.
Suite au prochain épisode
Voici le schéma final complet (avec tous les éléments rapportés sur une unique feuille pour simplifier le screenshot) :
Vous noterez la présence de quelques éléments supplémentaires que je n'ai pas abordé : les mires de positionnement, utilisées pour la production en série, et le logo de Techno-Innov, mais je détaillerais la méthode de création d'un logo dans un prochain article.
La partie schéma de notre module est terminée. La suite (association des empreintes, placement et routage) sera traitée dans un prochain article. Nous verrons aussi différentes solutions pour créer les PCB et souder les composants, L'écriture d'un programme pour le micro-contrôleur LPC1224 et la programmation, puis nous créerons d'autres modules à partir de notre base, comme une station météo, ou un module pour piloter une lampe.
Vous pouvez télécharger le résultat ici : Schema_Module_GPIO_Demo.tar.bz2 (il faudra ajouter la bibliothèque domotab).
A une prochaine !
Note : Choix d'un fournisseur et Kits de composants.
Pour rendre le module moins cher pour tous, j'ai choisi un unique fournisseur pour les composants. Certes, l'utilisation de plusieurs sources permet de gagner quelques centimes sur le coût final, mais en multipliant d'autant les frais de port, ce qui n'a donc aucun intérêt.
Cependant, compte tenu des quantités minimum d'achat et du coût de certains composants à l'unité, le prix reste très élevé, et nous vous proposons donc des kits complets sur notre site pour vous faire profiter de l'effet de volume.