 Je suis heureux d'être venu avec vous pour la deuxième partie de l'Enzone. En première partie, avec Dominique, vous avez pu connecter votre smartphone à l'application de l'application BLE peer-to-peer sur SEM32 WBA. Mais pour le temps, nous n'avons pas pu échangeer des données. Dans la seconde partie de cette session de l'Enzone, nous implementons maintenant un profil BLE peer-to-peer, un profil pour échange des données entre le smartphone et le boulot nucléaire. Donc, nous commençons ensemble. Pour commencer la seconde partie, ici sont les préquisites, je ne vais pas prendre du temps sur ça, car l'Enzone 2 est un follow-up de l'Enzone 1, donc il n'y a rien de nouveau ici. Ce que nous allons faire dans cette seconde partie de l'Enzone, avec Dominique, vous avez pu connecter votre smartphone. Connectez, disconnectez, advertisez de nouveau et connectez. Dans cette partie, nous allons maintenant voir comment créer un service custom pour pouvoir échangeer des données entre le SEM32 WBA, le Firmware peer-to-peer et le smartphone. Donc, nous allons échangeer votre application existante. Donc, n'hésitez pas à garder l'Enzone 1 ouvert sur votre laptop car c'est un follow-up. Nous allons simplement échangeer l'Enzone 1. Donc, comme un souvenir, à l'abord, c'est ce que vous avez fait avec l'Enzone 1. Vous créez un service qui veut échangeer des données. C'est mon service. Il veut échangeer des données. Ensuite, devant mon service, j'ai un client, typiquement un smartphone, qui est en train de échangeer des données. Donc, c'est pourquoi le service s'advertit à dire, je suis ici, je suis ici, je suis ici. Et le client, sur le côté de ce smartphone, est en train de regarder des données et donc, échangeer, échangeer et échangeer des données. Donc, c'est ce que nous avons défini, cette architecture client-service pour l'échange. Maintenant, nous devons échangeer les données. Comment échangeer les données ? C'est le propose de table attributable. C'est ce qu'on appelle ATT. ATT définit un moyen d'échangeer les données. Il définit le notion de service, caractéristiques et de données. Et tout est inclus dans ce qu'on appelle un profil. Qu'est-ce que le profil de l'énergie Bluetooth ? Peut-être que vous avez déjà entendu du profil de l'énergie Bluetooth. Qu'est-ce que le profil de l'énergie Bluetooth ? Le profil inclut un ou plus de services. Chaque service peut échangeer un ou plus de caractéristiques. Puis chaque caractéristique a différentes propriétés. Trois principales propriétés sont « READ », « WRITE », « NOTIFIER ». Chaque service ou caractéristique est défini par une idée unique. Cette idée unique a deux formats. Il y a une idée unique de 16 bits. Dans ce cas, nous parlons d'une idée unique standard. Un profil standard, un service standard défini par l'Alliance Bluetooth. Ou un profil propriétaire. Dans ce cas, l'idée unique est de 128 bits. C'est le cas de notre « peer-to-peer » serveur. Nous travaillons sur cela aujourd'hui. Le profil standard, l'idée est défini par l'Alliance Bluetooth. Cela signifie que cela assure interopabilité. Qu'est-ce que la différence entre le profil standard et le profil propriétaire ? Si vous utilisez un profil standard, tout est défini par l'Alliance. Les Alliances de l'Alliance définissent tout pour cet profil. Le rôle, le requirement et la structure de l'attributé incluent les différentes idées uniques. C'est le cas, par exemple, de la service de l'aéroport. Cela signifie que l'application smartphone d'implémentation de l'aéroport sera capable de discuter avec d'autres défis d'implémentation de l'aéroport. Dans le cas du profil propriétaire, c'est la choice d'une grande majorité de nos clients. Ici, vous pouvez faire ce que vous voulez. En tout cas, cela va requiser votre propre app pour pouvoir communiquer. On parle ici du profil propriétaire. Cela signifie que si vous voulez discuter avec un smartphone, vous avez besoin d'une application qui implique le même profil. Sinon, vous ne pourrez pas communiquer ou pour transmettre des données, vous verrez juste les données. Comme exemple, ici, pour notre serveur peer-to-peer. Pour le serveur peer-to-peer, nous allons définir des idées uniques spécifiques. Ici, sur notre application de l'application smartphone de l'aéroport, qui implique ce serveur peer-to-peer, le profil propriétaire, cela signifie que quand nous connectons à un dispositif impliquant ceci, notre app STBLE Toolbox va automatiquement reconnaître la spécifique idée unique pour le serveur peer-to-peer et nous allons pouvoir déployer un bon logo. C'est le même pour le logo de l'aéroport. Au lieu de déployer les deux caractéristiques pour le bouton de l'aide, grâce à l'idée unique qui sera reconnaissée par le STBLE Toolbox, nous pouvons déployer un bon logo. À ce point, je dirais que maintenant, c'est temps de pratiquer et d'activer des services et des caractéristiques pour ce profil peer-to-peer dans notre code existant. Nous sommes en retour avec le code de l'anzen 1 et nous allons réopérer le .ioc pour sélectionner l'application BLE sur le service et sélectionner un service. En effet, notre BLE peer-to-peer serveur contient un service avec deux caractéristiques. Un service qui est défini plus tard avec une spécifique idée, qui reviendra sur ça. Et puis, un caractéristique pour le l'aide pour déployer le l'aide sur le smartphone et un caractéristique pour le bouton de switch quand nous allons presser le bouton sur le bord du nucléaire nous allons utiliser ce caractéristique pour envoyer une notification sur le smartphone. Donc, nous allons retourner à l'idée Q. En utilisant l'idée Q, c'est le statut de l'anzen 1 que vous avez fait avec Dominique dans la vidéo précédente. Juste réopérer le .ioc. Ensuite, dans le component de software nous allons sélectionner le .stm322WPAA C'est déjà l'un que vous avez activé durant l'anzen 1 et nous allons aller dans l'application BLE et le service tab et nous allons définir un service. En tant que nous avons créé cela, nous avons ajouté un service un nouveau tab appire qui s'appelle Service 1 et nous allons maintenant remplir ce service configuration. Donc, nous allons maintenant installer et configurer notre service 1. Pour configurer notre service 1, nous devons premièrement cliquer sur le service 1 tab ici et configurer la définition de notre peer-to-peer service profil. Peer-to-peer service profil est plus ou moins une spécification. C'est un document. Et nous devons suivre exactement comment cela est défini. Donc, premièrement nous devons configurer le unique ID. Le unique ID, comme dit le profil de propriété, donc 128 bits. Ici, nous allons simplement entrer un short unique ID, FE40. Vous pensez que ok, vous avez dit que le profil de propriété est 128 bits alors que ici, nous sommes entrés seulement 4 bytes. Ne vous inquiétez pas, le code application va arriver le reste de 112 bits. La idée ici est d'éviter de tirer le unique ID. Ensuite, nous devons donner un nom pour notre service. Nous allons l'appeler peer-to-peer server. S'il vous plaît, vous utilisez exactement le même nom que par ce que j'ai partagé currently sur cette pièce. Parce que le nom que vous seterez ici pour le nom long de service et le nom short de service sont les 1res que vous utilisez pour la génération de codes. Bien sûr, vous êtes libre de modifier le code, mais juste soyez compteux que si vous modifiez ce nom, le nom de fonction, le nom de file sera différent et vous ne pourrez pas copier le code après la génération de codes directement de la sheet-sheet. Donc, vous devez adapter. Si vous voulez simplement copier le code, utilisez exactement ce nom avec respect à la case en cas bas et la case en cas bas. Donc, ceci est terminé. Donc, nous allons définir unique ID FE40 le nom de service. Ensuite, ce service indique 2 caractéristiques. 1 pour le nom, 1 pour le nom. Donc, maintenant, nous allons entrer le nom de caractéristiques. Nous devons configurer le nom de caractéristiques par définition de la serveur BLE peer-to-peer. Ce cas, le nom de service est FE41. C'est pareil pour les caractéristiques long et short-name par ce que je dis pour le nom de service. Utilisez exactement ce nom my underscore led underscore char. Et nous allons voir en cas bas pour le nom de short-name. C'est important pour la génération de codes. Ensuite, le nom de la serveur, c'est le nom de nos caractéristiques. Nous disons 2 bytes. Pourquoi 2 bytes ? Parce que c'est la définition de la caractéristique. Comme bien, dans cette documentation, le nom de caractéristique est defini comme variable. Ce n'est pas mandatoire, mais nous devons définir par le nom de la serveur BLE. Donc, variable. Nos caractéristiques de led ont deux propertés. L'une est la properté de read parce que notre smartphone doit être capable de lire la valeur de la caractéristique et de lire le statut de la led. Et c'est la réponse de write-read. D'ailleurs, notre smartphone doit être capable de togner le led par write-reading dans cette caractéristique. Comme bien, nous allons réactiver la réponse de l'application. Ce n'est pas besoin ici. Ensuite, nous allons faire le même pour la deuxième caractéristique, qui est la caractéristique de bouton. Donc, cette fois-ci, nous avons une nouvelle idée unique pour cette caractéristique, FE42. Le nom, une fois plus, je me répète, mais nous devons suivre exactement ce nom, my underscore, switch underscore, char et shortname, switch underscore C, uppercase. Le nom est aussi 2 pour cette caractéristique et le nom de la caractéristique est variable. Cette fois-ci, en termes de caractéristiques, nous allons seulement réactiver la notification. Notify. Ici, la purpose de Notify est que si cette caractéristique a une caractéristique notifiée, cela signifie que le smartphone peut enregistrer une notification. Et chaque fois que nous allons réactiver cette caractéristique, le smartphone sera notifié d'une change de caractéristique. Et c'est exactement ce que nous voulons pour ce pire-à-pire serveur. Ce que nous voulons c'est que quand nous pressons le bouton, nous voulons une notification pour être reçue sur le côté smartphone. Et comme pour Lead, nous voulons réactiver l'application de réponse. Quand nous avons fait ça, nous configurons le service, nous configurons les deux caractéristiques, nous avons fait un profil que la création est terminée. C'est temps de bouger à la génération de code. Pour bouger à cette génération de code, maintenant, vous savez la procédure. Sur Q by D, tout est maintenant complété. Nous allons simplement cliquer sur la roue, ici, pour générer le code. Et il devrait générer tout le code qui est lié à notre pire-à-pire serveur. Et cette fois, nous avons tout le profil défini. C'est-à-dire que nous avons la définition du service et la définition des caractéristiques. Donc, nous attendons quelques secondes pour obtenir le code complètement généré. Nous sommes faibles. Nous avons maintenant le code complètement généré. Maintenant, ce n'est pas suffisant. Réfléchissez-vous, nous devons manager ces caractéristiques. Tout est en place, mais nous devons réétenir, nous devons lire ces caractéristiques et envoyer la notification sur la presse. Et c'est partie de l'application de l'utilisation. Et c'est ce que nous allons faire maintenant. Et pour cela, nous allons utiliser le code sheet-sheet que vous avez déjà utilisé pour Unzone 1, mais cette fois, nous allons cliquer sur Unzone 2 et nous allons appliquer le code modifié qui est descrivé ici. Donc, nous allons l'arriver. Pour summariser où nous sommes maintenant, nous performons la configuration hardware. Nous configurons les paramètres BLE. Nous avons créé le profil des caractéristiques qui ont créé le code. Et maintenant, c'est temps de changer l'application. À l'abord, nous allons remettre ce que nous avons fait avec Dominic dans Unzone Session 1. Pourquoi ? L'application qui a été shared durant Unzone 1 a été accessée à BLE Stack. API, API Level. C'est OK et c'est bien mais QBemix a créé un nouveau code avec un layer d'abstraction ou un layer d'abstraction qui peut faire le même dans une ligne. Donc, si nous pouvons faire le même dans une ligne, pourquoi pas le faire ? Ce sera votre développement et le niveau de software. Et pour cela, nous avons cette fonction Gap Peripheral et nous avons installé un paramètre pour dire OK, commencez l'advertissement. Et c'est ce que nous allons faire maintenant. Donc, pour cela, nous allons utiliser le cheat sheet, le code cheat sheet, simplement aller à app BLE.C donc à la place où nous avons tout le code dans Unzone 1, nous allons simplement remplacer cela avec cette nouvelle ligne copiée de le cheat sheet. Et nous allons faire le même quand nous recevons une complète disconnection. Quand nous recevons une complète disconnection, nous voulons commencer l'advertissement de nouveau, pour être discoverable et de nouveau pour accéder une nouvelle connecté. En plus, commencer l'advertissement est une décision d'application. Ce n'est pas automatique. La seconde partie, nous voulons togner le pin. Quand le smartphone nous réveille les caractéristiques, nous voulons togner le pin. Pour cela, nous voulons dans l'app folder BLE peer-to-peer-server-app.c. Nous voulons l'ouvrir. Chaque fois que le smartphone nous réveille les caractéristiques, nous voulons recevoir ce type d'événement de notification. Donc, ici, nous ne voulons prendre le statut de l'advertissement. Nous voulons simplement togner le pin. Chaque fois que le client nous réveille la caractéristique de l'advertissement, nous voulons togner le pin. Qu'est-ce que la valeur. Ce n'est pas le souhait de ce point de vue. Ce souhait est d'interacte avec l'advertissement. Nous voulons maintenant togner le pin. Pour le pin, nous voulons ajouter un sequencer. Qu'est-ce que c'est un sequencer ? Dans notre BLEQ firmware code exemple, nous offrons la possibilité d'adverir un sequencer. Un sequencer est une simple façon. Ce n'est pas un RTO, ce n'est pas un système de temps que nous avons un sequencer qui permet d'adverir un tasque. Et nous allons définir un tasque pour notre bouton. Pour cela, nous devons définir une nouvelle idée de tasques pour définir un nouveau tasque. Ensuite, nous voulons réagir ce tasque. Et pour réagir ce tasque, nous voulons réagir ce tasque et associer un callback pour cette fonction. Ici, le callback va envoyer une notification pour le client. Bien sûr, nous devons établir ce tasque. Et quand nous allons établir ce tasque, c'est temps que l'utilisateur pressera le bouton. Basiquement, dans IRQ. Et c'est ce que nous allons faire maintenant. Donc, je vais revenir à Q by DE et à mon code cheat sheet. Donc, à l'abord, je dois définir mon nouveau tasque. Pour cela, je vais aller dans Core, Include, dans app.conf.h file. Et je vais regarder pour la définition des tasques pour se trouver, vous pouvez regarder directement sur ce commentaire des idées des tasques. Donc, je vais simplement copier la définition et ajouter mon nouveau tasque. En terminant, je dois réagir un callback pour mon tasque. Pour cela, je vais ouvrir le file peer-to-peer server app.c et je vais manager ce registre des tasques à la fin de la initialisation. Quand tout est initialisé, je sais que je peux registrer ce callback pour envoyer notification à mon bouton de tasque. Cette fonction est déjà générée par Q by Mix. Cette fonction est déjà présente. Cette fonction est utilisée pour envoyer notification. Et c'est exactement ce que nous voulons acheter. Maintenant, quand nous allons caduler notre tasque, nous allons simplement caduler notre tasque quand quelqu'un pressera le bouton. Pour cela, nous allons simplement déterminer la fonction weak pour le Gpio IRQ et le lien pour le Gpio et le lien PIN. Donc, ceci est fait dans appp.n3.c à la fin de l'enquête. Donc, par défaut, ce callback est une fonction weak. Nous sommes simplement sous-écoutés à cette fonction weak. Maintenant, nous sommes presque faits pour ce bouton. Ce qui est mis est pour envoyer des données dans notre notification parce qu'aujourd'hui, nous sommes envoyés notification mais une notification électorale pour envoyer des données. Nous allons le faire dans peer-to-peer-server-app.c Je dis que cette fonction est ici. Cette fonction est déjà générée. Nous allons simplement ajouter quelques lignes ici de code cheat-cheat pour ajouter des données. Et nous sommes faits. Ici, notre bouton task est complété. Nous sommes maintenant prêts à construire le code flash et rouler et tester notre application. Nous allons maintenant construire le code par cliquer sur l'icone hammer. Donc, ça peut prendre quelques minutes. Dans ce temps, je peux connecter mes WBA 5 de la borde nucléaire à mon laptop. Et une fois plus, nous allons utiliser l'embede ST-Link de Probe de flash et de debug. Donc, la compilation est maintenant OK. Avec 0 erreur et 0 warning, nous allons rouler notre application flash et rouler. Donc, flash encore en train de vérifier le download suffisamment. Je suis terminé. Nous allons vérifier maintenant si tout est bien et premièrement voir la borde nucléaire. Dans notre borde nucléaire, nous pouvons voir que la borde nucléaire est flash et par défaut, nous avons déjà activé. Maintenant, nous pouvons ouvrir notre smartphone activer l'application ST-BLI de la borde nucléaire. Elle commence à scanner. Maintenant, je peux découvrir mon service peer-to-peer. Je peux connecter. Comme vous pouvez le voir, maintenant, comparé à la session en zone n°1 que vous faisiez avec Dominique dans la vidéo précédente, nous pouvons voir que nous avons un service additionnel qui est le service peer-to-peer. Je peux voir que mon application ST-BLI reconnaît ce service. Je vais ouvrir ce service et il reconnaît aussi grâce à la unique ID il peut déployer un bon icône pour la borde nucléaire et un bouton parce qu'il reconnaît la unique ID. Maintenant, si je touche la borde nucléaire sur le côté smartphone, je peux voir la borde nucléaire sur la borde nucléaire. Donc, ceci est prévenu. Ici, la borde nucléaire sur le smartphone n'est pas alignée avec la borde nucléaire sur la borde nucléaire. Mais, on va dire que c'est prévenu parce que dans l'application que nous ajoutons, on simplement touche la borde nucléaire sans prendre soin de sa borde nucléaire. De l'autre façon, maintenant, si je pousse un bouton sur le bouton B1, je peux voir que je suis reçu sur mon smartphone une notification. Donc, cela signifie cela ici. Depuis le scratch, nous avons pu créer un serveur peer-to-peer, mais ce ne peut être aucun profil propriétaire. Nous sommes ébouillés pour communiquer le scratch de WBA d'ambérité par notre profil de la borde nucléaire avec le smartphone et nous pouvons le faire dans les deux directions. Cela signifie que nous avons tout en place pour développer l'application BLE. J'espère que cette session a été utile pour vous. Cela peut être réplicé bien sûr avec votre propre profil et votre propre caractéristique, tous les services. Vous pouvez ajouter ce que vous voulez. Mais ici, nous succéterons ensemble pour construire cette application BLE. Merci pour votre attention. Nous allons summariser briefly notre session en zone. D'autres outils. Vous avez pu construire une application BLE en quelques clics. Vous avez pu commencer au scratch de sélectionner le right target en utilisant Q by D, Q by Mix. Nous avons sélecté le WBA 5 target STM32. Sur ce point, nous avons pu construire un profil BLE customisé des services customisés d'adverteurs caractéristiques. Et ensuite, nous avons pu ajouter quelques lignes de code pour faire la connexion possible avec le smartphone et l'action des données avec le smartphone dans les deux directions. Et c'est typiquement ce que l'application Bluetooth de l'énergie fait. Et c'est probablement ce que votre application va avoir à faire. Et, comme vous l'avez vu, dans quelques clics, nous avons pu générer une full Bluetooth de l'énergie de l'application. Donc, je dirais que, en termes de firmes, nous avons fait. Maintenant, je vais donner la flore à mon collègue Hardware Laurent qui va parler de comment optimiser votre PCB pour obtenir les meilleures performances et performances de Power. Et il vous donnera aussi quelques mots sur la certification de Bluetooth. Merci pour votre attention et à bientôt !