Warum erstellen Leute Webserver auf einem Mikrocontroller?

Ich habe dies in einigen Produkten getan. Bisher war der Grund, eine einfache Feldkonfiguration zu ermöglichen. Jedes Mal, wenn das Produkt aufgrund seines Hauptbetriebs bereits mit Ethernet verbunden werden musste. Der Webserver wurde also lediglich um Code im Mikrocontroller ergänzt.

Der große Vorteil eines HTTP-Servers besteht darin, dass keine spezielle Hardware oder Software erforderlich ist, um dem Endbenutzer eine vernünftige Benutzeroberfläche zu präsentieren. Jeder hat bereits einen Webbrowser, daher ist dies für den Kunden kein Problem. Denken Sie über andere Alternativen nach. Sie könnten einen RS-232-Anschluss bereitstellen, aber dann müssen Sie entweder eine benutzerdefinierte App bereitstellen oder jemandem erklären, wie man ein Terminalprogramm mit der richtigen Baudrate, Startbits, Stoppbits und Parität einrichtet. Sie müssen auch entweder ein Kabel liefern oder hoffen, dass der Kunde eines hat, und jemand muss zum Gerät gehen und es physisch anschließen. USB hat nicht das gleiche Konfigurationsproblem, würde aber im Allgemeinen ein ganz separates Mikro im Produkt bedeuten, und dort benötigen Sie ein benutzerdefiniertes Programm, das auf jeder Plattform des Kunden ausgeführt werden kann.

RAM ist für einen HTTP-Server kein großes Problem. Ein TCP-Protokollstapel benötigt etwas RAM, aber der HTTP-Server nicht wirklich, abgesehen von den zusätzlichen Ressourcen, die er möglicherweise vom Netzwerkstapel benötigt. Ein Webserver benötigt meistens ROM-Speicherplatz, da der größte Teil jeder Seite konstant ist, normalerweise mit einigen Werten, die in Text konvertiert und im laufenden Betrieb eingefügt werden. Webserver für kleine Mikros arbeiten mit ROM-Dateisystemen und Escape-Sequenzen in diesen Dateien, die dazu führen, dass Ihr Anwendungscode aufgerufen wird, um anpassbare Zeichenfolgen zum Einfügen an einigen vordefinierten Stellen zu erzeugen.

Bisher habe ich in all diesen Fällen einen PIC 18 verwendet. Während die weniger als 4 KB RAM eine Einschränkung darstellen, können Sie noch viel tun. Der ROM-Speicherplatz war noch nicht einmal annähernd ein Problem. Mein Netzwerk-Stack für den PIC 18 (verfügbar in meiner PIC-Entwicklungstools-Version unter www.embedinc.com/pic/dload.htm ) nimmt nur einen kleinen Bruchteil des ROM-Speicherplatzes eines 18F67J60 ein, was für solche Dinge ein nettes Teil ist Es hat einen kompletten Ethernet-MAC/PHY eingebaut. In einem Fall habe ich diesen PIC als Server für 6 gleichzeitige TCP-Verbindungen. Es ist wirklich nicht so schwer wie die Leute zu denken scheinen.

Ein wesentlicher Faktor für die jüngste Zunahme der Popularität von Webservern auf Mikrocontrollern ist der Wunsch, aus der Ferne auf physische Sensorinformationen (Temperatur, Feuchtigkeit, Lichtstärke, Vorhandensein von Kohlenmonoxid usw.) zuzugreifen und Dinge in der physischen Welt zu bewirken (switch an einer LED, Auslösen eines Alarms, Einschalten eines Notabsauggebläses, Einschalten einer Kühlmittelpumpe) auch aus der Ferne. Das sind die Anwendungen.

Gibt es einen besseren Weg, um einen generischen, konsistenten, geräteunabhängigen und Designer-unabhängigen Fernzugriff zu erreichen, als das allgegenwärtige HTTP-Protokoll über das noch allgegenwärtigere IP-Netzwerk? Die physische Kommunikationsschicht kann WiFi, kabelgebundenes Ethernet oder jede andere praktische Option sein, die IP-Netzwerke unterstützt. Aus diesem Grund werden Webserver auf eingebetteten Geräten verwendet.

Für weitere Einblicke könnte man nach dem „ Internet der Dinge “ suchen und die breite Palette von Denkprozessen sehen, die sich daraus ergeben.

In Bezug auf die „ winzigen Server mit so kleinem RAM “ ist anzumerken, dass das HTTP-Protokoll einfach genug ist, um auf sehr wenig RAM mit sehr geringer Verarbeitungsleistung implementiert zu werden. Außerdem sind die heutigen Mikrocontroller mit den Prozessoren der frühen Personal Computer vergleichbar oder in einigen Fällen sogar noch leistungsfähiger als diese, auf denen Menschen nicht nur das Web implementiert, sondern auch eine Vielzahl interaktiver Aufgaben ausgeführt und sogar Spiele gespielt haben.

Viele vernetzte Geräte bieten einen Webserver zum Untersuchen und Einstellen von Konfigurationsparametern, Überprüfen des Gerätestatus usw. Zum Beispiel kann ich den Router in meinem System konfigurieren, indem ich in meinem Browser auf http:///192.168.0.254(wenn ich mich richtig erinnere...) zeige.

1. Weil sie es können.

2. Weil sie sehr stromsparend sein können. Wie unter 1W mit einigen Spitzenwerten. Unter einem halben Ampere. Batterie- und Solarenergie sind im Gegensatz zu größeren Computern praktisch.

3. Physische Größe. Ein Mikrocontroller + WLAN- oder Ethernet-Chip kann die Größe eines USB-Sticks haben.

4. Kosten. Ein dafür geeigneter Mikrocontroller könnte im Ein-Dollar-Bereich liegen. Die Netzwerkteile fast genauso günstig.

5. Einweg. Sie können sie in einmalige Projekte stecken, und wenn sie sterben, ist es nicht so schlimm wie bei einem teuren Computer.

6. Gerechte Sache.

Mit dem Aufkommen ausgewachsener Computer für Dutzende von Dollar (kostenlos bis 100 $) (Shrevaplugs, Himbeer-Pi, Smartphones, Linux-Sticks, Android-Sticks, ROUTER) werden Sie in Zukunft wahrscheinlich weniger Mikrocontroller-Webserver sehen, denn es gibt sie nicht mehr KOSTEN und Größe als treibende Faktoren. Ein 35-Dollar-Raspberry Pi oder ein 45-Dollar-Beaglebone kann ein Arduino + Ethernet- oder Wifi-Shield in Bezug auf Kosten, Leistung und einfache Einrichtung übertreffen. Es ist kaum größer als das Arduino. Das einzige, was das Arduino dagegen tun kann, ist eine Energieeffizienz von 0,1 W (0,5 mA bis 50 mA Ruhezustand bis zur vollen Rechenleistung [5 V, 16 MHz, 100 % CPU] allein durch ATMEGA) gegenüber 4 W für das RPI ohne Ethernet / HDMI / USB Nutzung im Leerlauf.

So können Mikrocontroller-Webserver aufgrund des geringen Stromverbrauchs batteriebetrieben werden. Selbst dann können einige der neueren Linux-SoCs wie ein Pocket-Router mit einem Webserver in ihrer Nähe sein.

Olins Antwort trifft so ziemlich jeden Grund, warum ich einen eingebetteten Webserver verwendet habe. Ich arbeite an der Entwicklung von Industriesteuerungen und fast jedes Produkt, das wir produzieren, hat einen eingebetteten Webserver.

Die meisten Kunden haben aus verschiedenen Gründen bereits alle ihre Geräte in ihrem Netzwerk. Daher ist es sehr wünschenswert, es über einen Webbrowser konfigurieren und/oder steuern zu können, anstatt Dutzende von benutzerdefinierten Programmen zu installieren.

Selbst wenn sie ein Industrieprotokoll wie PROFINET verwenden , ist die physikalische Schicht die gleiche wie der Rest ihres Ethernets und sie benötigen dann nur eine Software (einen PROFINET IO-Supervisor), um Dutzende von Maschinen zu steuern. Meiner Erfahrung nach ist diese Einrichtung in vielen Branchen ziemlich üblich.

In Bezug auf die Ressourcen (Rechenleistung, RAM, ROM) ist, wenn man sie auf das Wesentliche reduziert, unglaublich wenig Hardware erforderlich, um eine Webseite erfolgreich bereitzustellen. webACE hält meiner Meinung nach den Rekord für den kleinsten Webserver. Schade, dass Sie die gehostete Seite nicht mehr besuchen können.

Die Software

Einige Code-Statistiken für die Originalsoftware. Ich hatte ursprünglich vergessen, das 64-Byte-On-Chip-"Daten-EEPROM" in die Gesamtsumme einzubeziehen, was zu der auf TBTF angegebenen Zahl von 1010 Bytes führte.

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

Was andere benötigte Fähigkeiten betrifft, so ist ein tiefes Verständnis von Netzwerken nicht wirklich notwendig. Ich habe noch nie einen Stack für irgendein Protokoll geschrieben, weil es eine Fülle von Bibliotheken gibt, die eingebunden und für jede erdenkliche Architektur verwendet werden können. Die Kenntnis einiger grundlegender roher HTML-Elemente ist nützlich, um die eigentliche Seite zu entwerfen und zu schreiben.

Abgesehen davon ist die Fähigkeit, ein Protokoll von Wireshark oder Fiddler (Netzwerkanalysatoren) zu lesen und zu verstehen , wahrscheinlich die nützlichste Fähigkeit, da es beim Debuggen von Problemen, die Sie haben, sehr hilfreich sein wird. Ein wenig Lektüre der Paketstruktur des von Ihnen verwendeten Protokolls (TCP, IP, HTTP, UDP, PROFINET usw.) wird Ihnen sagen, wo Sie im Paket nach den benötigten Informationen suchen müssen. Sie können sogar sofort einen dieser Analysatoren starten und sich den Verkehr ansehen, der zu Ihrem Computer kommt und geht, um ein Gefühl dafür zu bekommen.

Einer der Gründe ist die Herausforderung. Dies gilt umso mehr, wenn Sie das Mikrocontroller-Board entwickeln und / oder Ihre eigene Software schreiben.