Pourquoi les gens créent-ils un serveur Web sur un microcontrôleur?

J'ai rencontré des gens qui créent des serveurs Web à l'aide de microcontrôleurs, pourquoi quelqu'un ferait-il cela? Quelles sont ses applications? De quelles compétences, outre le langage C, a-t-on besoin pour créer de tels serveurs? Je suis assez curieux de savoir que ces petits serveurs ont une si petite RAM.

Je l'ai fait dans quelques produits. Jusqu'à présent, la raison a été de permettre une configuration simple sur le terrain. Chaque fois, le produit devait déjà être connecté à Ethernet en raison de son fonctionnement principal. Le serveur Web n'a donc été que du code ajouté dans le microcontrôleur.

Le gros avantage d'un serveur HTTP est qu'aucun matériel ou logiciel spécial n'est requis pour présenter une interface utilisateur raisonnable à l'utilisateur final. Tout le monde a déjà un navigateur Web, donc cela ne dérange pas le client. Pensez à d'autres alternatives. Vous pouvez fournir un port RS-232, mais vous devez alors fournir une application personnalisée ou expliquer à quelqu'un comment configurer un programme de terminal avec la bonne vitesse de transmission, les bits de démarrage, les bits d'arrêt et la parité. Vous devez également fournir un câble ou espérer que le client en a un, et que quelqu'un doit se rendre à l'unité et s'y connecter physiquement. L'USB n'a pas le même problème de configuration, mais cela signifierait généralement un micro séparé dans le produit et là, vous avez besoin d'un programme personnalisé pour fonctionner sur la plate-forme que le client pourrait avoir.

Quant à la RAM, ce n'est pas vraiment un problème pour un serveur HTTP. Une pile de protocoles TCP a besoin de RAM, mais pas vraiment du serveur HTTP, à l'exception des ressources supplémentaires dont elle peut avoir besoin de la pile réseau. Un serveur Web a principalement besoin d'espace ROM, car la plupart de chaque page est constante, généralement avec quelques valeurs converties en texte et insérées à la volée. Les serveurs Web pour petits micros fonctionnent avec des systèmes de fichiers ROM et des séquences d'échappement dans ces fichiers qui provoquent l'appel de votre code d'application pour produire des chaînes personnalisables à insérer à quelques endroits prédéfinis.

Jusqu'à présent, j'ai utilisé un PIC 18 dans tous ces cas. Bien que les moins de 4 kilo-octets de RAM soient une limitation, il y a encore beaucoup à faire. L'espace ROM n'a même pas été proche d'un problème. Ma pile réseau pour le PIC 18 (disponible dans ma version des outils de développement PIC à www.embedinc.com/pic/dload.htm ) ne prend qu'une petite fraction de l'espace ROM d'un 18F67J60, ce qui est une bonne partie pour de telles choses depuis il a un MAC / PHY Ethernet complet intégré. Dans un cas, j'ai ce PIC comme serveur pour 6 connexions TCP simultanées. Ce n'est vraiment pas aussi lourd que les gens semblent le penser.

Un facteur clé de l'augmentation récente de la popularité des serveurs Web sur les microcontrôleurs est le désir d'accéder à distance aux informations des capteurs physiques (température, humidité, niveau de lumière, présence de monoxyde de carbone, etc.), ainsi que de faire bouger les choses dans le monde physique (commutateur sur une LED, déclencher une alarme, allumer un ventilateur d'extraction d'urgence, allumer une pompe de liquide de refroidissement) également à distance. Ce sont les applications.

Quelle meilleure façon d'obtenir un accès à distance générique, cohérent, indépendant de l'appareil et indépendant du concepteur que le protocole HTTP omniprésent, sur le réseau IP encore plus omniprésent? La couche physique de communication peut être le WiFi, Ethernet câblé ou toute autre option pratique prenant en charge les réseaux IP. C'est pourquoi les serveurs Web sur les appareils intégrés sont en cours.

Pour plus de perspicacité, on pourrait rechercher «l' Internet des objets » et voir le large éventail de processus de pensée qui en résulte.

En ce qui concerne les " petits serveurs ayant une si petite RAM ", il convient de noter que le protocole HTTP est assez simple pour être implémentable sur très peu de RAM, avec très peu de puissance de traitement. De plus, les microcontrôleurs d'aujourd'hui sont comparables ou, dans certains cas, plus puissants que les processeurs des premiers ordinateurs personnels sur lesquels les gens ont implémenté non seulement le Web, mais ont également effectué une variété de tâches interactives, même joué à des jeux.

De nombreux appareils en réseau fournissent un serveur Web pour examiner et définir les paramètres de configuration, vérifier l'état de l'appareil, etc. Par exemple, je peux configurer le routeur dans mon système en pointant mon navigateur sur http:///192.168.0.254(si je me souviens bien ...).

