사람들이 마이크로 컨트롤러에서 웹 서버를 만드는 이유는 무엇입니까?

마이크로 컨트롤러를 사용하여 웹 서버를 만드는 사람들을 만났습니다. 왜 누군가 그렇게할까요? 그 응용 프로그램은 무엇입니까? 그러한 서버를 만들려면 C 언어 외에 어떤 기술이 필요합니까? 작은 RAM을 가진 작은 서버가 궁금합니다.

나는 몇 가지 제품 에서이 작업을 수행했습니다. 지금까지의 이유는 간단한 현장 구성이 가능했기 때문입니다. 제품의 주요 작동으로 인해 제품을 이미 이더넷에 연결해야했습니다. 따라서 웹 서버는 마이크로 컨트롤러에 코드를 추가하기 만했습니다.

HTTP 서버의 가장 큰 장점은 최종 사용자에게 합리적인 사용자 인터페이스를 제공하기 위해 특별한 하드웨어 나 소프트웨어가 필요하지 않다는 것입니다. 모든 사람은 이미 웹 브라우저를 가지고 있으므로 고객에게 귀찮게하지 않습니다. 다른 대안을 생각해보십시오. RS-232 포트를 제공 할 수 있지만 사용자 지정 앱을 제공하거나 올바른 보드 속도, 시작 비트, 정지 비트 및 패리티로 터미널 프로그램을 설정하는 방법을 누군가에게 설명해야합니다. 또한 케이블을 공급하거나 고객에게 케이블이 제공되기를 바랍니다. 누군가가 장치로 이동하여 물리적으로 연결해야합니다. USB는 동일한 구성 문제가 없지만 일반적으로 제품에서 완전히 분리 된 마이크로를 의미하므로 고객이 어떤 플랫폼에서든 실행할 수있는 사용자 정의 프로그램이 필요합니다.

RAM의 경우 HTTP 서버에는 그다지 큰 문제가 아닙니다. TCP 프로토콜 스택에는 약간의 RAM이 필요하지만 네트워크 스택에서 필요할 수있는 추가 리소스를 제외하고는 실제로 HTTP 서버가 아닙니다. 웹 서버는 대부분 ROM 페이지를 필요로합니다. 대부분의 페이지는 일정하며 보통 몇 개의 값이 텍스트로 변환되어 즉시 삽입됩니다. 소형 마이크로 웹 서버는 ROM 파일 시스템과 작동하며 이러한 파일의 이스케이프 시퀀스를 사용하여 응용 프로그램 코드를 호출하여 미리 정의 된 몇 군데 위치에 삽입 할 수 있도록 사용자 정의 가능한 문자열을 생성합니다.

지금까지 이러한 모든 경우에 PIC 18을 사용했습니다. 4KB 미만의 RAM은 제한 사항이지만 여전히 많은 작업을 수행 할 수 있습니다. ROM 공간은 문제에 가깝지 않았습니다. PIC 18의 네트워크 스택 ( www.embedinc.com/pic/dload.htm의 PIC Development Tools 릴리스에서 사용 가능 )은 18F67J60의 ROM 공간 중 일부만 차지하므로 그 이후로 좋은 부분입니다. 완전한 이더넷 MAC / PHY가 내장되어 있습니다. 어떤 경우에는 PIC가 6 개의 동시 TCP 연결을위한 서버입니다. 사람들이 생각하는 것만 큼 무거운 것은 아닙니다.

최근 마이크로 컨트롤러에서 웹 서버의 인기가 높아지는 주요 원인은 물리적 센서 정보 (온도, 습도, 조도, 일산화탄소 등)에 원격으로 액세스하고 물리적 환경에서 발생하도록하는 것입니다 (스위치 LED에서 알람을 트리거하고 비상 배기 팬을 켜고 냉각수 펌프를 켭니다). 그것들은 응용 프로그램입니다.

훨씬 더 많은 유비쿼터스 IP 네트워크를 통해 유비쿼터스 HTTP 프로토콜보다 일반적이고 일관된 장치 독립적 인 디자이너 독립적 원격 액세스를 달성하는 더 좋은 방법은 무엇입니까? 물리적 통신 계층은 WiFi, 유선 이더넷 또는 IP 네트워킹을 지원하는 기타 편리한 옵션 일 수 있습니다. 이것이 임베디드 장치의 웹 서버가 수행되는 이유입니다.

더 많은 통찰력을 얻으려면 " Internet of Things "를 검색 하여 다양한 사고 과정을 볼 수 있습니다.

" 이러한 작은 RAM을 가진 작은 서버 "와 관련하여 , HTTP 프로토콜은 처리 능력이 거의없는 아주 작은 RAM에서도 구현할 수있을 정도로 단순하다는 점에 주목할 가치가 있습니다. 또한 오늘날의 마이크로 컨트롤러는 사람들이 웹뿐만 아니라 게임을 수행 한 다양한 대화 형 작업을 수행 한 초기 개인용 컴퓨터의 프로세서와 비교할 수 있거나 일부 경우에는 더 강력합니다.

