Start · Native services. One shared runtime.
Native services. One shared runtime.¶
Micros separates application behavior from the resident base that loads and manages it. Each native service has its own worker, state, and declared resources; all services share the device's address space.
01 · What runs on the device¶
Lifecycle · owned resources · channels · supervision
Tasks, time, memory & hardwareEnabled management
Inspect & deploy from host tools
The base contains the kernel, platform integration, and enabled management. On ESP32, ESP-IDF and FreeRTOS provide underlying tasks and scheduling. Micros adds service ownership, lifecycle, channels, and independent deadline supervision. The same kernel source is built for each target; drivers and native binaries still depend on the target and base.
The source follows the same boundary: kernel/ owns execution and supervision; controller/ owns application lifecycle, deployment, rollback and reporting; and platforms/ implements hardware, storage and transport contracts. Every target uses the same shared controller and deployment record. Capability declarations reject explicitly required unsupported features at compile time. The platform contract map defines what a new platform must implement and how to check it.
Independently deployed diagnostic packages live in services/, and reference applications in examples/. They use the public service SDK. The CLI and management server share host tooling; the server owns its browser console. Use the repository map to find each component's source.
02 · Follow a service lifetime¶
| Stage | Service | Kernel |
|---|---|---|
| Admission | Supplies its native descriptor and requirements | Checks compatibility and capacity |
| Initialization | Establishes state | Supplies zeroed arena, context, and API table |
| Start/work | Performs bounded hooks and callbacks | Serializes the instance's work on its worker |
| Stop | Releases application-owned resources | Waits for quiescence before reclaiming memory |
Generated hook services delegate resource plumbing to generated code. The Service API defines exact lifecycle, memory, and error rules; Write a service implements a small example.
03 · Pass messages¶
In the illustrative greenhouse, the sensor publishes climate readings and the fan controller and display read independently. A latest-value channel retains current state; a bounded stream retains a limited sequence. Neither removes the need to handle stale or missing readings.
Use Connect services for the declaration and retention rules. Across boards, Coordination distinguishes state, actions with outcomes, and transient events.
04 · Change behavior¶
A service or setting update can retain the resident base. Compatible selective updates on supporting bases preserve unchanged peers; shared-layout changes and unsupported bases require whole-application activation. The deployment plan reports the scope.
A candidate trial checks liveness before recording a good selection. Runtime confirmation is not a physical acceptance test. For the greenhouse's threshold change from 28°C to 26°C, a fresh 27°C reading with the fan initially off would distinguish the two policies. This greenhouse remains an illustrative design.
05 · Essential limits¶
- Trusted native code: ownership checks do not isolate memory. A bad write can affect peers, kernel, or management.
- Bounded resources: each worker consumes stack/state; channels can overflow. The selected base can impose tighter limits than the declaration format.
- Recovery, not hard real time: a worker that cannot stop may require device recovery. Detecting a deadline miss does not make its memory safe to reuse.
- Source portability: rebuild for the target, ABI, and exact base; a board definition cannot supply a missing driver.
Quickstart runs a real service locally. Packages and compatibility explains artifacts and base matching; the glossary defines terms used in the references.