« SE3Groupe2024-2 » : différence entre les versions
Ligne 293 : | Ligne 293 : | ||
* le gnd est relié à la masse | * le gnd est relié à la masse | ||
* le power est relié au 3,3V | * le power est relié au 3,3V | ||
* le fil de données est branché sur le pin | * le fil de données est branché sur le pin PD2 (digital 2). | ||
On branche également une résistance de 4,7kΩ entre le fil de données et le 3,3V.[[Fichier:Capteur eau.jpg|alt=capteur_eau|vignette|capteur_eau|centré]] | |||
[[Fichier:Capteur eau.jpg|alt=capteur_eau|vignette|capteur_eau|centré]] | |||
<p style="clear: both;" /> | <p style="clear: both;" /> | ||
Ligne 311 : | Ligne 310 : | ||
* main.c : pour le code principal | * main.c : pour le code principal | ||
* Makefile : pour faciliter la compilation | * Makefile : pour faciliter la compilation | ||
<p style="clear: both;" /> | <p style="clear: both;" /><p style="clear: both;" />[INSERER LE CODE UNE FOIS QU IL SERA MIS AU PROPRE] | ||
===== Démonstration ===== | ===== Démonstration ===== |
Version actuelle datée du 5 mai 2025 à 13:13
Lien GIT
Voici le lien git pour accéder aux différents fichiers relatifs à notre projet : https://gitea.plil.fr/ahouduss/se3_2024_B2.git
Description
Objectif
L'objectif de ce projet est de concevoir une station domotique capable de collecter et d'afficher des mesures provenant de capteurs. Elle devra également être capable d'activer des actionneurs, tels que des LEDs, des cadenas ou tout autre dispositif, en fonction des besoins.
Cahier des charges
La station domotique devra permettre l'affichage des informations suivantes concernant une pièce :
- Température ambiante ;
- Taux d'humidité ;
- Présence humaine (via capteur de mouvement) ;
- D'autres paramètres pourront être ajoutés en fonction de l'avancement du projet.
Elle devra aussi permettre de contrôler différents actionneurs dans la pièce, tels que :
- L'éclairage, en fonction de la présence d'une personne (via un capteur de mouvement) ;
- D'autres dispositifs pourront être intégrés en fonction des besoins.
Des capteurs et actionneurs supplémentaires pourront être ajoutés si le projet atteint ses objectifs initiaux.
Spécification techniques
Microcontrôleur
Le projet nécessite un microcontrôleur, qui contiendra le programme, et qui communiquera avec les autres composants via les GPIOs.
Nous avons le choix entre plusieurs modèles de microcontrôleur : ATmega16u4, AT90USB1286, AT90USB1287.
Voici un tableau comparatif afin de sélectionner le plus adapté pour notre usage :
Caractéristiques | ATmega16U4 | AT90USB1286 | AT90USB1287 |
Architecture | AVR 8 bits | AVR 8 bits | AVR 8 bits |
Mémoire Flash | 16 KB | 128 KB | 128 KB |
RAM (SRAM) | 1.25 KB | 4 KB | 4 KB |
EEPROM | 512 Bytes | 4 KB | 4 KB |
Fréquence d'horloge max. | 16 MHz | 16 MHz | 16 MHz |
Nombre de broches GPIO | 26 | 48 | 48 |
Interfaces de communication | UART, SPI, I²C, USB 2.0 | UART, SPI, I²C, USB 2.0 | UART, SPI, I²C, USB 2.0 |
Contrôleur USB intégré | Oui (USB 2.0) | Oui (USB 2.0) | Oui (USB 2.0) |
Taille des registres | 8 bits | 8 bits | 8 bits |
Nombre de broches | 32 | 64 | 64 |
Différences principales | Conçu pour des applications compactes avec
moins de mémoire et d'E/S |
Plus de mémoire, adapté à des projets complexes nécessitant de nombreuses E/S et de la mémoire | Similaire au AT90USB1286 mais avec des fonctionnalités spécifiques
pour certaines configurations USB (e.g., modes host/OTG). |
Lien documentation | https://www.microchip.com/en-us/product/atmega16u4 | https://www.microchip.com/en-us/product/at90usb1286 | https://www.microchip.com/en-us/product/at90usb1287 |
Avec ce tableau, on constate que l'ATmega16U4 ne possède pas suffisamment de broches GPIOs. Cependant l'AT90USB1286 et son homologue l'AT90USB1287 dépassent notre cadre d'usage (utilisation mode USB spécifique HOST/OTG, etc... ).
Le compromis est donc d'opter pour un ATmega32u4 afin d'avoir suffisamment de broches et de mémoire.
Caractéristiques | ATmega32U4 |
---|---|
Architecture | AVR 8 bits |
Mémoire Flash | 32 KB |
RAM (SRAM) | 2.5 KB |
EEPROM | 1 KB |
Fréquence d'horloge max. | 16 MHz |
Nombre de broches GPIO | 26 |
Interfaces de communication | UART, SPI, I²C, USB 2.0 |
Contrôleur USB intégré | Oui (USB 2.0) |
Taille des registres | 8 bits |
Nombre de broches | 32 |
Différences principales | Conçu pour des applications nécessitant un contrôleur USB intégré, avec une mémoire et un nombre de broches intermédiaires |
Datasheet ATmega32u4 :
Communication
La station utilisera une puce NRF24L01 pour la communication sans fil entre les différents actionneurs et capteurs.
La communication entre le pc et la station se fera quant à elle en USB.
Lien tutoriel utilisation de puces à distance : NRF24L01
Datasheet NRF24L01 :
Énergie
La station sera alimentée de manière hybride, selon les scénarios suivants : - Par un port USB, pour la programmation, les tests et la configuration avec affichage sur moniteur PC ;
- Par une batterie Lithium, en mode autonome pour une utilisation prolongée (avec affichage écran LCD dans un second temps).
Les capteurs/actionneurs seront alimentées de manière hybride, selon les scénarios suivants :
- Par un port USB, pour la programmation, les tests et la configuration ;
- Par une batterie Lithium, en mode autonome pour son usage définitif.
Modèles de batterie à notre disposition :
- Batterie 3.7V 100 mAh, connecteur molex mâle ;
- Batterie 3.7V 300 mAh, connecteur molex mâle ;
Nous allons ajouter la possibilité de recharger notre batterie depuis notre carte via le composant MAX1811. La carte se rechargera lorsqu'elle sera branché en USB mais l'USB fournit du 5V, ce qui peut nuire à certains de nos composants...
Pour proteger les composants, nous allons ajouter un régulateur de tension pour garder une tension de 3,3V sur l'ensemble de notre carte.
Datasheets du chargeur et du régulateur :
Affichage
Dans un premier temps, les informations seront remontées via la connexion USB à un programme sur PC (selon les exigences du cahier des charges).
Dans un second temps, un écran LCD sera utilisé pour afficher les données directement sur la station, offrant ainsi une solution autonome, sous réserve du temps disponible pour cette implémentation.
Datasheet de l'écran graphique utilisé :
On décide de prgrammer l'écran en C. On code donc notre écran via l'API "glcd.h". L'écran sera composé d'un menu permettant de naviguer parmi les différents capteurs enregistrés afin de consulter la valeur renvoyée par cle capteur choisi. Les boutons intégrés sur la carte ainsi que l'encodeur rotatif permettront à l'utilisateur de naviguer entre les différents capteurs..
Diverses
La carte comportera également une led afin d'indiquer son état d'alimentation ainsi que deux autres leds permettant de faire des tests de programmation.
Hardware de la station domotique
Schématique
Notre schéma électrique
Comprendre notre schéma
Vue 3D
Brasure
Software de la station domotique
Capteurs
Capteur de mouvement
Spécifications techniques
On utilise un capteur de mouvement HC-SR501 (voir datasheet ci-dessous) afin de détecter ou non la présence de quelqu'un dans une pièce et de pouvoir ensuite allumer la lumière si une personne est présente ou a contrario l'éteindre si la pièce est vide. Ici la lumière sera modélisée par une led présente sur l'arduino uno.
- Jumper Set
Les deux modes repeat ou single trigger permettent de régler le temps de détection avant d'arrêter de détecter une présence (par exemple, besoin d'une présence continue pour que la led reste allumée ou bien besoin de réactiver de temps à autre le capteur en bougeant).
- Sensitivty Adjust
On modifie le potentiomètre à l'aide d'un tournevis afin d'ajuster la sensibilité à la présence de notre main, par exemple pour l'amplitude de nos mouvements.
Circuit
On connecte le GND à la masse de l'arduino, le power au 5V et la sortie au pin PB0 (digital 8). Voir la vidéo de démonstration pour plus de détails.
Programmation
Voici le code afin d'allumer une led dès qu'une présence est détectée.
/* ceci est le code pour le capteur de présence HC-SR501
* pour plus d'informations regarder dans le dossier datasheet pour la doc */
#include <avr/io.h>
#include <util/delay.h>
int main(void) {
DDRB |= (1 << PB5); //led D13 en sortie
while (1) {
if (PINB & (1 << PB0)) { //si mvmt
PORTB |= (1 << PB5); //led allumée
} else { //si absence
PORTB &= ~(1 << PB5); //led éteinte
}
_delay_ms(500);
}
return 0;
}
Démonstration
Voici le résultat en vidéo ci-dessous. On constate bien que la led s'allume lorsqu'une présence est détectée.
Dans un second temps, on fera communiquer ce capteur avec notre carte station domotique par le biais des modules nrf24 afin d'afficher l'état de la pièce sur l'écran.
Capteur de température
Spécifications techniques
On utilise aussi le capteur de température DS18B20 (voir datasheet ci-dessous) afin de mesurer la température de l'eau (pour une piscine ou une plante par exemple).
Circuit
On branche les 3 broches de notre sonde de la manière suivante :
- le gnd est relié à la masse
- le power est relié au 3,3V
- le fil de données est branché sur le pin PD2 (digital 2).
On branche également une résistance de 4,7kΩ entre le fil de données et le 3,3V.
Programmation
Arduino
Pour commencer on a testé si notre sonde fonctionnait correctement à l'aide d'un code arduino et on a constaté aucun souci (voir dans le git).
C
On est donc passer à du code en c et on a trouvé plusieurs ressources sur github que l'on a fusionné afin d'obtenir un code fonctionnel.On a utilisé les fichiers du répertoire test1 :
- onewire.h, onewire.c : pour remplacer la librairie OneWire.h de l'arduino afin de communiquer avec l'unique fil de données de la sonde.
- ds18b20.h, ds18b20.c : pour les fonctions princiales utiles à notre sonde.
- UART.h, UART.c : pour afficher la température sur la liaison série.
- main.c : pour le code principal
- Makefile : pour faciliter la compilation
[INSERER LE CODE UNE FOIS QU IL SERA MIS AU PROPRE]
Démonstration
Voici le résultat en vidéo ci-dessous. On constate bien que la température affichée sur le minicom augmente lorsque la sonde reste longtemps dans la bouilloire chauffée au préalable.
Dans un second temps, on fera communiquer ce capteur avec notre carte station domotique par le biais des modules nrf24 afin d'afficher la température de la pièce sur l'écran.
Actionneur
Lumière
On peut décider d'allumer une lumière selon certains critèrres (par exemple lorsque le capteur de présence détecte quelqu'un). Ici allumer une led par exemple.
Communication
Pour plus de détails, se référer à la rubrique spécifications techniques->communication. Ici nous traiterons du code implémenté afin de communiquer entre les différents capteurs/actionneurs et notre carte principale.
Ecran
Afin d'avoir une interface pour l'utilisateur, nous décidons d'afficher sur un écran les données reçues des capteurs et l'état des actionneurs. On doit donc voir s'afficher la température d'une pièce, si il y a une présence etc.
Pour cela, on va devoir coder l'écran NHD‐C12832A1Z‐FSW‐FBW‐3V3 (voir datasheet dans la rubrique spécifications techniques->écran).
Programmateur AVR
Objectif
Réaliser un programmateur AVR afin d'envoyer notre code C sur le microcontrôleur de notre carte.
Cours / Tutoriel
https://rex.plil.fr/Enseignement/Systeme/Systeme.PSE/systeme063.html
Schématique
Notre schéma électrique
Conception de notre schéma électrique
Documents relatifs à la conception du kicad de la carte
Vue 3D
Fichier kicad
Brasure
Programmation
Test leds et boutons
Afin de vérifier que notre carte fonctionne correctement après brasure, on code un programme permettant d'allumer une led périodiquement puis un autre programme allumant une led lorsqu'un bouton poussoir est pressé.
Afin de mettre le programme sur notre carte, on vérifie au préalable que notre carte est bien reconnue en tant que périphérique USB à l'aide de la commande lsusb.
Pour plus de détail sur notre périphérique usb branché on doit faire la commande " lsusb -s [bus]:[device] -v " :
cedricagathe@computer:~$ lsusb -s 003:008 -v
Bus 003 Device 011: ID 03eb:2044 Atmel Corp. LUFA CDC Demo Application
[...]
Device Descriptor:
bLength 18
bDescriptorType 1
[...]
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
[...]
idVendor 0x03eb Atmel Corp.
idProduct 0x2044 LUFA CDC Demo Application
[...]
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
[...]
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
[...]
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
[...]
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
[...]
Comme vu en cours, on revoit nos descripteurs ainsi que la description des interfaces de l'usb ainsi que d'autres données.Une fois notre carte détectée, on appuie sur le bouton HWB puis reset afin de mettre notre carte en mode DFU. On téléverse ensuite notre programme sur la carte à l'aide d'un makefile préalablement codé en tapant la commande make upload.
LUFA
Afin de pouvoir faire de notre carte un périphérique USB, nous allons utiliser la LUFA (Lightweight USB Framefork for AVRs).
- Tout d'abord, nous avons codé un programme permettant de voir si la lufa détecte bien les boutons-poussoirs de notre carte comme des points d'accès d'entrées en affichant sur le minicom quel bouton-poussoir était pressé par l'utilisateur. Notre code se trouve dans le répertoire se ci-dessous : https://gitea.plil.fr/ahouduss/se3_2024_B2/src/branch/main/01%20-%20Programmateur%20AVR/programmation/lufa-LUFA-210130-NSI/se/VirtualSerial
Pour écrire notre code, nous avons réutilisé l'exemple VirtualSerial récupéré au repertoire suivant :
LUFA/Demos/Device/LowLevel/VirtualSerial
- On place le programme dans notre carte à l'aide de la commande make upload. Pour ce faire, il faut modifier le makefile original par ceci :
MCU = atmega8u2
ARCH = AVR8
BOARD = NONE
F_CPU = 16000000
F_USB = $(F_CPU)
OPTIMIZATION = s
TARGET = VirtualSerial
SRC = $(TARGET).c Descriptors.c spi.c $(LUFA_SRC_USB)
LUFA_PATH = ../../LUFA
CC_FLAGS = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS =
PROGRAMMER = dfu-programmer
all:
upload: $(TARGET).hex
$(PROGRAMMER) $(MCU) erase
$(PROGRAMMER) $(MCU) flash $(TARGET).hex
$(PROGRAMMER) $(MCU) reset
clean:
rm -f *.bin *.elf *.lss *.map *.sym *.eep
Le MCU a été changé afin de correspondre au nôtre. Une commande clean à été ajouté et la fréquence CPU augmentée à 16 MHz.
- On lance la commande minicom afin de voir si le bouton pressé est bien affiché via la liaison série. On configure le minicom au préalable.
sudo minicom -os
Ensuite nous entrons dans Serial port setup :
Il va falloir procéder à 3 changements :
- Appuyer sur A et changer modem par l'emplacement de notre carte (ici /ttyACM0) puis ENTRER
- Appuyer sur E puis appuyer sur C pour configurer la vitesse de notre minicom puis ENTRER
- Appuyer sur F puis ENTRER
Appuyer de nouveau sur ENTRER pour enregistrer la configuration et ensuite faite Exit. On est maintenant prêt à recevoir les messages USB qu'on envoie lors d'un appui :
- Nous avons ensuite implémenté un programme permettant d'allumer une led différente à chaque bouton-poussoir pressé.
Modification du fichier virtual.c
Modification de l'horloge
Ainsi notre microprocesseur détecte notre quartz comme étant du 16MHz
void SetupHardware(void)
{
CLKSEL0 = 0b00010101; // sélection de l'horloge externe
CLKSEL1 = 0b00001111; // minimum de 8Mhz
CLKPR = 0b10000000; // modification du diviseur d'horloge (CLKPCE=1)
CLKPR = 0; // 0 pour pas de diviseur (diviseur de 1)
}
Fonction pour les boutons
void init_boutons(void){
// A MODIF CEDRIC
//bouton sw3 du haut
DDRB = 0x00; //0 input
DDRC = 0x00;
PORTB = 0x60; //PB5 -> SW6 (bas) et PB6 -> SW4 (droite)
PORTC = 0x50; //PC4 -> SW3 (haut) et PC6 -> SW5 (gauche)
MCUCR |= 0x10; //Pour activer resistance cf DS p38
}
Fonction pour la led
void init_leds(void){
// A MODIF CEDRIC
DDRD |= 0x0f; //PD3-0 : leds 1 à 4
}
Afficher sur le minicom lorsqu'un bouton est pressé
void CDC_Task(void)
{
char* ReportString = NULL;
static bool ActionSent = false;
init_boutons();
init_leds();
/* Device must be connected and configured for the task to run */
if (USB_DeviceState != DEVICE_STATE_Configured)
return;
/* Determine if a button action has occurred */
if ((PINC&0x10)<=0){ //PC4
ReportString = "bouton du haut\r\n"; //affiché dans le minicom
PORTD = 0x01; //allume led1
_delay_ms(300);
}
if ((PINB&0x20)<=0){ //PB5
ReportString = "bouton du bas\r\n";
PORTD = 0x02; //allume led2
_delay_ms(300);
}
if ((PINC&0x40)<=0){ //PC6
ReportString = "bouton de gauche\r\n";
PORTD = 0x04; //allume led3
_delay_ms(300);
}
if ((PINB&0x40)<=0){ //PB6
ReportString = "bouton de droite\r\n";
PORTD = 0x08; //allume led4
_delay_ms(300);
}
else
ActionSent = false;
getID(ReportString);
[...]
}