PrajnaEdge is not navigated like a conventional website. Knowledge is represented through paths, structures, and transitions.
Matter
NodeClick a node name to enter that concept and continue along the awakened path.
ExplorationsStep-by-step learning experiences containing theory, architecture, and interactive elements.
SetuA Setu connects related concepts that can be explored independently from the main sequence.
VortexA Vortex opens a path toward another knowledge area, foundation, or future domain.
BlackholeA deeper exploration space opened through the Vortex, where you select the depth of investigation.
AntarguhaA concealed exploration existing outside the regular path, waiting to be discovered within the system.
For the best experience, open PrajnaEdge on a desktop or laptop screen.
PrajnaEdge
A curiosphere for curious minds who want to understand, experiment with, and experience technology.
Technology is a system of connections.
Modern technology is built from layers that continuously interact with one another. At the physical level, electronic devices transform electrical signals into digital information. Digital logic turns that information into computation, while processors, memory and communication interfaces provide the machinery needed to execute instructions and move data. As these components become part of embedded systems, they begin to interact with the physical world through sensors, controllers, actuators and real-time software.
But computation does not exist in isolation. Operating systems coordinate hardware and software, firmware gives specialized machines their behaviour, and communication protocols allow independent systems to exchange information. At the same time, machine learning is moving beyond the cloud into edge and on-device systems, where models must operate within real constraints such as memory, processing power, latency and energy consumption.
PrajnaEdge explores these connections as one continuous technology landscape — and takes them beyond explanation. From computing foundations and embedded systems to intelligent machines and edge AI, ideas can be understood, experimented with, and eventually turned into technology that can be experienced in the real world.
PrajnaEdge products and technology experiences are currently in development.
In Development
Playground
Experiment with intelligence beyond the cloud.
AI inference performed closer to where data is generated — optimizing model representation to reduce latency, memory footprint, and bandwidth requirements.
Run an optimized, trained model directly on physical embedded silicon.
Cloud AIComing Soon
Model Training & Representation
Explore how neural networks learn representations from data before compression and deployment. Future experiments will allow adjusting learning parameters—such as learning rate, epoch counts, and batch sizes—to observe loss trajectories and decision boundaries.
Edge AIComputer Vision
Image Classification
Can this image classifier maintain its intelligence while becoming small enough for the edge?
On-device AIAI-Thinker ESP32-CAM
On-device Image Classification
Run a fully quantized INT8 image-classification model directly on embedded hardware.
On-device AIComing Soon
On-Device Model Adaptation
Can a constrained edge device adapt or fine-tune model parameters directly using local data? Exploring on-device transfer learning and few-shot adaptation under strict compute, memory, and thermal limits.
Edge AI Playground
Image Classification
Can this image classifier maintain its intelligence while becoming small enough for the edge?
Choose an image
Upload an image
Supports JPG, JPEG, PNG
This classifier recognizes only Apple, Banana, and Orange. Other objects may be incorrectly classified as one of these classes.
Run a fully quantized INT8 image-classification model directly on embedded hardware.
This experiment investigates preparing a compact INT8 TensorFlow Lite model for direct inference on resource-constrained embedded hardware. The model uses the same CNN architecture as the Edge AI exploration, converted to a full INT8 representation to classify three classes: Apple, Banana, and Orange.
Practical guides to embedded systems and engineering.
Automotive · EmbeddedProtocol Debugging
CAN Bus Debugging: From Symptoms to Root Cause
Select
United States
United Kingdom
Germany
France
Spain
Italy
Netherlands
Japan
Brazil
Canada
Mexico
Australia
India
Edge AI Demonstrations
Deploying neural networks and intelligent decision loops on raw silicon targets.
Sort:
Bare Metal
When Behaviour Becomes State
How to design predictable firmware states without operating system schedulers.
Bare MetalState MachineFirmware DesignSuperloopTiming
1. Same Input, Different Behaviour
Our previous explorations built a sequential superloop and taught it to coordinate tasks at precise intervals using hardware timers. The machine now has heartbeat and timing structure. But a critical question remains: even if the system knows exactly when to run a task, how does it decide what behaviour is appropriate at this exact millisecond?
Consider a motor-driven industrial system. It receives a single input: a Start button press. If the system is idle, pressing Start should engage the power relays and initiate a startup sequence. If the motor is already running, pressing Start should be ignored. If the system is in a fault state due to an overcurrent trigger, pressing Start must be rejected for safety.
The physical input is identical in all three cases. Yet, the required software reaction is entirely different. This is because input alone does not determine behaviour. Behaviour is a function of both the current input and the historical context of the system. We call this context the system's State.
Embedded software cannot exist as a pure function of its inputs. It must remember its past to govern its future.
2. The Hidden Memory Inside Behaviour
In poorly structured firmware, state is often stored in scattered boolean flags: bool is_running = false;, bool has_fault = false;, bool is_starting = false;. As features grow, these flags multiply. Contradictory states accidentally become possible: what happens if both is_running and has_fault are true? The code enters an undefined territory.
To avoid this complexity, we define mutually exclusive modes of operation using an explicit enumeration:
By declaring a single current_state variable, we guarantee that the firmware can occupy exactly one state at any given moment. This is the foundation of a Finite State Machine.
3. The First State Machine
The most common bare-metal state machine pattern utilizes a switch statement inside a periodic superloop task:
switch (current_state)
{
case STATE_IDLE:
HandleIdle();
break;
case STATE_STARTING:
HandleStarting();
break;
case STATE_RUNNING:
HandleRunning();
break;
case STATE_FAULT:
HandleFault();
break;
default:
current_state = STATE_FAULT; // Fail-safe default
break;
}
This switch-case structure maps our states, events, and transitions. It organizes code into modular, isolated blocks, preventing feature additions from degrading into a tangle of conditional statements.
SYSTEM STATE TRANSITION DIAGRAM
Mutually exclusive enums form deterministic paths where inputs trigger state transitions and execution modes.
4. Transitions: When Behaviour Changes
A state transition is the act of switching from one state to another. In our motor example, transitions are conditional:
case STATE_IDLE:
if (start_requested)
{
current_state = STATE_STARTING;
}
break;
By validating transitions only within specific states, we ensure that out-of-order events (such as pressing Start while the machine is already running or faulted) are ignored, maintaining safety and operational constraints.
5. Entry, Run, and Exit Actions
Transitioning to a state often requires one-time configurations. For example, entering STATE_STARTING requires enabling a motor relay, clearing a fault log, and setting a boot timer. If we place this logic inside the state handler:
case STATE_STARTING:
EnableMotorRelay();
ResetBootTimer();
break;
These routines execute repeatedly on every iteration of the superloop. This wastes execution cycles and resets timers continuously, preventing the system from progressing. We must divide state actions into distinct phases:
1. On Entry: Runs exactly once when entering the state.
2. While Active (Run): Runs repeatedly while the state remains active.
3. On Exit: Runs exactly once when leaving the state.
STATE TRANSITION LIFECYCLE (ENTRY / RUN / EXIT)
Explicit boundaries ensure setup and teardown routines execute exactly once during transitions.
In modular systems, transitions are routed through a dedicated state-setter function that enforces this lifecycle:
Let's connect this state model with the timing engine we built in our previous exploration. Suppose our startup process must wait in STATE_STARTING for exactly 500 milliseconds before transitioning to STATE_RUNNING. The naive approach uses blocking delay:
case STATE_STARTING:
EnableMotorRelay();
DelayMs(500); // Blocks the entire system
current_state = STATE_RUNNING;
break;
This delay freezes the superloop. The CPU cannot check sensors, handle communications, or evaluate safety limits for half a second, exposing the machine to catastrophic failure modes if a fault occurs during boot.
Instead of blocking, we integrate state with our non-blocking tick counter: On entering STATE_STARTING, we record the start timestamp: startup_begin_time = system_ticks;. Then, inside the active state checks, we evaluate the duration:
case STATE_STARTING:
if ((uint32_t)(system_ticks - startup_begin_time) >= 500U)
{
SetState(STATE_RUNNING); // Transition safely
}
break;
By checking elapsed time instead of waiting passively, the processor is released. The loop continues to run, keeping communication layers flowing and safety interrupts fully armed while the startup period progresses. The machine doesn't wait; it remembers.
7. Putting It Inside the Superloop
We can now examine how the entire bare-metal architecture comes together inside our main application loop:
int main(void)
{
Initialize();
while (1)
{
ProcessInputs();
ProcessCommunication();
if (control_task_due)
{
control_task_due = false;
RunStateMachine(); // Executes periodic control logic
}
ProcessBackgroundWork();
}
}
THE COOPERATIVE TIMED STATE ARCHITECTURE
Hardware timers tick background registers; superloop filters dispatch; state enums direct actual instruction blocks.
8. Events Can Come from Many Places
State transitions can be driven by a variety of asynchronous event sources:
- Hardware Input Events: Button presses, optical sensor triggers, limit switch closures.
- Timer Expired Events: Software timeout completions (like our non-blocking 500 ms wait).
- Sensor Thresholds: Temperature crossing safety ranges.
- Communication Messages: Host system packet arrivals.
- Interrupt Signals: Critical peripheral hardware updates.
In a clean cooperative architecture, background interrupts capture and queue these events, leaving the foreground logic to evaluate and execute the state transitions at a safe, unified execution level. This limits context-switch issues and race conditions.
9. State Explosion
State machines are a powerful structuring tool, but they have a scaling bottleneck: state explosion. A basic application starts with 4 states. As features are added, you introduce new states: STOPPING, CALIBRATING, DIAGNOSTIC, UPDATE_FW, LOW_POWER. The number of states grows, and the paths between them multiply exponentially.
If transition paths are modified from multiple locations in the file without clear boundaries, states can trigger unexpectedly, causing hidden bugs. Designing state machines requires caution: keep state counts bounded, keep state modification unified, and enforce strict ownership of state-variable updates.
10. A State Machine Is Not the Machine
A state machine is a conceptual model used to organize code, not a representation of the entire system. Real-world systems also contain continuous physical processes, asynchronous hardware registers, packet streams, and interrupt lines. Trying to model every single variable and condition as a state will make the code unmanageable. State should be reserved for representing the system's primary operating modes.
11. The Complete Bare Metal Picture
We have reached the end of our foundational path. Our bare-metal machine now possesses a complete execution architecture, built step-by-step across four key stages:
1. Before main(): How silicon boots, configures vectors, migrates memory segments, and constructs the C environment.
2. The Infinite Loop That Runs a Machine: How the core commits to perpetual execution, performing background and foreground cycles.
3. Teaching Time to an Infinite Loop: How independent counters and timer interrupts segment execution, scheduling tasks periodically.
4. When Behaviour Becomes State: How explicit enums and transitions organize behaviors, ensuring the machine reacts safely to inputs.
The Limits of the Simple Model
This simple timed superloop and state machine architecture can support highly sophisticated products—from medical devices to aerospace sensor nodes. It operates directly on the silicon with zero kernel overhead, minimal memory foot print, and complete predictability.
But as system complexity continues to scale, this cooperative model reaches a boundary. What happens when multiple tasks must block for external events, or task execution times collide? When sequential cooperation is no longer enough, a new way of organizing execution is waiting.
The superloop keeps running, ticking millisecond by millisecond, waiting for the next path to awaken.
Engineering concepts you don't just read — you experience.
Founded in 2026.
PrajnaEdge is a technology company exploring the space between understanding technology, experimenting with ideas, and turning them into things that can be experienced.
Our Mission
To make technology easier to explore, deeper to understand, and more exciting to experience.
Our Vision
To build a technology ecosystem where curiosity, experimentation and creation continuously lead to one another.
Where it began
Embedded Systems
PrajnaEdge began with Embedded Systems — exploring the foundations that connect hardware, software and intelligent computation.
The first technology universe is built around that foundation. The journey will expand as new ideas, experiments and products emerge.
I am the engineer behind the design, development, and content of PrajnaEdge. I build low-level systems where code directly controls hardware, bridging the gap between register-level silicon behavior and intelligent edge decision loops.
I am an Embedded Firmware Engineer focused on developing software for resource-constrained systems. My experience spans bare-metal firmware, device drivers, microcontroller peripherals, and communication protocols, working across the boundary between hardware and software.
My work has involved microcontroller-based systems, real-time behaviour, hardware interfaces, and communication technologies such as CAN, CAN FD, UART, SPI, and I²C. I am particularly interested in understanding systems from the lowest level upward—from registers and peripherals to intelligent edge systems.
ENGINEERING PHILOSOPHY
Engineering is not just about writing code; it is about managing constraints, timings, and physical hardware characteristics. True mastery of complex systems comes from understanding the interactions across different layers of the stack.
This conviction is why I built PrajnaEdge—to bridge the gap between conceptual theory and direct, register-level physical reality.
Where it all began — understanding the physical layer of computation. Circuits, signals, and systems gave me a mental model of how information moves through hardware.
⬡
Connects to Systems Understanding circuits directly enables writing firmware that talks to peripherals at the register level.
What it is
BTech in Electronics and Communication
Undergraduate foundation covering analog & digital circuits, signal processing, microprocessors, and communication systems.
CircuitsSignal ProcessingMicroprocessorsVLSI
What I did
Core Engineering Fundamentals
Studied semiconductor physics, digital logic design, and embedded microcontrollers. Built prototypes using 8-bit MCUs.
8051Logic DesignPCB Basics
What I learned
The Hardware Mental Model
Every software abstraction sits on physical reality. Understanding silicon teaches you why timing, power, and noise are first-class engineering problems.
Let's Connect
Interested in embedded systems, AI, or building something meaningful? I'd love to hear from you.
PrajnaEdge is an independent education platform built to make knowledge freely accessible.
If you find PrajnaEdge useful, you can support its continued development.
Your support helps fund the time, tools, infrastructure, and experimentation that go into building and maintaining PrajnaEdge.
Select Region
Select Amount
₹
Select an amount to support PrajnaEdge.
Legal & Privacy
Last updated: September 2026
1. Terms of Use
Welcome to PrajnaEdge (prajnaedge.dev), an independent engineering and technology platform created and maintained by Devaharsha Meesarapu. By using this website, you agree to these terms.
Educational & Research Focus: PrajnaEdge publishes interactive technical explorations, architectural models, and simulation walk-throughs covering embedded systems, computer architecture, operating systems, and edge artificial intelligence. All materials, interactive tools, and code demonstrations are provided solely for educational and conceptual understanding.
Hardware & Firmware Disclaimer: Embedded programming interacts directly with hardware registers, physical voltages, and precise timing. While all writeups and code demonstrations are prepared with care, they are provided "as is" without warranty of any kind. You are responsible for reviewing component datasheets, circuit schematics, and electrical ratings before deploying code to physical microcontrollers or custom hardware.
PrajnaEdge is committed to user privacy and minimal data collection. We do not sell, rent, or monetize your personal information.
Voluntary Correspondence: When you submit a message through the Contact or Feedback forms, or write directly to contact@prajnaedge.dev, we receive your name, email address, and message. This information is used strictly to reply to your inquiry.
Server Diagnostics: Standard web hosting infrastructure automatically logs basic technical access data (such as IP address, browser type, and timestamps) for server security, performance monitoring, and error diagnostics.
Local Storage: PrajnaEdge uses client-side browser localStorage purely to remember your interface preferences on your device (such as sound preferences for animations and tutorial display states). No personal identity data is stored in localStorage.
3. Advertising & Cookies
To help support platform operation and hosting, PrajnaEdge displays advertisements served by third-party advertising partners, including Google AdSense.
Advertising Cookies: Google and other third-party vendors use cookies to serve ads based on your prior visits to this website and other websites across the Internet.
DoubleClick / DART Cookie: Google's use of advertising cookies enables it and its partners to serve ads based on your visit to PrajnaEdge and other sites on the web.
Third-Party Ad Networks: When advertisements are requested by your browser, third-party ad networks automatically receive your IP address and may use technologies such as cookies or web beacons to measure ad effectiveness. PrajnaEdge does not control these cookies set by third-party advertisers.
4. Analytics
We use Google Analytics (measurement tag: G-6Y8ZVQB1V0) to evaluate anonymous, aggregate usage trends across our technical writeups.
Aggregate Telemetry: Google Analytics uses cookies to collect anonymous metrics such as page visit counts, device screen sizes, and navigation flows. This data helps us optimize responsive layouts and focus on high-interest topics.
Voluntary Support (Razorpay): If you choose to support PrajnaEdge through the Support page, transactions are handled through Razorpay's PCI-DSS compliant checkout interface. PrajnaEdge never handles, collects, or stores payment card numbers, UPI PINs, or banking credentials.
5. User Rights & Contact
Depending on your jurisdiction (including rights under GDPR, CCPA/CPRA, and applicable privacy laws), you have the right to request access to, correction of, or deletion of any personal communications you have submitted. We do not sell personal data.
For any questions regarding these terms, privacy practices, or data inquiries, contact the creator directly:
