How to Stream OV2640 JPEG Frames with W5500 on an STM32 MCU?

Summary

This project architecture combines an STM32 microcontroller, an OV2640 camera, and a WIZnet W5500 Ethernet controller to stream JPEG images directly to a web browser. The OV2640 generates compressed JPEG frames, the STM32 captures and buffers those frames, and the W5500 provides hardware TCP/IP networking over SPI. An HTTP connection delivers the browser interface, while a separate WebSocket connection carries successive JPEG frames. The architecture is applicable to STM32 MCUs that provide sufficient memory and peripheral resources for camera capture and SPI Ethernet communication.

What the Project Does

The system implements a compact wired network camera that can be viewed from a browser without requiring a dedicated desktop application.

The overall data path is:

OV2640 → STM32 MCU → JPEG Frame Buffer → W5500 → Ethernet → WebSocket → Web Browser

The OV2640 performs image acquisition and JPEG compression. The STM32 configures the camera, captures the resulting byte stream, identifies complete JPEG frames, and passes them to the network transmission logic.

The W5500 then transports those frames over Ethernet.

The original reference implementation used an STM32F103 device, but the architecture is not inherently tied to that MCU. A generalized STM32 implementation needs:

An SPI peripheral for W5500 communication

GPIO or a suitable parallel camera interface for OV2640 pixel data

An I2C-compatible peripheral or GPIO implementation for OV2640 SCCB configuration

Enough SRAM to hold at least one expected JPEG frame

Interrupt, DMA, or peripheral resources capable of receiving camera data without losing bytes

The OV2640 is configured using its SCCB control interface. Image data is transferred separately through an 8-bit parallel bus with synchronization signals including PCLK, HREF, and VSYNC. In the original implementation, image bytes were sampled on PCLK events while HREF indicated valid line data.

The camera is configured to output JPEG rather than raw RGB data. This is important for MCU-based streaming because an uncompressed VGA image requires substantially more memory and network bandwidth than a compressed JPEG frame.

The source project reports JPEG frames of roughly 12 KB in its tested 640×480 configuration, although actual JPEG size varies with image content, compression settings, lighting, and resolution.

The STM32 identifies individual JPEG images using the standard JPEG boundaries:

FF D8   JPEG Start of Image
...
FF D9   JPEG End of Image

After a complete frame has been captured, it is sent through a persistent WebSocket connection.

The browser-side flow is therefore:

HTTP request → HTML page → WebSocket connection → JPEG binary frames → HTML5 Canvas

This avoids repeatedly requesting each image through HTTP polling. The HTTP server is mainly responsible for delivering the user interface, while WebSocket becomes the continuous image channel.

Where WIZnet Fits

The WIZnet product in this architecture is the W5500 Hardwired TCP/IP Ethernet Controller.

The W5500 connects to the STM32 over SPI and handles TCP/IP networking independently from the MCU application.

It provides:

Hardware TCP/IPv4 processing

Eight independent hardware sockets

32 KB of internal TX/RX buffer memory

Integrated 10/100 Ethernet MAC and PHY

SPI host communication supporting high-speed transfers

For this camera architecture, two W5500 sockets can be assigned different responsibilities.

Socket A — HTTP server

The browser initially connects to the STM32/W5500 system using HTTP. The firmware returns the HTML and JavaScript required to display the camera interface.

Socket B — WebSocket server

After loading the page, the browser establishes a WebSocket connection. Completed JPEG images are sent as binary WebSocket messages through this persistent TCP connection.

The original project explicitly uses one W5500 socket for HTTP and another for WebSocket image transfer.

This separation is useful because the two connections have different workloads.

HTTP traffic is relatively small and intermittent. The WebSocket channel carries repeated image payloads and therefore requires greater sustained throughput.

The W5500's role can be summarized as:

STM32 application → W5500 socket API → hardware TCP/IP → Ethernet

The STM32 does not need to execute the complete TCP/IP protocol stack in software. Instead, application firmware controls hardware sockets and moves payload data between MCU memory and W5500 socket buffers.

That separation is useful in camera applications because the MCU is already responsible for time-sensitive image acquisition.

Implementation Notes

OV2640 JPEG Configuration

