Programmation et échange de données avec ARDUINO via WIFI via ESP8266 Deuxième partie

Je vous propose, chers lecteurs de GeekTimes, l'article suivant du cycle (j'espère que ce n'est pas le dernier) sur l'utilisation de la puce ESP8266 comme pont sans fil pour les microcontrôleurs AVR, en utilisant la plate-forme matérielle Arduino Uno (Nano) comme exemple.

Après le premier article sur ce sujet, j'ai reçu de nombreuses réponses amicales, telles que: «Pourquoi diable avez-vous pris de l'arduine si tout pouvait être fait exclusivement sur ESP8266» ou «Pourquoi n'avez-vous pas, idiot, utilisé esp-link ». "Vraiment pourquoi?" - J'ai pensé, et déjà lancé cet article et mis à jour plusieurs de mes programmes comme nouveaux arguments.

Alors, rencontrez le programmeur sans fil pour microcontrôleurs AVR BABUINO version 0.9



Détails sous la coupe:

La version originale du programme a été publiée dans un article précédent et, en principe, faisait presque la même chose que la nouvelle version. Mais il se distinguait par des désagréments extrêmes dans le travail. Comme, cependant, et esp-link concurrent. Par conséquent, avec un soupir, j'ai vissé l'interface graphique sur JAVA. Vous pouvez désormais sélectionner en toute sécurité le fichier à télécharger via le gestionnaire de fenêtres, ainsi que modifier l'adresse IP de l'appareil cible. J'ai toujours saisi le numéro de port TCP étroitement (il n'est édité que dans le code), mais en théorie, il ne doit être modifié que si ce port est utilisé ailleurs (mais vous devrez également changer son numéro dans le firmware ESP8266 également).

Le microcontrôleur est également utilisé jusqu'à présent avec un microcontrôleur d'une taille de 32 Ko de mémoire FLASH, c'est par exemple le bien connu Mega328P. Comme, comme je l'ai mentionné dans un article précédent, théoriquement, mon programmeur coud des versions en 16 kilo-octets, et peut-être même 8 kilo-octets. Eh bien, bien sûr, dans les versions 64 Ko et 128 Ko de l'AVR, il peut même probablement flasher les 32 premiers Ko de mémoire. Mais je n'ai pas de tels microcontrôleurs entre les mains et je ne peux pas dire comment c'est vraiment. Le fait est que 16 bits d'adresses dans les commandes de programmation SPI standard sont si intelligemment divisés et coupés (bit ici, bit là-bas) qu'il n'est pas facile de comprendre comment tout se passera avec une taille de mémoire différente de 32 kilo-octets.

Oui, le programme n'est pas vérifié après l'enregistrement, les registres AVR spéciaux ne sont pas lisibles, l'EEPROM n'écrit pas non plus. Mais tout cela est théoriquement possible de se passer de problèmes (contrairement aux limitations fondamentales du téléchargement de code via UART, comme dans esp-link). Vous pouvez ajouter, cela ne me dérange pas, le produit n'est pas commercial.

Voici le fichier exécutable pour Windows 64 bits . Vous pouvez en extraire le code Java. Ou affrontez github

Commençons donc.

Ensuite, tout est simple, ouvrez le fichier HEX dont vous avez besoin (oui, le programme a appris à convertir le format BIN en HEX, bravo!) Entrez l'adresse IP ESP8266 dont vous avez besoin et cliquez sur «Télécharger» (comment trouver l'adresse IP du module ESP est une histoire distincte). Si le programmeur trouve ESP8266, il pousse rapidement (beaucoup plus vite que esp-link) votre code dedans, et il l'envoie déjà plus loin au microcontrôleur AVR via l'interface SPI. Le programmeur décrit en détail ses actions dans la fenêtre et il peut même lui faire confiance, sauf que le programme a été enregistré en AVR. Comme je l'ai déjà dit, il n'y a pas de vérification de l'enregistrement, mais l'interface SPI est purement synchrone, il ne se soucie généralement pas s'il y a quelqu'un à la deuxième extrémité de la ligne ou non. Il jette des données, mais n'attend pas de réponse.

