Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA4 2018/2019 P57

2019-05-10T09:01:46Z

Fleroy2 : /* Travail supplémentaire (Partie Réalisation) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="13"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="4"|32
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="4"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

[[Fichier:P57_2019_Envoid'unfichier.JPG|400px|thumb|left|Tests émission/réception]][[Fichier:P57_2019_Buffer.JPG|200px|thumb|right|Vitesse en fonction de la taille du buffer]]
Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.
La première étape était de transmettre le header et ainsi obtenir la version, l'identification et pouvoir vérifier l'authenticité du paquet.
Une fois la taille récupérée, le but était de transmettre (sans perte) le paquet. Pour cela, il faut utiliser un buffer de données afin de transmettre partie par partie. La taille de ce Buffer étant spécifiée à l'avance dans le programme. Mais alors comment choisir la taille du buffer ? Des tests ont étés effectuées et la taille du buffer a une énorme incidence sur la vitesse de transfert des fichiers (voir courbe). Cette courbe n'est pas la seule à prendre en compte. Le buffer ne peut pas dépasser les 32 bytes imposés par le composant. De plus, ici ces temps concernent que la transmission, il faut également que le microcontrôleur charge ces valeurs dans la mémoire SPI.
<div style="clear: both;"></div>
L'écriture et la vérification par CheckSum étant fonctionnelle, on passe maintenant à la transformation du programme en Bootloader à l'aide du logiciel Atmel Studio et du bootloader Optiboot (qui est le bootloader le plus léger et fonctionnel pour une arduino). Ce tutoriel pourra nous être utile afin de modifier le bootloader plus simplement : [https://www.electronicwings.com/arduino/basics-to-developing-bootloader-for-arduino/ Tuto]

==Travail supplémentaire (Partie Réalisation)==
Quelques problèmes ont été rencontrés. En procédant étape par étape, nous avons pu déterminer d'où venait le problème qui faisait que le module refusait de fonctionner à 8MHz en 3.3V. Premièrement, la conception a été réalisée à l'aide du schéma de l'Arduino Pro Mini. Celui ci fonctionnant à 3.3V comme à 5V à 8MHz et 16MHz. Cependant, cet Arduino fonctionne grâce à un résonateur qui permet d'obtenir, à la fois des fréquences de 8/16 et 20 MHz.
Dès lors plusieurs tests nous ont permis de démontrer que le circuit fonctionne sur 5V avec un quartz à 16MHz comme avec un quartz à 8MHz cependant, lors du passage à 3.3V, l'Atmega ne fonctionnait plus.

L'oscillateur externe en est la cause. Pour cela, je décide donc de réécrire les fuses de l'Atmega. Ces fuses me permettent de désactiver le prescale de 8 et d'utiliser l'oscillateur interne au microprocesseur même si celui ci est moins précis.
{| class="wikitable"
!colspan="7"|Fuses
|-
|colspan="1"|
|colspan="3"|Avant
|colspan="3"|Après
|-
|colspan="1"|Low
|colspan="3"|FF
|colspan="3"|E2
|-
|colspan="1"|High
|colspan="3"|DA
|colspan="3"|D8
|-
|colspan="1"|Extend
|colspan="3"|05
|colspan="3"|07
|}
Ces différentes valeurs de fuse nous permettent :
'''Low Fuse''' : Spécifier que l'on veut utiliser un quartz de 8MHz en interne avec un CK (temps de boot de 65ms)
'''High Fuse''' : Spécifie l'utilisation d'un bootloader de 2ko
'''Extend Fuse''' : permet de désactiver la brown-out protection. Cette protection permet d'éviter que le microcontrôleur ne fonctionne en une tension trop basse afin d'éviter les anomalies. Dans notre cas, je souhaite la désactiver afin d'écarter des risques de bugs.

Le fusible extend ne peut être programmé en 3.3V, une modification de ce fusible en 3.3v rendra le capteur inutilisable jusqu'à la reprogrammation du contrôleur en 5V.

=Documents Rendus=
'''Rapport de projet :''' [[Média:P57_2019_Rapport_de_projet_IMA4.pdf]] <br/><br/>

'''PCBs :'''

Conception du capteur : [[Média:P57_2019_PCBv1.PDF]]
Archive : [[Fichier:P57_2019_Conception_CapteurSansLibs.zip]]

Conception du Shield: [[Média:P57_2019_ConceptionShield.PDF]]
Archive : [[Fichier:P57_2019_Conception_Module_RAMSansLibs.zip]]

'''Programmes :'''

Sender (Raspberry) : [[Fichier:P57_2019_Raspberry.zip]]
Bootloader (Atmega328p) : [[Fichier:P57_2019_Atmega.zip]]

IMA4 2018/2019 P57

2019-05-10T01:39:35Z

Fleroy2 : /* Documents Rendus */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="13"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="4"|32
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="4"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

