Lab: Map MCU Domains to SDK Layers

Course 1 · Module 1 Type: Conceptual lab (no board flash required) Suggested time: 30–45 minutes

Read first: Lesson · Cheatsheet · ← Table of Contents · M02 →

Useful references while you map domains

Document	Use when
E84 Product Brief (PDF)	Checking domain names / NPU / HMI
AN241775 — HAL on PSOC™ Edge (PDF)	Matching the BSP / PDL / HAL terminology
Arm Cortex-M55 · Ethos-U55	Reading deeper on the core / NPU

Lab Goals

Once complete, you will:

Match hardware domains (Cortex-M55 / Cortex-M33 / Ethos-U55 NPU) to workload types with sound reasoning
Identify which layer (HAL/BSP, Driver API, Utility or Application) each kind of code should sit in
Check your understanding with a short checklist

Prerequisites

Have finished reading the lesson
Have the summary sheet sdk-layer-cheatsheet.md open
Paper, notes, or an empty file to fill in answers

Where’s Flash / Hello World? Installing ModusToolbox, creating a project, and flashing the board are in M02. This lab is deliberately a mental map, before you get hands-on with the tools.

Part 1 — Map Domains to Workloads

From the table below, choose the most suitable domain for each task. You may answer with more than one domain if needed, but must write a short reason.

#	Task	Options
1	Loop reading buttons and blinking an LED per the UI state	M55 / M33 / NPU
2	Listen for a wake word continuously, low-power	M55 / M33 / NPU
3	Run a gesture-recognition model on the device	M55 / M33 / NPU
4	Format JSON and publish MQTT	M55 / M33 / NPU

Self-Check Guidance (read after answering)

#	Guidance
1	Main UI/control work usually sits on the Cortex-M55
2	Always-on / low-power work usually ties to the Cortex-M33
3	Heavy inference work usually relies on the Ethos-U55 (NPU) (an app on M55 still coordinates it)
4	Building the payload / MQTT is Application work on the main core — not directly the NPU’s job

You don’t need to match this table word for word; if your reasoning agrees with the multi-domain principle, it counts as a pass.

Part 2 — Label the SDK Layers

Assume a simplified firmware project folder structure (hypothetical names for learning — not the SDK’s real paths):

app/
  main.c                 # product logic, creates tasks
  gesture_policy.c       # decides once an inference result comes back
bsp/
  board_init.c           # clock, pin mux, bring-up
drivers/
  gpio_api.c
  i2c_api.c
  uart_api.c
utils/
  ring_buffer.c
  simple_filter.c

Fill in the table:

File group	Layer (HAL/BSP, Driver, Utility, Application)	Short reason
`bsp/board_init.c`
`drivers/i2c_api.c`
`utils/ring_buffer.c`
`app/gesture_policy.c`

Self-Check Guidance

File group	Expected layer
`bsp/board_init.c`	HAL / BSP
`drivers/i2c_api.c`	Driver API
`utils/ring_buffer.c`	Utility
`app/gesture_policy.c`	Application

Part 3 — Integrated Scenarios

3A — On-Device Gesture

The task:

Read IMU values periodically over I²C → keep a short window of samples → feed it into a model on the Ethos-U55 → if it’s a gesture of interest, turn on an LED and prepare a message for the cloud

Answer point by point (no code needed):

Which layer is responsible for talking I²C to the sensor chip?
Which layer suits the sample-window buffer?
Which domain/hardware block accelerates advanced inference?
Which layer decides “this gesture is important enough to turn on the LED”?
Why is publishing MQTT still not the NPU’s job?

Self-Check Guidance (3A)

Driver API
Utility (or a structure in the Application that calls the utility)
Ethos-U55 NPU
Application
The NPU accelerates model computation — formatting the message and the protocol is app/communication-stack work on the main core

3B — Always-On Then Wake

The task:

The system waits to catch audio activity on the low-power domain all night; once an event occurs, it wakes the high-performance domain to run a heavy model and update the screen

Answer:

Which core/accelerator suits the “listening all night” phase?
Which core/accelerator suits the “heavy inference after being woken” phase?
Why should the Ethos-U55 not run at full power for 24 hours if the product runs on a battery?

Self-Check Guidance (3B)

The Cortex-M33 and/or NNLite
The Cortex-M55 coordinating + the Ethos-U55
The high-performance domain and the NPU use more power — always-on work should sit in the low-power domain and only wake the other when needed

Part 4 — Understanding Checklist (True / False)

Answer True or False

TESA Firmware SDK is the name of an IDE program that replaces ModusToolbox
HAL/BSP lets a developer avoid setting up the board’s basic registers by hand every time
The Driver API is the main layer for controlling GPIO, UART, I2C, SPI, PWM, ADC, in this course’s approach
Utility modules replace the Driver when you need to talk to hardware directly
The Cortex-M55 and the Ethos-U55 play the same role in every task
Edge AI always means sending all raw data up to the cloud
Choosing a processing domain affects power and latency
M01 requires learners to successfully flash Hello World firmware
Chip-level security (such as Secure Boot) is part of the architecture, not a topic separate from the MCU
The next lesson (M02) will get hands-on installing tools and building a real project

Checklist Answers

False — SDK ≠ IDE
True
True
False — Utility does not replace the Driver
False — they play different roles
False — Edge AI aims to process at the edge
True
False — that belongs to M02
True
True

Suggested bar: at least 8/10 before moving to M02

Common Misconceptions

Misconception	How to fix it
Having an NPU means you don’t need to write I/O-controlling firmware	The NPU accelerates inference — reading sensors/driving actuators still goes through the Driver and the app
Utility is just a shorthand driver	Utility helps with repeated work — talking to hardware still goes through HAL/Driver
You must memorise the whole datasheet before the first lab	M01 focuses on the architecture and SDK-layer map

Submission Checklist

Part 1’s table filled in completely, with reasons
Part 2’s table filled in completely
Parts 3A and 3B fully answered
Part 4’s checklist scored at least 8/10
Ready for M02, able to explain how the SDK differs from the IDE, and how multi-domain differs from a single core

Lesson · Cheatsheet · Table of Contents

Cite this lesson

If you teach from this lesson or reuse it in slides or documents, credit it with the text below. If you changed it, add (adapted) after the title.

"Lab: Map MCU Domains to SDK Layers" from TESA Open Knowledge by the Thai Embedded Systems Association (TESA), https://github.com/tesaiot/tesa-qualification-program, licensed under CC BY-NC 4.0

Thai attribution: "แล็บ: จับคู่โดเมน MCU กับชั้นของ SDK" จาก TESA Open Knowledge โดยสมาคมสมองกลฝังตัวไทย (Thai Embedded Systems Association: TESA) https://github.com/tesaiot/tesa-qualification-program สัญญาอนุญาต CC BY-NC 4.0

Lesson link: https://tesaiot.github.io/tesa-qualification-program/en/courses/firmware-sdk-edge-ai/m01-mcu-architecture/l02-lab/

This lesson adapts the source below; keep its credit too.
https://github.com/drsanti/TESAIoT-Courses/blob/287c21814ba8c75f693136616dcd270349a15966/C1/M01/lab.md · Original content by Asst. Prof. Dr. Santi Nuratch (ผศ.ดร.สันติ นุราช), KMUTT. Course 1 (C1/) of drsanti/TESAIoT-Courses. TESA funded the work and holds the rights; published here under CC BY-NC 4.0. The upstream repository carries no licence file. Text kept faithful; structure, front matter, quizzes and notes added by TESA Open Knowledge.

Full guide: how to cite TESA

Content is licensed CC BY-NC 4.0. Reuse it non-commercially and credit the Thai Embedded Systems Association (TESA) every time. · How to cite TESA