Introduction

Most embedded systems are designed assuming that the required power will always be available.

The power supply is selected based on:

• Maximum processor load
• Peak peripheral consumption
• Worst-case communication activity
• Sensor requirements

The calculation looks simple:

Available Power > Maximum Expected Load

But real products rarely operate in perfectly controlled conditions.

A battery-powered device reaches low charge.

A USB power source provides less current than expected.

A thermal condition forces power reduction.

A user activates multiple high-power features simultaneously.

A modular system adds an expansion board that consumes more than originally planned.

At that moment, the system has a choice.

Either every subsystem continues requesting power until the system becomes unstable.

Or the hardware architecture decides what matters most and protects critical functions.

This decision should not happen accidentally inside firmware.

A reliable product defines power priorities as part of the hardware architecture.

At Hoomanely, power management is treated as a resource allocation problem.

The question is not:

"How do we provide power to everything?"

The better question is:

"When power becomes limited, which functions deserve to continue operating?"

Power Budget Is a System Resource, Not Just a Supply Rating

A common design approach is selecting a regulator that can support the expected maximum load.

However, maximum load conditions are not always realistic or sustainable.

Consider a device containing:

• Main processor
• Camera module
• Wireless communication
• Audio system
• Sensors
• Display
• Storage

Each subsystem has different importance.

For example:

When the available power decreases, the system should not treat every load equally.

A camera processing task and a status LED should not compete for the same power budget.

Power priority rules create controlled behaviour.

Designing Subsystem Priority Encoding

Priority encoding defines the importance of each subsystem.

Instead of every block independently requesting power, the architecture creates a hierarchy.

A simple priority structure:

Priority 1
Critical Functions

↓

Priority 2
Core Operation

↓

Priority 3
Enhanced Features

↓

Priority 4
Optional Features

For hardware architecture, this can be implemented using:

• Power enable sequencing
• Load switch control
• Current monitoring
• Power-good signals
• Hardware priority signals

Example:

A smart device has:

• MCU
• Camera
• Wi-Fi module
• Speaker amplifier

During normal operation:

Everything is enabled.

During limited power:

1. Speaker turns off
2. Camera frame rate reduces
3. Wireless transmission reduces
4. MCU continues operation

The user experiences reduced features, not a complete failure.

Hardware-Based Priority Is More Reliable Than Software Decisions Alone

Software-based power control is useful.

However, software has limitations.

The MCU itself requires power to execute.

If the system voltage collapses before firmware reacts, software cannot protect the hardware.

Hardware priority mechanisms provide immediate protection.

Examples:

Load Switch Control

Each major subsystem receives power through a controlled switch.

Main Power

 |

Power Controller

 |
 -----------------
 |       |        |
MCU   Camera   Radio

The controller can disable lower-priority loads instantly.

Current Monitoring

A current monitor can detect when consumption exceeds the available budget.

The system can react before voltage collapse occurs.

Hardware Enable Dependencies

Critical subsystems can be independent from optional blocks.

For example:

Battery Power

 |
Critical Rail
 |
MCU

Optional Rail
 |
Camera / Display

The critical rail remains protected.

Load Shedding: Removing the Right Loads at the Right Time

Load shedding means intentionally disabling selected functions when power availability decreases.

The important part is selecting the correct loads.

Poor load shedding:

• Randomly disables functions
• Creates unpredictable behaviour
• Causes user confusion

Good load shedding:

• Removes non-critical functions first
• Preserves system control
• Maintains safe operation

A practical sequence:

Level 1: Reduce Optional Loads

Examples:

• LEDs
• Background communication
• High-speed sensors

Level 2: Reduce Performance

Examples:

• Lower camera resolution
• Reduce wireless transmission rate
• Reduce processor frequency

Level 3: Disable Secondary Features

Examples:

• Audio output
• Additional sensors
• External interfaces

Level 4: Controlled Shutdown

Only when power is insufficient for safe operation.

This approach creates graceful degradation.

The product becomes less capable, but remains functional.

Staged Enable Policies Prevent Power Surges

Many systems fail not because the total power requirement is too high.

They fail because everything starts at the same time.

Example:

At startup:

• Processor boots
• Camera initializes
• Wi-Fi connects
• Storage powers up
• Display turns on

All loads demand current simultaneously.

The result:

• Voltage drop
• Brownout
• Repeated resets

A staged enable policy avoids this.

Example:

Stage 1

Power Controller
MCU
Memory


↓

Stage 2

Sensors
Communication


↓

Stage 3

High Current Features
Camera
Audio
Motors

Each stage receives permission only after the previous stage is stable.

Power Budget Arbitration in Modular Systems

Modern products increasingly use modular architectures.

A carrier board may support:

• Sensor modules
• Compute modules
• Communication modules

The challenge:

The main power source may not always know what modules are connected.

A fixed power assumption becomes risky.

A better approach is power negotiation.

The system identifies:

• Connected modules
• Power requirement
• Priority level

Then allocates available power.

Example:

A USB-powered product receives:

Input Capability:
15W

Connected modules request:

Compute Module:
8W

Camera:
5W

Audio:
4W

Total:

17W Required

The system cannot provide everything.

The architecture must decide.

Possible decision:

Compute Module
8W - Enabled

Camera
5W - Enabled

Audio
4W - Disabled

The system remains stable.

Designing Power States Instead of Simple ON/OFF Control

A mature architecture does not have only:

ON

and

OFF

states.

It defines operating modes.

Example:

Full Performance Mode

All features active.

Balanced Mode

Reduced optional loads.

Low Power Mode

Only essential functions.

Emergency Mode

Critical operation only.

These states can be controlled using:

• Hardware signals
• Power controller ICs
• MCU commands
• Battery monitoring

The advantage is predictability.

Every power condition has a defined response.

Protecting Against Unexpected Load Combination

A common field failure occurs when individual features work correctly but fail together.

Example:

A camera works.

A speaker works.

Wi-Fi works.

But:

Camera + Speaker + Wi-Fi together causes reset.

This happens because subsystem validation was performed independently.

Power arbitration must consider combinations.

Testing should include:

• Maximum feature concurrency
• Worst-case battery voltage
• Temperature extremes
• Peak communication activity

The system should be validated against realistic usage, not individual component specifications.

Hoomanely Design Perspective

At Hoomanely, power availability is treated like a shared resource.

Every subsystem has a cost.

Every feature has a priority.

Every power source has a limitation.

The hardware architecture should answer these questions before the product reaches the field:

• Which functions must always survive?
• Which features can temporarily disappear?
• Which loads should never start together?
• How quickly can the system react to power limitation?
• Can the product degrade gracefully?

A good power architecture does not simply provide maximum power.

It manages limited power intelligently.

Final Thoughts

Power limitations are not unusual events.

They happen because of:

• Battery aging
• Weak chargers
• Thermal restrictions
• Expansion modules
• User behaviour

A product that ignores power priority will eventually fail unpredictably.

A product with defined priority rules behaves intentionally.

Subsystem priority encoding protects important functions.

Load shedding prevents collapse.

Staged enable policies improve startup reliability.

Power arbitration allows modular growth.

The goal is not keeping every feature alive at every moment.

The goal is ensuring the right features survive when the system has the least available power.