arc/sketch.hpp
Compatibility alias for small app-style programs.
Fit
- Use it when firmware structure, task lifetime, ownership, command parsing, or policy state needs a visible contract.
- Do not start here when a hardware-specific module already owns the same decision more directly.
- Verification focus: put the owner near board topology, make rollback explicit, and keep slow side effects on Core 0.
Arc Contract
- Header:
arc/sketch.hpp - Module group: Program Shape And Ownership
- CMake feature:
core - Closest example:
.
Declare arc_requires(main_requires core) in the component that includes this header.
CMake And Include
cmake
include(${CMAKE_CURRENT_LIST_DIR}/../cmake/arc-deps.cmake)
arc_requires(main_requires core)
idf_component_register(
SRCS "app_main.cpp"
REQUIRES ${main_requires}
)cpp
#include "arc/sketch.hpp"Source Landmarks
Source landmarks: Sketch, Work, App.
Start From Zero
- Start from the closest example or the root project listed below.
- Load the ESP-IDF environment with
. ./env.sh. - Add the include and CMake feature only in the component that owns this lane.
- Keep board topology, buffers, and ownership in one visible owner type.
- Move from build proof to hardware proof only after the wiring or runtime dependency is known.
Owner Skeleton
cpp
namespace app {
void boot()
{
// Put board policy, buffer ownership, and failure handling here.
// Keep Core 1 hot work separate from Core 0 service work.
}
}
extern "C" void app_main()
{
app::boot();
}Step-By-Step Check
- Decide whether this module owns silicon, memory, protocol bytes, or policy only.
- Name the owner type once, close to the board topology.
- Allocate any DMA or shared buffers before the hardware starts.
- Initialize with the recoverable path while bringing up the board.
- Switch to the fail-fast path only after the topology is treated as fixed.
- Log from Core 0 after the hot path has handed off a compact event or snapshot.
Build Or Example
The root project is the smallest place to try this module.
sh
. ./env.sh
idf.py build
idf.py -p /dev/ttyACM0 flash monitorRuntime Check
The build command proves the dependency path. Runtime proof still needs the actual board condition that matches this module: attached device, loopback, radio peer, flash partition, sleep wake source, or captured serial/network output. Do not turn the example command into a performance or hardware claim without that evidence.