How to handle interrupts on HTTP requests on the W6300-EVB-Pico

Implementing Interrupt-Driven Handling on HTTP Requests with W6300-EVB-Pico

COMPONENTS

PROJECT DESCRIPTION

How to Build a Deterministic Interrupt-Driven HTTP Server with W6300 on RP2040?

Summary

This project demonstrates how to implement event-driven Ethernet networking on the W6300-EVB-Pico by wiring the W6300 INTn hardware signal to the RP2040 GPIO interrupt system. Instead of polling socket registers, the firmware reacts only when the W6300 TCP/IP Offload Engine (TOE) asserts a hardware interrupt. This architecture provides bounded response latency, protects RTOS scheduling predictability, and enables clean dual-stack (IPv4/IPv6) HTTP server design on resource-constrained MCUs.

What the Project Does

The reference implementation builds a lightweight HTTP server running on:

RP2040 (MCU)

W6300 (Hardware TCP/IP Controller)

Traditional embedded Ethernet examples often use a polling model:

while(1) {
    check_socket_status();
    if(data_available) {
        process_packet();
    }
}

This approach introduces two architectural issues:

Unbounded latency
Response delay can be as large as the main loop period.

CPU inefficiency
The MCU continuously reads socket registers even when no packet exists.

This project replaces polling with hardware-triggered interrupts, where:

The W6300 hardware state machine detects TCP events.

Interrupt flags are set internally.

INTn is asserted immediately.

The RP2040 ISR processes only real events.

The main loop remains free for control logic.

Where WIZnet Fits

The W6300 provides three essential architectural capabilities:

1️⃣ Hardware TCP/IP State Machine

Full TCP/UDP stack in silicon

IPv4 / IPv6 dual stack

32 KB internal packet buffer

No LwIP required

TCP handshake, retransmission, checksum, and header parsing occur entirely inside hardware.

2️⃣ Interrupt Logic Block (Register-Level Mechanism)

The interrupt path works as follows:

A socket event occurs (e.g., RECV).

The corresponding Sn_IR RECV bit is set.

If enabled in Sn_IMR, the socket bit propagates to:

SIR (Socket Interrupt Register).

If allowed by Global IMR, INTn is driven LOW.

In other words:

Sn_IR → Sn_IMR → SIR → IMR → INTn

This hardware chain ensures the MCU is interrupted only for enabled events.

When a packet is received:

Data is already stored in the internal W6300 buffer.

The MCU does not poll.

The MCU does not parse TCP headers.

The MCU reacts only when necessary.

3️⃣ Dual-Stack Interrupt Transparency

The interrupt mechanism is protocol-agnostic.

Whether:

IPv4 packet

IPv6 packet

TCP handshake

HTTP payload

The same INTn hardware signal is triggered.

No additional firmware branching is required for IPv6 support.

Deterministic Latency Analysis

Polling Model

If the main loop period is:

T_loop = 2 ms

Worst-case response delay:

Latency ≤ T_loop

Under load, latency becomes dependent on:

Loop complexity

Other blocking tasks

RTOS scheduling

Latency is variable and unbounded under burst conditions.

Interrupt Model

Latency becomes:

Latency = Interrupt Latency + SPI Register Read Time

Both are bounded:

GPIO interrupt latency (few µs)

SPI register access (deterministic)

Thus:

Response time is bounded and independent of main loop timing.

This is critical in:

Industrial control

Robotics

Motor control loops

Real-time sensing systems

RTOS Scheduling Impact

In RTOS systems:

Polling introduces periodic high CPU usage inside a network task.

Under burst traffic:

ISR → stack processing → context switching

High-priority tasks may experience jitter

With W6300 interrupt-driven TOE:

No protocol stack execution on MCU

ISR duration remains short

Network task consumes time only on actual events

This improves:

Worst-case latency bounds

Task scheduling predictability

Control-loop timing integrity

Implementation Notes

1️⃣ GPIO Interrupt Registration

gpio_set_irq_enabled_with_callback(
    W6300_INT_PIN,
    GPIO_IRQ_EDGE_FALL,
    true,
    &w6300_callback
);

INTn is active-low.

2️⃣ ISR with Register-Level Awareness

void w6300_callback(uint gpio, uint32_t events)
{
    // Read Global Interrupt Register
    uint8_t ir = getIR();  

    if(ir & _IK_SOCK_ALL)
    {
        // At this point:
        // - Sn_IR.RECV is already set
        // - Data is already stored in internal buffer
        process_http_socket_events();
    }

    // Important:
    // Interrupt flags must be cleared before exit
    // otherwise INTn will remain asserted
}

Key engineering detail:

Interrupt flags must be cleared in Sn_IR before exiting ISR to re-arm detection.

3️⃣ Main Loop Remains Clean

while(1)
{
    do_critical_control_loop();
}

No polling.
No socket scanning.
No unnecessary SPI traffic.

Interrupt Storm Handling

If traffic becomes excessive:

Use Sn_IMR to enable only critical events (e.g., RECV).

Disable SEND_OK or DISCON interrupts if unnecessary.

Apply socket-level filtering.

This prevents CPU overload during heavy traffic bursts.

Practical Tips / Pitfalls

Always clear Sn_IR bits after servicing.

Keep ISR minimal; defer heavy HTTP parsing to task context.

Validate PHY link before enabling interrupts.

Avoid long SPI transactions inside ISR.

Mask unused socket interrupts.

Test both IPv4 and IPv6 flows.

FAQ

Q: Does interrupt-driven networking increase throughput?
A: No. Throughput depends on bus speed and buffer size. Interrupt-driven design improves CPU efficiency and response determinism.

Q: How does this differ from using LwIP on RP2040?
A: LwIP executes TCP/IP in software on the MCU. W6300 executes the TCP state machine in hardware, reducing interrupt frequency and eliminating protocol parsing overhead.

Q: What is the advantage over W5500?
A: W6300 supports native IPv4/IPv6 dual stack and architectural refinements while maintaining hardware TOE operation.

Q: What happens if interrupts occur too frequently?
A: Use Sn_IMR and global IMR to mask non-critical events. Only enable RECV or connection-related interrupts as required.

Q: Is this suitable for RTOS-based systems?
A: Yes. Hardware offloading combined with interrupt-driven notification preserves scheduler predictability and reduces task jitter.

Source

Original Project:
https://maker.wiznet.io/bruno/projects/how-to-handle-interrupts-on-http-requests-on-the-w6300-evb-pico/

Wiznet makers