많은 네트워크 장치는 구성 매개 변수를 검사 및 설정하고 장치의 상태를 확인하는 등의 웹 서버를 제공합니다. 예를 들어, 브라우저를 http:///192.168.0.254(정확하게 기억하는 경우) 를 가리키면 시스템에서 라우터를 구성 할 수 있습니다 .

1. 그들이 할 수 있기 때문에.

2. 그들은 매우 낮은 전력이 될 수 있기 때문입니다. 1W 이하에서 약간의 피크 드로우가 있습니다. 반 암페어 미만. 더 큰 컴퓨터와 달리 배터리와 태양열 발전은 실용적입니다.

3. 물리적 크기. 마이크로 컨트롤러 + wifi 또는 이더넷 칩은 썸 드라이브의 크기 일 수 있습니다.

4. 비용. 이에 적합한 마이크로 컨트롤러는 단일 달러 범위에있을 수 있습니다. 네트워킹 부품은 거의 저렴합니다.

5. 사용 후 버릴 수 있는. 당신은 그것들을 일회성 프로젝트에 넣을 수 있고 그들이 죽어도 값 비싼 컴퓨터만큼 나쁘지 않습니다.

6. 다만 원인.

수십 달러 (무료로 $ 100까지) (슈어 플러그, 라즈베리 파이, 스마트 폰, 리눅스 썸 드라이브, 안드로이드 스틱, 라우터)에 대대적 인 컴퓨터가 등장함에 따라 앞으로 마이크로 컨트롤러 웹 서버가 줄어들 것입니다. 더 이상 원가율과 비용으로 작용하지 않습니다. 35 달러의 라즈베리 파이 또는 45 달러의 비글 본은 비용, 성능, 설정 용이성면에서 Arduino + 이더넷 또는 Wifi 차폐보다 성능이 뛰어납니다. arduino보다 거의 큽니다. arduino가 할 수있는 것은 이더넷 / hdmi / usb가없는 RPI의 경우 전력 효율 0.1W (ATMEGA만으로는 최대 컴퓨팅 전력 [5v, 16mhz, 100 % CPU에 대해 0.5mA ~ 50mA 슬립], 4W) 대 4W입니다. 유휴 상태에서의 사용량.

따라서 낮은 소비 전류로 인해 마이크로 컨트롤러 웹 서버에 배터리 전원을 공급할 수 있습니다. 그럼에도 불구하고 웹 서버가있는 포켓 라우터와 같은 최신 Linux SoC 중 일부가 가까이있을 수 있습니다.

Olin의 답변은 내장 웹 서버를 사용하는 모든 이유에서 많은 인기를 얻었습니다. 산업용 컨트롤을 개발하고 있으며 거의 ​​모든 제품에 웹 서버가 내장되어 있습니다.

대부분의 고객은 다양한 이유로 이미 모든 장비를 네트워크에 보유하고 있습니다. 따라서 수십 개의 사용자 정의 프로그램을 설치하는 대신 웹 브라우저를 통해 구성 및 / 또는 제어 할 수있는 것이 매우 바람직합니다.

PROFINET 과 같은 산업용 프로토콜을 사용하더라도 물리적 계층은 나머지 이더넷과 동일하며 수십 대의 시스템을 제어하기 위해 단 하나의 소프트웨어 (PROFINET IO 수퍼바이저) 만 필요합니다. 내 경험상이 설정은 많은 산업 분야에서 상당히 표준입니다.

리소스 (프로세싱 파워, RAM, ROM)와 관련하여 베어 필수 요소로 분류 할 때 웹 페이지를 성공적으로 제공하기 위해서는 매우 작은 하드웨어가 필요합니다. webACE 가장 작은 웹 서버에 대한 기록을 보유하고 있다고 생각합니다. 더 이상 호스팅 된 페이지를 방문 할 수 없다는 것은 부끄러운 일입니다.

소프트웨어

원본 소프트웨어에 대한 일부 코드 통계. 원래 온칩 64 바이트 "데이터 eeprom"을 총계에 포함하는 것을 잊어 버렸기 때문에 TBTF에서 인용 한 1010 바이트의 수치로 이어졌습니다.

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

필요한 다른 기술에 대해서는 네트워킹에 대한 깊은 이해가 필요하지 않습니다. 상상할 수있는 모든 아키텍처에 사용할 수있는 수많은 라이브러리가 있기 때문에 프로토콜에 대해 스택을 작성하지 않았습니다. 기본 원시 HTML을 아는 것은 실제 페이지를 디자인하고 작성하는 데 유용합니다.

Wireshark 또는 Fiddler (네트워크 분석기) 의 로그를 읽고 이해할 수있는 것 외에는 문제를 디버깅하는 데 큰 도움이되므로 아마도 가장 유용한 기술 일 것입니다. 사용중인 프로토콜 (TCP, IP, HTTP, UDP, PROFINET 등)의 패킷 구조를 조금만 읽으면 필요한 정보를 찾기 위해 패킷을 찾을 위치를 알 수 있습니다. 지금 당장 그 분석기 중 하나를 가동시키고 컴퓨터로 들어오는 트래픽을보고 느낄 수 있습니다.

그 이유 중 하나는 도전입니다. 마이크로 컨트롤러 보드를 개발하거나 자체 소프트웨어를 작성하는 경우 더욱 그렇습니다.