Après avoir fermé le programme (via «Arrêter» ou simplement fermer la fenêtre), les données que vous avez entrées (si vous avez appuyé sur le bouton Télécharger auparavant) sont stockées dans le fichier tcp_dat.txt dans le répertoire racine du lecteur C, de sorte que la prochaine fois que vous l'ouvrirez, vous n'aurez pas à vous inquiéter beaucoup, encore une fois recruter. En général, la fenêtre du programme peut ne pas être fermée. Par expérience, cela ne dérange personne.

Maintenant, tournons-nous vers le côté du module ESP et rappelons-nous à nouveau, maintenant en détail, comment le connecter à l'AVR et de quelle manière le flasher, afin de pouvoir utiliser le programmeur susmentionné, et aussi simplement piloter des données via WI-FI sans fil.

Donc, la première chose est le schéma de connexion. Veuillez noter que nous avons besoin d'ESP8266 dans les versions avec une quantité suffisante de GPIO. Nous aurons besoin de conclusions gratuites sous RESET, MOSI et SLK pour la programmation sur l'interface SPI, en plus du fait que pour l'échange de données, nous utiliserons également l'UART habituel avec ses RX et TX. Pour cela, l'ESP8266-07 semblait le plus pratique pour le prix et la qualité.

Nous le prenons et soudons immédiatement deux résistances d'une valeur de 5-10 kOhm. Le premier en EN (CH-PD) et alimentation, le second en GPIO15 et au sol



Vous pouvez maintenant le connecter à l'adaptateur, via lequel nous téléchargerons le firmware NodeMCU, puis notre chargeur de démarrage LUA.



Un million d'adaptateurs, prenez-en. Nous connectons, comme d'habitude, RX c TX et vice versa. Nous rendons la terre commune. Nous alimentons l'ESP8266 séparément et son adaptateur à partir du port USB est suffisant. Nous jetons zéro sur GPIO0 et remplissons le dernier firmware NodeMCU (vous pouvez le prendre ici , ou créer le vôtre) via le programme NODE MCU PyFlasher .



Tout cela, en principe, est décrit dans l'article précédent et plusieurs fois sur Internet. Ensuite, nous supprimons le zéro de GPIO0 (vous pouvez simplement le laisser suspendu, ça va) et ouvrons l'environnement ESPlorer pour le débogage et le téléchargement de programmes sur Lua. Certes, cette infection sans l'environnement JAVA ne fonctionne pas. Donc, cette chose ( téléchargez Java sur votre ordinateur de bureau maintenant! ) Devra de toute façon être préinstallée.

Après la connexion à ESPlorer, il formatera légèrement le module ESP, vous informant avec les messages appropriés. (l'essentiel est de ne rien toucher en ce moment), puis ESP redémarrera. Vous pouvez commencer à télécharger des programmes LUA.



Et nous aurons le programme suivant :


C'est presque le même que celui décrit dans la première partie, mais maintenant il peut non seulement transmettre le flux de données de l'ordinateur au microcontrôleur AVR, mais maintenant le faire dans la direction opposée.

En cours d'écriture, j'ai dû résoudre un problème intéressant. Lorsque nous envoyons des données d'un ordinateur vers l'ESP8266 en utilisant UDP, il n'y a aucun problème. L'adresse IP du module ESP est connue (nous le pilotons nous-mêmes au début, si cela), le port est connu, tout va bien. Mais lorsque nous essayons d'envoyer des données dans la direction opposée, nous ne pouvons pas le faire, car le module ESP ne connaît pas l'adresse IP de l'ordinateur sur lequel le programmeur s'exécute. Il le connaît plutôt, car avant cela, nous établissons le contact via le protocole TCP pour l'envoi des commandes de contrôle (programme, données, stop). Et lors de l'utilisation de ce protocole, les appareils échangent leurs adresses, car il est bidirectionnel. Mais ici, il ne le lui dira pas. En tout cas, je n'ai pas trouvé dans les fonctions de l'API NodeMCU pour le retirer. Vous pouvez, bien sûr, conduire l'adresse IP de l'ordinateur directement dans le chargeur de démarrage sur l'ESP8266, mais ce n'est pas une option. Soudain, nous exécutons un programme pour échanger des données sur un autre ordinateur. Ou il a plus d'une carte réseau.

J'ai donc fait une béquille. Nous transférons explicitement l'IP de l'ordinateur sur lequel le programme s'exécute avant de commencer l'échange de données. Dans l'API JAVA, heureusement, il existe une fonction pour déterminer l'adresse réseau de l'hôte sur lequel le programme s'exécute. ESP8266, ayant reçu cette adresse, peut désormais envoyer facilement des données non seulement à l'AVR, mais aussi à partir de celui-ci. Quant au programme LUA, il est très chêne, naïf et simple, et cela est dû au fait que dans cette langue je suis encore très mal orienté.

Ainsi, avec l'aide d'ESPlorer, nous enregistrons le chargeur de démarrage mis à jour dans ESP8266. N'oubliez pas de nommer initialement le fichier comme init.lua ou de le renommer via ESPlorer, sinon il ne décollera pas . Eh bien, bien sûr, martelez dans le corps (où BLOC PRINCIPAL) du chargeur de démarrage votre nom de réseau et votre mot de passe.

Ensuite, nous devons déterminer et corriger l'adresse IP du module ESP dans notre réseau interne. Nous allons dans le routeur local sous les droits d'administrateur et voyons quelque chose comme ça.



Cette adresse est toujours dynamique (c'est-à-dire qu'une fois reconnectée, elle peut être affectée à une autre), nous l'associons donc à l'adresse MAC ESP8266 au même endroit dans le routeur.



Vous pouvez même l'écrire (derniers chiffres) sur le module lui-même, si vous souffrez de sclérose en plaques.



Le module ESP est prêt à fonctionner, vous pouvez le connecter avec un microcontrôleur AVR.



Nous lançons BABUINO, écrivons l'adresse IP du module ESP, sélectionnons le fichier HEX (certains BLINK), appuyons sur «Upload» et profitons du clignotement de la LED. Le programmeur écrira dans sa fenêtre, quelque chose comme ceci:



Mais parfois, cela peut se produire si le module ESP est silencieux pour une raison quelconque:



Voyons maintenant comment notre chargeur de démarrage câblé en ESP8266 peut échanger des données dans les deux sens. Pour ce faire, nous contrôlerons le chariot robotique à partir du clavier de l'ordinateur, et il nous enverra son chemin parcouru. Mon premier chariot robotique à quatre roues est décédé de la mort des courageux, recevant un signal du Cosmos et tombant de la table (ce fait astral sera expliqué plus loin). Par conséquent, jusqu'à ce qu'un nouveau cadre en acrylique vienne de Chine, des expériences seront menées sur un chariot robotique à deux roues, que j'ai d'ailleurs essayé de forcer à équilibrer sur deux roues d'année en année, mais jusqu'à présent sans succès. Selon le schéma de connexion électronique et le programme pour AVR, ces chariots ne diffèrent pas, que nous utiliserons.



Le programme du chariot est écrit en C et ne devrait pas poser de grandes difficultés de compréhension. Nous écrivons constamment une nouvelle valeur de vitesse dans les registres PWM du contrôleur, et cela donne des signaux aux moteurs. Il y a un circuit de rétroaction sur l'ADC interne du microcontrôleur. Lorsque la tension de la batterie diminue, la vitesse augmente par programme. De ce fait, jusqu'au retrait complet, le chariot roule à vitesse constante. L'essentiel est que plus le remplissage PWM est dense, plus les moteurs tournent vite, mais comme la tension de la batterie chute avec le temps, ils tournent plus lentement. Ensuite, le remplissage PWM augmente et ils tournent à nouveau plus rapidement. Et donc jusqu'à ce que le remplissage PWM soit à 100%, c'est-à-dire que la sortie sera constamment logique «1». Vous ne pouvez rien y faire. Pour charger!


Le chemin parcouru est considéré comme un commutateur à lames, qui déclenche une interruption externe INT10. Dès que le chemin est incrémenté, les données sont immédiatement versées dans l'UART. En conséquence, les signaux de commande (avant, arrière, gauche, droite, gaz, frein, arrêt) proviennent de l'UART dans la direction opposée.

Veuillez noter que les moteurs chinois sont bruyants avec une puissance terrible, donc aucun condensateur de puissance n'aide. Dans le circuit des roseaux, une telle interférence est induite qu'il semble que votre voiturette participe à la Formule 1 en termes de vitesse du parcours. Il permet d'économiser, seul un condensateur de 22 nF à l'entrée d'une interruption externe avale cette interférence.

Le programme de direction du chariot lui-même était tiré d'un article précédent, où il fonctionnait auparavant avec un bras mécanique. Seuls de petits ajouts ont été effectués: deux zones de texte, où vous pouvez voir en temps réel, les données reçues et envoyées (1,2,3,4,5,6,0 - avant, droite, gauche, arrière, gaz, frein, arrêt) , ainsi que la possibilité de modifier et d'enregistrer l'adresse IP du module ESP via l'interface graphique et le bouton "Connecter". Nous contrôlons le chariot avec les flèches depuis le clavier ou avec la souris dans la fenêtre. Certes, puisque tous les boutons sont dans un cycle, changer la vitesse et la direction en même temps ne fonctionnera pas, un seul à la fois. Mais bien sûr, c'est uniquement parce que le programme est une démo.



Le fichier exécutable pour Windows 64 bits . Vous pouvez en extraire le code Java. Ou affrontez le github .

Maintenant que le programmeur et l'échange de données ont été testés (en général, j'ai probablement flashé AVR sur WI-FI au moins cent fois de cette façon), nous pouvons revenir à la question de savoir pourquoi j'ai choisi ce chemin pour moi-même, et non esp-link.

