Dlaczego ludzie tworzą serwer sieciowy na mikrokontrolerze?

Spotkałem ludzi tworzących serwery sieciowe za pomocą mikrokontrolerów, dlaczego ktoś miałby to zrobić? Jakie są jego zastosowania? Jakie umiejętności poza językiem C są potrzebne do tworzenia takich serwerów? Jestem bardzo ciekawy, że te małe serwery mają tak małą pamięć RAM.

Zrobiłem to w kilku produktach. Do tej pory powodem była prosta konfiguracja pola. Za każdym razem produkt musiał być podłączony do sieci Ethernet ze względu na jego główne działanie. Serwer WWW został więc jedynie dodany kod do mikrokontrolera.

Dużą zaletą serwera HTTP jest to, że nie jest wymagany żaden specjalny sprzęt ani oprogramowanie do przedstawienia rozsądnego interfejsu użytkownika użytkownikowi końcowemu. Każdy ma już przeglądarkę internetową, więc nie przeszkadza to klientowi. Pomyśl o innych alternatywach. Możesz podać port RS-232, ale musisz albo dostarczyć niestandardową aplikację, albo wyjaśnić komuś, jak skonfigurować program terminalowy z odpowiednią prędkością transmisji, bitami początkowymi, bitami stopowymi i parzystością. Musisz albo dostarczyć kabel, albo mieć nadzieję, że klient go ma, a ktoś musi iść do urządzenia i fizycznie się z nim połączyć. USB nie ma tego samego problemu z konfiguracją, ale ogólnie oznaczałoby to całkowitą oddzielną mikro w produkcie i tam potrzebujesz niestandardowego programu do uruchomienia na dowolnej platformie, jaką może mieć klient.

Jeśli chodzi o pamięć RAM, nie stanowi to większego problemu dla serwera HTTP. Stos protokołu TCP potrzebuje trochę pamięci RAM, ale tak naprawdę serwer HTTP, z wyjątkiem dodatkowych zasobów, które mogą wymagać ze stosu sieciowego. Serwer sieciowy potrzebuje głównie miejsca w pamięci ROM, ponieważ większość każdej strony jest stała, zwykle z kilkoma wartościami konwertowanymi na tekst i wstawianymi w locie. Serwery sieci Web dla małych mikrosów działają z systemami plików ROM i sekwencjami Escape w tych plikach, które powodują wywołanie kodu aplikacji w celu wygenerowania dostosowywanych ciągów do wstawienia w kilku wstępnie zdefiniowanych miejscach.

Do tej pory korzystałem z PIC 18 we wszystkich tych przypadkach. Chociaż mniej niż 4 KB pamięci RAM stanowi ograniczenie, nadal można wiele zrobić. Miejsce w pamięci ROM nawet nie było bliskie problemowi. Mój stos sieciowy dla PIC 18 (dostępny w moim wydaniu PIC Development Tools na www.embedinc.com/pic/dload.htm ) zajmuje tylko niewielką część pamięci ROM 18F67J60, co jest dobrą częścią takich rzeczy, ponieważ ma wbudowany kompletny Ethernet / MAC PHY. W jednym przypadku mam ten PIC będący serwerem dla 6 jednoczesnych połączeń TCP. To naprawdę nie jest tak ciężkie, jak się wydaje.

Kluczowym czynnikiem przyczyniającym się do niedawnego wzrostu popularności serwerów internetowych na mikrokontrolerach jest chęć dostępu do informacji z czujników fizycznych (temperatura, wilgotność, poziom światła, obecność tlenku węgla itp.) Zdalnie, a także aby zdarzały się rzeczy w świecie fizycznym (przełącznik na diodzie LED, uruchom alarm, włącz awaryjny wentylator wyciągowy, włącz pompę płynu chłodzącego) również zdalnie. To są aplikacje.

Czy jest lepszy sposób na uzyskanie ogólnego, spójnego, niezależnego od urządzenia, niezależnego od projektantów zdalnego dostępu niż wszechobecny protokół HTTP w jeszcze bardziej wszechobecnej sieci IP? Fizyczną warstwą komunikacji może być WiFi, przewodowy Ethernet lub inna wygodna opcja, która obsługuje sieci IP. Właśnie dlatego tworzone są serwery sieciowe na urządzeniach wbudowanych.

Aby uzyskać więcej informacji, można wyszukać „ Internet przedmiotów ” i zobaczyć szeroki zakres procesów myślowych, które się pojawiają.

Jeśli chodzi o „ małe serwery posiadające tak małą pamięć RAM ”, warto zauważyć, że protokół HTTP jest na tyle prosty, że można go wdrożyć na bardzo małej pamięci RAM i przy bardzo małej mocy obliczeniowej. Ponadto dzisiejsze mikrokontrolery są porównywalne lub w niektórych przypadkach bardziej wydajne niż procesory na wczesnych komputerach osobistych, na których ludzie zaimplementowali nie tylko sieć, ale także wykonywali różnorodne interaktywne zadania, nawet grając w gry.

