Architecture - ZGoode/Legacy_RS232_DripFeeder GitHub Wiki

Architecture

flowchart LR
  subgraph WIN[Windows workstation — FileLinkDiscovery]
    direction TB
    W[WPF windows and user actions]
    D[DiscoveryService<br/>mDNS lookup]
    A[DeviceApiClient<br/>device, SD, settings, OTA]
    Q[TransferQueue<br/>normal file transfers]
    P[DeviceProtocolEngine<br/>protocol/device validation]
    R[Rs232ApiClient<br/>raw serial API client]
    W <--> D
    W <--> A
    W <--> Q <--> A
    W <--> P <--> R
  end

  subgraph BOUNDARY[Network boundary]
    direction TB
    MDNS[mDNS<br/>_filelink._tcp.local.]
    HTTP[Plain HTTP / JSON<br/>plus streaming bodies]
  end

  subgraph ESP[ESP32 device — FileLink firmware]
    direction TB
    H[HTTP server and handlers]
    NET[Active interface<br/>W5500 Ethernet or Wi-Fi]
    SD[SD/FATFS]
    CRC[CRC cache background task]
    UART[UART1 / RS232]
    OTA[ESP-IDF OTA partitions]
    NVS[NVS<br/>device, auth, Wi-Fi settings]
    RTC[PCF8523 RTC / system clock]
    LED[NeoPixel status / identify]
    H <--> SD <--> CRC
    H <--> UART
    H <--> OTA
    H <--> NVS
    H <--> RTC
    H <--> LED
    H <--> NET
  end

  D <-->|mDNS queries / responses| MDNS
  MDNS <-->|advertisement / resolution| NET
  A <--> HTTP <--> H
  R <--> HTTP

  classDef windows fill:#dbeafe,stroke:#2563eb,color:#172554;
  classDef boundary fill:#fef3c7,stroke:#d97706,color:#78350f;
  classDef firmware fill:#dcfce7,stroke:#16a34a,color:#14532d;
  class W,D,A,Q,P,R windows;
  class MDNS,HTTP boundary;
  class H,NET,SD,CRC,UART,OTA,NVS,RTC,LED firmware;
Loading

Color key: blue is Windows-side code and local client state; amber is the network boundary; green is firmware and device-owned state. Bidirectional arrows show request/response, read/write, or status-feedback paths; single-direction arrows are reserved for the startup lifecycle diagram below. The amber boundary is deliberately labeled as plain HTTP: it is not HTTPS, and the password feature does not add global request authorization at that boundary.

Firmware lifecycle

Firmware initializes NVS and peripherals, tries Ethernet, then starts Wi-Fi/provisioning only if Ethernet is unusable. After choosing an active interface, it initializes SD and CRC maintenance, arms Network Fallback, starts HTTP, and advertises mDNS.

flowchart TD
 A[Startup] --> B[Initialize peripherals]
 B --> C[Ethernet]
 C --> D{Link and IP?}
 D -->|yes| E[Ethernet active]
 D -->|no| F[Wi-Fi / primary saved credential]
 F --> G{Connected?}
 G -->|yes| H[Wi-Fi active]
 G -->|no| I[Open provisioning AP]
 E --> J[SD + CRC cache + fallback + HTTP + mDNS]
 H --> J
Loading

Concurrency and ownership

Firmware contains task/event paths for CRC maintenance, RS232 processing, status behavior, network fallback, and HTTP servicing. Ethernet and SD share SPI. In Windows, TransferQueue uses locked state and one normal active transfer per device. The text editor is a separate direct-transfer path.

OLED and buttons are outside the main control path: their setup is present, but a display or local input UI is not established.

⚠️ **GitHub.com Fallback** ⚠️