Learning goal

By the end of this chapter you can answer three questions without looking anything up: what this board can do, which module owns each capability, and which chapter to open when you want to do a particular thing. This is the one chapter on the site with nothing to run — it is a map, not a lesson.

What the SDK is made of

Four things ship in the package:

Prebuilt module libraries, under lib/<module>/. Each carries its own static archive plus include/, api.txt (the exported-symbol roster), consumer_must_provide.txt, overridable.txt and PROVENANCE.txt. The set is signed; lib/verify.sh checks it against lib/manifest.txt.
A buildable template application: three ModusToolbox projects (proj_cm33_s, proj_cm33_ns, proj_cm55) that link those archives and boot into working firmware, with the sensor drivers, the MQTT pipeline and the UI pages shipped as source.
Tutorials, grouped by feature and sitting with their feature in the sidebar.
The API reference, last in every section — one page per function family, each carrying a code example.

Which module owns which capability

Six archives ship (lib/manifest.txt) — three link into CM55, three into CM33_NS. The two cores are not ABI-compatible, so linking one into the wrong core's image fails at the link step rather than at run time.

Module	Archive	Core	Exported symbols	What it does	Start at
Edge AI	libbento_edge_ai.a	CM55	39	The on-device inference engine: the model registry, the sensor feed router that keeps several models running at once, and the run-time loader that builds a model from a staged manifest	Edge AI
IPC Core	libbento_ipc.a	CM55	58	Core IPC management of internal services: sensor hub, LCD, UI and service dispatch	UI Pages & IPC
CM55 Core	libbento_cm55.a	CM55	30	CM55 display bring-up, the model-link control plane and the HSM provisioning flow as operated	UI Pages & IPC
TESAIoT HSM	libbento_hsm.a	CM33_NS	18	OPTIGA Trust M enrolment: device keypair, CSR and the isolated Protected Update path	Security / HSM
BLE NUS	libbento_secure.a	CM33_NS	87	The BLE NUS agent carrying the Bento Buddy protocol	BLE / Bento Buddy
MicroPython Secure	libbento_mpy.a	CM33_NS	46	The TACP wire protocol and WiFi credential management, as used by the MicroPython layer (mtb-mpy only)	the mtb-mpy set

Note: Credit: the Edge AI models are Infineon's, not TESAIoT's. The motion, audio and radar models this firmware ships (proj_cm55/modules/ai_models/model_*.c) are DEEPCRAFT™ Studio exports, copyright Imagimob AB, an Infineon Technologies company. The Siren, Cough and Factory Alarm models are DEEPCRAFT™ Ready Models by the same author, published by Infineon under the Imagimob AI Model Evaluation License Agreement, and are not redistributed here. TESAIoT trained none of them and owns none of them — what is ours is the engine around them. The shipped model sources carry a bare "All Rights Reserved" reservation and no grant of any kind, so they are credited here rather than licensed on. Our use is research and teaching, and not commercial; a reader who needs a grant must obtain it from Infineon and Imagimob. Train your own at https://www.infineon.com/design-resources/embedded-software/deepcraft-edge-ai-solutions/deepcraft-studio Full credit and the clause citations: THIRD_PARTY_NOTICES.md §2.2, §2.4 and §4.3.

What is not a library, and is worth knowing before you go looking: the peripherals (sensors, LEDs, buttons, radar, the QWA309 base board) and connectivity (WiFi, MQTT, mTLS). Both ship as template source. There is no libbento_peripherals.a and no connectivity library anywhere. The map from API family to the section that homes it is Where the peripheral APIs live and Where the APIs live; storage and credentials are Storage & Credentials.

"I want to do X" — which chapter