Wiele urządzeń w sieci udostępnia serwer WWW do badania i ustawiania parametrów konfiguracyjnych, sprawdzania stanu urządzenia itp. Na przykład mogę skonfigurować router w moim systemie, wskazując przeglądarkę na http:///192.168.0.254(jeśli dobrze pamiętam ...).

1. Ponieważ mogą.

2. Ponieważ mogą mieć bardzo niską moc. Jak poniżej 1 W z pewnymi szczytami. Poniżej pół wzmacniacza. Bateria i energia słoneczna są praktyczne, w przeciwieństwie do większych komputerów.

3. Fizyczny rozmiar. Mikrokontroler + Wi-Fi lub układ Ethernet może mieć rozmiar pendrive'a.

4. Koszt. Odpowiedni do tego mikrokontroler może znajdować się w przedziale jednego dolara. Części sieciowe są prawie tak tanie.

5. Jednorazowy. Możesz umieścić je w jednorazowych projektach, a jeśli umrą, nie będzie tak źle, jak w przypadku drogiego komputera.

6. Właśnie dlatego.

Wraz z pojawieniem się w pełni wydanych komputerów za kilkadziesiąt dolarów (za darmo do 100 USD) (shrevaplugs, raspberry pi, smartfony, napędy USB z linuksem, pendrive z Androidem, ROUTERY), prawdopodobnie w przyszłości będzie mniej serwerów sieciowych z mikrokontrolerem, ponieważ istnieje nie jest już KOSZTEM i rozmiarem jako czynnikiem napędzającym. Raspberry Pi o wartości 35 dolarów lub Beaglebone o wartości 45 dolarów może przewyższyć ekran Arduino + Ethernet lub Wi-Fi pod względem kosztów, wydajności i łatwości konfiguracji. Jest niewiele większy niż arduino. Jedyne, co Arduino może z tym zrobić, to wydajność energetyczna 0,1 W (0,5 mA do 50 mA uśpienia do pełnej mocy obliczeniowej [5 V, 16 MHz, 100% procesora] według samej ATMEGA) vs 4 W dla RPI bez Ethernet / HDMI / USB użycie na biegu jałowym.

Tak więc serwery sieciowe mikrokontrolera mogą być zasilane bateryjnie z powodu niskiego zużycia prądu. Nawet wtedy niektóre nowsze Linux SoC, takie jak kieszonkowy router z serwerem internetowym, mogą być blisko nich.

Odpowiedź Olin prawie trafia z każdego powodu, dla którego użyłem wbudowanego serwera internetowego. Pracuję nad rozwojem sterowania przemysłowego i prawie każdy produkowany przez nas produkt ma wbudowany serwer internetowy.

Większość klientów będzie już mieć cały sprzęt w swojej sieci już z różnych powodów. Bardzo pożądana jest możliwość skonfigurowania i / lub kontrolowania go za pomocą przeglądarki internetowej zamiast instalowania dziesiątek programów niestandardowych.

Nawet jeśli używają przemysłowego protokołu, takiego jak PROFINET , warstwa fizyczna jest taka sama jak reszta ich sieci Ethernet, a następnie potrzebują tylko jednego oprogramowania (nadzorcy PROFINET IO) do sterowania dziesiątkami maszyn. Z mojego doświadczenia wynika, że ​​ta konfiguracja jest dość standardowa w wielu branżach.

Jeśli chodzi o zasoby (moc obliczeniową, pamięć RAM, ROM), w przypadku niezbędnego niedźwiedzia niezbędny jest niewiarygodnie minimalny sprzęt, aby z powodzeniem obsługiwać stronę internetową. webACE Myślę, że ma rekord najmniejszego serwera WWW. Szkoda, że ​​nie możesz już odwiedzać strony, którą hostował.

Oprogramowanie

Niektóre statystyki kodu dla oryginalnego oprogramowania. Pierwotnie zapomniałem o dołączeniu 64-bajtowego „eepromu danych” do sumy, co doprowadziło do liczby 1010 bajtów cytowanej na 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

Jeśli chodzi o inne potrzebne umiejętności, dogłębne zrozumienie sieci nie jest tak naprawdę konieczne. Nigdy nie napisałem stosu dla żadnego protokołu, ponieważ istnieje mnóstwo bibliotek, które można połączyć i używać dla każdej możliwej architektury. Znajomość podstawowych podstawowych plików HTML jest przydatna przy projektowaniu i pisaniu rzeczywistej strony.

Oprócz tego umiejętność czytania i rozumienia dziennika z Wireshark lub Fiddler (analizatory sieci) będzie prawdopodobnie najbardziej przydatną umiejętnością, ponieważ znacznie pomoże w debugowaniu wszelkich problemów. Trochę lektury na temat struktury pakietu dowolnego używanego protokołu (TCP, IP, HTTP, UDP, PROFINET itp.) Pokaże Ci, gdzie szukać w pakiecie wszelkich potrzebnych informacji. Możesz nawet odpalić jeden z tych analizatorów i spojrzeć na ruch przychodzący i wychodzący na komputer, aby go wyczuć.

Jednym z powodów jest wyzwanie. Co więcej, jeśli opracujesz płytę mikrokontrolera i / lub napiszesz własne oprogramowanie.