Table of contents
Open Table of contents
Introduction
When people think about embedded systems, they often picture microcontrollers, sensors, and motors. While those components are important, the real challenge is often modeling system behavior. How should the system react when a button is pressed? What happens if an emergency stop is activated while a gate is moving? How do we ensure the system behaves predictably in every situation?
To explore these questions, I started building a prototype driveway gate controller using an affordable microcontroller, a pair of small servos to represent gate actuators, and a handful of push buttons to simulate user controls.
My initial instinct was to think in terms of hardware. I needed buttons, motors, and LEDs. However, after sketching a few ideas, it became clear that the more important problem was not the hardware itself. The challenge was defining the behavior of the system.
The first design decision was to separate system state from hardware state. A gate can be opening, closing, stopped, or fully open. Buttons can be pressed or released. Lights can be on or off. These are different concepts and should not be mixed together.
Instead of allowing buttons to directly control motors, I chose an event-driven state machine architecture. Button presses generate events. The state machine processes those events and decides how the system should respond. This creates a clear separation between inputs, decision-making, and outputs.
For example, pressing the Open button does not directly move a motor. Instead, it generates an Open event. If the system is idle, the state machine transitions into an Opening state. If an emergency stop is active, the same event is ignored. The button behavior remains simple while the system logic remains centralized.
This approach scales surprisingly well. Whether an event originates from a button, a limit switch, a timer, or a sensor, the state machine processes it using the same mechanism. As the project grows, new hardware can be added without fundamentally changing the architecture.
The exercise reminded me that embedded systems are often software architecture problems disguised as electronics projects. Before writing code or wiring components, it is worth spending time defining states, events, and transitions. Once the model is clear, the implementation becomes much simpler.
In the next stage of the project, I will begin implementing the state machine on the STM32 and connecting it to servos and simulated gate controls. The goal is not simply to move motors, but to build a controller that behaves predictably, safely, and consistently.