---
title: "cSTER-devices"
url: "https://maker.wiznet.io/TheoIm/projects/cster-devices/"
markdown_url: "https://maker.wiznet.io/TheoIm/projects/cster-devices/md"
type: "UCC: User Created Content"
author: "Alejandro Martinez"
author_url: "https://github.com/amartinezacosta/cSTER-devices"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Alejandro Martinez"
original_url: "https://github.com/amartinezacosta/cSTER-devices"
published: "2026-04-10"
language: "en"
hardware: ["WIZnet WizFi360"]
likes: 0
views: 299
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# cSTER-devices

> Cortex-M4F driver framework using WizFi360-PA over UART to enable MQTT via Wi-Fi, offloading TCP/IP from the MCU for modular embedded control systems.

Original author: Alejandro Martinez (source: https://github.com/amartinezacosta/cSTER-devices)

## Components

- **WIZnet WizFi360** x 1 ([docs](https://docs.wiznet.io/Product/Modules/Wi-Fi-Module/WizFi360))

## Article

## 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)

![](https://maker.wiznet.io/upload/ckeditor5/1071770351%5F1775820239%2Epng)

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`

```plaintext
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`

```plaintext
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

---

Source: https://maker.wiznet.io/TheoIm/projects/cster-devices/