You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+32Lines changed: 32 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,6 +31,21 @@ The intended position is simple:
31
31
- Runtime identity, ABI version, manifest, timing reports, diagnostics hooks, and task-scoped capability gating
32
32
- Low-level internal helpers for cycle counting and idle hints, including C and assembly where it actually helps
33
33
34
+
## Repo Health
35
+
36
+
The repository now ships with project-level release and validation scaffolding:
37
+
38
+
- GitHub Actions CI on every push to `main` and on pull requests
39
+
- Tag-driven release packaging on `v*` tags
40
+
- A local `CHANGELOG.md` for release notes and regression history
41
+
- Wiki-ready documentation pages under `docs/wiki/`
42
+
43
+
Start points:
44
+
45
+
-`docs/wiki/Home.md`
46
+
-`docs/wiki/Validation.md`
47
+
-`docs/wiki/Beta-Modules.md`
48
+
34
49
## Current Runtime Snapshot
35
50
36
51
Latest measured references:
@@ -81,6 +96,17 @@ Tradeoff summary:
81
96
82
97
The ESP32 tradeoff is also healthy: the footprint increase is small relative to total headroom, while the scheduling result is materially better under the same workload.
83
98
99
+
## Optional Network Modules (BETA)
100
+
101
+
The optional network helpers are currently marked **BETA**:
102
+
103
+
-`ZeroTransportMetrics`
104
+
-`ZeroHttpPump`
105
+
-`ZeroMqttPump`
106
+
-`ZeroWiFiMaintainer`
107
+
108
+
They are already useful and validated on desktop plus ESP32 hardware, but they are still under active tuning for footprint, retry behavior, and cross-board transport quirks. The core runtime is the stable layer; the network helpers should be treated as add-on modules that are ready for evaluation and controlled deployments.
109
+
84
110
## Field Validation: ESP8266 Seismic Node
85
111
86
112
Measured on a real `ESP8266` direct-AP seismic node using:
@@ -351,6 +377,11 @@ void loop() {
351
377
352
378
## Higher-Intent Demo Projects
353
379
380
+
Recommended realistic network workload:
381
+
382
+
-`examples/RealProjectNode`:
383
+
a portable node-style workload that simulates sensor sampling, WiFi link maintenance, HTTP delivery, MQTT delivery, queue pressure, and realistic intermittent transport failures.
384
+
354
385
-`examples/ESP32TelemetryNode`:
355
386
a richer ESP32 node example with WiFi maintenance, capability-gated diagnostics, heartbeat events, and periodic runtime summaries.
The following optional modules are currently marked **BETA**:
4
+
5
+
-`ZeroWiFiMaintainer`
6
+
-`ZeroHttpPump`
7
+
-`ZeroMqttPump`
8
+
-`ZeroTransportMetrics`
9
+
10
+
They are already useful and validated on desktop plus ESP32 smoke tests, but they are not yet considered fully field-proven across all transport stacks and all board families.
11
+
12
+
## What BETA Means Here
13
+
14
+
- API shape is usable, but may still tighten as real-world patterns accumulate.
15
+
- Performance and footprint are measured and improving, but still under active tuning.
16
+
- The modules are suitable for evaluation, prototypes, and controlled deployments.
17
+
- For production, validate them against your actual transport stack and retry policy.
18
+
19
+
## Not BETA
20
+
21
+
The core runtime (`scheduler`, `task registry`, `events`, `watchdog`, `state`, `panic`, `timing`) is the stable part of the project and is not flagged as BETA.
- ESP8266 (`Wemos D1 mini`) for compare, stress, and seismic-node validation
15
+
- ESP32 for module smoke tests, telemetry compare, and real-project network simulation
16
+
17
+
## Known Tooling Limits
18
+
19
+
-`arduino-cli` compile jobs should run sequentially. Parallel compile runs can collide in cache paths.
20
+
- ESP32 upload can occasionally fail mid-flash due to `esptool` transport instability; retrying the upload usually succeeds.
21
+
- Serial capture on ESP32 is valid but can truncate if capture starts mid-stream; the provided capture helper reduces this but does not eliminate it entirely.
22
+
23
+
## Reading Performance Results
24
+
25
+
- Favor deterministic metrics first: `fast_miss`, average lag, max lag.
26
+
- Compare `success rate` and queue depth, not just raw `ok/fail` counts, when failure injection is part of the workload.
27
+
- Treat synthetic fail-injection examples as throughput/stability checks, not as production success-rate claims.
0 commit comments