Wiznet makers

What the Project Does

At its core, this project is a device driver framework that combines real-time motor control with network communication over Wi-Fi.

The system operates as follows:

• The MCU runs control logic (motor PID, servo, RC input)
• The Wi-Fi module handles all network communication via AT commands
• MQTT is implemented on top of this interface to communicate with external systems

In practical terms, this enables use cases such as:

• Remote motor control over MQTT
• Telemetry streaming from embedded devices
• Wireless control systems without a full TCP/IP stack on the MCU

System Architecture (Block Diagram)

Generated By Gemini

This diagram highlights a key design decision:
the MCU never directly implements TCP/IP. Instead, all networking is delegated to the WizFi360 module.

Where WIZnet Fits

The WizFi360-PA is used as a UART-controlled network processor.

Its role in this architecture is:

• Handling Wi-Fi connection (SSID, DHCP)
• Managing TCP sockets internally
• Transporting MQTT packets between MCU and broker

Unlike Ethernet controllers such as W5500, this module operates through:

• AT command interface over UART
• Internal firmware-based TCP/IP stack
• String-based command/response handling

This makes integration simple but introduces:

• Parsing overhead (string matching)
• Non-deterministic timing (Wi-Fi latency)
• Limited low-level control

Implementation Notes

WizFi360 Driver Abstraction

File: wifi/src/wizfi360-pa/wizfi360.c

typedef struct {
    char_devio_t com;   // UART interface abstraction
} wizfi_t;

This abstraction allows the Wi-Fi driver to remain portable across different MCU platforms by relying on HAL-provided UART functions.

MQTT Layer Integration

File: wifi/include/mqtt.h

typedef struct {
    wizfi_t *client;        // WizFi360 interface
    uint32_t state;
    uint8_t *buffer;
    MQTT_callback callback;
} mqtt_t;

The MQTT implementation is tightly coupled with the WizFi360 driver, meaning all packet transmission depends on AT command execution rather than direct socket APIs.

AT Command Execution Flow

The initialization sequence includes:

• "AT" → communication check
• "ATE0" → disable echo
• "AT+CWMODE_CUR=1" → station mode
• "AT+CWDHCP_CUR=1,1" → enable DHCP

Runtime communication relies on parsing responses such as:

• "OK" / "ERROR" → command result
• "SEND OK" → transmission success
• "+IPD,<len>:" → incoming data

This parsing mechanism is implemented in a blocking function that converts UART streams into driver states.

Practical Tips / Pitfalls

• UART buffering is critical; 128-byte limits can break MQTT payload handling
• AT command responses may arrive fragmented—parsing must be robust
• Wi-Fi reconnection logic is not fully implemented
• MQTT QoS 0 means no delivery guarantee
• SysTick timing accuracy directly affects keep-alive stability
• Logging should be disabled in production to reduce UART congestion
• Blocking AT calls can interfere with real-time motor control loops

FAQ

Q: Why use WizFi360-PA in this project?
A: It provides a complete Wi-Fi + TCP/IP stack via UART, allowing Cortex-M4F systems to avoid implementing LwIP while still supporting MQTT communication.

Q: How is WizFi360 connected to the MCU?
A: It uses a UART interface abstracted through char_devio_t, with HAL managing low-level communication and timing.

Q: What role does WizFi360 play in this system?
A: It acts as the entire network stack, handling Wi-Fi connection, TCP communication, and MQTT packet transport.

Q: Can beginners follow this project?
A: It is suitable for intermediate developers with experience in embedded C, UART communication, and basic networking concepts.

Q: How does this compare to Ethernet solutions like W5500?
A: WizFi360 offers wireless flexibility but relies on AT command parsing and has variable latency, while W5500 provides deterministic, hardware-offloaded TCP/IP via SPI.

Source

• Original Project: cSTER-devices (UTEP)
• License: Not specified

Tags

#WizFi360 #WIZnet #CortexM4 #MQTT #Embedded #WiFi #DeviceDriver #UART #IoT #PID