1. Parce qu'ils le peuvent.

2. Parce qu'ils peuvent être de très faible puissance. Comme sous 1W avec quelques pics de tirage. Moins d'un demi-ampli. La batterie et l'énergie solaire sont pratiques, contrairement aux gros ordinateurs.

3. Grandeur physique. Un microcontrôleur + puce wifi ou ethernet peut avoir la taille d'une clé USB.

4. Coût. Un microcontrôleur approprié pourrait être de l'ordre d'un dollar. Les pièces réseau presque aussi bon marché.

5. Jetable. Vous pouvez les mettre dans des projets uniques et s'ils meurent, ce n'est pas aussi mauvais que si un ordinateur cher le faisait.

6. Cause juste.

Avec l'avènement d'ordinateurs à part entière pour des dizaines de dollars (gratuits à 100 $) (shrevaplugs, raspberry pi, smartphones, clés USB Linux, clés Android, ROUTERS), vous verrez probablement moins de serveurs Web de microcontrôleurs à l'avenir, car il y a plus de COÛT et de taille comme facteur déterminant. Un Raspberry Pi de 35 dollars ou un Beaglebone de 45 dollars peut surpasser un bouclier Arduino + Ethernet ou Wifi en termes de coût, de performances et de facilité d'installation. Il est à peine plus grand que l'arduino. La seule chose que l'arduino peut faire est une efficacité énergétique de 0,1 W (0,5 mA à 50 mA en veille jusqu'à la pleine puissance de calcul [5 V, 16 MHz, 100% CPU] par l'ATMEGA seul) vs 4 W pour le RPI sans Ethernet / HDMI / USB utilisation au ralenti.

Les serveurs Web à microcontrôleur peuvent donc être alimentés par batterie en raison de la faible consommation de courant. Même alors, certains des nouveaux SoC linux comme un routeur de poche avec un serveur web peuvent être proches d'eux.

La réponse d'Olin touche à peu près toutes les raisons pour lesquelles j'ai utilisé un serveur Web intégré. Je travaille au développement de commandes industrielles et presque tous les produits que nous fabriquons ont un serveur Web intégré.

La plupart des clients auront déjà tout leur équipement sur leur réseau pour diverses raisons. Il est donc hautement souhaitable de pouvoir le configurer et / ou le contrôler via un navigateur Web au lieu d'installer des dizaines de programmes personnalisés.

Même s'ils utilisent un protocole industriel comme PROFINET , la couche physique est la même que le reste de leur Ethernet et ils n'ont alors besoin que d'un seul logiciel (un superviseur PROFINET IO) pour contrôler des dizaines de machines. D'après mon expérience, cette configuration est assez standard dans de nombreuses industries.

En ce qui concerne les ressources (puissance de traitement, RAM, ROM), une fois réduit à l'essentiel de l'ours, un matériel incroyablement minimal est nécessaire pour servir avec succès une page Web. Je pense que webACE détient le record du plus petit serveur web. C'est dommage que vous ne puissiez plus visiter la page qu'il a hébergée.

Les logiciels

Quelques statistiques de code pour le logiciel d'origine. J'avais initialement oublié d'inclure le "eeprom de données" de 64 octets sur puce dans les totaux, ce qui a conduit au chiffre de 1010 octets cité sur TBTF.

Startup       36 bytes
Serial       179
SLIP          91
IP           144
ICMP          47
TCP          188
Checksum     132
Application  257
Total       1074 bytes

Comprising:
  454 instructions
  912 instruction bytes
  162 data bytes
 2.01 bytes/instruction average

Quant aux autres compétences nécessaires, une compréhension approfondie du réseautage n'est pas vraiment nécessaire. Je n'ai jamais écrit de pile pour aucun protocole car il existe une pléthore de bibliothèques disponibles pour être liées et utilisées pour toutes les architectures imaginables. La connaissance d'un HTML brut de base est utile pour concevoir et écrire la page réelle.

En plus de cela, être capable de lire et de comprendre un journal de Wireshark ou Fiddler (analyseurs de réseau) sera probablement la compétence la plus utile car cela aidera grandement à déboguer tous les problèmes que vous rencontrez. Une petite lecture sur la structure des paquets de n'importe quel protocole que vous utilisez (TCP, IP, HTTP, UDP, PROFINET, etc.) vous dira où chercher dans le paquet les informations dont vous avez besoin. Vous pouvez même lancer l'un de ces analyseurs en ce moment et regarder le trafic entrant et sortant sur votre ordinateur pour en avoir une idée.

L'une des raisons est le défi. Plus encore si vous développez la carte microcontrôleur et / ou écrivez votre propre logiciel.