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
Teaching Time to an Infinite Loop
How to schedule multiple tasks at predictable intervals without an operating system.
Bare MetalSuperloopTimerInterruptsCooperative Scheduler
1. The Concept of Time
At the end of our previous journey, we watched the processor enter an infinite loop. It was a structural guarantee that the CPU would never run out of instructions. But we also hit a wall: the loop knows how to repeat, but it does not understand time. Consider this basic superloop:
while (1)
{
ReadSensor();
UpdateControl();
RefreshDisplay();
SendStatus();
}
What if the application dictates that ReadSensor() must execute every 10 milliseconds, UpdateControl() every 20 milliseconds, RefreshDisplay() every 100 milliseconds, and SendStatus() every 1000 milliseconds? Neither the CPU instruction pipeline nor the while loop has any concept of a millisecond. If we run this loop as-is, it executes as fast as the system clock allows. The tasks run at arbitrary, hardware-dependent rates. To build a reliable machine, we must teach our software how to measure intervals.
2. The Tempting Solution: Delay
The most common initial attempt to solve timing is the blocking delay. We insert waiting routines directly into the execution path:
while (1)
{
ReadSensor();
DelayMs(100); // Wait 100 ms
UpdateDisplay();
}
During DelayMs(100), the CPU core spins in a dummy loop, burning power while executing instructions that do nothing. The entire foreground execution path is blocked. If we try to schedule multiple tasks with different intervals using this approach, the timing collapses:
These delays do not run independently; they accumulate. The actual period between executions of ReadSensor() is not 10 milliseconds. It is the sum of all task execution times plus the sum of all delays—a cycle time exceeding 1130 milliseconds. Blocking delays only mean 'do not progress past this line of code for N milliseconds.' They are not a scheduling architecture.
ACCUMULATED LATENCY OF BLOCKING DELAYS
Delays stack sequentially, so the actual period of any task is stretched by all other operations and delay cycles in the loop.
Blocking delays are appropriate only in limited situations: initializing a display chip during boot, letting voltage lines settle, or debugging simple single-task setups. In real runtime environments, they paralyze foreground logic.
3. The Machine Already Has a Clock
Instead of wasting CPU instruction cycles, we can delegate timekeeping to hardware peripherals. Microcontrollers contain hardware timers. These modules are independent binary counters on the silicon that increment based on a dedicated clock signal, running in parallel with the CPU's execution pipelines.
HARDWARE TIMER PERIPHERAL PIPELINE
The hardware timer counts clock pulses independently of the CPU core instruction pipeline.
Consider a simple configuration: an input clock of 1 MHz. If we set the timer's prescaler to 1, the counter increments every 1 microsecond. If we set a target compare register value of 1000, a comparator on the silicon triggers a compare match event exactly every 1000 counts—representing a precise 1 millisecond interval.
4. The Hidden Connection: The Architecture of Time
We have encountered this hardware before. In The Architecture of Time, we explored what happens when timers themselves reach their limits — overflow, wraparound, and the edge cases hidden inside measuring time. Here, we are looking at the same hardware from another direction. Not how time can fail, but how time can organize software.
5. Creating a System Tick
By configuring a hardware timer to assert an interrupt line at a periodic rate, we establish a software timebase—a system tick. Every tick, the CPU jumps to the interrupt vector to increment a global counter:
If the timer is configured to interrupt every 1 millisecond, then system_ticks increments 1000 times a second. An elapsed tick count of 10 corresponds to 10 milliseconds, and 1000 ticks represents 1 second. This global tick is the heartbeat of the system.
6. Avoid ISR Bloat
Since we have a periodic timer interrupt, it is tempting to run our task logic directly inside the ISR:
This is a dangerous anti-pattern. While this code runs at precise intervals, it executes inside the high-priority interrupt context. If the display refresh or status transmission takes longer than 1 millisecond, the ISR will not complete before the next timer interrupt triggers. The system crashes or locks up. Foreground execution is starved, other interrupts are blocked, and real-time promises fail.
7. Flags: Turning Time Into Events
To keep the interrupt context lean, we use flags. The background ISR handles the timing calculations, sets boolean indicators when tasks become due, and yields control immediately. The heavy application execution is performed inside the foreground superloop:
The background ISR triggers at a precise frequency to raise flags, which the foreground superloop checks and processes cooperatively.
8. Why Flags Are Not Time
This split design keeps interrupts fast. However, it introduces a new variable: scheduling latency. A flag setting does not mean the task executes exactly at the due timestamp; it means the task is released for execution. The actual run begins when the foreground loop reaches the task's check block.
SCHEDULING LATENCY EFFECT
The difference between a task's release trigger and its actual execution start is the scheduling latency.
If the superloop is currently busy executing a 25 ms calculation when the 10 ms flag is raised, the task experiences 25 ms of scheduling latency. The execution time of the background tasks limits the timing accuracy of the foreground loop.
9. When a Boolean Flag Loses Information
What happens if the scheduling latency is longer than the period of the task itself? Suppose the foreground loop is blocked for 35 milliseconds. During this block, the background timer interrupt fires three times at 10 ms, 20 ms, and 30 ms.
With a simple boolean flag: task_10ms = true. The flag switches from false to true on the first tick, and remains true on the second and third ticks. When the foreground loop finally unblocks and checks the flag, it sees a single true event. Two occurrences have collapsed, causing data loss. If our task is to refresh a screen, this is acceptable; we simply paint the latest frame. If the task is to sample a sensor, we have lost two critical packets of information.
To resolve this, systems rely on event counters, timestamp registers, ring buffers, or hardware-managed DMA paths to capture data autonomously without depending on loop response times.
10. Timestamp-Based Periodic Execution
An alternative scheduling architecture checks elapsed timestamps directly in the superloop without setting flags in the ISR. Instead of blocking the loop using delays, we check system ticks continuously:
uint32_t last_sensor_time = 0;
while (1)
{
uint32_t now = system_ticks;
if ((uint32_t)(now - last_sensor_time) >= 10U)
{
last_sensor_time = now;
ReadSensor();
}
// Other non-blocking checks can run here
}
Instead of waiting, the CPU evaluates the condition. If 10 milliseconds have not elapsed, it falls through to check other tasks. This transition from blocking waits to non-blocking timestamp comparisons keeps the loop flowing. Furthermore, by utilizing unsigned subtraction (now - last_sensor_time), the comparison remains completely wrap-safe when the 32-bit counter overflows and wraps back to zero.
11. Period Versus Execution Time
Regardless of whether we use flags, timestamps, or operating system schedulers, there is an absolute physical constraint. Suppose a task must run every 10 milliseconds, but the task itself requires 15 milliseconds of CPU execution time. No scheduling technique can resolve this. The task overflows its time budget, causing a scheduling overrun:
THE TIME BUDGET COLLAPSE (OVERRUN)
If execution time exceeds the required period, the system cannot meet its timing goals, regardless of the scheduler used.
To avoid timing collapses, the total processor utilization—the sum of all task execution times divided by their periods—must remain safely below 100%. If utilization exceeds this boundary, the workload must be reduced, optimized, or distributed across multiple cores.
12. A Simple Cooperative Scheduler
By organizing tasks inside non-blocking time checks, we have constructed a basic Cooperative Scheduler directly on the bare metal:
while (1)
{
if (TaskDue_10ms()) RunFastTask();
if (TaskDue_100ms()) RunMediumTask();
if (TaskDue_1000ms()) RunSlowTask();
}
Because there is no RTOS kernel managing preemptive context switches, every task runs to completion. This system works because each task cooperates by completing its work quickly and returning control to the superloop. It is simple, highly efficient, and predictable—but it requires discipline to avoid any blocking calls.
13. The Timer Solved 'When', But Not 'What'
We have structured our loop, bringing order and timing to our tasks. The microcontroller now executes routines at predictable frequencies.
But knowing when to run is only half of firmware behavior. A system must also know what to do at that moment. A motor controller running every 10 milliseconds must act differently if it is starting up, spinning at target speed, braking, or indicating a fault. Time tells the system when to reconsider its state. We must now explore how behavior shifts as the machine transitions across conditions.
The Division of Time
The infinite loop gave the machine repetition. The timer gave that repetition structure, dividing time into predictable intervals.
But to make that repetition useful, the machine must also understand its conditions.
A loop without time is a runaway engine. Time gives it a path; state gives it a purpose.
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:
