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 runs closer to where data is generated — reducing dependence on distant cloud infrastructure and enabling faster, more responsive systems.
Edge AI Computer Vision

Image Classification

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

On-Device AI Coming later

On-Device Intelligence

AI runs directly on the device where data is generated, bringing intelligence into the device itself while operating within its compute, memory, power and latency constraints.

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.
Playground · Future Area

On-Device AI

AI runs directly on the device where data is generated, bringing intelligence into the device itself while operating within its compute, memory, power and latency constraints.

Coming later

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

PrajnaEdge Navigation Tree
Embedded Systems Tree

Edge AI Demonstrations

Deploying neural networks and intelligent decision loops on raw silicon targets.

Sort:
Operating Systems

The Name Is Not the File

Understanding directories, path resolution, and filesystem identity.

Operating SystemsFile ManagementPath ResolutionDirectoriesHard Links

1. Start with the Familiar Name

When we interact with persistent storage, we locate and open files using names:

notes.txt

To a user or a programmer, it is natural to assume that the name is the file itself.

But this assumption is incorrect.

A filename is merely a string used to identify an object. It is not the underlying file object, nor is it the physical container of the data. A filename is a name used for lookup within a namespace. The physical data blocks on disk and the metadata describing them have an entirely separate identity.

This separation becomes more apparent when we construct a sequence of names to identify a file—a Path:

/home/dev/projects/notes.txt

A path is not a single physical string stored on disk that points directly to a sector. Instead, a path is a map. It represents a route that the operating system must navigate component by component to find the target object.

2. From Path to File

To resolve the path /home/dev/projects/notes.txt, the filesystem must step through each component of the directory hierarchy:

Path Resolution Sequence / home dev projects notes.txt File Identity (Inode)

The process begins at the absolute root of the filesystem namespace. The operating system looks up the root node, retrieves its contents, finds the mapping for home, and traverses downward. It repeats this matching step for dev and projects until it gets the entry for notes.txt.

A path is not a pointer to data. A path is a set of instructions for navigating a hierarchical namespace.

3. Directories Are Not Folders

In graphical user interfaces, directories are styled as "folders"—visual bins that contain physical files.

Conceptually, however, a directory is a mapping table. It is an organizational structure that translates human-readable name strings into unique filesystem internal identities.

Conceptual Directory Structure Directory Entries Table 📄 notes.txt 🖼️ photo.jpg 📁 projects/ File: 'notes.txt' Metadata and Inode #7182 File: 'photo.jpg' Metadata and Inode #8221 Directory Object: Inode #1204

A directory provides mappings from names to filesystem objects. When we look up notes.txt inside a directory table, we receive the internal index key. By nesting directory objects inside other directory tables, the filesystem builds the entire hierarchical directory tree.

4. EdgeCase: Path Resolution

Watch the interactive sequence below to trace how the operating system resolves /home/dev/projects/notes.txt from the root node through nested directories, retrieving directory entry tables along the path:

5. The Surprising Part: Name ≠ Identity

Because directories only link names to identities, the name of a file is decoupled from the file itself. This means multiple names can point to the same underlying file identity.

This relationship is known as a Hard Link:

Hard Link Architecture Directory Entries Map 📄 report.txt 📄 backup.txt Inode #7182 (Single File Identity) Link Count: 2 Data blocks: #41902, #41903

In this system, both report.txt and backup.txt entries are registered inside a directory pointing to the exact same file metadata entry (Inode #7182).

This is not a copy. Both names refer to the exact same file. If a program writes to report.txt and updates its content, a subsequent read of backup.txt immediately reveals those updates. The file remains alive until all names pointing to its inode reference are deleted (reducing the link count to 0).

6. Symbolic Links

Another way to map names is through a Symbolic Link (often called a symlink or shortcut).

Unlike a hard link, which points directly to the file identity, a symbolic link is a separate file that stores a path string referencing another name:

Symbolic Link (Shortcut) Pathing Directory Entry Table 🔗 latest.txt 📄 report.txt Symlink Inode #8012 Contents: 'report.txt' Inode #7182 Real Data Blocks

The difference between the two configurations is fundamental: * Hard Link: A direct path from multiple names to the same target inode. * Symbolic Link: A path from a name to a new file object whose data payload contains the text string of another path.

If the target name report.txt is deleted, the symlink latest.txt remains behind but becomes a "broken link," resolving to a path that no longer exists.

7. Relative vs. Absolute Paths

Paths can be specified in two formats:

* Absolute: Starts from the root token (/), e.g., /home/dev/projects/notes.txt. Resolution always begins at root. * Relative: Does not start from root, e.g., projects/notes.txt. Resolution begins from a contextual environment—typically the process's Current Working Directory (CWD).

This context means the same relative path can resolve to different physical files depending on which folder the application is executed from.

8. Real Operating-System Connection

While disk format structures vary across operating systems, the core programming interface remains uniform.

For instance, Linux filesystems (like ext4) implement directory entries as tables mapping name strings to numerical index nodes (inodes). The inode contains all metadata and block addresses, but has no knowledge of the name itself. Regardless of the underlying operating system—be it Windows, macOS, or Linux—the OS presents the exact same unified namespace abstraction (names, paths, directories, and file objects) to user application processes.

9. The Next Question

How does the filesystem keep track of all this information — the file's metadata, its directory entries, its data blocks, and the free space around them?

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.