The reference implementation initializes the OV2640 in main.c with calls including:

iic_init();
ov2640_jpeg_config(JPEG_640x480);

File: main.c

The first function initializes the control interface used to configure the OV2640. The second selects JPEG output at the requested camera resolution. The original project then configures additional parameters such as exposure, contrast, saturation, lighting mode, and the GPIO interface used for image capture.

For a general STM32 MCU, the exact peripheral initialization will vary by STM32 family and board design. The important architectural requirement is that the OV2640 itself produces the compressed JPEG stream before the image reaches the STM32.

This avoids performing JPEG encoding on the MCU.

JPEG Frame Detection

The original frame-capture logic is located in websocket.c.

A simplified excerpt from the actual source logic is:

case 2:
    JPEGBuffer[JPEGCnt++] = temp;

    if(temp == 0xff)
        jpg_flag = 3;
    break;

case 3:
    JPEGBuffer[JPEGCnt++] = temp;

    if(temp == 0xd9)
        jpg_flag = 4;

File: websocket.c

The complete state machine first detects FF D8, stores the JPEG payload, and continues until FF D9 is received. jpg_flag then indicates that a complete frame is ready for transmission.

This logic is portable across STM32 devices because JPEG boundary detection is independent of the MCU family.

What changes between STM32 platforms is how the bytes enter the buffer.

A smaller STM32 may sample a GPIO bus through interrupts, as the reference design does. Other STM32 devices may provide peripherals or DMA arrangements that can capture the camera bus with less CPU intervention.

The networking architecture remains the same.

WebSocket Transmission Through W5500

The original project waits until a complete image is available:

while(jpg_flag != 4);
jpgLen = JPEGCnt;

File: websocket.c

It then creates a WebSocket binary frame and transmits the JPEG through the W5500 socket API.

The source divides large images into smaller transmission blocks:

if(jpgLen > WS_PACKET_LEN)
{
    send(s, (uint8*)(JPEGBuffer + send_len), WS_PACKET_LEN);
    send_len += WS_PACKET_LEN;
    jpgLen -= WS_PACKET_LEN;
}

File: websocket.c

This exists because an entire JPEG should not be assumed to fit into one W5500 socket-buffer operation.

The W5500 contains 32 KB of total internal TX/RX memory distributed among its eight sockets. Buffer allocation should therefore be selected according to the needs of the HTTP and image-streaming channels.

The WebSocket frame itself uses binary opcode 0x02. Because JPEG payloads are normally much larger than 125 bytes, the reference project uses the WebSocket extended payload-length mechanism.

The complete generalized processing sequence is:

Capture JPEG → Detect FF D9 → Determine Frame Length → Build WebSocket Header → Send Header + JPEG in Chunks → Reset Capture State → Acquire Next Frame

This architecture does not require a specific STM32 model.

Practical Tips / Pitfalls

Size the JPEG buffer for worst-case frames. JPEG size changes considerably depending on resolution, quality settings, and scene complexity. A buffer sized only for an observed average frame can overflow.

Keep camera acquisition independent from blocking network operations. Image capture is driven by camera timing. Long SPI or socket waits can cause lost camera bytes if acquisition and transmission share the same blocking execution path.

Use the fastest reliable SPI configuration for the board. W5500 supports high-speed SPI, but practical speed depends on the STM32 peripheral, PCB layout, wiring length, and signal quality. WIZnet's own STM32 testing shows that achievable TCP throughput changes significantly with SPI clock rate and buffer configuration.

Allocate W5500 socket memory according to traffic. The WebSocket image channel typically needs more sustained buffering than the HTTP control channel. Do not assume equal socket allocation is optimal.

Validate JPEG markers before transmission. Missing bytes during parallel camera capture can corrupt a frame. A valid FF D8 start and FF D9 end provide a basic integrity boundary before sending the image.

Recover from link and WebSocket failures. Production firmware should handle Ethernet link loss, TCP disconnects, WebSocket reconnects, camera timeout, and incomplete JPEG frames rather than waiting indefinitely.

Consider double buffering when MCU SRAM permits it. One buffer can receive the next camera frame while the other is being transferred to W5500. This can reduce gaps between frames, although memory requirements increase substantially.

FAQ

Q: Why use W5500 for an STM32 camera project?

The STM32 must already manage camera configuration, image acquisition, JPEG buffering, and application logic. W5500 moves TCP/IP socket processing into dedicated hardware and exposes a simpler SPI-based socket interface. It provides eight hardware sockets and 32 KB of internal network-buffer memory, allowing the STM32 to spend more of its resources on the camera data path.

Q: How does W5500 connect to an STM32 MCU?

W5500 connects through SPI using SCLK, MOSI, MISO, and chip-select signals, together with reset and optionally interrupt handling. The exact STM32 SPI peripheral and GPIO pins depend on the selected MCU and PCB. W5500 supports SPI modes 0 and 3 and is designed to be controlled by an external MCU.

Q: What role does W5500 play in this camera architecture?

W5500 provides the Ethernet and TCP transport between the STM32 camera application and the browser. One hardware socket can serve the HTML interface over HTTP, while another socket maintains the WebSocket connection that continuously transports JPEG frames. The camera capture itself remains an STM32 and OV2640 responsibility.

Q: Can beginners build this with another STM32 MCU?

The concept is portable, but the project requires more than basic STM32 programming. Developers should understand SPI, interrupts or DMA, GPIO timing, camera interfaces, SRAM management, TCP sockets, and WebSocket framing. Moving to another STM32 mainly requires replacing the MCU-specific camera-capture and peripheral initialization layers while retaining the W5500 socket and JPEG processing architecture.

Q: How does W5500 compare with running LwIP directly on STM32?

LwIP implements the TCP/IP stack in MCU software and normally uses an Ethernet MAC available on suitable STM32 devices together with external PHY hardware. This gives the application deeper control over the network stack but also consumes MCU RAM, processing time, and software-maintenance effort. W5500 instead implements TCP/IP socket processing, MAC, and PHY functions in dedicated hardware and communicates with STM32 through SPI. For a camera node already handling a continuous image stream, the W5500 approach separates network protocol processing from the camera workload; the trade-off is the additional W5500 device and SPI data-transfer overhead.

Source

Original Project: Building a Home Network Real-Time Monitoring System with HTML5

The original implementation uses an STM32F103-class MCU, W5500, and OV2640. It documents the two-socket HTTP/WebSocket architecture, OV2640 JPEG configuration, JPEG boundary detection, WebSocket framing, and chunked W5500 transmission.

This article generalizes that architecture to STM32 MCUs as a platform family. Exact camera-capture peripherals, GPIO assignments, DMA capabilities, available SRAM, and SPI configuration depend on the selected STM32 device and board.

W5500 Technical Reference: WIZnet W5500 Documentation

License: No explicit open-source license was identified for the complete original implementation in the accessible source article. Code excerpts should therefore be treated as reference material rather than assumed to be freely reusable under an open-source software license.

Tags

#W5500 #STM32 #OV2640 #EthernetCamera #WebSocket #JPEG #Ethernet #EmbeddedSystems #SurveillanceCamera #IoT

STM32 MCU에서 W5500을 이용해 OV2640 JPEG 프레임을 스트리밍하는 방법은?

요약

이 프로젝트 구조는 STM32 마이크로컨트롤러, OV2640 카메라, WIZnet W5500 Ethernet 컨트롤러를 결합하여 JPEG 이미지를 웹 브라우저로 직접 스트리밍합니다. OV2640은 압축된 JPEG 프레임을 생성하고, STM32는 해당 프레임을 캡처하고 버퍼링하며, W5500은 SPI를 통해 하드웨어 TCP/IP 네트워크 기능을 제공합니다. HTTP 연결은 브라우저 인터페이스를 전달하고, 별도의 WebSocket 연결은 연속적인 JPEG 프레임 전송에 사용됩니다. 이 구조는 카메라 데이터 캡처와 SPI Ethernet 통신에 필요한 메모리 및 주변장치 자원을 갖춘 다양한 STM32 MCU에 적용할 수 있습니다.

프로젝트가 하는 일

이 시스템은 별도의 PC 전용 프로그램 없이 웹 브라우저에서 확인할 수 있는 소형 유선 네트워크 카메라를 구현합니다.

전체 데이터 흐름은 다음과 같습니다.

OV2640 → STM32 MCU → JPEG 프레임 버퍼 → W5500 → Ethernet → WebSocket → 웹 브라우저

OV2640은 이미지 촬영과 JPEG 압축을 담당합니다. STM32는 카메라를 설정하고, 출력되는 바이트 스트림을 캡처하며, 완전한 JPEG 프레임의 경계를 판단한 뒤 네트워크 전송 로직으로 넘깁니다.

W5500은 이렇게 준비된 JPEG 데이터를 Ethernet을 통해 전달합니다.

원본 참조 구현은 STM32F103 계열 MCU를 사용하지만, 이 구조 자체가 특정 STM32 모델에 종속되는 것은 아닙니다. 일반적인 STM32 기반 구현에서는 다음과 같은 기능이 필요합니다.

W5500 통신을 위한 SPI 주변장치

OV2640 픽셀 데이터를 수신할 GPIO 또는 적절한 병렬 카메라 인터페이스

OV2640 SCCB 설정을 위한 I2C 호환 주변장치 또는 GPIO 구현

예상되는 JPEG 프레임 하나 이상을 저장할 수 있는 충분한 SRAM

카메라 데이터를 손실 없이 수신할 수 있는 Interrupt, DMA 또는 전용 주변장치

OV2640의 레지스터 설정에는 SCCB 제어 인터페이스가 사용됩니다. 실제 이미지 데이터는 별도의 8비트 병렬 버스를 통해 전달되며 PCLK, HREF, VSYNC와 같은 동기화 신호가 함께 사용됩니다.

원본 구현에서는 PCLK 이벤트에 맞춰 이미지 바이트를 샘플링하고 HREF 신호를 이용해 현재 데이터가 유효한 이미지 라인에 해당하는지 판단합니다.

카메라는 Raw RGB가 아니라 JPEG 형식으로 출력하도록 설정합니다.

이 방식은 MCU 기반 스트리밍에서 중요합니다. 비압축 VGA 이미지는 많은 메모리와 네트워크 대역폭을 요구하지만, OV2640은 내부에서 JPEG 압축을 수행할 수 있기 때문입니다.

원본 프로젝트에서는 테스트한 640×480 설정에서 한 JPEG 프레임이 약 12 KB 수준이라고 보고하지만, 실제 크기는 장면 복잡도, JPEG 품질, 조명 상태, 해상도에 따라 달라질 수 있습니다.

STM32는 다음 JPEG 마커를 이용해 하나의 이미지 경계를 찾습니다.

FF D8   JPEG Start of Image
...
FF D9   JPEG End of Image

완전한 JPEG 프레임이 캡처되면 해당 데이터를 지속적으로 유지되는 WebSocket 연결을 통해 전송합니다.

브라우저 측 흐름은 다음과 같습니다.

HTTP 요청 → HTML 페이지 → WebSocket 연결 → JPEG Binary Frame → HTML5 Canvas

각 이미지마다 HTTP 요청을 반복하는 방식이 아니라, HTTP는 주로 사용자 인터페이스를 제공하고 WebSocket은 지속적인 이미지 데이터 채널로 사용됩니다.

WIZnet은 어디에 사용되는가

이 구조에서 사용되는 WIZnet 제품은 W5500 Hardwired TCP/IP Ethernet Controller입니다.

W5500은 SPI를 통해 STM32에 연결되며 MCU 애플리케이션과 분리된 하드웨어에서 TCP/IP 네트워크 처리를 수행합니다.

W5500은 다음과 같은 기능을 제공합니다.

Hardware TCP/IPv4 처리

8개의 독립적인 Hardware Socket

총 32 KB의 내부 TX/RX Buffer Memory

내장 10/100 Ethernet MAC 및 PHY

고속 데이터 전송이 가능한 SPI Host Interface

이 카메라 구조에서는 W5500의 두 개 Socket을 서로 다른 목적으로 사용할 수 있습니다.

Socket A — HTTP Server

브라우저는 처음에 HTTP를 통해 STM32/W5500 시스템에 접속합니다.

펌웨어는 이 연결을 이용해 카메라 화면을 표시하는 HTML 및 JavaScript 코드를 브라우저에 전달합니다.

Socket B — WebSocket Server

웹 페이지 로딩이 완료되면 브라우저는 별도의 WebSocket 연결을 생성합니다.

이후 완성된 JPEG 이미지가 Binary WebSocket Message 형태로 반복적으로 전송됩니다.

원본 프로젝트에서도 하나의 W5500 Socket은 HTTP에 사용하고 다른 하나는 JPEG 전송용 WebSocket에 사용하는 구조를 확인할 수 있습니다.

두 연결을 분리하는 이유는 트래픽 특성이 다르기 때문입니다.

HTTP 트래픽은 상대적으로 작고 간헐적으로 발생합니다.

반면 WebSocket 채널은 JPEG 이미지를 지속적으로 전송해야 하므로 더 높은 지속 전송량이 필요합니다.

W5500의 역할은 다음과 같이 정리할 수 있습니다.

STM32 Application → W5500 Socket API → Hardware TCP/IP → Ethernet

STM32는 완전한 TCP/IP Protocol Stack을 소프트웨어로 실행할 필요가 없습니다.

대신 애플리케이션 펌웨어가 Hardware Socket을 제어하고 MCU 메모리와 W5500 Socket Buffer 사이에서 Payload 데이터를 이동합니다.

카메라 애플리케이션에서는 STM32가 이미 시간에 민감한 이미지 캡처를 담당하기 때문에 이러한 역할 분리가 유용합니다.

구현 참고 사항

OV2640 JPEG 설정

원본 구현에서는 main.c에서 다음과 같은 호출을 통해 OV2640을 초기화합니다.

iic_init();
ov2640_jpeg_config(JPEG_640x480);

파일: main.c

첫 번째 함수는 OV2640 설정을 위한 제어 인터페이스를 초기화합니다.

두 번째 함수는 카메라가 지정된 해상도에서 JPEG를 출력하도록 설정합니다.

원본 프로젝트에서는 이후 노출, 대비, 채도, 조명 모드와 이미지 캡처에 필요한 GPIO 설정도 구성합니다.

일반적인 STM32 MCU에서는 정확한 주변장치 초기화 방식이 STM32 제품군과 보드 설계에 따라 달라집니다.

하지만 구조적으로 중요한 점은 JPEG 압축을 STM32가 아니라 OV2640이 수행한다는 것입니다.

따라서 STM32가 JPEG Encoder 역할까지 담당할 필요가 없습니다.

JPEG 프레임 검출

원본 프레임 캡처 로직은 websocket.c에서 확인할 수 있습니다.

실제 소스의 일부는 다음과 같습니다.

case 2:
    JPEGBuffer[JPEGCnt++] = temp;

    if(temp == 0xff)
        jpg_flag = 3;
    break;

case 3:
    JPEGBuffer[JPEGCnt++] = temp;

    if(temp == 0xd9)
        jpg_flag = 4;

파일: websocket.c

전체 상태 머신은 먼저 FF D8을 검출한 뒤 JPEG Payload를 저장하고, 이후 FF D9가 나타날 때까지 데이터를 수집합니다.

jpg_flag는 하나의 완전한 JPEG 프레임이 준비되었는지 나타내는 상태 값으로 사용됩니다.

이 JPEG 경계 검출 로직은 특정 STM32 모델에 종속되지 않기 때문에 다른 STM32에서도 그대로 적용할 수 있는 개념입니다.

STM32 제품별로 달라지는 부분은 카메라 데이터가 JPEG Buffer로 들어오는 방식입니다.

저사양 MCU에서는 GPIO와 Interrupt를 이용하여 카메라 데이터를 캡처할 수 있습니다.

다른 STM32 제품에서는 DCMI와 DMA 같은 전용 주변장치를 사용하여 CPU 개입을 줄일 수도 있습니다.

네트워크 처리 구조 자체는 동일합니다.

W5500을 통한 WebSocket 전송

원본 프로젝트에서는 완전한 JPEG 이미지가 준비될 때까지 다음과 같이 기다립니다.

while(jpg_flag != 4);
jpgLen = JPEGCnt;

파일: websocket.c

그 후 WebSocket Binary Frame을 구성하고 W5500 Socket API를 통해 JPEG를 전송합니다.

큰 이미지는 다음과 같이 여러 전송 블록으로 나눕니다.

if(jpgLen > WS_PACKET_LEN)
{
    send(s, (uint8*)(JPEGBuffer + send_len), WS_PACKET_LEN);
    send_len += WS_PACKET_LEN;
    jpgLen -= WS_PACKET_LEN;
}

파일: websocket.c

이 처리가 필요한 이유는 JPEG 전체가 한 번의 W5500 Socket Buffer 처리에 들어간다고 가정할 수 없기 때문입니다.

W5500은 총 32 KB의 내부 TX/RX 메모리를 가지고 있으며 이를 8개의 Hardware Socket에 분배하여 사용합니다.

따라서 HTTP와 이미지 스트리밍 채널의 요구 사항에 맞춰 Socket Buffer를 설정해야 합니다.

WebSocket Frame에는 Binary Opcode 0x02가 사용됩니다.

JPEG Payload는 일반적으로 125 Byte를 크게 초과하기 때문에 원본 구현에서는 WebSocket의 Extended Payload Length 방식도 사용합니다.

전체적인 일반화된 처리 흐름은 다음과 같습니다.

JPEG 캡처 → FF D9 검출 → 프레임 길이 확인 → WebSocket Header 생성 → Header와 JPEG 분할 전송 → 캡처 상태 초기화 → 다음 프레임 획득

이 구조는 특정 STM32 모델을 요구하지 않습니다.

실용적인 팁과 주의사항

JPEG Buffer는 평균 크기가 아니라 최대 예상 프레임 크기를 기준으로 설계해야 합니다. JPEG 크기는 해상도, 품질 설정, 장면의 복잡도에 따라 크게 달라질 수 있습니다. 평균 크기만 기준으로 버퍼를 설계하면 Overflow가 발생할 수 있습니다.

카메라 캡처 로직과 Blocking Network Operation을 가능한 한 분리해야 합니다. 이미지 입력은 카메라 타이밍에 따라 진행되기 때문에 긴 SPI 전송이나 Socket 대기가 동일한 실행 경로에서 발생하면 카메라 데이터를 놓칠 수 있습니다.

보드에서 안정적으로 동작하는 범위 내에서 높은 SPI Clock을 사용하는 것이 좋습니다. W5500 자체는 고속 SPI를 지원하지만 실제 안정적인 동작 속도는 STM32의 SPI 주변장치, PCB Layout, 배선 길이와 Signal Integrity에 따라 달라집니다.

W5500 Socket Buffer는 트래픽 특성에 맞게 할당해야 합니다. WebSocket 이미지 채널은 HTTP 제어 채널보다 지속적인 전송량이 크기 때문에 동일한 Buffer를 배분하는 것이 항상 효율적인 것은 아닙니다.

JPEG 마커를 확인한 뒤 전송하는 것이 좋습니다. 병렬 카메라 데이터 수신 중 Byte Loss가 발생하면 이미지가 손상될 수 있습니다. 최소한 FF D8 시작과 FF D9 종료가 정상적으로 확인된 프레임만 전송하는 방식이 유용합니다.

Ethernet과 WebSocket 연결 장애에 대한 복구 로직이 필요합니다. 실제 제품에서는 PHY Link Loss, TCP Disconnect, WebSocket Reconnect, Camera Timeout, 불완전한 JPEG 프레임을 처리해야 합니다.

STM32의 SRAM이 충분하다면 Double Buffering을 고려할 수 있습니다. 하나의 Buffer를 W5500으로 전송하는 동안 다른 Buffer에서 다음 카메라 프레임을 받을 수 있습니다. 프레임 사이의 공백을 줄이는 데 도움이 되지만 필요한 SRAM은 증가합니다.

FAQ

Q: STM32 카메라 프로젝트에서 왜 W5500을 사용하나요?

STM32는 이미 카메라 설정, 이미지 캡처, JPEG Buffer 관리와 애플리케이션 로직을 처리해야 합니다. W5500은 TCP/IP Socket 처리를 전용 하드웨어로 분리하고 STM32에는 SPI 기반 Socket Interface를 제공합니다. 8개의 Hardware Socket과 32 KB의 내부 Network Buffer를 이용할 수 있기 때문에 STM32의 자원을 카메라 데이터 처리에 더 집중시킬 수 있습니다.

Q: W5500은 STM32 MCU에 어떻게 연결하나요?

W5500은 SPI를 통해 연결합니다. 일반적으로 SCLK, MOSI, MISO, Chip Select 신호가 필요하며 Reset과 Interrupt 신호도 사용할 수 있습니다. 정확한 SPI Peripheral 및 GPIO Pin은 선택한 STM32 MCU와 PCB 설계에 따라 달라집니다. 따라서 특정 STM32 Pin Map에 종속되지 않고 SPI 기능을 기준으로 설계할 수 있습니다.

Q: 이 카메라 구조에서 W5500은 정확히 어떤 역할을 하나요?

W5500은 STM32 카메라 애플리케이션과 웹 브라우저 사이의 Ethernet 및 TCP Transport를 담당합니다. 하나의 Hardware Socket은 HTTP를 이용해 HTML Interface를 제공하고, 다른 Socket은 JPEG 프레임을 지속적으로 전달하는 WebSocket 연결을 유지할 수 있습니다. 실제 카메라 데이터 캡처와 JPEG 프레임 관리는 STM32와 OV2640이 담당합니다.

Q: 다른 STM32 MCU에서도 이 프로젝트를 구현할 수 있나요?

가능합니다. 다만 SPI, Interrupt 또는 DMA, GPIO Timing, Camera Interface, SRAM 관리, TCP Socket과 WebSocket Frame 구조에 대한 이해가 필요합니다. 다른 STM32로 변경할 때 가장 크게 달라지는 부분은 카메라 데이터를 받아오는 Peripheral 및 Low-Level Initialization이며, W5500 Socket과 JPEG 처리 구조는 대부분 유지할 수 있습니다.

Q: W5500을 사용하는 방식은 STM32에서 LwIP를 직접 실행하는 방식과 어떻게 다른가요?

LwIP 방식은 TCP/IP Stack을 STM32 소프트웨어에서 처리하며, Ethernet MAC이 내장된 STM32에서는 일반적으로 외부 PHY와 함께 사용합니다. Network Stack을 세밀하게 제어할 수 있지만 MCU의 RAM, CPU 시간과 소프트웨어 유지보수 비용을 사용합니다.

W5500은 TCP/IP Socket 처리, Ethernet MAC 및 PHY 기능을 별도의 하드웨어에 구현하고 STM32와 SPI로 통신합니다. 카메라처럼 지속적인 데이터 스트림을 동시에 처리해야 하는 시스템에서는 Network Protocol 처리를 카메라 Workload와 분리할 수 있다는 장점이 있습니다. 대신 외부 W5500 IC와 SPI 데이터 전송에 필요한 추가 하드웨어 및 대역폭을 고려해야 합니다.

출처

Original Project: Building a Home Network Real-Time Monitoring System with HTML5

원본 구현은 STM32F103 계열 MCU, W5500, OV2640을 사용하며 HTTP/WebSocket의 두 개 Socket 구조, OV2640 JPEG 설정, JPEG Boundary Detection, WebSocket Frame 구성 및 W5500을 통한 분할 전송 방식을 설명합니다.

이 문서에서는 해당 구현을 특정 STM32 모델이 아닌 STM32 MCU 제품군 전체에 적용 가능한 구조로 일반화했습니다.

실제 Camera Capture Peripheral, GPIO Pin, DMA 기능, SRAM 크기 및 SPI 설정은 선택한 STM32 제품과 보드 구성에 따라 달라집니다.

W5500 Technical Reference: WIZnet W5500 Documentation

License: 접근 가능한 원본 자료에서는 전체 구현에 대한 명시적인 Open-Source License를 확인할 수 없습니다. 따라서 코드 예제는 오픈소스로 자유롭게 재사용할 수 있다고 가정하지 않고 기술 참고 자료로 취급해야 합니다.

태그

#W5500 #STM32 #OV2640 #EthernetCamera #WebSocket #JPEG #Ethernet #EmbeddedSystems #SurveillanceCamera #IoT