Skip to content

Getting started

TinySHM separates algorithm libraries from application projects. Choose a project, then inspect its main/AIoTNode.cpp: including a module or defining a test function does not establish that startup executes it.

1. Select a project

Goal Starting point Check
Core framework CODE/AIoTNode-TinySHM Initialization order and acquisition mode
Data registry and orchestration CODE/AIoTNode-TinySHM-Bench-Orch Whether registered callbacks execute real algorithms
Multi-node synchronization CODE/AIoTNode-TinySHM-WSN NODE_ROLE, gateway and leaf configuration
Streaming demonstration DEMO/AIoTNode-TinySHM-LiveStreaming Sensor, network, sampling and transmission settings
Thesis experiments THESIS-TEST/TESTBED-OK Startup path, parameters and revision associated with logs

See projects and versions for other variants. Algorithm explanations generally reference Core; Bench/Orch explanations reference Bench-Orch. Experiment projects may expose additional methods or different parameters.

2. Build and run

Use a terminal with ESP-IDF configured; read the development environment first. From the repository root:

cd CODE/AIoTNode-TinySHM
idf.py build
idf.py -p YOUR_SERIAL_PORT flash monitor

Replace YOUR_SERIAL_PORT with the device port. Run idf.py set-target esp32s3 when initially changing chip targets; it regenerates configuration, so back up a customized sdkconfig first. Inspect network, component and hardware settings with idf.py menuconfig. Dependency declarations, component directories and sdkconfig determine the build; IDE screenshots alone do not specify a reproducible environment.

3. Trace execution

  1. Start at app_main() in main/AIoTNode.cpp. Confirm that BSP, sensor and network initialization are reachable.
  2. Inspect called examples, loops and early returns. Some experimental entry points stay in a test loop before acquisition initialization.
  3. Initialize acquisition configuration, bind an initialized sensor handle, then start. Configure online, offline and real-time modes separately to avoid competing for one sensor. See acquisition.
  4. Check input length, layout, sample rate, workspace and return codes before comparing algorithm output.

4. Read validation records

Layer Question
Design notes What problem and assumptions define the algorithm?
API and implementation How is data laid out, who owns memory, how are failures reported?
Test source What inputs and pass criteria are used?
Historical output What was actually printed?
Interpretation What conclusion is supported and what remains untested?

The FFT test provides a complete example. Missing device, firmware revision or run date is marked as unrecorded; a source-file date does not establish a run date. For a new run, record the project path, Git commit, hardware, build configuration, inputs and complete serial output.