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.

To continue exploring
Products

Technology, made tangible.

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.
Cloud AI Coming 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 AI Computer Vision

Image Classification

Can this image classifier maintain its intelligence while becoming small enough for the edge?

On-device AI AI-Thinker ESP32-CAM

On-device Image Classification

Run a fully quantized INT8 image-classification model directly on embedded hardware.

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.

Choose the model

Model size
4.91 MiB
Largest activation
~625 KiB
Test accuracy
99.11%
Measured model accuracy
Your image is processed locally in your browser.
On-device AI · Inference

On-device Image Classification

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.

Model size
1.23 MiB
INT8 quantized weights
Model accuracy
99.11%
Measured test accuracy
Target hardware
AI-Thinker ESP32-CAM
Embedded microcontroller target

Explore the ideas, systems and connections that shape technology — choose any node to begin your journey.

PrajnaEdge Navigation Tree
Embedded Systems Tree
View Books →
PrajnaEdge Library

PrajnaEdge Library

Practical guides to embedded systems and engineering.

CAN Bus Debugging: From Symptoms to Root Cause Book Cover
Automotive · Embedded Protocol 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:
Operating Systems

When Code Comes Alive

How a program becomes something the Kernel can manage.

ProcessThreadProgramKernelCPUOperating Systems

1. The Passive Blueprint

When you compile your C or assembly code, the toolchain generates an ELF binary or raw hex file.

But what actually runs when you power on the processor? Is it the program itself, or is it something else? * A Program is a static collection of instructions and data sitting passively on your flash memory or hard drive. It does nothing on its own. * A Process is the active, living instance of that program loaded into memory and running under the supervision of the Kernel.

To understand how operating systems coordinate concurrent software, we must trace this transition from passive instructions to active execution paths.

2. The Execution Hierarchy

Before we dive into the scheduling algorithms, we must establish a clear hierarchy of running software:

The Execution Hierarchy
PROGRAM (Passive) Flash / Storage Load & Launch PROCESS (Active) RAM Container Owns Isolated Resources Contains Thread 1 (Path 1) Thread 2 (Path 2) Thread 3 (Path 3)

3. Active Execution: The Process

When the Kernel loads a Program into RAM, it creates a Process. A Process is not simply a copy of the code; it is a complete, isolated sandbox.

The Process owns all resources required for execution: * Private Memory Space: Isolated regions of RAM that other processes cannot read or modify. * Resources: File descriptors, network sockets, and hardware ports assigned to that running application. * Execution State: Status metrics tracking credentials, privileges, and context data.

Within this Process sandbox runs the actual work. This is the role of the Thread.

A Thread is the actual path of execution inside a Process. A Process represents resource ownership; a Thread represents execution state. Every Process has at least one Thread, but advanced applications can spawn multiple Threads that share the same Process memory space.

4. Inside the Container

To understand the relationship between a Process and its Threads, we can look at how resources are shared inside the container:

Process vs. Thread Architecture
PROCESS BOUNDARY (Isolated Memory) Shared Code Shared Data Shared Heap Shared File Descriptors Thread 1 Private Stack 1 Local variables & calls Private CPU State 1 Registers, PC, SP Thread 2 Private Stack 2 Local variables & calls Private CPU State 2 Registers, PC, SP Thread 3 Private Stack 3 Local variables & calls Private CPU State 3 Registers, PC, SP

5. The Anatomical View

When the Kernel manages a Process, it maps out a strict layout within the system RAM. This structure contains both the program resources and the execution states of the threads:

* Program Code (Text): The compiled machine instructions read directly from flash or disk. This region is read-only to prevent programs from modifying themselves. * Stack: A fast, private memory region allocated to each thread. It tracks active function calls, parameters, local variables, and return targets. * Heap: A large dynamic memory pool used by the application during runtime. Memory is requested via malloc or new and must be freed explicitly. * Registers: High-speed hardware CPU storage slots. When a thread is executing, it writes directly to registers. When it yields, its register state must be saved. * Program Counter (PC): The specialized CPU register that holds the memory address of the next machine instruction to be executed by the active thread. * Process State: Flags and identifiers monitored by the Kernel that track process privileges, identity numbers, and current execution eligibility.

6. The Unit of Orchestration

In the previous exploration, we saw that the Kernel coordinates system resources. Now we can see the exact target of that coordination.

The Kernel does not interact with static files or programs directly. It schedules the active execution threads running within a Process sandbox. The Process acts as the boundary of resource ownership: * A crash inside one Process is isolated. Because Process RAM blocks are separated, one application cannot accidentally overwrite or crash another. * Before the Kernel can schedule clock cycles or allocate RAM space, it first needs a Process structure.

The Process is the fundamental container of running code that makes multiplexed operating systems possible.

7. The Lifecycle

The Kernel maintains a complete tracking directory of all active processes. But a process does not remain in the same execution state forever.

As it runs instructions, waits for network packets, yields to high-priority tasks, or shuts down, its execution eligibility changes. The Kernel must continuously monitor and adjust these states to maintain high performance.

The journey of execution is mapped through these changing stages.

The Lifecycle of Execution

A process is not a static container. It is a dynamic, living entity.

As it executes instructions, handles hardware inputs, and waits for memory resources, its relationship with the CPU changes.

The Kernel must continuously track this changing behavior to decide who runs next.

The journey of execution is mapped through these changing states.

A program is a map, a process is the journey, and the thread is the step.
System Tree Node Operating Systems

PrajnaEdge

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.

PrajnaEdge is a technology company created by Devaharsha Meesarapu.

CREATOR PROFILE

Devaharsha Meesarapu

Embedded Systems • Firmware • Edge AI

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.

View Resume →

ABOUT ME

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.

CONNECT

LinkedIn → GitHub →

Interactive Career Journey

BTech · ECE

Foundations

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.
Open to collaborations, research, and interesting engineering conversations.
Help Improve PrajnaEdge
Found something to improve? I'd love to hear your thoughts.

Bare Metal

Software that runs directly on hardware without an operating system.

Applications
↑
Operating Systems
YOU ARE HERE
Bare Metal
Processor
↑
Hardware

"Every embedded application begins long before main()."

Operating Systems

An Operating System manages hardware and software resources so complex applications can work efficiently.

Applications
↑
YOU ARE HERE
Operating Systems
Bare Metal
↑
Processor
↑
Hardware

"When one loop is no longer enough to carry the burden."

← Return to Systems Tree
Select Domain
Explore application domains branching from the Systems Tree
Automotive
Aerospace & Defence
Consumer
Embedded AI
Industrial
Medical
Multimedia
Network & Connectivity
Robotics
Explore Active Systems Tree →
← Return to Systems Tree
Select Depth
Examine computation through architectural depth layers
Architecture
Controller
Digital
Programming
Processor
Explore Processors → Explore Controllers →

Support PrajnaEdge

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.