Hardware and software interfaces - Qualcomm Dragonwing Documentation

Review how the MCU interacts with platform hardware and the software stack used to control it. Understand the roles of key interfaces such as QUP, GPIO, interrupts, QTIMER, and debug paths, along with how they map to drivers, runtime services, and application logic. 6.1 Hardware interfaces You can align interface configuration, driver usage, and event handling with the expected programming model as listed in the following table. Table 6-1 Hardware interface roles

Interface	Role in integration	Typical software touchpoints
QUP serial engines	▪ Controller plane for UART ▪ I2C ▪ I3C transactions	▪ Mode selection ▪ Framing ▪ Timing ▪ Transfer setup ▪ Interrupt-driven ▪ DMA-backed operation.
Generic Peripheral Interface	Descriptor or ring-based data movement beneath selected QUP transfers	▪ Ring setup ▪ Ownership ▪ Completion and error interrupts ▪ Abort and reset handling
GPIO and external lines	▪ Interrupt ▪ Wake ▪ Reset ▪ Chip-select ▪ Enable ▪ Sideband interactions	▪ GPIO setup ▪ Interrupt routing ▪ Wake-source selection ▪ Peripheral reset ▪ Board bring-up.
Interrupt inputs	External events routed into MCU ISR handling.	▪ IRQ registration ▪ Wake classification ▪ ISR-to-thread handoff
QTIMER and wake sources	Time base and wake scheduling for active and low-power operation	▪ One-shot and periodic timing wake scheduling ▪ Latency measurement
Debug interface	Visibility during bring-up and fault analysis	▪ Memory inspection ▪ Trace capture ▪ Register dumps ▪ Exception ▪ Fault triage

6.2 Software stack and programming model Table 6-2 Software layer roles

Layer	Role
Startup and platform initialization	▪ Reset entry ▪ Exception vectors ▪ Cache ▪ Memory setup, and early board or platform initialization.
Zephyr runtime	▪ Threads, ▪ ISRs ▪ Work queues ▪ Timers ▪ Semaphores ▪ Mutexes, k_poll ▪ Deterministic timing services
Platform drivers	▪ Interrupt controller ▪ Timer services ▪ Host interface ▪ Power hooks ▪ Watchdog ▪ Error handling
Bus and peripheral drivers	▪ UART ▪ I2C ▪ I3C paths using native subsystem APIs and platform bindings beneath them.
Transfer layer	▪ QUP programming with optional GPI or ring-based data movement.
Application layer	▪ Sensor and event processing ▪ Policy handling, mission-mode logic, and host escalation.
Diagnostics	▪ Logging ▪ Fault capture ▪ Dump collection ▪ Trace hooks

■ Use threads and work queues for work that is too heavy for interrupt context. ■ Keep the ISR short. Acknowledge the event, capture minimal state, and hand off the rest. ■ Assert power, clock, and path dependencies only for the active duration of the transfer or work item. ■ Prefer native subsystem APIs for UART, I2C, and I3C in the delivered Zephyr environment. ■ Treat QUP as the protocol controller and GPI as the optional data-movement layer beneath it.