[[Fichier:P57_2019_Envoid'unfichier.JPG|400px|thumb|left|Tests émission/réception]][[Fichier:P57_2019_Buffer.JPG|200px|thumb|right|Vitesse en fonction de la taille du buffer]]
Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.
La première étape était de transmettre le header et ainsi obtenir la version, l'identification et pouvoir vérifier l'authenticité du paquet.
Une fois la taille récupérée, le but était de transmettre (sans perte) le paquet. Pour cela, il faut utiliser un buffer de données afin de transmettre partie par partie. La taille de ce Buffer étant spécifiée à l'avance dans le programme. Mais alors comment choisir la taille du buffer ? Des tests ont étés effectuées et la taille du buffer a une énorme incidence sur la vitesse de transfert des fichiers (voir courbe). Cette courbe n'est pas la seule à prendre en compte. Le buffer ne peut pas dépasser les 32 bytes imposés par le composant. De plus, ici ces temps concernent que la transmission, il faut également que le microcontrôleur charge ces valeurs dans la mémoire SPI.
<div style="clear: both;"></div>
L'écriture et la vérification par CheckSum étant fonctionnelle, on passe maintenant à la transformation du programme en Bootloader à l'aide du logiciel Atmel Studio et du bootloader Optiboot (qui est le bootloader le plus léger et fonctionnel pour une arduino). Ce tutoriel pourra nous être utile afin de modifier le bootloader plus simplement : [https://www.electronicwings.com/arduino/basics-to-developing-bootloader-for-arduino/ Tuto]

==Travail supplémentaire (Partie Réalisation)==
Quelques problèmes ont été rencontrés. En procédant étape par étape, nous avons pu déterminer d'où venait le problème qui faisait que le module refusait de fonctionner à 8MHz en 3.3V. Premièrement, la conception a été réalisée à l'aide du schéma de l'Arduino Pro Mini. Celui ci fonctionnant à 3.3V comme à 5V à 8MHz et 16MHz. Cependant, cet Arduino fonctionne grâce à un résonateur qui permet d'obtenir, à la fois des fréquences de 8/16 et 20 MHz.
Dès lors plusieurs tests nous ont permis de démontrer que le circuit fonctionne sur 5V avec un quartz à 16MHz comme avec un quartz à 8MHz cependant, lors du passage à 3.3V, l'Atmega ne fonctionnait plus.

L'oscillateur externe en est la cause. Pour cela, je décide donc de réécrire les fuses de l'Atmega. Ces fuses me permettent de désactiver le prescale de 8 et d'utiliser l'oscillateur interne au microprocesseur même si celui ci est moins précis.
{| class="wikitable"
!colspan="7"|Fuses
|-
|colspan="1"|
|colspan="3"|Avant
|colspan="3"|Après
|-
|colspan="1"|Low
|colspan="3"|FF
|colspan="3"|E2
|-
|colspan="1"|High
|colspan="3"|DA
|colspan="3"|D8
|-
|colspan="1"|Extend
|colspan="3"|05
|colspan="3"|07
|}

=Documents Rendus=
'''Rapport de projet :''' [[Média:P57_2019_Rapport_de_projet_IMA4.pdf]] <br/><br/>

'''PCBs :'''

Conception du capteur : [[Média:P57_2019_PCBv1.PDF]]
Archive : [[Fichier:P57_2019_Conception_CapteurSansLibs.zip]]

Conception du Shield: [[Média:P57_2019_ConceptionShield.PDF]]
Archive : [[Fichier:P57_2019_Conception_Module_RAMSansLibs.zip]]

'''Programmes :'''

Sender (Raspberry) : [[Fichier:P57_2019_Raspberry.zip]]
Bootloader (Atmega328p) : [[Fichier:P57_2019_Atmega.zip]]

Fichier:P57 2019 Raspberry.zip

2019-05-10T01:30:23Z

Fleroy2 :

Fichier:P57 2019 Rapport de projet IMA4.pdf

2019-05-10T01:30:14Z

Fleroy2 :

Fichier:P57 2019 PCBV2.PDF

2019-05-10T01:30:01Z

Fleroy2 :

Fichier:P57 2019 PCBv1.PDF

2019-05-10T01:29:45Z

Fleroy2 :

Fichier:P57 2019 ConceptionShield.PDF

2019-05-10T01:29:27Z

Fleroy2 : rendu conception

rendu conception

Fichier:P57 2019 Conception Module RAMSansLibs.zip

2019-05-10T01:28:48Z

Fleroy2 :

Fichier:P57 2019 Conception CapteurSansLibs.zip

2019-05-10T01:27:03Z

Fleroy2 :

Fichier:P57 2019 Atmega.zip

2019-05-10T01:26:37Z

Fleroy2 :

IMA4 2018/2019 P57

2019-05-09T22:15:10Z

Fleroy2 : /* Travail supplémentaire (Partie Réalisation) */

IMA4 2018/2019 P57

2019-05-03T18:20:29Z

Fleroy2 : /* Travail supplémentaire (Partie Réalisation) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="13"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="4"|32
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="4"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

[[Fichier:P57_2019_Envoid'unfichier.JPG|400px|thumb|left|Tests émission/réception]][[Fichier:P57_2019_Buffer.JPG|200px|thumb|right|Vitesse en fonction de la taille du buffer]]
Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.
La première étape était de transmettre le header et ainsi obtenir la version, l'identification et pouvoir vérifier l'authenticité du paquet.
Une fois la taille récupérée, le but était de transmettre (sans perte) le paquet. Pour cela, il faut utiliser un buffer de données afin de transmettre partie par partie. La taille de ce Buffer étant spécifiée à l'avance dans le programme. Mais alors comment choisir la taille du buffer ? Des tests ont étés effectuées et la taille du buffer a une énorme incidence sur la vitesse de transfert des fichiers (voir courbe). Cette courbe n'est pas la seule à prendre en compte. Le buffer ne peut pas dépasser les 32 bytes imposés par le composant. De plus, ici ces temps concernent que la transmission, il faut également que le microcontrôleur charge ces valeurs dans la mémoire SPI.
<div style="clear: both;"></div>
L'écriture et la vérification par CheckSum étant fonctionnelle, on passe maintenant à la transformation du programme en Bootloader à l'aide du logiciel Atmel Studio et du bootloader Optiboot (qui est le bootloader le plus léger et fonctionnel pour une arduino). Ce tutoriel pourra nous être utile afin de modifier le bootloader plus simplement : [https://www.electronicwings.com/arduino/basics-to-developing-bootloader-for-arduino/ Tuto]

==Travail supplémentaire (Partie Réalisation)==
Quelques problèmes ont été rencontrés. En procédant étape par étape, nous avons pu déterminer d'où venait le problème qui faisait que le module refusait de fonctionner à 8MHz en 3.3V. Premièrement, la conception a été réalisée à l'aide du schéma de l'Arduino Pro Mini. Celui ci fonctionnant à 3.3V comme à 5V à 8MHz et 16MHz. Cependant, cet Arduino fonctionne grâce à un résonateur qui permet d'obtenir, à la fois des fréquences de 8/16 et 20 MHz.
Dès lors plusieurs tests nous ont permis de démontrer que le circuit fonctionne sur 5V avec un quartz à 16MHz comme avec un quartz à 8MHz cependant, lors du passage à 3.3V, l'Atmega ne fonctionnait plus.

L'oscillateur externe en est la cause. Pour cela, je décide donc de réécrire les fuses de l'Atmega. Ces fuses me permettent de désactiver le prescale de 8 et d'utiliser l'oscillateur interne au microprocesseur même si celui ci est moins précis.
{| class="wikitable"
!colspan="7"|Fuses
|-
|colspan="1"|
|colspan="3"|Avant
|colspan="3"|Après
|-
|colspan="1"|Low
|colspan="3"|FF
|colspan="3"|E2
|-
|colspan="1"|High
|colspan="3"|DA
|colspan="3"|DE
|-
|colspan="1"|Extend
|colspan="3"|05
|colspan="3"|07
|}

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-02T15:10:09Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

IMA4 2018/2019 P57

2019-05-02T13:10:48Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="13"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="4"|32
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="4"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

[[Fichier:P57_2019_Envoid'unfichier.JPG|400px|thumb|left|Tests émission/réception]][[Fichier:P57_2019_Buffer.JPG|200px|thumb|right|Vitesse en fonction de la taille du buffer]]
Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.
La première étape était de transmettre le header et ainsi obtenir la version, l'identification et pouvoir vérifier l'authenticité du paquet.
Une fois la taille récupérée, le but était de transmettre (sans perte) le paquet. Pour cela, il faut utiliser un buffer de données afin de transmettre partie par partie. La taille de ce Buffer étant spécifiée à l'avance dans le programme. Mais alors comment choisir la taille du buffer ? Des tests ont étés effectuées et la taille du buffer a une énorme incidence sur la vitesse de transfert des fichiers (voir courbe). Cette courbe n'est pas la seule à prendre en compte. Le buffer ne peut pas dépasser les 32 bytes imposés par le composant. De plus, ici ces temps concernent que la transmission, il faut également que le microcontrôleur charge ces valeurs dans la mémoire SPI.
<div style="clear: both;"></div>

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-02T13:10:13Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="13"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="4"|32
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="4"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

[[Fichier:P57_2019_Envoid'unfichier.JPG|400px|thumb|left|Tests émission/réception]][[Fichier:P57_2019_Buffer.JPG|200px|thumb|right|Vitesse en fonction de la taille du buffer]]
Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.
La première étape était de transmettre le header et ainsi obtenir la version, l'identification et pouvoir vérifier l'authenticité du paquet.
Une fois la taille récupérée, le but était de transmettre (sans perte) le paquet. Pour cela, il faut utiliser un buffer de données afin de transmettre partie par partie. La taille de ce Buffer étant spécifiée à l'avance dans le programme. Mais alors comment choisir la taille du buffer ? Des tests ont étés effectuées et la taille du buffer a une énorme incidence sur la vitesse de transfert des fichiers (voir courbe). Cette courbe n'est pas la seule à prendre en compte. Le buffer ne peut pas dépasser les 32 bytes imposés par le composant. De plus, ici ces temps concernent que la transmission, il faut également que le microcontrôleur charge ces valeurs dans la mémoire SPI.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

Fichier:P57 2019 Buffer.JPG

2019-05-02T13:09:09Z

Fleroy2 :

Fichier:P57 2019 Envoid'unfichier.JPG

2019-05-02T13:02:45Z

Fleroy2 :

IMA4 2018/2019 P57

2019-05-02T09:55:05Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="13"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="4"|32
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="4"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-02T08:56:01Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="12"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="3"|24
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="3"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-02T08:55:38Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="9"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
|colspan="3"|24
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
|colspan="3"| MAJ Size
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-01T17:55:17Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.
<center>
{| class="wikitable"
!colspan="9"|Entête d'une MAJ
|-
| '''Bits'''
|colspan="2"|16
|colspan="2"|16
|colspan="2"|16
| colspan="2"| 16
|-
| '''Uses'''
|colspan="2"| ID MAJ Provider
|colspan="2"| Groupe ID
|colspan="2"| Version
| colspan="2"| CheckSum
|}
</center>

Pour une sécurité optimale, ce schéma devra être encrypté. Un algorithme par cryptographie asymétrique serait parfait pour encoder et décrypter ce signal. La trame décodée pourra être reconnue comme étant correcte si l'ID MAJ Provider est correct. De plus, le checksum devra être correct également avant d'implémenter la MAJ. La version, quant à elle permettra d'éviter la mise à jour répétée de tous les capteurs si on désire installer de nouveaux capteurs ou si l'entreprise est trop grande pour mettre à jour tous les capteurs d'une traite. Le schéma se résumera en quelques étapes.

;Coté émetteur :
# Calcul du checkSum du code HEX
# Attribution d'une version au code ainsi que le Groupe ID ciblé
# Encryptage de la trame et du code HEX
# Émission à tous les capteurs de l'entête
# Temporisation afin de laisser faire le traitement
# Émission du code HEX encrypté

;Coté capteur :
# Reception d'une trame encodée
# Décodage de la trame
# Vérification de l'ID MAJ Provider, du Groupe ID et de la version
# Si tout correspond et version > version actuelle, réception de la trame et stockage dans la mémoire SPI
# Décryptage du code HEX
# Calcul du checksum et validation de l'authenticité
# Si le checksum est correct, transfert vers la mémoire de programme

Pour commencer, les algorithmes de cryptographies ne seront pas implémentés afin de limiter les bugs rencontrés.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-01T17:16:05Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la [https://github.com/TMRh20/RF24.git librairie python]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Atmega)]). Les mémoires ont pu êtres testées a l'aide de la[https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-01T17:14:45Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la librairie python [https://github.com/TMRh20/RF24.git librairie]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Arduino)]). Les mémoires ont pu êtres testées a l'aide de la librarie Flash [https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.
<div style="clear: both;"></div>
La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-01T17:13:55Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_Testemission.JPG|200px|thumb|left|Tests émission/réception]]
Des premiers tests ont été effectués avec la librairie python [https://github.com/TMRh20/RF24.git librairie]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Arduino)]). Les mémoires ont pu êtres testées a l'aide de la librarie Flash [https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.

La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

Fichier:P57 2019 Testemission.JPG

2019-05-01T17:13:22Z

Fleroy2 :

IMA4 2018/2019 P57

2019-05-01T17:12:35Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
Des premiers tests ont été effectués avec la librairie python [https://github.com/TMRh20/RF24.git librairie]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. Les codes sont simples a comprendre et donc le code pour le bootloader pourra commencer a partir de ces premiers codes sources ([http://electroniqueamateur.blogspot.com/2017/02/communication-entre-raspberry-pi-et.html Source (partie Raspberry)] et [http://electroniqueamateur.blogspot.com/2017/02/communication-par-nrf24l01-entre-deux.html Source (partie Arduino)]). Les mémoires ont pu êtres testées a l'aide de la librarie Flash [https://github.com/LowPowerLab/SPIFlash librarie SPIFlash]. Cette librarie fonctionne parfaitement avec la mémoire RAM et cause quelques erreurs avec la Flash mais sans aucune incidence car les tests de lecture et d'écriture sont concluants avec les deux types de mémoires.

La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-01T16:18:55Z

Fleroy2 : /* Travail supplémentaire (Partie Code) */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

Des premiers tests ont été effectués avec la librairie python [https://github.com/TMRh20/RF24.git librairie]. Celle-ci fonctionne parfaitement avec le capteur utilisée avec le code de base. [photos a venir]

La conception d'une entête permettant l'identification de la version, l'authenticité du paquet et du destinataire afin de débuter la réception. Premièrement le code sera implémenté dans la partie programme de l’Arduino afin de faciliter l'Upload. Puis celui ci sera transformé en bootloader après avoir obtenus des tests concluants.

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-05-01T15:54:16Z

Fleroy2 : /* Réalisation du Projet */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieure avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus, le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants et d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

==Travail supplémentaire (Partie Code)==

==Travail supplémentaire (Partie Réalisation)==

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:35:48Z

Fleroy2 : /* Semaine 3 à 7 */

IMA4 2018/2019 P57

2019-04-14T16:33:20Z

Fleroy2 : /* Semaine 3 à 7 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir à une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:31:49Z

Fleroy2 : /* Semaine 3 à 7 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentés'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:30:56Z

Fleroy2 : /* Semaine 2 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permise de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:28:26Z

Fleroy2 : /* Semaine 1 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencer avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:25:40Z

Fleroy2 : /* Semaine 1 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolu. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:22:28Z

Fleroy2 : /* Analyse du second concurrent */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mises-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:20:38Z

Fleroy2 : /* Positionnement par rapport à l'existant */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer à chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommations.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-14T16:17:46Z

Fleroy2 : /* Description */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise à jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2018/2019

2019-04-08T23:07:18Z

Fleroy2 : /* Présence */

== Répartition des binômes ==

{| class="wikitable"
| Projet || Analyse || Matériel || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P9 [[IMA4 2018/2019 P9|Spider and I]]
| La description des "concurrents" aurait pu être plus précise. Un effort sur le scénario d'usage qui aurait, lui aussi, pu être développé. Des coquilles. Un vague plan de travail.
| Rien ou presque, fournisseur non utilisable.
|
| N'utilisez pas le mode "code" (espace en première colonne) pour distinguer une ligne. Une progression régulière mais il faudrait résoudre les problèmes soulevés à la semaine 7. Le travail à réaliser est assez simple, un résultat parfait est attendu.
|
|
|
|-
| P10 [[IMA4 2018/2019 P10|Capteur de niveau d'eau et de pollution]]
| Des coquilles. Bonne description des concurrents. Un effort pour le scénario, bonne mise en contexte, forcer sur la description de l'usage. Un plan de travail correct.
| Une liste préliminaire de matériels. Fournisseurs correctement choisis. Rien sur la page principale.
|
| <font color="red">Coquilles inacceptables dans le Wiki</font>. <font color="orange">Wiki assez vide. Il est à espérer que le projet est plus avancé !</font>.
|
|
|
|-
| P12 [[IMA4 2018/2019 P12|Recyclage plastique imprimante 3D]]
| Vous êtes sur pour les servo-moteurs ? Ne serait-ce point des moteurs pas à pas ? Très bonne description du produit à réaliser avec illustrations. Bel effort de rédaction, encore pas mal de coquilles surtout en fin de page. Bonne étude des concurrents. Un scénario d'usage un peu rapide qui ne donne pas assez envie d'acquérir le produit. Questions difficiles mal exploitées (une réponse à la première question pourrait aussi être "par l'expérience", pas de réponse à la seconde question). Une étude solide du projet même si la liste des tâches à effectuer manque.
| Bonne question sur le budget, mais posez la si vous voulez une réponse :D Liste de matériel encore très embryonnaire : rien sur l'électronique, une discussion avec votre encadrant s'impose pour fixer la partie mécanique.
|
| <font color="green">Wiki très bien tenu mais corrigez les quelques coquilles. Avancé du travail bien présenté.</font> Vous devez toujours me présenter la note pour les matériels achetés chez Leroy-Merlin.
|
|
|
|-
| P13 [[IMA4 2018/2019 P13|Emetteur / Récepteur analogique en bande 5725-5875 MHz]]
| Un seul concurrent. Scénario d'usage ne donnant probablement pas la pleine mesure du produit. <font color="red">Rien sur la planification</font>.
| <font color="red">Rien.</font>
|
| <font color="red">Rien. Votre travail n'est pas évaluable. Votre projet est en péril.</font>
|
|
|
|-
| P14 [[IMA4 2018/2019 P14|Voiture autonome en modèle réduit]]
| Il me semble que le chassis doit être celui d'un modèle radio-commandé existant. Il me semble que le pilotage manuel n'est pas autorisé. Description un peu rapide des concurrents. Une synthèse du matériel et logiciels employés aurait été intéressant. Pour le scénario d'usage, une description avec la voiture comme sujet aurait être plus intéressant. La réponse à la première question ne va pas dans le sens de l'autonomie. Dire que python est le langage par défaut de la RPi n'a pas de sens. Vous avez tout intérêt à prendre le langage le plus efficace est ce n'est probablement pas python. Pas de servo-moteurs continus sur une voiture radio-commandé. Pas vraiement de plan de travail. <font color="orange">Prenez contact avec votre encadrant direct, j'aimerais que vos choix soient validés, certains me paraissent discutables.</font>
| Aucune référence précise pour les matériels. Rien sur la page principale.
|
| Wiki moyen, peu dense, très peu illustré. Vous partez comme les IMA5 sur une solution de votre cru alors que vous n'avez aucune expérience en réseaux de neurones. Il est à craindre que le résultat final soit décevant.
|
|
|
|-
| P22 [[IMA4 2018/2019 P22|Secure And Verified Public Announcements through Blockchain]]
| <font color="green">Excellente rédaction.</font> Une bonne tentative de description du projet mais toujours un flou sur le travail à réaliser. Cela aurait pu être levé avec une liste précise des tâches à effectuer (une tentative de liste dans les objectifs).
| Pas de matériel nécessaire (une RPi peut être).
|
| <font color="green">Un wiki très propre. Travail effectué décrit.</font>. Il manque juste l'information sur la validation du prototype 0 par l'encadrant direct.
|
|
|
|-
| P26 [[IMA4 2018/2019 P26|Discussion pair à pair]]
| <font color="red">Nombre de coquilles inacceptable</font>. Rajouter dans les objectifs de devoir tenter une ouverture de bouclier pour TCP (TCP Hole Punching). Analyse du premier concurrent : le prétexte pour n'utiliser que des serveurs microsoft pour les supernoeuds skype est le faible nombre de machines d'utilisateurs non handicapées par des parefeux. Bonne réponse aux questions difficile. L'expérience de skype dit qu'il faut totalement éviter qu'un noeud utilisateur ait à relayer les communications d'un autre utilisateur (ce qui est d'ailleurs contraire aux objectifs). Il faut donc une solution de pair à pair pour '''tous''' les clients. En particulier, IPv6 '''doit''' être intégré dans les solutions possibles. Il ne me semble pas que l'enregistrement des utilisateurs soit nécessaire, elle nuit même à la vie privée. Il faut simplement mémoriser les utilisateurs connectés.
| Pas de matériel listé pourtant il faut mettre en place un banc d'essai.
|
| <font color="red">Coquilles inacceptables dans le Wiki</font>. <font color="orange">En fin de projet vous avez seulement mis en place le banc de test sans aucun développement d'un système de perçage de box que ce soit en UDP ou en TCP</font>.
|
|
|
|-
| P28 [[IMA4 2018/2019 P28|Affichage à billes]]
| Pour les panneaux d'affichage publicitaire, je ne suis pas sur que la consommation puisse être qualifiée d'énorme (il semble que si, à la lecture de votre réponse aux questions difficiles mais cela doit comprendre l'éclairage dont votre produit pourrait avec aussi besoin). <font color='green'>Rédaction très correcte. Un gros effort sur les illustrations. Un scénario d'usage, lui aussi, bien rédigé</font>. La réponse à la question difficile sur l'énergie consommée par votre produit ne me convainc pas : partez sur la différence d'énergie potentielle pour monter une bille pas sur la force à exercer qu'il faudrait intégrer sur la hauteur de la remontée. Il faut approfondir l'analyse des tâches à effectuer.
| Il me semble avoir demandé de limiter la complexité du dispositif : 8 moteurs ?? Pas de références précises pour les matériels (lien sur le matériel dans le site du fournisseur).
|
| <font color="green">Très bon Wiki. Avancé du travail très bien présenté.</font> On attend avec impatience le résultat des tests sur le prototype "carton".
|
|
|
|-
| P30 [[IMA4 2018/2019 P30|Système minimal de gestion de conteneurs]]
| <font color="green">Excellent Wiki à ce jour. Rédaction très claire. Très bonne introduction. Tâches à réalisées clairement listées (mais dans les objectifs). Présentation très correcte du "concurrent principal". Un scénario d'usage correct (j'aurais plutôt insisté sur la faible consommation du système en ressources que sur l'installation dans un système fortement personnalisé). Un calendrier prévisionnel.</font> Le second "concurrent" est en fait l'ancienne couche bas niveau de <code>Docker</code>. Il faudrait utiliser la syntaxe Wiki mais ne touchez à rien avant la séance du 10 décembre cela me fera un exemple parfait pour expliquer cette syntaxe.
| Pas de matériel nécessaire (une machine virtuelle sera concédée en cours de projet).
|
| <font color="green">Wiki très complet et très propre. Avancé du travail bien présenté.</font> Il faut arriver à finaliser les scripts de gestion des conteneurs.
|
|
|
|-
| P31 [[IMA4 2018/2019 P31|Robot hexapode de mesure de RSSI WiFi]]
| <font color="red">Beaucoup trop de coquilles</font>. Bonne présentation des "concurrents" qui vous servent aussi pour expliquer que votre projet est leur synthèse. Le scénario d'usage se tient. Bonne réponse à la question. Je ne crois pas trop au positionnement par RFID (il faut être sur un tag RFID pour le lire). Etes-vous sur pour l'Arduino méga ? Un Uno avec un bouclier PWM ne serait-il pas plus efficace ?
| <font color="green">Effort de liste de matériel avec des références précises</font>. Pas de liste sur la page principale.
|
| <font color="orange">N'utilisez pas le mode "code" de mediawiki (espace en première colonne) pour distinguer des lignes. Utilisez la syntaxe pour les items. Wiki très peu dense. L'avancement du projet semble être suspendu.</font> Un bel effort pour la partie mécanique (les pattes du robot). Par contre la partie programmation semble très peu avancée.
|
|
|
|-
| P32 [[IMA4 2018/2019 P32|Robe augmentée]]
| En français l'abréviation de Monsieur est M. Mr est l'abrévation de Mister donc à n'utiliser qu'en anglosaxonnerie. Attention nous avons une expérience du fil à coudre conducteur et cela ne marche pas très bien sauf sur une surface très réduite. <font color="orange">Le scénario d'usage est perturbant : cela semble être un scénario pour deux produits différents</font>. <font color="orange">Vous avez considérablement simplifié le projet (sous-ensemble de projets déjà réalisés), la réalisation devra être impeccable pour que cela puisse être validé comme projet IMA4</font>.
| La liste du matériel précise ce que vous souhaitez faire. Que vient faire la platine d'essai dans cette liste ? Pour le prototype ? Vous ne parlez pas du tout de la carte contrôleur. C'est une Lilypad ?
|
| Wiki bien illustré mais une rédaction séche. Développez un peu. OK pour les cartes électroniques mais vous devriez présenter une esquisse de la robe telle que vous souhaitez la réaliser.
|
|
|
|-
| P33 [[IMA4 2018/2019 P33|Collier à animations lumineuses]]
| Un français imaginatif avec un nombre de coquilles dans la moyenne. Un scénario d'usage rocambolesque (il doit me manquer quelques références) mais acceptable. Des concurrents pertinents. Réponses aux questions acceptables. Se limiter à trois plaques ne me semble pas pertinent (même si vous pouvez faire un premier test sur trois plaques). Pour l'étude de la communication prévoyez un prototype avec quelques Arduino.
| Une liste de matériel qui semble être établie à la hâte. Il manque de nombreux composants électroniques pour faire tourner micro-contrôleurs et pilotes de LED. Pas de référence précise pour les composants.
|
| <font color="red">Rien sur votre travail, il n'est donc pas évaluable. Votre projet est en péril.</font> Vous devriez avoir fait les tests de communication sur le bus SPI et avoir conçu votre PCB.
|
|
|-
| P35 [[IMA4 2018/2019 P35|Machine Learning pour navigation autonome de robots mobiles]]
| Il n'est pas tenu compte des erreurs de français. Dans la partie objectifs, la première sous-partie devrait plutôt s'appeler "partie robotique", il n'y a rien d'électronique ici. Le travail a effectuer est assez flou. En particulier le Wiki ne contient rien sur les bibliothèques de "machine learning" à utiliser.
| Le matériel est fourni par les encadrants directs (AIP ?)
|
| <font color="red">J'ai peur que votre Wiki rende bien compte du travail effectué jusque là : uniquement des études, rien de concret à part utiliser une manette pour acquérir des jeux de données. C'est très inquiétant en cette période de fin de projet. Votre projet pourrait ne pas être validé.</font>
|
|
|
|-
| P37 [[IMA4 2018/2019 P37|Station de recharge intelligente pour robot mobile]]
| Trop de coquilles. <font color="orange">Il semble que le sujet initial ne correspond plus à ce qui est demandé, merci de préciser le nouveau sujet, calibrage du robot ?</font>Comment comptez-vous calibrer un préhenseur avec simplement du code (pas de réponse au niveau de la question difficile) ? <font color="red">Un seul concurrrent et sur la partie obsolète du projet</font>. Une analyse du travail a effectuer qui ne tient pas compte de l'abandon du sujet original.
| <font color="red">Aucune liste de matériel</font>
|
| Rien à redire sur votre Wiki. Il me semble bien rendre compte de l'avancé de votre projet. <font color="red">Une liste de matériel finalisée en fin de projet : vous prenez de grands risques. Je vous rappelle qu'un prototype fonctionnel est attendu.</font>
|
|
|-
| P38 [[IMA4 2018/2019 P38|Interface Graphique pour Robotino 2 Upgradé]]
| Choix des "concurrents" peu pertinents ou il fallait insister sur les différences entre ces robots et le robotino 2 amélioré. Le scénario d'usage se tient. Bonne réponse à la question "difficile". Il semble que le but du projet se réduise à créer une interface web avec une bibliothèque spécifique. <font color="orange">L'interface devra être irréprochable pour constituer un projet IMA4</font>.
| Projet purement informatique, pas de matériel nécessaire (autre qu'un robotino amélioré).
|
| <font color="orange">N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Corrigez les coquilles ! En cette fin de projet vous semblez bien peu avancés sur l'interface Web. Rien sur la démonstration de fonctionnement du robotino que vous devez implanter. Il va falloir diantrement accélérer !</font>
|
|
|
|-
| P40 [[IMA4 2018/2019 P40|RFID/NFC]]
| L'objectif est clairement explicité et dans un français très correct. Desc concurrents peu pertinents et une analyse trop hâtive des dits concurrents. La réponse sur la question de la difficulté du projet n'est pas convaincante. <font color="orange">Votre application de contrôle du robotino par smartphone se devra d'être irréprochable pour constituer un projet IMA4</font>.
| Attention, tout votre projet repose sur la validité des lecteur RFID commandés. Si ces lecteurs ne sont pas utilisables votre projet tombe à l'eau. Vous avez étudié la compatibilité des lecteurs avec les robotino ?
|
| Vous semblez avoir avancé dans votre projet mais vos dernières entrées dans le Wiki sont trop courtes pour permettre de juger. Etoffez votre Wiki en décrivant mieux cette application (copies d'écrans). Je ne vois aucune trace de la partie de connexion IP automatique via NFC au robotino ?
|
|
|
|-
| P42 [[IMA4 2018/2019 P42|Coupe de robotique des écoles primaires]]
| <font color="red">Beaucoup trop de coquilles</font>. Objectifs très clairement précisés. Analyse des concurrents et réponse lapidaires. Le fait que vous ne respectiez pas le cahier des charges imposé aux enfants est problématique. <font color="green">Une liste précise des tâches a effectuer. Un calendrier prévisionnel.</font>
| Bel effort de liste de matériel. Quelques composants chez des fournisseurs non agréés. <font color="green">Liste sur la page principale</font>.
|
| <font color="green">Wiki plus que correct qui donne bien une idée de la progression.</font> Tentez d'appeler Robotshop pour savoir ce qu'est devenue la commande. Il faut aussi que vous vous penchiez sur le PCB de commande des LED et servo-moteurs de la piste.
|
|
|
|-
| P44 [[IMA4 2018/2019 P44|Clônes améliorés des modules ARDUINO]]
| Restriction du sujet à la conception et réalisation d'une seule carte, ce qui est, ma foi, prudent. Bonne description de "concurrents". Des coquilles mais sans plus. Ne mettez pas d'espace ou d'accents dans les noms des fichiers téléchargés. Scénario d'usage acceptable. Clairement vous avez déjà pas mal réfléchi à votre carte.
| Une liste de matériel mais sans lien vers le composant chez un fournisseur agréé.
|
| <font color="red">Rien. Votre travail n'est pas évaluable. Votre projet est en péril.</font>
|
|
|
|-
| P45 [[IMA4 2018/2019 P45|Sac à main ou sac à dos solaire]]
| <font color="green">Wiki très bien illustré, rédaction assez correcte (quelques coquilles)</font>. Bonne description de concurrents, scénario d'usage convenable. Réponses un peu rapides aux questions "difficiles"
| Une liste de composants qui parait encore bien préliminaire. Aucun lien sur les composants chez les fournisseurs.
|
| <font color="orange">Vous avez posé quelques réflexions dans votre Wiki. Cependant aucune trace de réalisation. Une liste de matériel exploitable trop tardive.</font>
|
|
|
|-
| P46 [[IMA4 2018/2019 P46|Kit Robot]]
| PLutôt bien rédigé malgré quelques coquilles. Objectifs bien fixés. Concurrents décrits en détail (un peu de synthèse n'aurait pas fait de mal). <font color="green">Scénario d'usage très correct</font>.
| Un liste de composants bien avancée. <font color="green">Des liens vers les fournisseurs. Matériels sur la page principale.</font>
|
| Le Wiki est correct. Vous semblez avoir terminé la phase de conception même s'il manque les informations sur le PCB. Disons que je serais rassuré quand vous aurez découpé les pièces du chassis et fait réaliser la carte électronique. En une phrase : il est plus que temps d'avoir des résultats tangibles !
|
|
|
|-
| P57 [[IMA4 2018/2019 P57|Mise à jour over the air]]
| Bon cahier des charges qui répond aux questions que l'on pourrait se poser à la lecture du reste de la page. Quelle différence entre votre solution et Dualoptiboot du coup ? Dualoptiboot ne comprend pas la partie matérielle ? Allez-vous l'utiliser ? Un scénario d'usage bien rapide. La réponse semble à coté de la question, il semble que vous répondez à la question "comment vérifier une somme de contrôle avant de flasher la mémoire programme ?". Comment allez vous gérer la clef de chiffrement ? Elle est figée dans l'amorceur ? Je crois comprendre en fin de page que vous voulez fixer une clef par capteur, cela casse le principe de la mise à jour par diffusion radio, non ?
| Une première liste de matériel sans lien vers les sites des fournisseurs agréés.
|
| <font color="orange">N'utilisez pas le mode "code" de mediawiki pour distinguer une ligne. Cinq semaines pour router une carte ? Au minimum donnez les problèmes rencontrés et les résultats obtenus. Dans l'état de vacuité de votre Wiki, il est légitime de douter de la validation du projet.</font>
|
|
|
|-
| P63 [[IMA4 2018/2019 P63|Etude de la consommation d'un capteur de pollution]]
| <font color="green">Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire</font>.
| Une liste de matériel avec des liens vers des fournisseurs. Par contre les fournisseurs choisis ne sont pas forcément utilisables.
|
| Il y a comme un trou entre la semaine 3 et la semaine 7 ? Un problème de légende et de figure. <font color="green">Wiki acceptable.</font> <font color="orange">Les cartes doivent être vérifiées et réalisées de toute urgence.</font>
|
|
|
|-
| P70 [[IMA4 2018/2019 P70|Impact du matériel et du logiciel sur le rayonnement électromagnétique]]
| <font color="green">Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire.</font>
| Une liste de matériels très embryonnaire et sans lien exploitable.
|
| Le Wiki n'est pas à jour et ne permet pas de se faire une idée du travail des deux dernières semaines. Rien à redire sur le travail antérieur.
|
|
|
|-
| P72 [[IMA4 2018/2019 P72|Mesure du courant simple]]
| <font color="green">Rédaction correcte. Wiki bien illustré. Une partie analyse correcte.</font>
| <font color="green">Une liste de matériel bien avancée avec des liens exploitables.</font> Recopiez les liens sur la page principale.
|
| <font color="green">Wiki très correct. Bien illustré. Il manque le schematic de la carte, vous l'avez réalisé n'est-ce pas ?</font> <font color="orange">Vous devriez déjà avoir routé et réalisé votre carte.</font>
|
|
|
|-
| P73 [[IMA4 2018/2019 P73|Ecriture automatique de partition musicale]]
| <font color="green">Rédaction très correcte. Une partie analyse tout à fait correcte. La liste des tâches à effectuer est détaillée et claire. Un calendrier prévisionnel.</font>
| Une tentative de liste de matériel qui ne pourra effectivement être finalisé qu'après discussions avec un électronicien.
|
| <font color="green">Wiki très correct. Bien illustré.</font> Par contre vous semblez marquer le pas sur ces deux dernières semaines alors qu'il s'agirait, au contraire, de mettre un coup d'accélerateur. <font color="orange">Routez cette carte, il est plus que temps !</font>
|
|
|
|-
|}

== Présence ==

{| class="wikitable"
! Projet !! Elèves !! 10/12/2018 !! 16/01/2019 !! 23/01/2019 !! 30/01/2019 !! 06/02/2019 !! 13/02/2019 !! 27/02/2019 !! 06/03/2019 !! 13/03/2019 !! 20/03/2019 !! 27/03/2019 !! 03/04/2019
|-
| P9 [[IMA4 2018/2019 P9|Spider and I]]
| Nestor Martinez / Lina Mejbar
| OK
| E305
| E305
| E305
| E304
| A208
| E304
<font color="green">Présents</font>
| E304
| E304
<font color="green">Présents</font>
| E304
| E304
| E304
|-
| P10 [[IMA4 2018/2019 P10|Capteur de niveau d'eau et de pollution]]
| Antoine Branquart
| Absent (certificat médical)
| E305
| E305
| E301
| Absent (certificat médical)
| E301
| E303
<font color="green">Présent</font>
| <font color="blue">Excusé (malade)</font>
| C201
<font color="green">Présent</font>
|C201
|C201
|C201
|-
| P12 [[IMA4 2018/2019 P12|Recyclage plastique imprimante 3D]]
| Corentin Danjou / Pol Mulon
| OK
| E305
| E305
| E301
| E304/E301
| E301
| E303
<font color="green">Présents</font>
| E303
| E303
<font color="green">Présents</font>
| E304 / C201
| Fabricarium / C201
| Fabricarium
|-
| P13 [[IMA4 2018/2019 P13|Emetteur / Récepteur analogique en bande 5725-5875 MHz]]
| Arthur Reviron
| Absent
| C201
| C201
| C201
| C201
| C201
| C201
<font color="green">Présent</font>
|
| C201
<font color="green">Présent</font>
|-
| P14 [[IMA4 2018/2019 P14|Voiture autonome en modèle réduit]]
| Hugo Dejaegher / Brandon Elemva
| OK
| E306
| E306
| E306
| E306
| E306
| E306 + Fabricarium
| E306
<font color="green">Présents</font>
| E306
| E306
<font color="green">Présents</font>
| E306
| E306
|-
| P22 [[IMA4 2018/2019 P22|Secure And Verified Public Announcements through Blockchain]]
| Arezki Ait Mouheb
| OK
| E306
| E305
| E306
| E306
| E306
| E306
<font color="green">Présent</font>
| E306
| E306
<font color="green">Présent</font>
| E306
| E306
|-
| P26 [[IMA4 2018/2019 P26|Discussion pair à pair]]
| Fabien Di Natale / Ibrahim Ben Dhiab
| OK
| E304
| E304
| E304
| E304
| E304
| E304
<font color="green">Présents</font>
| E304
| E304
<font color="green">Présents</font>
| E304
| E304
| E304
|-
| P28 [[IMA4 2018/2019 P28|Affichage à billes]]
| Flora Dziedzic / Martin Michel
| OK
| Fabricarium
| E305
| Fabricarium
| Fabricarium
| A311
| Fabricarium
| Fabricarium
<font color="green">Présents</font>
| Fabricarium
| Fabricarium
<font color="green">Présents</font>
| Fabricarium
| Fabricarium
|-
| P30 [[IMA4 2018/2019 P30|Système minimal de gestion de conteneurs]]
| Hind Malti
| OK
|E304
|E304
|E304
|E304
|E303
|E306
<font color="green">Présente</font>
|E306
|E306
<font color="green">Présents</font>
|E306
|E306
|E306
|-
| P31 [[IMA4 2018/2019 P31|Robot hexapode de mesure de RSSI WiFi]]
| Rémi Foucault / Hugo Velly
| OK
|E304
|E304
|E304 / Fabricarium
|E304 / Fabricarium
|E304
|E303
<font color="green">Présents</font>
|E303
|E303
<font color="green">Présents</font>
|E303/C202-bis
|E304
|C201
|-
| P32 [[IMA4 2018/2019 P32|Robe augmentée]]
| Brinda Muzakare / Yan Xuelu
| OK
| E304
| E304
| E304
| E304
| E304
| E304
<font color="green">Présentes</font>
| E304
| E304
<font color="green">Présentes</font>
| E304
| E304
|-
| P33 [[IMA4 2018/2019 P33|Collier à animations lumineuses]]
| Loris Ahouassou
| OK
| E306
| E305
| E304
| E304
| C201
| E304
<font color="green">Présent</font>
| E304
|
<font color="red">Absent</font>
| E304
|-
| P35 [[IMA4 2018/2019 P35|Machine Learning pour navigation autonome de robots mobiles]]
| Wenjing Chen / Puyuan Lin
| OK
| E304
| E305
| C304
| C102
| C304
| C304
<font color="red">Absents</font>
| C002
<font color="green">Présents</font>
| C002
<font color="green">Présents</font>
|-
| P37 [[IMA4 2018/2019 P37|Station de recharge intelligente pour robot mobile]]
| Guillaume Declerck / Pierre Guigo
| OK
| E305
| E305
| E301
| E303
| E301
| E303
<font color="green">Pierre Guigo présent</font>
<font color="red">Guillaume Declerck absent</font>
| E303 & C201
| C201 & E303
<font color="green">Présents</font>
|
|C203
|-
| P38 [[IMA4 2018/2019 P38|Interface Graphique pour Robotino 2 Upgradé]]
| François Brassart / Jérôme Haon
| OK
| E304
| E304
| E303
| E304
| E305
| E304
<font color="green">Présents</font>
| E304
| E304
<font color="green">Présents</font>
|C304
|C304
|C304
|-
| P40 [[IMA4 2018/2019 P40|RFID/NFC]]
| Jean De Dieu Nduwamungu / Xinwei Hu
| OK
| E305
| E304
| E304
| E304
| E304
| E304
<font color="green">Présents</font>
| E304
| E304
<font color="green">Présents</font>
| E304
| E304
|-
| P42 [[IMA4 2018/2019 P42|Coupe de robotique des écoles primaires]]
| Pierre Frison / Thibault Lepoivre
| OK
| E305
| E305
| E304
| Fabricarium
| E301(fab fermé)
| Fabricarium
<font color="green">Présents</font>
| Fabricarium
| Fab et C201
<font color="green">Présents</font>
| Fabricarium
| E303 (Lepoivre) / frison absent(malade)
|-
| P44 [[IMA4 2018/2019 P44|Clônes améliorés des modules ARDUINO]]
| Théau Moinat
| OK
| C201
| C201
| C201
| C201
|
| C201
<font color="green">Présent</font>
| C201
| C201
<font color="green">Présent</font>
|-
| P45 [[IMA4 2018/2019 P45|Sac à main ou sac à dos solaire]]
| Mathis Dupré
| OK
| E305
| E305
| E301
| E304
| E306
| E306
| E306
<font color="green">Présent</font>
| E306
| E306
<font color="green">Présent</font>
| C201
|-
| P46 [[IMA4 2018/2019 P46|Kit Robot]]
| Valentin Pitre / Gaëlle Bernard
| OK
| E304
| E305
| E303
| E304
| A208
| E304
| E304
<font color="green">Présents</font>
| E304
<font color="green">Présents</font>
| E304
| C202
| C202/E306
|-
| P57 [[IMA4 2018/2019 P57|Mise à jour over the air]]
| Florent Leroy
| OK
| C201
| C201
| C201
| C201
| C201
| C201
<font color="green">Présent</font>
| C201
| C201
<font color="green">Présent</font>
| C201 & E304
| C201 & E304
| E304
|-
| P63 [[IMA4 2018/2019 P63|Etude de la consommation d'un capteur de pollution]]
| Victor Lorthios / Juliette Obled
| OK
| C201
| C201
| C201
| C201
| C201
| C201+E303
<font color="green">Présents</font>
| E303
| C201
<font color="green">Présents</font>
| C201
| C201
|-
| P70 [[IMA4 2018/2019 P70|Impact du matériel et du logiciel sur le rayonnement électromagnétique]]
| Antoine Moreau / Souheib Khinache
| OK
| E305
| E305
| E304
| E304
| E304
| E304
<font color="green">Présents</font>
| E304
| Fabricarium
<font color="green">Présents</font>
| Fabricarium
| Fabricarium
| Fabricarium
|-
| P72 [[IMA4 2018/2019 P72|Mesure du courant simple]]
| Raphaël Martin
| OK
| E305
| E305
| E301
| E303
| E303
| E303
| E303
<font color="green">Présent</font>
| E303
| E303
<font color="green">Présent</font>
| E303
| Fabricarium
|-
| P73 [[IMA4 2018/2019 P73|Ecriture automatique de partition musicale]]
| Hugo Leurent / Fabien Ronckier
| OK
| C201
| C201
| C201
| C201
| C201
| C201
<font color="green">Présents</font>
| C201
| C201
<font color="green">Présents</font>
| C201
| C201
|-
|}

IMA4 2018/2019 P57

2019-04-08T23:04:20Z

Fleroy2 : /* Semaine 11 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même conception. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-08T22:58:01Z

Fleroy2 : /* Semaine 11 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même infrastructure réseau. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]
[[Fichier:P57_2019_Schematique_final2.JPG|500px|thumb|center|Schématique carte shield]]

=Documents Rendus=

Fichier:P57 2019 Schematique final2.JPG

2019-04-08T22:56:37Z

Fleroy2 :

IMA4 2018/2019 P57

2019-04-08T22:49:43Z

Fleroy2 : /* Semaine 11 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même infrastructure réseau. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures. Les fichiers de documentations ont également été réalisés pour cette carte. [[Fichier:P57_2018_CarteV2.PDF]]

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, '''la carte est 100% fonctionnelle''' à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]

=Documents Rendus=

Fichier:P57 2018 CarteV2.PDF

2019-04-08T22:48:18Z

Fleroy2 :

IMA4 2018/2019 P57

2019-04-08T22:45:50Z

Fleroy2 : /* Semaine 8 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tutoriels permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même infrastructure réseau. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures.

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, la carte est 100% fonctionnelle à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-08T22:45:28Z

Fleroy2 : /* Feuille d'heures */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 15
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tuto permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même infrastructure réseau. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures.

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, la carte est 100% fonctionnelle à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-08T22:45:05Z

Fleroy2 : /* Feuille d'heures */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
| 13
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tuto permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même infrastructure réseau. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures.

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, la carte est 100% fonctionnelle à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]

=Documents Rendus=

IMA4 2018/2019 P57

2019-04-08T22:44:05Z

Fleroy2 : /* Semaine 11 */

__TOC__
<br style="clear: both;"/>

=Présentation générale=

==Description==
[[Fichier:P57-2018-prez.jpg|center]]
<br>
Les capteurs sont omniprésents dans le domaine de l'entreprise. Une usine peut disposer de plusieurs centaines de capteurs répartis dans toute sa structure. Ces capteurs ont des rôles différents comme la mesure de la température, la présence d'une pièce où encore la mesure métrique d'un élément. <br>
Chacun de ces capteurs peut être amené a être mis à jour afin de modifier un temps de réponse ou changer la couleur de détection d'un capteur optique etc...<br>
Ces mise-à-jours peuvent être fastidieuses à implémenter car nécessite l'intervention physique d'un opérateur et la mise à jour se fait pour chaque capteur individuellement.

==Objectifs==
<br>
L'objectif de ce projet est de proposer un système permettant de reprogrammer un capteur de manière OTA (Over The Air) sans aucune intervention physique.<br><br>
Le système devra être :
# '''Sécurisé''' : la mise à jour devra être vérifié (provenance, checksum) avant l'implémentation.
# '''Économe en énergie''' : l'impact énergétique sera pris en compte dans le choix des technologies.
# '''(Bonus)''' Le système sera générique afin de pouvoir mettre a jour un groupe de capteur automatiquement

=Analyse du projet=

==Positionnement par rapport à l'existant==
Un système semble déjà exister pour les composants ATmega328P(arduino) [https://www.mysensors.org/about/fota] <br>
Le but de ce projet sera de créer un module indépendant qui devra respecter certains critères afin de pouvoir être polyvalent et s'appliquer a chaque capteur. Ce module sera ajouté à chaque capteur lors de sa fabrication. Une étude du coup supplémentaire sera alors effectuée.
# '''Polyvalence''' : le module pourra s'implémenter à chaque capteur facilement sans ajouter un code particulier.
# '''Sécurisé''' : chaque mise à jour sera contrôlée avant l'implémentation du programme. (calcul du MD5 Checksum + Clée de décryptage)
# '''Économe en énergie''' : ce module devra utiliser le moins possible de courant. Les composants seront donc choisis pour leurs consommation.
<br>
'''Avantages''' :
# Hautement sécurisé : chaque mise à jour sera vérifiée à l'aide d'une clé de cryptage et d'un checksum.
# Peut théoriquement s'adapter à tout type de capteur.
# Temps de mise hors service très court. (Par rapport à une maintenance physique)
<br>
'''Inconvénients''' :
# Coûts de fabrication plus important

==Analyse du premier concurrent==

'''MYSBootloader by Tekka (Mysensors Team)'''<br><br>
Ce système fonctionne en tant que bootloader uniquement sur les microcontrôleurs ATmega328P. Lors du boot du microcontroleur ou reset, il applique la mise à jour du code qu'il a reçu. Lors de la réception de la mise à jour le capteur doit être offline.<br>
Ce système ne nécessite pas de mémoire externe.<br><br>
'''Avantage''' :
# Si le firmware est défectueux, il est possible de réimplémenter <br>
'''Inconvénients''' :
# Le capteur doit être en mode '''hors-ligne''' afin de pouvoir se mettre à jour (il doit rebooter)
# le bootloader dépend énormément du module radio (un bootloader différent pour chaque module radio)

==Analyse du second concurrent==
'''Dualoptiboot''' by Lowpowerlab <br><br>
Cette solution est une solution codée dans le firmware à implémenter. Elle nécessite une mémoire externe afin de stocker le firmware reçu avant de le téléverser dans la mémoire interne du microcontrôleur. En incluant la librairie Dualoptiboot, un programme scrutant les mise-à-jour est continuellement exécuté.
<br><br>
'''Avantages''' :
# Ne dépend pas du module radio.
# Peut être mis à jour en fonctionnement

'''Inconvénients''' :
# Un firmware défectueux ne peut plus être mis-à-jour OTA
# Nécessite une mémoire externe

==Positionnement par rapport a la concurrence==
Les concurrents utilisent le système radio comme communication entre un serveur et plusieurs capteurs. Cette communication s'effectue dans les deux sens et permet de réaliser un diagnostic et envoyer les mises a jour en clair via les ondes radios. Cependant ces mises à jour ne sont pas cryptés. De plus n'importe quel ordinateur sur le réseau pourrait envoyer les mises à jour sans qu'il y ai de vérification de sécurité.
<br> Pour faire simple, la solution proposée par les concurrents est surtout utilisé pour effectuer de la domotique ou d'autres taches au domicile. Cependant, la sécurité est quand a elle insuffisante pour l'implantation dans l'entreprise.<br>
Une clée de cryptage sera attribuée à chaque entreprise.
Le système proposé sera '''différent''' de :
<br>
'''MYSBootloader''' par :
# Le bootloader contiendra toutes les fonctions permettant de décoder les trames reçues.
# Il exécutera en plus du code du capteur, un processus de scrutation du signal radio et lors de la réception d'une mise-à-jour, stockera et traitera les informations. Au lieu d'écrire directement. (Par l'implémentation d'un ordonnanceur)
# La mise à jour pourra être reçue en fonctionnement '''sans avoir a rebooter'''
<br>
'''Dualoptiboot''' par :
# Mis-a-part le checksum, aucune vérification de sécurité n'est réalisée.
# L'algorithme de sécurité contenant la clé de décryptage ne peut pas être contenue dans une librairie transmise au client. (Un usager mal intentionné pourrait exploiter ces données pour pouvoir diffuser de fausses mise-à-jour)
# L'utilisateur n'aura pas a recompiler à chaque fois la partie gestion du module radio.
<br>
Cependant ces différences apportent leurs lots de contraintes :
# Une place utilisée sur la mémoire interne de l'Atmega plus importante.
# Un temps de traitement plus long lors de la vérification des mises à jour
# La nécessité d'avoir une mémoire interne afin de réaliser le traitement

==Scénario d'usage du produit ou du concept envisagé==
[[File:8d054c8b70dfa86ff542fae6930b530d.jpg|left|100px|légende]]
'''Scénario''' : <br>

Le chef d'entreprise doit mettre à jour ses capteurs afin de pouvoir gagner en productivité (envoi de donnée plus rapide). Un technicien doit démonter et reprogrammer un a un plusieurs centaines de capteurs alors que son chef lui demande d'aller plus vite car la chaine de production est interrompue. Quand SensorOTA propose de mettre a jour en quelques secondes tous les capteurs à l'aide d'une antenne et de la communication broadcast avec presque aucune coupure.

<br/>

==Réponse à la question difficile==
'''Comment faire pour que l’ATMEGA puisse se reprogrammer toute seule ?'''
<br/>
Pour pouvoir écrire dans l'EEPROM (la mémoire interne de l'ATMEGA), il faut posséder une autre mémoire (vive ou morte).
Le choix s’oriente vers une EEPROM pour plusieurs raisons :
# La consommation énergétique presque nulle en dehors des lectures et écritures.
# La mémoire conserve la mise à jour même si elle est déconnecté du réseau (mémoire morte).
Cependant, d'autres facteurs peuvent être contestés :
# Le coût est légèrement supérieur a un autre type de mémoire (mémoire vive)
# Durée de vie plus courte (10 000 écritures)

<br/>
<br/>
L'Atmega peut réécrire son programme interne grâce au bootloader. Le bootloader est une portion de code qui s'exécute avant le programme principal. Actuellement, le bootloader optimise la vitesse d'exécution du code. <br/>
Des bootloader alternatifs existent, c'est le cas notament de celui de Dave Berkeley '''site WEB'''[[https://www.rotwang.co.uk/projects/bootloader.html]] '''Github''' : [[https://github.com/DaveBerkeley/arduino/tree/master/boot/optiboot]]<br/>
Toutefois, celui-ci ne s'occupe pas de la sécurité nécessaire a une mise en production ainsi que l'identification d'un capteur spécifique.

=Préparation du projet=

==Cahier des charges==
Le projet choisi doit permettre une implémentation en usine ainsi qu'une commercialisation possible. Pour cela de nombreux aspects doivent êtres analysés.
<br/>
# Le système devra avoir une portée suffisante (environs 50m)
# L'ATMEGA ne sera reprogrammé qu'après avoir acquis la certitude que la mise à jour est authentique (Algorithme par cryptographie symétrique + Checksum)
# La transmission de mise-à-jour devra être cryptée afin d'éviter qu'une écoute réseau révèle le contenu de celle-ci. (Données cryptées envoyées sur le réseau)
# La consommation du capteur ne devra pas augmenter de plus de '''10%''' de la consommation habituelle
# Les performances du capteur ne devront pas être impactées en dehors des mises à jour.
<br>
De plus d'un point de vue architecture :
<br/>
# Le système utilisera des composants répandus sur le marché afin de pouvoir être réparé a moindre frais
# Le système n'utilisera pas de CMS afin de pouvoir être entretenu par l'utilisateur. (Et aussi afin de pouvoir réduire les couts de fabrication)
# Un autre moyen de reprogrammation devra être implémenté afin de pouvoir mettre a jour manuellement (en cas de panne).

==Choix techniques : matériel et logiciel==

'''Matériel nécessaire :''' (pour la partie capteur)
# ATMEGA328P-Au x1 [https://www.microchip.com/wwwproducts/en/ATmega328p]
# USB-TTL Arduino Programmer
# Flash 128kB [https://www.mouser.fr/ProductDetail/Winbond/W25X10CLSNIG?qs=sGAEpiMZZMve4%2fbfQkoj%252bOhLEICX0StD3ede4x7EGwE%3d]
# SRAM 128kB [https://www.mouser.com/ProductDetail/ISSI/IS62WVS1288FBLL-20NLI?qs=sGAEpiMZZMt9mBA6nIyysO%252bUVEHy8kHdw1Lt0j8%2flOw%3d]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# BreadBoard
# 16Mhz oscillator [https://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?gclid=Cj0KCQiA-JXiBRCpARIsAGqF8wUEu0Ne-RC-vjXZ_b2i6tajmkh-N3i4CzSyy-ehYtkqTLWsK0wsu7waAu6-EALw_wcB&gross_price=true&mckv=kpBqurSg_dc|pcrid|80993958782|&CAWELAID=120185620000131014&CAGPSPN=pla&CAAGID=13038031862&CMP=KNC-GFR-GEN-SHOPPING-9713808&CATCI=pla-73752353462]
# Capacitors
# 3v3 regulator [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM1117MP-33-NOPB?qs=X1J7HmVL2ZFn4x9DZ4T2hA%3D%3D]
# Led x1
# Resistance x1

'''Matériel nécessaire :''' (pour la partie émetteur)
# Raspberry Pi [[https://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/1720555/]]
# NRF24L01 [https://www.robotshop.com/en/24g-transceiver-nrf24l01p-module.html]
# 1 ecran lcd Raspberry pi [https://fr.rs-online.com/web/p/kits-de-developpement-pour-afficheurs-graphiques/8997466/]

''' Choix Logiciel :'''<br/>
Je choisis de m'inspirer du programme concurrent MYSBootloader qui sera modifié afin de permettre la mise à jour pendant le fonctionnement. '''FreeRTOS''' pourra être utilisé dans ce projet.
<br/><br/>
L'architecture de la mémoire sera semblable a celle trouvée sur les Arduino.

==Liste des tâches à effectuer==
Taches à effectuer (dans l'ordre)
# Conception du capteur
# Mise en place de la Raspberry
# Mise en service de la Raspberry
# Création du programme de communication de la Raspberry
# Modification du bootloader afin d'écrire sur le programme principal

BONUS :
# Mise en place du protocole de sécurité
# Attribution de clés uniques via la Raspberry Pi (communication via le port série)
# Programme pour que la Raspberry puisse flasher le bootloader et attribuer la clé de sécurité

==Calendrier prévisionnel==

=Réalisation du Projet=
==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Analyse du projet
| 0
| 4
| 8
| 4
| 4
| 5
| 5
| 7
| 6
| 6
| 6
|
|}

==Prologue==
==Semaine 1==

Définition des fonctionnalités de la carte, première phase de conception, choix des composants selon les besoins du projet.
Choix d'une technologie de mémorisation SRAM au lieu d'une technologie EEPROM (pour sa durée de vie, sa consommation électrique, son prix). La persistance des données n'étant pas un absolue. J'ai pris la décision de penser le programme différemment.
Lors de la réception d'une mise à jour, le micro-contrôleur la stockera dans la mémoire SRAM et effectuera les vérifications de celle-ci. Une fois la mise à jour vérifiée, le micro-contrôleur transférera les données directement dans la mémoire de programme.

Concernant le module radio, un emplacement sera disponible (header) afin de pouvoir attacher le circuit directement sur la carte. Cela permet d'utiliser le modèle déjà existant et également pouvoir le changer pour de la maintenance.

Le schématique a été commencé et la recherche des différentes empreintes a commencé avec parfois, la requête à un service de création d'empreinte.

==Semaine 2==

[[Fichier:P57_schematics_V1.PNG|200px|thumb|left|Schématique]][[Fichier:328P_memory_plans.PNG|200px|thumb|right|Mémoire ATMEGA]]
Cette semaine, une semaine où la conception du circuit récepteur devient primordiale. Mise en place d'un schématique lisible qui permet de répondre aux besoins.

Une concertation avec les encadrants m'a permis de définir plusieurs choses. '''Premièrement''', qu'il fallait mettre les deux types de mémoire afin de pouvoir les comparer d'un point de vue énergétique, pratique etc. Une mémoire flash sera donc ajoutée au schématique afin de permettre la commutation entre les deux mémoires.

La '''deuxième''' chose est que le programme OTABoot pourra se situer dans '''deux espaces''' :
# A la fin de la mémoire de programme en prenant garde que le programme à mettre dans l'espace mémoire de programme ne réécris pas cette partie.
# Dans la partie Bootloader (qui est extensible jusqu'à 4ko) ce qui évitera que celui ci soit supprimé par une manipulation utilisateur.

La fonction OTABoot devra pouvoir stocker temporairement dans la mémoire (RAM ou Flash) les données reçu jusqu'à la fin de la réception et vérifier la conformité des données reçu avant de flasher l'espace mémoire.

==Semaine 3 à 7==
'''Conception du circuit électronique'''

[[Fichier:Schematique_final_P57_2019.JPG|200px|thumb|left|Schématique final]]
Changement de conception, dorénavant '''2 types de mémoires seront implémentées'''. Une mémoire RAM et une mémoire FLASH. L'une étant volatile et l'autre non volatile. Cependant, la vitesse de lecture et d'écriture de la RAM est bien plus rapide que celle de la flash. Des tests seront donc effectués afin de déterminer laquelle est la plus efficace dans le cas étudié.
De plus, il existe la possibilité de stocker une sauvegarde du programme d'usine dans la mémoire FLASH en cas d'erreur de mise à jour, il reste la possibilité de revenir a une version antérieur avec ce type de mémoire.

De nombreuses semaines se sont écoulées car il a fallu chercher des footprints et parfois demander la réalisation de nouveaux footprints. De plus le routage était plus fastidieux que prévu. Il a fallu changer les connexions entre chaque composant afin de pouvoir connecter les composants afin d’éviter de faire des vias qui devront être créés à la main.
<div style="clear: both;"></div>
Le routage s'est effectué de la manière suivante :
# Éviter de faire des croisements entre les fils symbolisant les routages à effectuer.
# Placer les composants sur la carte en fonction de leurs utilisation (stockage, alimentation, communication FTDI, communication ISP et communication avec le module radio).
# Il faudra ensuite effectuer les changements nécessaire afin d'éviter de faire des vias.
# Placer les capacités de découplages le plus proche possible des éléments qu'elles doivent filtrer.

Au départ, une erreur a été commise. Celle de vouloir utiliser l'outil d'autoroute qui me donnait des résultats possibles mais pas du tout efficaces.

A cause de l'impossibilité de faire des trous métallisés, il a fallu penser à effectuer toutes les connexions à l'opposé des headers présents sur la carte. Il a fallu faire passer toutes les connexions sur la bottom layer ce qui a augmenté le nombre de via.

De plus après avoir suivi ces règles, j'ai demandé conseils à M. Thierry Flamen afin d'avoir une expertise sur ma carte. De nombreux conseils m'ont été fortement utile afin de maximiser les chances de fonctionnement de mon prototypage. Notamment :
# Avoir une clearance plus importante (espacement entre les lignes) afin de facilité l'impression.
# Choisir des lignes parallèles.
# Placer plusieurs vias tout au long de la carte afin d'éviter les différences de potentiels entre les 2 plans de masses (en top layer et bottom layer).

Une fois le routage terminé une semaine fut nécessaire (S7) afin de corriger les erreurs et améliorer le routage. Certaines pistes étaient perpendiculaires, d'autres n'étaient pas parallèles, les règles de clearance modifiées empêchait une réalisation efficace, il a donc fallu modifier cela et reprendre une grande partie du routage.

La conception étant maintenant terminée, j'ai préparé une documentation permettant de visionner le travail réalisé rapidement. Ce document m'aidera aussi grandement lors de la soudure des composants.

[[Fichier:P57_2019_Apercucarteglobale.JPG|500px|thumb|center|Carte Finale]]

==Semaine 8==

[[Fichier:2019_P57_Avantsoudure.jpg|200px|thumb|left|PBC + pâte à braser]] [[Fichier:P57_2019_Raspbian.jpg|300px|thumb|right|Raspberry + touchscreen avec debian]]
Cette semaine est consacrée a l'impression de la carte et une première vérification que tout est bien fonctionnel. La qualité d'impression est impressionnante, un seul coup de cutter était nécessaire afin de séparer 2 pistes. Après cela, j'ai souhaité placer les composants CMS avant la fin de cette séance. A l'aide de pâte à braser j'ai placer les composants les plus petits sur la carte, cette étape fastidieuse est très chronophage. Un passage dans le four à 150°C pendant 180s puis 220 pendant 150s et enfin un refroidissement rapide pendant 220s a permis la soudure des différents composants. Des tests sont à prévoir afin de vérifier si tous les composants ont bien étés soudés correctement.

En parallèle, j'ai souhaité commencer la partie sur la Raspberry. Forte heureusement les modules NRF24l01 compatibles avec la Raspberry pi 3 pourront fonctionner directement avec l’alimentation 3V3 de la Raspberry. De plus il existe de nombreux tuto permettant de faire communiquer ces modules avec une Arduino. Un premier test sera donc de communiquer avec une Arduino classique afin de prendre en main le système de communication et maitriser les librairies disponibles.
<div style="clear: both;"></div>
La raspberry a été configurée de la manière suivante :

* Installation de l'image de Raspbian (récupérée sur le site officiel)
* Création d'un fichier SSH dans la partition Boot afin d'autoriser les connexions SSH nativement
* Mise à jour des paquets
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade
* Autorisation l'utilisation des SPI afin de pouvoir utiliser le module NRF24L01 (module radio) qui débloquera la communication via l'interface MISO MOSI présente sur le GPIO
$ sudo raspi-config
-> Interfaces -> SPI -> yes
* Installation de la librairie NRF24L01
$ cd
$ mkdir nrf24l01
$ cd nrf24l01
$ git clone https://github.com/TMRh20/RF24.git
$ cd RF24
$ make
$ sudo make install

Une documentation est disponible pour cette librairie : [http://tmrh20.github.io/RF24/]

==Semaine 9==
Cette semaine, la carte doit être terminée et testée. On effectue des tests de continuité afin de détecter d'éventuels court-circuits et vérifier que chaque soudure a été correctement réalisée.

Un premier court-circuit a été détecté entre le VCC et le GND de la carte, ce court-circuit provient simplement du connecteur micro-USB. Celui-la même qui posait problème avant la soudure du composant. J'ai décidé de le retirer afin de ne pas perdre de temps à tenter de le ressouder. Cette prise n'étant pas nécessaire pour la programmation et l'alimentation de la carte.
La suite des vérifications s'est effectuée sans encombres.

'''Résultats des test :'''
# '''ATMEGA328P''' : Aucune patte n'est mal soudée, aucun court-circuit entre 2 pattes voisines.
# '''Mémoires''' : Test visuel concluant, toutes les pattes sont correctement soudées.
# '''Prise micro-USB''' : pont formée entre le VCC et le GND voisin. Retrait de la prise micro-USB pour le moment.
# '''LM117MP''' : Correctement soudé, vérification au multimètre.
# '''Résistances, condensateurs''' : Test visuels, et dans le doute test au multimètre.
# '''LEDs''' : Sur les 7 leds connectées, une était montée à l'envers, elle a pu être dessoudée sans problème et ressoudée dans le bon sens à l'aide d'un pistolet à air chaud.

La suite était de finir de souder le reste des composants, les composants CMS étant correctement soudés. Premièrement, les composants restants sont soudés en surface, puis les headers sont soudés par le dessous et enfin les vias.

[[Fichier:P57_2019_Cartecomplete.jpg|200px|thumb|left|Carte complète]] [[Fichier:P57_2019_TestCarte.jpg|200px|thumb|right|Test de la carte]]
Une fois tous les composants soudés, une inspection visuelle m'a permis de refaire certaines soudure à l'aide, parfois, de la pâte à braser.
La vérification visuelle appuyé par une vérification au multimètre m'a confirmé dans le choix de mettre sous tension le circuit. La mise sous tension à été effectuée à l'aide d'une alimentation stabilisé de laboratoire munie d'une limitation en courant qu'on fixera à 10mA et une tension d'entrée de 5V. L'alimentation globale s'est effectuée sans soucis, la led d'alimentation est bien allumée et on peut mesurer une tension de 3.3V en sortie du LM117MP. Les premiers signes sont plutôt concluants.

Cette semaine se terminera par le test final, l'envoie de données pour l'écriture du BOOTLOADER du micro-contrôleur. La carte est amenée à M. Redon (tuteur du projet) qui essaya de téléverser un programme, sans succès.

Le quartz était surdimensionné. Un ATMEGA328P alimenté en 3.3V ne peut fonctionner à une fréquence de 16MHz, un quartz de 8 MHz va donc le remplacer.
<div style="clear: both;"></div>

==Semaine 10==
Le remplacement du quartz a été effectué ainsi que des tests pour vérifier que la soudure est correcte. Par la suite, j'ai décider de me créer une Arduino capable de graver le bootloader du micro-contrôleur en lui transférant le programme Arduino_ISP ainsi qu'en déclarant qu'on utilise le programmateur Arduino_ISP avant d'essayer de graver un bootloader. L'envoie du bootloader fut, encore une fois, un echec.

Par la suite, après avoir essayer d'autres techniques comme changer d'Arduino et de version d'Arduino IDE, une vérification complète des tracés de connexion a été effectué avec l'aide de M. Redon. Aucune anomalie fut détectée.

[[Fichier:P57_2019_PontDiviseur.jpg|200px|thumb|left|Pont diviseur]] [[Fichier:P57_2019_Montagecomplet.jpg|200px|thumb|right|Nouveaux tests]]
La prochaine hypothèse est que le fait que les signaux logiques en 5 V alors que le micro-contrôleur est en 3.3V est problématique. La correction de ce problème fut simplement, d'utiliser un pont diviseur de tension afin d'abaisser la tension de 5V en 3.3V. Pour cela, on utilisera des résistances de 1kOhm et 1.8kOhms afin de passer d'une tension de 5V à une tension de 3.21V ce qui serait interprété par un signal logique 1 par le micro-contrôleur. De plus, comme il y a 4 signaux logiques ( Reset, SCK, MISO, MOSI), il faut 4 ponts diviseurs de tension.

Cette nouvelle idée n'a pas encore fourni de résultats concluant, d'autres tests doivent donc être menés afin de faire fonctionner cette carte.
<div style="clear: both;"></div>

==Semaine 11==
[[Fichier:P57_2019_ArduinoMini+Carte.jpg|200px|thumb|left|Tests avec une Arduino Mini (SPI flash)]]
Pour vérifier la théorie du problème d'alimentation en 3v3 des entrées logiques MISO/MOSI, j'ai décidé d'utiliser une Arduino mini 3.3V qui enverrait directement les signaux logiques en 3.3V. Pour cela, il a fallu shunter le convertisseur de tension 5V en 3.3V afin d'effectuer les tests. Ces tests n'ont malheureusement pas été concluants.

[[Fichier:P57_2019_ShieldSeul.jpg|200px|thumb|right|Shield seul]]
[[Fichier:P57_2019_ShieldMonte.jpg|200px|thumb|right|Shield monté]]
En raison des nombreux problèmes rencontrés pour programmer le micro-contrôleur avec l'ancienne carte, j'ai décidé de recommencer la conception d'une nouvelle carte afin de pouvoir avancer sur la partie programmation pendant l'interruption pédagogique. Cependant, la cause du problème avec l'ancienne carte n'étant pas identifiée, il était dommage de passer à autre chose. Dans cette optique, monsieur Redon s'est proposé pour réaliser une seconde carte identique à la première afin de vérifier que la conception de carte n'était pas faussée. Après plusieurs heures, la cause du problème fut identifiée, il s’agissait d'une erreur de réalisation puisque le prototype réalisé par monsieur Redon fonctionnait alors que celle ci utilisait la même infrastructure réseau. La réalisation de la carte par une entreprise professionnelle aurait pu éviter ce genre de problème de réalisation.

Cependant, comme la partie programmation n'a pas pu être commencé j'ai décidé de me focaliser sur celle ci en concevant une nouvelle carte utilisant une Arduino mini et qui fonctionnerait de la même manière que la première conception.

Cette carte fonctionnant sur le modèle d'un shield fonctionnera à partir d'une alimentation 5V qu'elle convertira en alimentation 3.3V pour tous les autres composants. Les 2 types de mémoires restent présents sur la carte afin de laisser la possibilité de tester ces 2 types de mémoire. Cette carte devra pouvoir être programmée puis alimenté à l'aide d'un câble mini-USB.

La conception étant relativement similaire à la première version, elle ne me prendra que 5 heures, la réalisation quant à elle me prendra 4 heures.

Des premiers tests m'ont permis de m’apercevoir que la partie module radio était 100% fonctionnelle. De futurs tests ont révélés que des problèmes subsistaient sur la partie mémoire, un court circuit entre la branche wp (wipe data) et le gnd empêchait les mémoires de communiquer.
<div style="clear: both;"></div>
Après de nombreux tests, la carte est 100% fonctionnelle à l'aide de 2 librairies :
# The SPIFlash library (pour les mémoires SPI) [https://github.com/LowPowerLab/SPIFlash]
# The RF24 library (pour le module radio nrf24l01) [https://github.com/maniacbug/RF24]

=Documents Rendus=

Fichier:P57 2019 ShieldMonte.jpg

2019-04-08T22:38:42Z

Fleroy2 :

Fichier:P57 2019 ShieldSeul.jpg

2019-04-08T22:36:58Z

Fleroy2 :

Fichier:P57 2019 ArduinoMini+Carte.jpg

2019-04-08T22:26:50Z

Fleroy2 :