Réalisation du PCB

Equipe : Demiguel F.-E., Espanol F., Souillac R.

Demonstrateur : https://github.com/RomainSouillac/Demo_Neocampus

Code source du projet : https://github.com/Thenaar38/neOCampus-arduino/

Objectifs

L’objectif était de créer un circuit imprimé capable de connecter :

  • 1 ESP32 devkit 30 broches
  • 1 écran OLED 1.3” via I2C
  • 3 capteurs via I2C
  • 1 capteur via liaison série
  • 3 boutons
  • 2 pour le pilotage de l’écran
  • 1 pour le redémarrage de la carte

Le circuit imprimé sera par la suite panélisé sur une carte de 10cm x 10cm, le but étant de créer un circuit de moins de 5cm x 5cm pour en faire rentrer 4 sur la version panélisée.

Pour la réalisation du circuit imprimé nous avons utilisé l’outil open source KiCad et nous avons travaillé sur un fork du dépôt git neOCampus [1].

Travail réalisé

Librairies

Nous avons dans un premier temps ajouté à la librairie neOSensor les composants n’existant pas de base et dont nous avions besoin, c’est à dire l’ESP32 devkit 30 broches, l’écran OLED 1.3” ainsi que le capteur de qualité de l’air SDS011 pour avoir la visualisation des empreintes physiques de ces composants.

Schéma

Nous avons ensuite relié sur le schéma tous les composants à l’aide de labels.

Placement des composants

Pour cette partie, nous avons réalisé 2 versions du circuit imprimé à partir du même schéma, une première version avec les boutons sur le dessus de l’écran, et une deuxième version avec les boutons sur le côté de l’écran.

Câblage entre composants

Nous avons respecté une norme qui simplifie le câblage, qui est la suivante : les câbles qui passent à l’horizontale sont sur la face arrière, et les câbles qui passent à la verticale sont sur la face avant, on évite autant que possible d’avoir des fils en diagonale. Lorsque nous avons besoin de faire passer un signal entre les deux faces, nous utilisons des via, qui sont des trous métallisés permettant de faire passer le signal d’un côté à l’autre de la carte.

Enfin pour plus de stabilité dans les signaux, nous avons mis en place un plan de masse de chaque côté de la carte.

Panélisation

Pour la panélisation des deux versions, nous avons utilisé l’outil permettant de créer un tableau (de 1x2 en l’occurence) de composants, en sélectionnant tous les éléments du circuit imprimé, et en le dupliquant. Nous avons effectué cette étape pour les deux versions pour un résultat panélisé de 4 circuits imprimés.

Quelques détails

Nous utilisons un AMS1117 pour convertir le 5V sortant de l’esp32 en 3V3, c’est un composant qui est susceptible de chauffer, nous avons donc disposé des vias sous l’empreinte de ce composant pour permettre à l’air de circuler.

Réalisation du démonstrateur

Détails de l’architecture matérielle du démonstrateur

Le démonstrateur est composé des parties suivantes :

  • le devkit ESP32
  • la logique de RESET
  • la logique de d’affichage manuel
  • le bus I2C avec le capteur de température MCP9808, le capteur de luminosité MAX44009 et l’écran OLED SSD1306.

logique de RESET

La logique de RESET consiste en une LED alimentée en 5V suivie d’une résistance de 68 ohms, connectée à la masse par l’intermédiaire d’un transistor piloté par un bouton alimenté en 3.3V.

L’appui sur le bouton actionne à la fois la grille du transistor pilotant la LED et la mise à 1 logique du GPIO34. Pour protéger l’ESP32, une résistance de 470 ohms est placée entre la broche et le bouton. Une résistance de pull-down de 15 kOhms permet la mise au 0 logique du circuit.

Nous étions partis pour utiliser le GPIO34 comme broche d’interruption pilotant le RESET. Cependant après l’impossibilité de déclencher une interruption depuis le GPIO34 , et parès plusieursx tests, ses voisins, nous nous sommes servi de la broche RST qui fonctionne en logique inverse ; c’est à dire que le reset ne se fait que si la broche est à l’état 0 logique. il a donc fallu modifier pour le démonstrateur le fonctionnement du bouton ; la résistance de pull-down est devenue une résistance de pull-up.

Logique de l’affichage manuel

La logique de l’affichage manuel consiste en un bouton contrôlant le GPIO4. Le bouton est par défaut à l’état 0 logique via une résistance de pull-down de 15 kOhms ; Il est connecté à l’ESP32 par l’intermédiaire d’une résistance de sécurité de 470 ohms.

Bus I2C

le bus I2C est relié au GPIO21 pour SDA et au GPIO22 pour SCL. Tous les capeurs et l’écran sont reliés en parallèle à ces broches, et au 3.3V pour VCC. Deux résistances de pull-up de 4.7kOhms sont présentes pour essayer de neutraliser respectivement les parasites sur SDA et SCL.

Détails de l’architecture logicielle du démonstrateur

Les librairies

Pour intégrer tout ces capteurs nous utilisons les drivers déjà réalisés lors des ver- sion précedente de neosensor, la librairie MAX44009 est utilisé par le GY49 et la librairie Adafruit MCP9808 par le MCP9808, ces librairies ont été réalisé à partir des librairies de base mais modifié pour une meilleure application à l’ESP. La librai- rie Adafruit GFX et Adafruit SSD1306 servent à utiliser l’écran OLED. La librairie PubSubclient nous permet d’utiliser le protocole MQTT. La librairie time permet d’actualiser l’heure et la date actuelle avec l’aide du protocole NTP. Pour se connec- ter sur internet avec la WiFi on utilise les librairie WiFiManager et HTTPClient et avec LITTLEFS on ouvre le fichier config pour se connecter par WiFi si besoin.

Le code

Lors du démarrage de la carte et de son setup, on affiche le logo de neOCampus et on connecte la carte par WiFi ; pour ce faire l’ESP va se mettre en mode ”station” sur lequel l’utilisateur va devoir se connecter à l’aide d’un appareil. Ensuite il se verra redirigé vers un portail captif ou il devra entrer le SSID et le mot de passe du réseau sur lequel il souhaite connecter la board. Aprés s’etre connecté en WiFi, l’ESP va setup le broker puis se souscrire aux topics qui l’interessent. Ensuite il va réaliser un scan pour voir les capteurs et verifier si c’est bien les bons. On confi- gure ensuite le temps avec l’aide de NTP et on alloue l’espace nécessaire pour les données des capteurs. On réalise aussi une collecte des données pour avoir quand même quelque chose à afficher en cas de probleme. C’est dans le setup aussi qu’on instancie l’interruption quand on appuie sur le bouton.

Pour réaliser les changements des types d’affichage on utilise un type énumeré. Ce type nous permet de savoir ce qu’on affiche et quel est le prochain type d’affichage à afficher. Toute les 10 secondes l’ESP va publier, dans un des topics auxquel il s’est déjà souscrit, un ordre lui permettant de passer à l’affichage suivant.

La collecte et l’affichage sur l’écran en fonction du type d’affichage que nous devont faire se réalise dans le loop du programe toute les 0.1 secondes.

Pour envoyer les messages personnalisés, l’utilisateur a besoin d’un autre appareil et de publier dans un des topics auquel l’ESP32 s’est abonné. Le message publié doit avoir la forme suivante : {”order” :”custom”, ”value” : ”exemple de message a afficher”}. A savoir que l’écran a la place pour afficher 40 caractéres et il peut afficher 10 caractères par ligne. Avant d’afficher le message custom on enregistre quel était le dernier type d’affiché hors le type des messages personnalisés pour savoir d’ou reprendre après l’affichage du message personnalisé. En effet, on a décidé de reprendre le cycle d’affichage avec le type suivant du message que nous avons enregistré. Cela nous permet d’éviter si il y a un spam de messages personnalisé de toujours rester sur le même type d’affichage.

Le programme appellé par l’interruption lié à la pression du bouton poussoir fait la même chose que le programme appellé par la reception de l’ordre ”change” par MQTT