I want to	Open	Note
get the board running my own code for the first time	A1 — From the zip to your first program	unpack → build → flash → first program
read a sensor	J1 — The sensor bus and its lock, then Peripherals at a glance	the bus lock comes first, always
drive an LED or read a button	Peripherals at a glance (pq_pins)	brightness() is two mechanisms; only three pins dim in hardware
know how the on-screen sensor values get there	J3 — The auto-push task and the sensor hub	the auto-push task writes the IPC sensor hub
use the radar	J6 — Radar
run an Edge AI model	E1 — Select, confirm, start: REQUESTED versus ACTIVE	REQUESTED is not ACTIVE
run several models at once	E2 — Parallel sets and result polling
stop, unload or load a staged model	E3 — Stop, unload, and staged models
work out why inference looks wrong	E4 — Reading the Edge AI diagnostics
get onto WiFi	C1 — WiFi: the two credential stores and boot auto-connect	there are two credential stores
scan and connect from the screen	C2 — WiFi from the UI over IPC
publish to the cloud	C3 — TESAIoT cloud: config file → MQTT task → broker
use an mTLS identity held in the secure element	C4 — mTLS: the OPTIGA-backed TLS identity
talk to the OPTIGA Trust M	D1 — The chip-access discipline: gate, lock, touch-hold	the access discipline precedes every call
enrol a device, issue a CSR, run a Protected Update	D2 — Enrolment and Protected Update end to end
add a screen	F1 — Adding a screen: three files, plus the Makefile truth	all three wirings or none
drive a widget from the other core	F2 — Driving widgets from MicroPython over IPC
keep files or settings across reboots	G1 — bento_storage and the C credential store
bring up BLE / pair with Bento Buddy	I1 — BLE bring-up and the single-RF rule	one radio: WiFi and BLE are mutually exclusive
understand how the firmware boots	B1 — CM33_NS boot walk-through, then B2 — CM55 boot to first frame
decode a console line or an LED code	Appendix W — The signal atlas	it is in the Appendices
find out what has already cost somebody a day	Appendix X — Traps and anti-patterns
know which symbols you must supply to an archive	Appendix Y — Consumer-provided symbols and overridables	one section per module

Where the examples are

Three places, deliberately different:

Every function's reference page carries an example. An example lifted from shipped source carries an Origin heading naming the file it came from; an example with no shipped call site is labelled Example (authored). You can always tell whether you are reading code that runs or code written to teach.
The tutorials walk the real code in order, cited to file and line, and close each step with a What you should observe callout that quotes only signals verified to print.
Peripherals at a glance is tables only: every C-side and Python-side call with its file, its line and its BSP_HAS_* gate. Use it when you already know what you are looking for.

Step-by-step

Step 1 — Pick one capability from the module table

Open its section in the sidebar and notice the shape: tutorials first, API reference after. Every section is ordered that way.

What you should observe: The section opens on a Tutorials child, not on a list of functions.

Step 2 — Open one reference page and see which kind of example it has

Look for the Origin or Example (authored) heading on the page.

What you should observe: Every page has one or the other. A page with an Origin is code that is running on the board right now.

Step 3 — Go to Chapter A1

The next chapter takes you from the zip to a first program of your own, which is where the map above starts paying.

What you should observe: That chapter ends with the board running your code, not with a console window.

Traps

Looking for a peripherals library. There is none: the sensor drivers and their bindings ship as template source (Where the peripheral APIs live). Hunting for libbento_peripherals.a finds nothing.
Naming a component after the directory it sits in. A directory name does not tell you what the code in it does. The module table above is written from what each archive actually exports (lib/<module>/api.txt).
Assuming any module links into any core. Three archives are CM55, three are CM33_NS; the wrong one fails at the link step, which is the good outcome.
Expecting mpy_secure on mtb-only. That package does not link libbento_mpy.a. The six lfs_wifi_creds_* names are the single exception, re-provided as C source (Storage & Credentials).

Variant applicability

Variant: mtb-mpy and mtb-only. The map applies to both packages; the only difference is the MicroPython Secure row of the module table, which is not in the mtb-only documentation set.