Commençons donc par l'installation.

Flasher le module ESP est un peu plus compliqué que celui d'un concurrent. Nous cousons d'abord NodeMCU, puis remplissons le chargeur de démarrage sur le LUA. Dans esp-link, nous cousons un seul firmware. Mais le temps passé ici est unique. À l'avenir, nous ne toucherons pas au module ESP. En revanche, dans notre cas, nous pouvons terminer mon programme chêne sur LUA, comme nous voulons, ajouter nos propres modules, etc. etc. Avec esp-link, c'est plus difficile. Là, la connaissance des bases de LUA et de l'API NodeMCU ne fonctionnera plus.

Côté informatique, tous les avantages de BABUINO. Exécutez simplement l'exécutable et travaillez. Même un environnement JAVA n'est pas nécessaire si vous avez une version 64 bits de Windows (mais vous avez alors besoin d'un disque de 200 Mo). Et si vous avez Linux ou Mac OS, vous pouvez vérifier le slogan d'Oracle à propos de son Java, "Il est écrit au même endroit, il fonctionne partout", car la machine virtuelle Java et le code d'octet sont les mêmes. Mais pour être honnête, je n'ai pas vérifié, je ne sais pas.

Avec esp-link, vous trouverez des danses nobles avec des tambourins, selon l'installation du manager Tibbo (je sais par expérience). Il s'agit d'un tel programme pour prendre en charge le port COM virtuel. Cela nécessite le réglage d'un tas de paramètres et une présence constante dans le système. Immédiatement improbable de fonctionner, préparez-vous. Ensuite, via le navigateur, vous devez configurer le module ESP lui-même. Il est important partout, y compris dans Tibbo, de définir les taux d'échange de données corrects et tous les bits d'arrêt et de parité.

Après cela, déjà via l'Arduino Uploader standard (dont je dors ... a pris la conception) ou via l'Arduino IDE (configurant à nouveau COM), nous commençons à charger le programme très AVO. Non, vraiment, ça se charge vraiment pour toujours. Même si petit. Vous pouvez aller faire du thé pendant cette période. Le moins tombe périodiquement, vous laissant complètement sans raison de savoir pourquoi le téléchargement n'a pas eu lieu. Et puis il n'y a qu'une seule issue: réinitialiser, redémarrer, réinitialiser, redémarrer ...

Et BABUINO lance beaucoup plus rapidement, comme un programmeur SPI ordinaire (et les fichiers qui tiennent dans un paquet de 1024 octets sont généralement instantanés). Certes, il ne vérifie pas. Mais cela est réparable et ne prendra pas beaucoup de temps de toute façon, car il sera effectué simultanément avec le firmware (une bonne caractéristique du protocole SPI). De plus, nous avons accès à toutes les commandes de programmation SPI: fusibles et bits de verrouillage, firmware EEPROM, etc. Et si l'enregistrement échoue, vous voyez toutes les raisons dans la zone de texte. Remarque Les commandes sont disponibles, mais il n'y a pas encore d'implémentation. Oups

C'est pour la programmation sans fil. Passons maintenant au transfert de données. À cet égard, je n'ai pas utilisé esp-link, donc mon raisonnement sera purement théorique.

Ainsi, esp-link utilise autant que je sache le protocole MQTT. En substance, ce n'est qu'une abstraction du niveau suivant sur TCP.



Sans entrer dans les subtilités, voyons pourquoi cela est nécessaire.

Eh bien, par exemple, lorsque vous avez beaucoup d'appareils dans une sorte de maison intelligente qui fonctionnent sur ce protocole. Lorsque vous avez quelque chose, il va dans le cloud et vice-versa. Lorsque vous vous intégrez à une sorte de réseau fonctionnant sur MQTT. Lorsque vous avez un projet commun, afin de ne pas inventer quelque chose de vous-même, mais d'utiliser quelque chose de prêt à l'emploi et de collègues bien connus.

Et si vous avez juste besoin d'envoyer le flux d'octets là-bas sans fils, alors qu'est-ce qui vous pose de telles difficultés? Pourquoi empiler un autre protocole d'en haut?

Bien que, bien sûr, je ne nie pas l'utilité des protocoles MQTT en général et j'essaie même d'intégrer son support dans mon bootloader-échangeur dans les développements et articles suivants. Mais même si je n'ai pas besoin de lui, nous irons plus loin. Et si vous en avez besoin, décidez par vous-même.

Pendant ce temps, mon chariot tourne docilement les roues dans la bonne direction et envoie la télémétrie de la distance parcourue à l'ordinateur (notez que le pare-feu de l'ordinateur peut ne pas autoriser les paquets avec ESP). La prochaine fois, nous essaierons de le contrôler à partir d'un téléphone mobile. J'ai essayé de l'équilibrer sur deux roues depuis le clavier, mais l'expérience a échoué. Il y a une idée d'utiliser les accéléromètres d'un smartphone pour cela (j'ai essayé d'utiliser une carte séparée avec un gyroscope et un accéléromètre, mais cela n'a pas décollé).

Revenons à la deuxième question, qui a été soulevée à plusieurs reprises lors de la discussion de l'article dans les commentaires. «Pourquoi ne pas tout faire chez ESP? Elle peut! Et laissez AVR être comme un extenseur de port et en tirer assez. »

Bien sûr, c'est possible! Bien que ce soit tout de même, comme vous pouvez le voir, l'AVR est indispensable.

Oui, elle le peut si:

1. Vous êtes un programmeur héréditaire orienté objet qui adore emballer dans toutes sortes de wrappers, faire des rappels et ne pas imaginer la vie sans méta-tables.

2. Vous connaissez bien les détails du travail des différents OS. Et vous venez de cracher pour apprendre que le nouveau système d'exploitation est maintenant RT (en temps réel) ses appels système et ses bibliothèques écrites par les chinois pour un bol de riz.

3. À l’université, votre connaissance des microcontrôleurs était limitée à un ou deux travaux de laboratoire, et vous ne voulez même pas en savoir de bits et de périphériques. Et en général, pour PWM, par exemple, il est plus facile pour vous de prendre une bibliothèque de logiciels que d'utiliser quelque chose de matériel là-bas.

4. Vous n'avez pas besoin d'une réponse de périphérique en microsecondes. Non, bien sûr, RTOS peut essayer de vous le fournir, car il s'agit également d'un système d'exploitation en temps réel. Mais pas le fait qu'il fournira.

5. Vous n'avez pas des centaines de kilo-octets de code déjà écrit, et surtout, vous travaillez déjà sans problèmes sur AVR et vous n'avez pas besoin de le porter et de le déboguer en conséquence, mais il est plus facile d'écrire sur le SDK natif (que vous devez également apprendre à cracher à partir de sources anglaises) à partir de zéro.

Alors oui. Ne lisez pas cet article. Et surtout, n'écrivez pas de commentaires.

Mais si:

1. Vous bricolez les microcontrôleurs depuis de nombreuses années et connaissez leur architecture par cœur.

2. Vous n'avez pas besoin de bugs d'origine chinoise incompréhensible.

3. Vous avez écrit et débogué des mégaoctets de code pour votre longue vie de développeur, et vous ne voulez absolument pas tout réécrire et tout déboguer.

4. Vous n'avez pas le temps ou le désir d'apprendre dans la langue d'un adversaire probable le SDK et le RTOS natifs d'une entreprise peu connue dans le monde (ce n'est toujours pas Microsoft), et attendez et croyez en leurs correctifs et mises à jour.

5. Lors de la programmation, vous n’avez pas grimpé spécialement pour «commencer si puis faire pendant la fin du commutateur», et vous considérez que les mots fonction lambda et coroutine sont du latin obscène.

6. Vous, en fait, à votre appareil déjà fonctionnel, mais conformément aux tendances des temps nouveaux, vous avez juste besoin d'un pont sans fil pour l'identification, la programmation et l'échange de données.

Eh bien, utilisez l'ESP8266 pour cela. Tout comme un pont sans fil. Ils, vous savez, utilisent AVR comme un expanseur de port pour ESP. Et nous ferons le contraire!



En fait, ne prenez pas trop au sérieux mes dernières déclarations. C'est essentiellement juste une blague. Tout développeur suffisamment expérimenté fait son choix sur la base de nombreux facteurs, tels que les paramètres de vitesse et de consommation d'énergie, le cycle de vie de l'appareil, la continuité avec les réalisations passées, le coût du produit lui-même et le coût de transfert vers une nouvelle plateforme, la fiabilité, le temps nécessaire pour étudier de nouvelles architectures, SDK, systèmes d'exploitation, la présence d'employés ayant une telle expérience dans un projet commun, etc.

Par conséquent, il vaut mieux quand:



Je serais heureux si vous avez aimé l'article. Je ne donne pas de bibliographies, c'est la même que dans l'article précédent.

PS

Et enfin, sur les signaux de l'espace. Tout le secret est que le module ESP avec le firmware NodeMCU aime vraiment envoyer toutes sortes d'informations à la console. Par exemple, après un redémarrage d'urgence (et cela arrive parfois à ESP, croyez-moi, le glucose est toujours le même). Ou, par exemple, si vous avez oublié de supprimer print ("quelque chose là-bas") du programme lui-même dans Lu après le débogage. Ou lorsque l'API obsolète (obsolète) apparaît (vous avez modifié le micrologiciel et devez maintenant utiliser une nouvelle orthographe, par exemple, lors du démarrage du serveur UDP) et ESP vous le rappelle désormais toujours. Jusqu'à ce que vous réécriviez le code.

Et le problème est que tout cela est envoyé avec précision et méthode à la console, c'est-à-dire au port UART. Eh bien, que se passe-t-il si votre port UART attend une commande ou des données à ce moment pour dire à votre chariot d'aller de l'avant? Votre panier pourrait alors tomber de la table.
Donc, ce point mérite également d'être examiné.