What most don’t realize is that the real engine behind this AI revolution started in a place few expected: inside the humble gaming PC.

The same graphics cards once built to render smooth 3D visuals are now powering chatbots, image generators, and self-driving systems. The journey from pixels to predictions is one of the most fascinating stories in modern computing.

The CPU Era and Its Limits

In the early days of machine learning, researchers depended on CPUs to crunch data.

CPUs were versatile and great for handling a wide range of tasks, but they had one big limitation: they worked on problems in sequence.

That means they could process only a few operations at a time. For small models, this was fine. But as neural networks grew in complexity, training them on CPUs became painfully slow.

Imagine trying to teach a computer to recognize images. A neural network might have millions of parameters, and every single one needs to be adjusted again and again during training.

On CPUs, that could take days or even weeks. Researchers quickly realized that if AI was going to advance, it needed a completely different kind of hardware.

How GPUs Entered the Picture

Graphics processing units, or GPUs, were originally built to render the fast-moving images in video games. They were designed for parallelism, performing thousands of small calculations at the same time.

While a CPU might have a handful of cores, a GPU has thousands. This architecture made GPUs ideal for the kind of math used in machine learning, where the same operation needs to be applied to huge amounts of data simultaneously.

In a way, the GPU was built for games but destined for AI. What started as a chip to make lighting effects smoother and explosions look more realistic soon found a second life powering neural networks.

Around the early 2010s, researchers began experimenting with running deep learning algorithms on GPUs, and the results were stunning. Training times dropped from weeks to days, and accuracy improved.

It was a quiet revolution happening in research labs around the world.

The Role of Gaming PCs in Early AI Research

Here’s where the story gets even more interesting: many of the early breakthroughs in AI didn’t come from massive data centres or expensive supercomputers. They came from researchers using consumer-grade GPUs, often sitting inside regular gaming PCs.

These machines, built for entertainment, turned out to be powerful enough for deep learning experiments.

NVIDIA’s CUDA platform made this possible by allowing developers to program GPUs for tasks beyond graphics. Suddenly, a gaming GPU could handle complex scientific computations.

Researchers used their own rigs, sometimes the same computers they played games on at night, to train neural networks that recognized speech, images, and text. The gaming PC became a testbed for the future of artificial intelligence.

The Turning Point: AlexNet and the Deep Learning Boom

In 2012, a neural network called AlexNet stunned the world by winning the ImageNet competition, a major benchmark in computer vision.

What made AlexNet special wasn’t just its architecture but the hardware behind it. It ran on two NVIDIA GTX 580 GPUs, hardware you could buy for your low-cost gaming PC. That win marked a turning point. It proved that GPUs weren’t just for rendering graphics – they were the key to advancing AI.

After that, the AI world changed fast. Every major research lab and tech company started building GPU clusters. NVIDIA, sensing the opportunity, leaned into AI hardware development.

The same company that once catered mainly to gamers now powered Google, OpenAI, and Tesla. What started as a tool for better visuals had become the backbone of machine intelligence.

Why GPUs Are So Good at AI

GPUs excel at matrix math, the kind of computation that neural networks rely on.

When you train a model, you’re constantly multiplying and adding matrices of numbers. GPUs do this faster because they handle thousands of operations in parallel. They’re also designed with high memory bandwidth, meaning they can move large amounts of data in and out quickly.

This architecture fits perfectly with deep learning workloads. Whether it’s image recognition or language translation, GPUs can process huge batches of data at once.

CPUs, by contrast, get bottlenecked by sequential processing. The difference in performance is like comparing a single craftsman building a house to a team of thousands working at once.

The AI Hardware Race

As AI took off, the demand for GPUs exploded. What began in gaming PCs scaled up into massive data centers filled with thousands of cards.

Companies like NVIDIA developed new lines of GPUs specifically for AI, such as the Tesla and A100 series. Other players joined the race too, like AMD with its ROCm platform, and Google with its custom TPUs (Tensor Processing Units).

Yet, even today, the line between gaming and AI hardware remains blurred. The same RTX GPUs designed for gamers are still used by many AI researchers and small startups.

A powerful gaming PC equipped with a modern GPU can run local AI models, generate images, or even fine-tune small language models. The hardware that made virtual worlds come alive now brings intelligence to our real one.

The Future of GPUs and AI

As AI models grow larger, new challenges are emerging. GPUs are evolving to handle trillion-parameter models, but they’re also getting smarter about energy use and efficiency.

Technologies like chiplet design, optical interconnects, and AI-specific cores are pushing performance further while keeping costs down.

Meanwhile, local AI is making a comeback. With advancements in GPU efficiency, many users are experimenting with running models on their own machines.

A well-equipped gaming PC can now do what once required access to a cloud GPU cluster. This shift could democratize AI development, letting anyone with the right hardware explore the field from home.

Conclusion

The GPU’s journey from gaming to AI is one of the most unexpected transformations in tech history. What started as a chip to render virtual landscapes evolved into the heart of artificial intelligence. From early experiments on gaming PCs to the data centers powering today’s largest models, GPUs have bridged the worlds of creativity, computation, and cognition.

As we look ahead, it’s clear that the same technology that once made games more realistic is now making machines more intelligent. The story of the GPU reminds us that innovation often comes from unexpected places, and sometimes, the future of AI begins in the glow of a gaming screen.

Hope you enjoyed this article. Find me on Linkedin or visit my website.

The first is general-purpose computing, where they handle a wide range of tasks, including running diverse applications and programs. Examples include laptops, desktops, servers, and supercomputers.

The second is embedded systems, which are specialized computers designed for specific functions. Commonly found in devices such as thermostats, refrigerators, cars, and other smart appliances, they rely on sensors to collect environmental data and execute their tasks efficiently.

The Role of Sensors

Sensors play a critical role in both types of computing. In embedded systems, sensors gather environmental data to help devices like autonomous vehicles, home appliances, and industrial machines perform tasks. In general-purpose computers, sensors primarily monitor internal conditions such as temperature and voltage, ensuring safe operation and preventing issues like overheating or electrical faults.

As Artificial Intelligence (AI) and the Internet of Things (IoT) evolve, sensors have become indispensable for gathering real-world data to support intelligent decision-making. Embedded systems leverage sensors to perceive their environment, transforming raw data into actionable insights that power automation and improve efficiency across industries.

This means that understanding sensor interfacing and designing robust sensor-driven software has become a vital skill for engineers and hobbyists alike.

Whether you're a beginner or experienced engineer, this guide will help you build a solid understanding of sensor interfacing software.

What You’ll Learn and Article Scope

In this article, you’ll learn how to connect sensors to microcontrollers (MCUs) and design sensor software pipelines that turn raw data into meaningful, usable information. You’ll also explore practical techniques for processing sensor data accurately and efficiently in embedded systems.

Here’s a breakdown of what we’ll cover:

• What sensors are and how they work – An introduction to sensors, common types, and how sensor pipelines help process sensor data.

• Key sensor characteristics – Important parameters like sensitivity, accuracy, precision, range, drift, and response time to help you choose the right sensor for your project.

• How to interface sensors with microcontrollers – Hardware connections and communication protocols like SPI, I²C, and GPIO that allow microcontrollers to read sensor data.

• Software architecture for sensor data – A high-level overview of the software pipeline that processes sensor data, including drivers, ADC support, scaling, calibration, and post-processing.

• Detailed design of pipeline components – A closer look at each step in the pipeline, focusing on scaling raw data, calibrating sensors, and applying filters to clean up noisy signals.

• Practical tips for power management – Best practices for handling power efficiently using low-power modes, FIFO buffers, and DMA when working with sensor data in embedded systems.

By the end of this article, you’ll know how to design and implement a complete sensor data pipeline for an embedded system, from reading raw sensor data to preparing it for real-world use in intelligent, connected devices.

Note: Advanced data processing, high-resolution ADCs, and hardware circuit design for sensors are outside the scope of this article.

Prerequisites

To get the most out of this article, you should have:

1. Basic knowledge of microcontrollers: Understanding of common peripherals like ADCs (Analog-to-Digital Converters), SPI (Serial Peripheral Interface), I2C (Inter-Integrated Circuit) and GPIO (General Purpose Input/Output). If you’re new to these protocols, this article provides a great overview.

2. Basic knowledge of electronics: Familiarity with circuits and signals, including analog and digital interfaces.

3. Programming in C: Familiarity in embedded software development, including driver development.

4. (Optional) Basic knowledge of sensors: Understanding different types of sensors (like temperature, pressure, motion) is helpful but not required.

Also, this article assumes the following:

• You are working with a microcontroller equipped with the peripherals needed for sensor integration. The details of microcontroller peripherals can be found in a reference manual for example for an STM32F4 series microcontroller will have all the details :

• You are familiar with compilers, debuggers, and IDEs used in embedded systems. Some common tools include:

  • Compilers: GCC, Clang,

  • Debuggers: GDB, LLDB

  • IDEs: Visual Studio Code (VSCode) is a popular choice, especially with extensions for embedded development and debugging.

• You aim to build reliable, sensor-driven embedded systems, capable of collecting and processing real-world data efficiently.

Table of Contents

• What is a Sensor and Sensor Pipeline?

• Sensor Characteristics

• How to Interface with a Microcontroller

• Software Architecture

  • High-Level Overview of Components

  • Accessing Data from the Sensor

  • Sensor Power Management

• Detailed Design of Components

  • 1. Sensor Driver

  • 2. ADC Support

  • 3. Scaling

  • 4. Calibration

  • 5. Data Post-Processing

• Conclusion

What is a Sensor and Sensor Pipeline?

A sensor detects changes in physical properties such as temperature, pressure, or light and converts them into electrical signals that can be measured or interpreted. For example, a thermistor is a type of resistor whose resistance changes with temperature. As the temperature varies, the resistance of the thermistor changes, altering the voltage across it. The system then interprets this voltage change to determine the temperature.

To better understand sensors, consider the natural sensors in the human body: the eyes, ears, skin, nose, and tongue. These natural sensors constantly send signals about the environment to the brain for processing. Different regions of the brain interpret these signals and use the information to drive actions and responses. Just like the brain processes signals from natural sensors, a microcontroller processes signals from electronic sensors using a sensor pipeline.

Sensors come in many types, each designed to detect specific physical properties. Some sensors have a sensing element that changes its properties in response to conditions like heat, light, or pressure. Examples include thermistors, infrared receivers, and photodiodes.

For detecting movement, such as acceleration and rotation, MEMS (Microelectromechanical Systems) sensors—like accelerometers and gyroscopes—are widely used.

To measure distance, sensors like sonars, ultrasonic sensors, and radars are common. These are just a few examples of the many types of sensors available.

Beyond the types of physical properties they detect, sensors also differ in their levels of integration. Some sensors are raw sensors, consisting only of a sensing element and a transducer with simple leads for direct connection to an external circuit.

Others, known as smart sensors, include additional components such as an ADC (analog-to-digital converter) and onboard processing capabilities, enabling them to handle more of the data processing independently.

The choice between a raw sensor and a smart sensor depends on your application requirements, including factors like cost, size, and the processing load on the interfacing microcontroller.

Returning to our human analogy, consider how vision works as a sensor pipeline. When light enters our eyes, photoreceptor cells (rods and cones) in the retina act as sensing elements, converting the light into electrical signals. These signals travel via the optic nerve to the brain’s visual cortex, where they undergo processing to form a recognizable image. The brain then interprets this information and initiates a response, like smiling when you see a beautiful scenery.

Similarly, a sensor pipeline for an embedded system can be defined as shown in the picture below:

Each of these steps may have different requirements based on the application. Creating a requirements document for the sensor is helpful when selecting the appropriate sensor and configuring the pipeline.

Sensor Characteristics

Before you dive into the blocks of the sensor pipeline, let’s review some important characteristics of a sensor.

Sensitivity

Sensitivity is the ability of a sensor to detect small changes in the physical property it’s designed to measure.

Sensitivity can vary based on factors like manufacturing processes, cost, and the design of the sensing element.

Sensors designed for a specific property often come in different sensitivity levels, allowing users to select an appropriate sensitivity based on the application requirements.

Accuracy

Accuracy is the degree to which a sensor’s measurement matches the true value of the physical property it’s measuring. Testing a sensor’s accuracy typically requires comparing its readings to those of a reference instrument.

A sensor may have gain and offset errors—issues that calibration can help correct. Calibration adjusts for these systematic errors, which are often due to manufacturing tolerances or design factors.

Once calibrated, the sensor’s output can be verified against a reference to confirm its accuracy. The required level of accuracy should be determined based on the application’s needs.

Precision

Precision refers to the consistency or repeatability of a sensor's measurements, regardless of how close those measurements are to the true value. It indicates the sensor's ability to produce the same output under identical conditions and how finely it can resolve and report values.

For example, if the true temperature of an object is 12.53°C:

• A precise sensor will consistently measure values like 12.52°C, 12.53°C, or 12.54°C, even if those values are slightly offset from the true temperature.

• A highly accurate sensor, on the other hand, will measure values close to 12.53°C but may lack precision if those readings vary widely (e.g., 12.50°C, 12.53°C, and 12.56°C).

For applications requiring exact measurements, a sensor with both high accuracy (closeness to the true value) and high precision (low variability) is essential. This is especially important in distinguishing small differences, such as between 12.5°C and 12.53°C.

In contrast, applications with less stringent requirements might use sensors with broader tolerances, such as ±1°C, which are sufficient for general monitoring purposes.

Range

The range of a sensor refers to the span between the maximum and minimum values of the physical property it can measure while maintaining its specified precision and accuracy. A sensor's operating range may extend beyond its measurement range, but the measurement range defines the limits within which the sensor reliably adheres to its specified sensitivity, accuracy, and response time.

Drift

Drift is when a sensor's output changes over time due to conditions like temperature or humidity. Components within the sensor, including the sensing element, may be sensitive to these conditions, leading to gradual shifts in measurements.

For example, many components are affected by temperature and humidity changes, which can alter sensor readings. Also, sensors with internal oscillators may experience time-based drift, impacting accuracy.

Regular calibration with an accurate external reference (such as a precise clock) can help correct for drift and maintain reliable measurements. For certain applications, selecting a sensor with acceptable drift characteristics is crucial.

Response Time

Response time is the duration a sensor takes to detect and reflect a change in the measured physical property. For example, if the temperature rises by 5°C, the response time indicates how long the temperature sensor takes to reflect this change in its output.

Response time depends on the sensor’s design, manufacturing quality, and internal components, such as the ADC (Analog-to-Digital Converter), averaging circuits, and filters within the sensor pipeline.

All the parameters mentioned above are thoroughly documented in the sensor’s data-sheet. In practice, it’s a good idea to create a sensor requirements document for each specific application, detailing these key parameters as a baseline for sensor selection.

Now that you’ve examined the key characteristics of sensors, let’s explore how you can connect them to a microcontroller for real-world applications.

How to Interface with a Microcontroller

Choosing a Communication Protocol

Another essential aspect of sensor requirements is specifying the communication interface between the sensor and the MCU or processor in the system. It’s important to understand how the sensor will be interfaced based on its output signal type and the available pins on the microcontroller.

For instance, certain sensors may connect directly to an analog or digital input pin on a microcontroller. A raw sensor, such as a temperature sensor, typically connects to an analog input pin, which is then read by the microcontroller’s internal ADC (Analog-to-Digital Converter).

In contrast, a digital-output sensor connects to a digital GPIO (General Purpose Input/Output) pin. For instance, speed sensors generate square waves with variable pulse widths to indicate speed. These signals are usually connected to a GPIO pin configured as an external interrupt or timer capture input, allowing the microcontroller to measure pulse width accurately.

A smart sensor, on the other hand, often supports communication protocols like SPI (Serial Peripheral Interface) or I2C (Inter-Integrated Circuit). These interfaces enable the microcontroller to configure the sensor, check its status, and retrieve data through register reads and writes.

Choosing the appropriate communication protocol for interfacing a sensor depends on the available pins in the system and the specific requirements of the application.

Tip: When working with protocols like I²C or SPI, using tools such as Saleae logic analyzers can greatly simplify debugging and validation. Logic analyzers capture and visualize communication signals, and tools like Saleae offer built-in protocol interpreters to help you decode sensor communication in real time. This can be especially helpful when troubleshooting configuration issues, timing problems, or communication errors during sensor interfacing.

Figure 2 below shows an example of a microcontroller connected to 4 sensors having different interfaces.

Determining Power Requirements

Power requirements are another key consideration when interfacing a sensor. Sensors may operate at different voltages (for example, 3.3V or 5V), so ensuring the microcontroller can accommodate these levels is essential. Level converters can bridge voltage mismatches, ensuring compatibility between the sensor and microcontroller voltage levels.

Timing and sampling requirements must also be evaluated, especially for sensors generating high-frequency data. Configuring external interrupts on GPIO pins can ensure timely data capture, while techniques like using DMA can streamline data transfer for sensors sampling at high frequencies without CPU involvement.

Now that you’ve learned about communication protocols and hardware connections, let’s focus on designing the software architecture that acquires, processes, and prepares sensor data for use. Designing effective software is crucial for obtaining clean, reliable data from the sensor.

Software Architecture

Now that we’ve chosen the sensor and communication protocol, let’s design the software architecture for the sensor pipeline. This software runs on the microcontroller connected to the sensor and processes raw data to make it clean and usable.

While application-level data processing is beyond the scope of this article, let’s focus on interfacing with the sensor and preparing the data for application use.

The sensor processing pipeline can be broken into the following components:

1. Sensor Driver

2. Analog-to-Digital Conversion (ADC) Support

3. Scaling

4. Calibration

5. Data Post-Processing

Let’s examine a high-level overview of these components for both smart and raw sensors.

High-Level Overview of Components

1. Sensor Driver

   1. Smart sensors: The driver configures the sensor, manages power, and handles read and write operations to the sensor registers over a communication protocol like SPI, I2C.

   2. Raw sensors: The driver may only control GPIOs for power management, as raw sensors typically lack registers.

2. Analog-to-Digital Conversion (ADC) Support

   1. Smart sensors: Include an onboard ADC, which is configured through the sensor driver.

   2. Raw sensors: Requires an external ADC, an ADC driver implemented in software to configure the ADC, initiate conversions, and retrieve data.

3. Scaling: Scaling is necessary for both smart and raw sensors. It converts digital counts after the analog to digital conversion into meaningful physical quantities using formulas provided in the sensor data sheet. For example, a temperature sensor will use a formula to convert digital counts to degree Celsius.

4. Calibration: Once the measured physical quantity is obtained, calibration adjusts the value by applying offsets, gains, or both to correct errors. This process ensures the sensor output aligns with reference values across its entire measurement range. A detailed discussion of the calibration process will follow in the next section.

5. Data Post-Processing: Post-processing techniques, such as filtering are applied to improve data quality and reduce noise. Common filters such as low-pass or high-pass filters can remove unwanted frequency components.

Accessing Data from the Sensor

The method of accessing data depends on the whether it’s a raw sensor or a smart sensor. Smart sensors will have onboard ADCs and FIFOs. Before delving into how data is accessed, it’s important to first understand sampling frequency.

Sampling Frequency:

The frequency of taking a measurement from the sensor must follow the Nyquist-Shannon sampling theorem. It states that the sampling rate must be twice the highest frequency component of the signal to be measured to accurately reconstruct the measured data.

The sampling frequency defines how often the sensor captures data, which affects how the data is accessed. Depending on whether the sensor is a raw sensor or a smart sensor, the approach to handling this sampled data varies.

Smart Sensors:

1. Data register: The sensor writes sampled data directly into a register based on the set sample frequency updated during setup. The microcontroller reads this data register based on a data conversion completion interrupt.

2. FIFObBuffer: Some sensors include FIFO (First-In, First-Out) buffers to store multiple data points. When enabled, the FIFO updates at the configured sampling frequency and trigger interrupts when it becomes full or reaches a predefined level.
   The benefits of FIFO include:

   1. Power efficiency: The MCU can process data in batches, reducing CPU overhead and allowing it to enter low-power mode during data collection.

   2. Sampling and processing rate matching: FIFO buffers help reconcile differences between the sensor’s sampling rate and the MCU’s data processing rate.

   3. For MCUs with Direct Memory Access (DMA), data transfer from the sensor to MCU memory can occur without CPU intervention, further reducing power consumption.

Raw Sensors:

For raw sensors, the MCU triggers ADC conversions at the sampling frequency, often using a timer interrupt. Data is read upon the ADC conversion complete interrupt, allowing the MCU to sleep during conversions and between samples to save power.

Sensor Power Management

Power management is critical for energy-sensitive applications. Strategies include:

1. Low-power modes: Many sensors support low-power modes configurable through sensor registers.

2. GPIO-controlled power cycling (Duty-Cycling): For sensors without built-in low-power modes, the microcontroller can toggle the sensor’s power line using a GPIO pin, reducing power consumption further. Figure 3 below shows the diagram of a raw temperature sensor whose power is controlled using a GPIO from the MCU. For example, a temperature sensor in sleep mode can be activated only when temperature readings are required.

The above techniques ensure efficient use of power while maintaining the required data sampling rate and sensor responsiveness.

With the high-level architecture in mind, we’ll now dive into the detailed design of each pipeline component.

Detailed Design of Components

In this section, you’ll delve into the key components of the sensor pipeline outlined in the Software Architecture section.

1. Sensor Driver

The sensor driver is responsible for managing communication, configuration, power, and data acquisition for both smart and raw sensors.

Smart Sensor Driver:

1. Communication driver: Generic I2C or SPI drivers on the MCU can be adapted using wrapper functions to handle sensor-specific requirements, such as 1-byte, 2-byte, or 4-byte transfers.

2. Configuration: Typical tasks include setting the sampling rate, configuring interrupts, managing FIFO buffers, and, if needed, clock settings.

3. Power management: APIs should allow higher software layers to transition sensors between power modes by writing to specific registers or controlling GPIO lines for sensors without built-in power modes.

Raw Sensor Driver:

For raw sensors, the driver primarily manages power, often through GPIO-controlled toggling.

2. ADC Support

ADC support is required only for raw sensors. In this article, we’re focusing on SAR ADCs, which are commonly embedded in microcontrollers.

How SAR ADCs Work?

A SAR ADC converts an analog signal to a digital value over multiple clock cycles, with the number of cycles equal to its bit resolution (for example, 10 cycles for a 10-bit ADC).

Key terms related to ADCs:

1. Reference Voltage (VRef): Represents the maximum voltage the ADC can measure. Analog signals exceeding this limit must be scaled down.

2. Resolution: Determines the smallest detectable voltage change. For example, a 10-bit ADC with a 3.3V VRef has a resolution of 3.22 mV

$$V_{\text{Res}} = V_{\text{Ref}} /2^{10}$$

The ADC result is stored in a data register, which can then be scaled to meaningful physical units.

3. Scaling

Scaling converts ADC counts into meaningful physical values, such as temperature (°C) or acceleration (g) depending on the sensor type. Sensor datasheets typically provide the necessary formulas or lookup tables.

For example, the method to convert a voltage measured by a raw temperature sensor to temperature value is shown below:

$$V_{\text{Measured}} = Counts_{\text{ADC}} / 2^{10} * V_{\text{Ref}} \quad \text{(Get V_Measured from ADC Counts)}$$

$$Temperature_{\text{Measured}} = V_{\text{Measured}} * T_{\text{C/mV}} \quad \text{(Get Temperature physical value)}$$

Similarly, a 3-axis accelerometer maps counts on the X, Y, and Z axes to acceleration values in g or milli-g.

4. Calibration

The figure above on the left (4a) is showing Calibration with gain and offset, while the figure above on the right (4b) is showing calibration with fixed offset.

$$x_{\text{calibrated}} = Gain * x_{\text{raw}} + Offset \quad \text{(Figure 4a - Linear Calibration)}$$

$$x_{\text{calibrated}} = x_{\text{raw}} + Offset \quad \text{(Figure 4b - Fixed offset Calibration)}$$

Calibration ensures the sensor’s output aligns with reference measurements, correcting for errors introduced by design, materials, or manufacturing.

Types of Errors:

1. Offset error: A constant deviation of the sensor’s output from the true reference value, regardless of input magnitude.

2. Gain error: A proportional error where the sensor’s output scale deviates from the expected value, causing the output to increase or decrease incorrectly relative to the input.

Calibration Methods:

1. 2/3-Point calibration: This type of calibration may involve either applying a fixed offset to the raw value or applying both gain and offset. Figure 4a illustrates an example of a gain/offset calibration, while Figure 4b depicts offset calibration. In both figures, the y-axis represents the reference value measured by an accurate instrument, while the x-axis represents the raw value measured by the sensor after ADC.

2. N-Point calibration: Involves multiple points for more complex, non-linear error correction.

Implementation:

1. Calibration points shall cover the sensor’s entire measurement range for accuracy.

2. Parameters like gain and offset once estimated shall be stored in a non-volatile memory in the system for persistence to be used across power cycles.

5. Data Post-Processing

Post-processing covered in this section talks about removing noise and unwanted signal components, which improves data reliability.

Filtering

Filtering is the process of removing unwanted frequency components from a signal to improve data quality. There are several different types of filters:

• Low-Pass Filters: Allows low-frequency signals to pass while attenuating high-frequency noise.

• High-Pass Filters: Allows high-frequency signals to pass while attenuating low-frequency noise. (for example, gravitational acceleration in accelerometer data).

• Band-Pass Filters: Retains only signals within a specific frequency range, removing both lower and higher frequencies outside the desired band.

These filters are often implemented as FIR (Finite Impulse Response) or IIR (Infinite Impulse Response) filters. IIR filters are easy to implement and computationally efficient while FIR filters are computationally intensive but have better control over the frequency response.

Here, we will explore a simple low-pass filter known as the Exponential Moving Average (EMA), a type of IIR filter. A moving average filter is a mathematical technique that smooths short-term fluctuations while highlighting longer-term trends.

Unlike other moving average filters, EMA does not require maintaining a buffer, making it more memory-efficient. It is also more responsive to data changes while still providing smoothing, making it well-suited for real-time filtering. EMA assigns greater weight to recent data samples than older ones, allowing it to adapt quickly to changes in sensor readings.

EMA can be calculated like this:

$$EMA_{\text{t}} = \alpha * x_{\text{t}} + (1 - \alpha) * EMA_{\text{t - 1}}$$

$$\alpha = 2 / (N + 1) \quad \text{(Smoothening Factor, N - filter window size)}$$

$$EMA_{\text{t}} \quad \text{(Exponential Moving Average in current iteration)}$$

$$x_{\text{t}} \quad \text{(New Data Sample in Current Iteration)}$$

$$EMA_{\text{t - 1}} \quad \text{(Exponential Moving Average in the last iteration)}$$

Now that we understand the Exponential Moving Average (EMA) filter, here are two key factors to consider when tuning it for an application:

• Smoothing vs. Responsiveness: A higher smoothing factor (closer to 1, smaller filter window size) gives more weight to recent data, making the filter more responsive to changes but less effective at noise reduction. A lower smoothing factor (closer to 0, larger filter window size) provides better noise reduction but reacts more slowly to data changes.

• Application-Specific Tuning: The smoothing factor should be chosen based on the sampling rate, sensor sensitivity, and application requirements. Real-time systems often require a balance between quick responsiveness and stable output.

Here’s a code sample for EMA:

#include <stdio.h>
#include <stdint.h>

// Exponential Moving Average (EMA) filter implementation
#define FILTER_WINDOW 5

// Function to calculate EMA
float calculateEMA(float ema, float new_value, float alpha) {
    return (alpha * new_value) + (1 - alpha) * ema;
}

int main() {
    float sensorReadings[] = {26.0, 27.5, 28.2, 27.0, 26.8, 26.5, 27.2};
    int numReadings = sizeof(sensorReadings) / sizeof(sensorReadings[0]);

    float alpha = 2.0f / (FILTER_WINDOW + 1); // Standard EMA formula
    float ema = sensorReadings[0];  // Initialize EMA with the first reading

    printf("EMA Filtered Sensor Data:\n");

    for (int i = 0; i < numReadings; i++) {
        ema = calculateEMA(ema, sensorReadings[i], alpha);
        printf("Reading %d: Raw = %.2f, EMA = %.2f\n", i + 1, sensorReadings[i], ema);
    }

    return 0;
}

Conclusion

In summary, sensors are the backbone of modern smart devices, bridging the gap between the physical world and digital systems. From consumer electronics to industrial automation and medical devices, they enable devices to perceive and interact with their environments.

Understanding how sensors work, the components of their data pipeline, and their integration with microcontrollers is essential for engineers and hobbyists alike. By designing effective pipelines, developers can ensure accurate, clean, and reliable data, enabling systems to meet performance and power efficiency goals.

If you have questions or want to talk more about this topic, feel free to reach out on Twitter or LinkedIn. Always happy to connect.

However, how does it work in deep detail? And how can it connect programs to certain computer hardware?

This article aims to make you understand this connection by deeply explaining how a CPU works. This topic is often familiar only to those with a background in computer hardware design from college.

Often, many computer science graduates never have a class in advanced digital logic. So even very experienced programmers may lack an understanding of how a CPU actually processes information.

Although we won't be designing logic gates from transistors or CPU components from logic gates, we will cover the key concepts needed to understand how a CPU processes data created by a program written in a programming language.

We will see:

• Analogy: Introduction to What Makes CPUs Work
• The Memory Hubs: Understanding RAM and ROM
• The Roadways of Data: Navigating the CPU Data Path
• Traffic Controllers: The Role of State Machines in CPUs
• Daily Routines: The Fetch-Execute Cycle Explained
• The Rulebook: Decoding the Instruction Set Architecture (ISA)
• From programming languages to machine code
• City Challenges: Addressing CPU Problems
• Conclusion: Better control units and data parts

I will use the Intel 8008 as a reference.

Analogy: Introduction to What Makes CPUs Work

To understand deeply how a computer works, let's imagine a city as our real-life scenario. We'll compare computer elements to parts of this city.

This way, you get a clearer view of different CPU parts and why they are important. Afterwards, we will look in depth to each of the components

The Memory Hubs: Understanding RAM and ROM

RAM (Random access memory) is like a city public library: it stores books and information for people to borrow and return as needed.

In a computer, the RAM loads data and instructions from the computer memory needed by the CPU to process data.

ROM (read Only Memory) is like a historical archive in the city: It only stores records that will never change and never be borrowed from the public.

The Roadways of Data: Navigating the CPU Data Path

The CPU data path is the network of roads in the city. The buses and registers of the CPU data path act like the city's road network.

Just as roads help cars and people move, the CPU data path guarantee the data travels in a efficient manner in the CPU

Traffic Controllers: The Role of State Machines in CPUs

States machines act as the traffic control systems.

The traffic control system manages the flow of vehicles, and the states machines manage the flow of data according to the instructions provided to the CPU.

Daily Routines: The Fetch-Execute Cycle Explained

The fetch-execute cycle is the daily commute for city residents.

Every day, people decide where they are going, travel there, perform their tasks and return home. This process is always repeated.

In the same way, the CPU fetches instructions, decodes them, and executes them in a repetitive cycle.

The Rulebook: Decoding the Instruction Set Architecture (ISA)

The instruction set architecture is like the city transportation law.

The city transportation law shows what is legal to do in the city in relation to the transportation of people.

The instruction set architecture is the set of rules and instructions that the CPU can execute.

The Memory Hubs: Understanding RAM and ROM

Photo by Valentine Tanasovich: https://www.pexels.com/photo/black-and-gray-computer-motherboard-2588757/

RAM stands for Random Access Memory and can be used to read and write data.

The CPU gets data from the computer memory to the RAM first to avoid long waiting times.

Then, it uses the data from the RAM to complete the instructions.

They are used in computers and in many electronic devices due to the memory being volatile. It means that the data is only there while the computer is turned on, making it ideal for temporal storage while the device works.

ROM stands for Read Only Memory. In there, there only exist data added during computer manufacturing.

They are widely used in firmware for devices, BIOS and small embedded systems.

This is because ROM is non-volatile memory. This means that it remains in memory when the device is powered off, making it very important for permanent data storage.

The Roadways of Data: Navigating the CPU Data Path

Photo by Rogeer Marques: https://www.pexels.com/photo/close-up-shot-of-a-chip-processor-11272008/

The CPU data path is a complex digital circuit with many components that work with one another, such as:

• Arithmetic Logic Unit (ALU): Performs arithmetic and logical operations inside the CPU data part.
• Registers: Small, fast storage locations for temporary data retrieved from the RAM.
• Buses: Data, control and address buses are wires used inside the CPU data path to transfer information.

While CPUs have changed a lot since the Intel 8008, these are some of the components that still serve as the foundation for all CPUs.

Thanks to them, it is possible to let data flow, but not control the actual flow. This is the job of the control unit in the CPU, created in the Intel 8008 as state machines.

Traffic Controllers: The Role of State Machines in CPUs

A state machine is a system that transitions between different states in order to perform tasks.

They are composed of a number of states and transitions. They were used in the Intel 8008 to create the control unit due to its structure and effective way to manage the sequence of operations needed to process instructions

Each of the states can activate one or many CPU components to process a certain assembly instruction.

This way, certain CPU data path parts are activated for an instruction to be completed.

Additionally, thanks to these state machines, the CPU is complete and can perform all instructions a user wants in a continuous loop called the fetch-execute cycle.

Daily Routines: The Fetch-Execute Cycle Explained

The state machine in the CPU controls how the CPU data path works together to perform a given instruction.

Nowadays, every computer receives millions of instructions per second. This way, the state machines act as a loop to get the instructions and execute them.

This process is known as the fetch-execute cycle, where the CPU retrieves and executes instructions:

• Fetch: The CPU fetches the instruction from memory.
• Decode: The fetched instruction is decoded to determine the required action.
• Execute: The decoded instruction is executed using the appropriate CPU components.
• Write-back: The result of the execution is written back to memory or a register.

In the fetch stage, the control unit tells the RAM to give the next instruction to the CPU.

In the decode stage, the CPU interprets the instruction, and in the execution stage, it performs the operation. Afterwards, the write-back stage ensures the result is stored correctly.

This cycle continues while the PC is on. This way, in modern processors, processing billions of instructions per second.

But What About Data from the Keyboard or Mouse?

This data does not come from RAM but is handled through a mechanism called interrupts. While the CPU runs instructions, it can detect when data comes from peripherals.

If this happens, the CPU stops its current task and prioritizes the instructions from the peripherals. Afterwards, the CPU resumes its previous tasks.

There are many ways to manage interrupts, with some of the most popular being:

1. Polled Interrupts: The CPU periodically checks if an interrupt has occurred.
2. Vectored Interrupts: The interrupting device directs the CPU to the appropriate interrupt service routine.
3. Prioritized Interrupts: Interrupts are assigned different priority levels, ensuring critical tasks are handled first.

This way, with these mechanisms, the CPU maintains its performance while interacting the peripherals.

The Rulebook: Decoding the Instruction Set Architecture (ISA)

With the control unit, the complete CPU and RAM, it is possible to perform many instructions.

But what instructions can be performed on a given CPU? And how many? This is what the Instruction Set Architecture (ISA) solves.

The ISA defines a set of instructions that a certain CPU can execute. It is what allows programmers to understand what a processor can and cannot do without having to understand all the digital logic hardware inside it.

This way, it acts as an interface between software and hardware.

Key Aspects of ISA:

• Instruction Types: Includes arithmetic, logical, control, and data transfer instructions.
• Addressing Modes: Methods for specifying operands of instructions.
• Registers: The set of registers available for use by instructions.

Common ISAs:

• x86: Widely used in desktop and server processors.
• ARM: Dominant in mobile and embedded devices due to its power efficiency.
• RISC-V: An open standard ISA designed for a wide range of applications.

Each CPU often has its own version of the instruction-set architecture. And the instruction set architecture is very often defined with the assembly programming languages.

This is why there are so many versions of the assembly programming language.

Since each CPU has its own hardware specifications, each will have similar components to other CPUs and, thus, similar assembly programming languages associated.

The choice of ISA impacts the CPU's design, performance, and compatibility with software.

For instance, the complexity of x86 allows for powerful desktop applications, while ARM's simplicity favors energy-efficient mobile devices.

From Programming Languages to Machine Code

Photo by luis gomes: https://www.pexels.com/photo/close-up-photo-of-programming-of-codes-546819/

While each processor has its own assembly language, managing code in assembly and writing code in assembly to make big programs can be complex.

It is very complicated, and may lead to wasting time on correcting things and details instead of, in a faster and easier way, managing the development of a program and actually developing it.

To solve this problem, many programming languages were created from assembly. We write the code in the programming languages, and it is then converted to assembly.

This way, instead of spending time on details, it is possible to focus on more important things like system development and algorithm design.

This is the process by which most programming languages convert their code into assembly:

1. Convert the code to assembly code through either a compiler or interpreter.
2. The assembly code is then converted to raw machine code and executed by the CPU.
3. A specific loop in the CPU's state machine is completed.
4. Afterward, the CPU fetches and executes the next instruction.

Let's see two examples of programming languages doing this!

C Programming Language

The C programming language was created from assembly in the early 1970s. It was created to provide a higher-level language for efficient system-level programming that also allows hardware manipulation.

With a compiler, the C code is converted to assembly and then processed by the complete CPU.

Thanks to this conversion, by writing programs in the C programming language, we can address many problems in a more efficient manner, such as:

• Memory management errors
• Buffer overflows
• Manual optimization issues

Nowadays, even for simpler tasks, the assembly code converted from C compiler is far more efficient and reliable than a human writing the assembly code.

If you want to learn more about the C compiler you can check out:

Python Programming Language

The Python programming language was created from C in the late 1980s.

Its goal was to provide a user-friendly, high-level programming language that emphasizes readability and simplicity, allowing for rapid application development.

In Python, an interpreter converts the Python code to bytecode line by line.

And this bytecode is converted to machine code in the CPU and processed in the fetch-execute cycle.

This way, it is possible for people to program in an easier way and focus on bigger programs, such as:

• Artificial intelligence models
• Web apps
• Data analysis
• Scientific computing

However, the challenge with the CPUs in all programming languages is that it processes data sequentially.

City Challenges: Addressing CPU Problems

Photo by Peng LIU: https://www.pexels.com/photo/timelapse-photography-of-vehicle-on-concrete-road-near-in-high-rise-building-during-nighttime-169677/

The traditional one core CPU processes data sequentially, instruction after instruction. This becomes a limitation if we have many instructions to process.

This is what GPUs (Graphics processing units) came to fix. Thanks to GPUs, we can process instructions in parallel, thereby reducing computing time significantly.

With these parallel processing capabilities, it is possible to achieve a much faster computation and improved efficiency in a wide range of applications.

Conclusion: Better Control Units and Data Parts

Photo by Miguel Á. Padriñán: https://www.pexels.com/photo/green-circuit-board-343457/

In addition to modern CPUs being multicore, advancements in control units and data paths play a critical role in improving processor performance.

Control units are often designed using microprogramming or hardwired control units.

Microprogramming offers greater flexibility and easier updates to the control logic, while hardwired control units provide faster performance by directly implementing control signals.

Another significant advancement is the exploration of new materials for transistors in logic gates.

Instead of relying solely on silicon, researchers are investigating alternative materials to create faster and more efficient processors.

As technology continues to advance, understanding these fundamental concepts will remain essential for both enthusiasts and professionals in the field.

Keeping up with these developments ensures the continued innovation and improvement of CPU design and functionality.

We talk about growing up in the European countryside, his early passion for computers, and ultimately his move to San Francisco, where he's founded several tech companies.

Bruno's super excited about embedded systems and custom hardware. He's building home appliances that incorporate open source software and open datasets.

We cover so many topics here. From Star Trek to the European Pirate Party.

I hope these weekly freeCodeCamp podcasts are firing you up about learning more about technology.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

You can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. You can also listen to the podcast below, right in your browser:

A couple interesting links from our discussion:

• "Only Amiga" song from Comdex 1987
• Halt and Catch Fire TV Show trailer

And here are some bonus photos from my time at Bruno's house in NYC:

Bruno at work in his office

A hardware project Bruno had prototyped in his bedroom. (This is the photo that I mentioned during the interview that I had snuck in to snap.)

Why have an on-premise artifact manager? There are many reasons for it:

• Use your private infrastructure: You may have proprietary code that needs to be safeguarded.

• Faster artifact download speeds: If you constantly download the same artifacts over the Internet, you can cache them on a central location, for the benefit of your multiple users across multiple servers by caching them.

• Control what artifacts make it to your build chain: Centralize the location of the artifacts, ensure they are approved for usage, and also confirm than they do not contain malicious code.

• Segregate who can have access to your artifacts: You may have more strict requirements on who can access some artifacts within your own organization.

In this article I will show you how you can download, install, and configure the OSS version of Nexus 3 using an Ansible playbook.

Nexus 3 will run on an Orange PI 5 computer with 8 GB or RAM, but this provisioning can be done on any machine with the minimum requirements. Part of the setup will consist of setting a proxy for PyPI.org, for the machines listed on my inventory file.

What you need to run the code from this tutorial

1. An Internet connection to download the source code for the Ansible playbook, Nexus, and PIP modules

2. Two or more Linux machines (I used Debian, Armbian and Fedora IOT), with at least 8 GB of RAM. My cluster has a mix of Raspberry PI 4 and an OrangePI 5.

3. Ansible controller will run on the Fedora machine, but any server can be the controller. Installation instructions for Ansible are easy to follow.

Playbook Organization

I divided the tasks in groups and the resulting playbook looks like this:

[josevnz@dmaf5 Nexus3OnOrangePI]$ tree -N ansible/
ansible/
├── inventories
│   └── home
│       └── hosts.yaml
├── roles
│   ├── clients
│   │   ├── tasks
│   │   │   └── main.yaml
│   │   └── templates
│   │       └── pip.conf.j2
│   └── nexus
│       ├── files
│       │   └── swagger.json
│       ├── tasks
│       │   ├── download.yaml
│       │   ├── install.yaml
│       │   ├── main.yaml
│       │   ├── post_install.yaml
│       │   ├── pre_install.yaml
│       │   ├── repositories.yaml
│       │   ├── third_party.yaml
│       │   └── user.yaml
│       └── templates
│           ├── logrotate.nexus3.j2
│           ├── nexus3.service.j2
│           ├── nexus.rc.j2
│           └── nexus.vmoptions.j2
├── site.yaml
├── vars
│   ├── clients.yaml
│   └── nexus.yaml
└── vault
    ├── nexus_password.enc
    └── README.md

13 directories, 21 files

Now a little bit of explaining:

• There are two roles: ‘nexus’ and ‘clients’. The nexus role is used to setup the artifact management software, while the client role sets up the pip settings on every machine.

• Vars contains variables used on each role, separated by files to make their usage more clear

• We have passwords, and we managed them using Ansible vault feature.

• The file ‘site.yaml’ Orchestrates the role execution:

- hosts: all
  tags: clients
  vars_files:
    - vars/clients.yaml
  roles:
    - clients
- hosts: nexus_server
  tags: nexus
  become_user: root
  become: true
  vars_files:
    - vars/nexus.yaml
  roles:
    - nexus

Now let’s move on to see the universe where the playbook will be executed.

The Host Inventory

In my case it is quite simple – I have two main groups: ‘clients’ and the machine where the Nexus 3 server itself will run:

all:
  children:
    nexus_server:
      hosts:
        orangepi5.home:
    home_lab:
      hosts:
        dmaf5.home:
        raspberrypi.home:
        orangepi5.home:

The next important task is to download and configure Nexus 3.

How to Install Nexus 3

The file main.yaml describes the order and purpose of each installation task for the Nexus role:

# Tasks listed here are related to the remote Nexus 3 server
# Included tasks are called in order
---
  - include_tasks: third_party.yaml
  - include_tasks: pre_install.yaml
  - include_tasks: download.yaml
  - include_tasks: install.yaml
  - include_tasks: post_install.yaml
  - include_tasks: user.yaml
  - include_tasks: repositories.yaml

Let’s see first what I like to call the “core tasks”:

1. third_party.yaml: In here we install the OpenJDK8 (Nexus 3 is written in Java) and logrotate to take care of the stale logs.

2. pre_install.yaml: A lot happens here, like creating required directories for nexus, dedicated non-privileged user that will run the process.

3. download.yaml: As the name says, we get a fresh version of the Nexus 3 OSS software and make sure it has the right checksum. We don’t want to install malware from the Internet.

Then come the tasks that fall into the “customized installation group”:

1. install.yaml: Unpack the software, prepare the systemd unit to start it automatically, setup JVM settings for Nexus, and deploy the logrotate configuration.

2. post_install.yaml: Exciting stuff happens here – the software is installed, and we run it for the first time. We also change the default password using the REST API, so we can move to the customization stage.

3. user.yaml: Here we prepare to provide our end users with proper access to the services offered by Nexus. We do this using a combination of the REST-API and Ansible client code:

# https://help.sonatype.com/repomanager3/installation-and-upgrades/post-install-checklist
# https://help.sonatype.com/repomanager3/integrations/rest-and-integration-api
---
- name: Enable anonymous user
  tags: anonymous
  ansible.builtin.uri:
    user: ""
    password: ""
    url: "/v1/security/anonymous"
    method: PUT
    body_format: raw
    status_code: [ 200, 202, 204 ]
    headers:
      Content-Type: application/json
    body: |-
      { "enabled" : true, "userId" : "anonymous", "realmName" : "NexusAuthorizingRealm" }
    force_basic_auth: true
    return_content: true
  any_errors_fatal: true
- name: Enable Docker security realm
  tags: docker_realm
  ansible.builtin.uri:
    user: ""
    password: ""
    url: "/v1/security/realms/active"
    method: PUT
    body_format: raw
    status_code: [ 200, 202, 204 ]
    headers:
      Content-Type: application/json
    body: |-
      [ "NexusAuthenticatingRealm", "NexusAuthorizingRealm", "DockerToken" ]
    force_basic_auth: true
    return_content: true
  any_errors_fatal: true

The logic is easy to follow, by using the ‘PUT’ http method you can tell is a modification operation (meaning existing roles and users already exist). Error detection is done by getting the HTTP codes returned by Nexus.

Next step is to prepare our local PyPi proxy. This is a multistep task and will be described in detail next.

How to Set Up PyPI Proxy on Nexus 3

The last file on the Nexus 3 role is ‘repositories.yaml’. In here we go through the following steps:

1. Check if the proxy was already setup (GET or read only operation)

2. If it doesn’t exist, create a new one (POST method with JSON payload with details to create whole new repository)

Notice than this playbook doesn’t offer the option to update repository settings. It is possible to do with the REST API, but I will leave that as an exercise to the reader.

The tasks to prepare the PyPi proxy are shown below:

# Create proxy for repositories
# https://help.sonatype.com/repomanager3/integrations/rest-and-integration-api
# PyPi: https://pip.pypa.io/en/stable/user_guide/
---
- name: Check if the PyPi proxy exists
  tags: pypi_proxy_exists
  ansible.builtin.uri:
    user: ""
    password: ""
    url: "/v1/repositories/pypi/proxy/python_proxy"
    method: GET
    body_format: raw
    status_code: [ 200, 202, 204, 404 ]
    headers:
      Content-Type: application/json
    force_basic_auth: true
    return_content: true
  any_errors_fatal: true
  register: python_local
- name: Create PyPI proxy
  tags: pypi_proxy_create
  ansible.builtin.uri:
    user: ""
    password: ""
    url: "/v1/repositories/pypi/proxy"
    method: POST
    body_format: raw
    status_code: [ 201 ]
    headers:
      Content-Type: application/json
    body: |-
      {
        "name": "python_proxy",
        "online": true,
        "storage": {
          "blobStoreName": "default",
          "strictContentTypeValidation": true
        },
        "proxy": {
          "remoteUrl": "https://pypi.org/",
          "contentMaxAge": -1,
          "metadataMaxAge": 1440
        },
        "negativeCache": {
          "enabled": true,
          "timeToLive": 1440
        },
        "httpClient": {
          "blocked": false,
          "autoBlock": true,
          "connection": {
            "retries": 0,
            "timeout": 60,
            "enableCircularRedirects": false,
            "enableCookies": true,
            "useTrustStore": false
          }
        }
      }
    force_basic_auth: true
    return_content: true
  any_errors_fatal: true
  when: python_local.status == 404

We are almost there. Now we need to tell our PyPi clients than we should use our local Nexus and not the direct PyPi site to get our Python libraries.

How to Set the Clients

The clients role is much simpler and only requires deploying a template for pip.conf with enough information to force the search on our new repository:

# Tasks here are meant to be used on our clients user
---
- name: Create installation directory for pip.conf
  tags: pip_basedir
  ansible.builtin.file:
    state: directory
    path: ""
    owner: ""
    group: ""
    mode: "u+rwx,go-rwx"
- name: Copy pip.conf file
  tags: pip_copy
  ansible.builtin.template:
    src: pip.conf.j2
    dest: "/pip.conf"
    owner: ""
    group: ""
    mode: u=rxw,g=r,o=r

The resulting file gets deployed on ‘~/.config/pip/pip.conf’ of every machine:

# https://pip.pypa.io/en/stable/topics/configuration/
[global]
timeout = 60
[install]
index = http://orangepi5.home:8081/repository/python_proxy/pypi
index-url = http://orangepi5.home:8081/repository/python_proxy/simple/
trusted-host = orangepi5.home

The file above shows an example of how the final version of the file will look once deployed on my cluster (yours will be different with the resolved URL).

It is time now to run the whole playbook and see what it looks like.

How to Run the Playbook

To run the playbook, we pass a few arguments:

1. The location of our host inventory

2. The location of the encrypted password file and a master file containing the master password to unlock the contents of the protected file

3. And finally the location of our main playbook file

cd ansible
ansible-playbook --inventory  inventories --extra-vars @vault/nexus_password.enc --vault-password-file $HOME/vault/ansible_vault_pass site.yaml

How to test the new PyPI proxy

To test our new proxy, we will install Python Rich using pip and a virtual environment.

josevnz@orangepi5:~$ python3 -m venv ~/virtualenv/rich
(rich) josevnz@orangepi5:~$ . ~/virtualenv/rich/bin/activate
(rich) josevnz@orangepi5:~$ pip install rich
Looking in indexes: http://orangepi5.home:8081/repository/python_proxy/simple/
Collecting rich
  Downloading http://orangepi5.home:8081/repository/python_proxy/packages/rich/13.3.4/rich-13.3.4-py3-none-any.whl (238 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 238.7/238.7 KB 14.8 MB/s eta 0:00:00
Collecting pygments<3.0.0,>=2.13.0
  Downloading http://orangepi5.home:8081/repository/python_proxy/packages/pygments/2.15.0/Pygments-2.15.0-py3-none-any.whl (1.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 23.8 MB/s eta 0:00:00
Collecting markdown-it-py<3.0.0,>=2.2.0
  Downloading http://orangepi5.home:8081/repository/python_proxy/packages/markdown-it-py/2.2.0/markdown_it_py-2.2.0-py3-none-any.whl (84 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 84.5/84.5 KB 6.9 MB/s eta 0:00:00
Collecting mdurl~=0.1
  Downloading http://orangepi5.home:8081/repository/python_proxy/packages/mdurl/0.1.2/mdurl-0.1.2-py3-none-any.whl (10.0 kB)
Installing collected packages: pygments, mdurl, markdown-it-py, rich
Successfully installed markdown-it-py-2.2.0 mdurl-0.1.2 pygments-2.15.0 rich-13.3.4

And then we can confirm than the cache was indeed used by seeing the new artifacts on the new repository:

See the PyPi artifacts

Let’s see a demo of the client in action, installing something else:

Further Customization Using the REST-API

Every Nexus installation allows you to download a JSON file that describes the API supported by the server. For example, in my server you can get a copy like this from my orangepi5.home server:

curl --fail --remote-name http://orangepi5.home:8081/service/rest/swagger.json

Also, the UI allows you to try the other REST API endpoints to customize your installation.

REST API testing

Conclusion

I recommend spending some time and reading the Nexus 3 book to get yourself familiar with the features this tool can offer.

The community prepared Debian and RPM installers, if you need this kind of setup as opposed to using Ansible.

Nexus 3 has lots of configurable settings. We covered only the surface here. While preparing this article I found 'ThoTeam Nexus3-oss repository' with a very complete and up-to-date playbook, but it was way more complex than anything I required for my home lab.

Archiva is another Open Source artifact manager, it is more limited in functionality but also simpler to setup.

There is a post-installation checklist with some tasks I did not need to complete for my home lab. Please check it out to make sure your setup is complete.

Random Access Memory (RAM) is a crucial component of any computer system, and it is responsible for temporarily storing data that is required by the system to carry out its functions. But the contents of RAM can be quite volatile, and they are usually lost when the system is shut down.

One way to preserve the contents of RAM is by performing a RAM dump, which is a process of copying the contents of RAM onto a storage device, such as a hard drive. You can analyze the RAM dump, and the data contained within it can provide valuable insights into the system's state at the time the dump was taken.

In this article, I will walk you through the process of reading the contents of RAM, as well as explain what a RAM dump is and how it can be useful in analyzing a computer system. I will also provide you with step-by-step instructions on how to perform a RAM dump and how to analyze the resulting data.

Why Read RAM Data?

Reading data from the disc is something you might be familiar with doing. But can we also read data straight from the RAM, where the most essential information is stored?

As developers, we can investigate the space complexity and delve further into the RAM to understand what is going on.

Accessing and reading the contents of RAM can be useful in a variety of scenarios. One common use case is for troubleshooting and diagnosing issues with a computer system. By examining the contents of RAM, you can gain insights into the state of the system at a particular point in time.

For example, if your computer suddenly crashes, examining the contents of RAM can help you identify the cause of the crash.

Another use case is for forensic analysis. When investigating a computer system for evidence of wrongdoing, examining the contents of RAM can provide valuable insights into the activities that were being carried out on the system.

For example, a security professional may use RAM analysis to determine whether a particular process was running on the system or to identify files that were recently accessed.

In addition, accessing and reading the contents of RAM can also be useful for software developers and researchers. By analyzing the data stored in RAM, developers can gain insights into the performance of their software and identify potential issues or bottlenecks. Researchers can also use RAM analysis to study the behavior of malware or to develop new security tools and techniques.

Overall, accessing and reading the contents of RAM can be useful for troubleshooting, forensic analysis, software development, and research. It provides a valuable way to gain insights into the inner workings of a computer system and can help identify issues and potential security threats.

Before we move further into the specifics, let's take a short look at the nomenclature. This may be common knowledge, but you'll need to understand the terminology as you go through this guide, so it's worth a review.

What is RAM?

There's a physical hardware device called RAM (which stands for Random Access Memory): the physical memory, a CPU, a hard disk, and other physical components.

On top of this, we have the operating system. The operating system is always in conversation with the piece of hardware known as the "kernel" – and this is one of the most critical aspects of this software.

If we consider things from the user's point of view, we initially log in to the operating system so that we can carry out our tasks, the majority of which include executing applications.

What is the Kernel?

A kernel is a fundamental portion of an operating system that accepts the instructions from the user with the aid of the program we run behind the scenes. This may happen regardless of the program that we run behind the scenes.

Everything that has to be computed is handled by the central processing unit (CPU), but whatever we do and however we manage the services provided by the CPU, the data, instructions, code, and program must all go via the random access memory (RAM).

This implies that the results of anything we do with the data at any given moment in time will be available on top of the memory. If you are a programmer and you're constructing some kind of data structure, this indicates that all of the data will live on top of the RAM.

We can directly go to the RAM and see how the data structures have been created and how they align, and we can see how the space complexity works there.

For instance, if we are discussing any web browser, such as Chrome, there may have been security flaws generated in an application. So the most effective method is to navigate to the RAM and investigate how the data has been operating.

Let's say you open any secure website in Chrome (or any browser), like gmail.com. Any information you enter into Gmail, including your username and password, is sent over the internet to a server run by Google. That data has been fully encrypted, and it will be challenging, if not impossible, to crack the password.

But in order to enter your password, you likely use a computer with a keyboard attached to it. After that, some programs will encrypt the data and send it to the internet. This means that initially, your data was present in the RAM.

First, the password is standard data, and the password goes and lands on the top of the RAM. Then, some programs will encrypt the data and send it to the internet. If you can access the RAM, you can examine it to determine whether or not your password has been encrypted. And this process is pretty straightforward.

Let's look at an example to see how this works. We'll pretend that "a" is a variable and "9" is the data. When we execute the program, this data loads onto the RAM. When the program ends, the data from the RAM will be gone, although nobody has proven it yet. But this is the case, and we can prove it with a little investigation.

So how can we check whether or not this data is still present in the RAM after the application has finished running if it was loaded at the very top of the memory?

Well, the RAM will be cleared of these contents shortly. A "RAM dump" is the process of capturing all of the RAM. This demonstrates the actual form in which the entire data set is made accessible and loaded onto the RAM for the first time. And you'll learn how to capture or extract the data from memory next.

In order to accomplish this, you'll need some form of software. As a result, the goal of this program is to travel further into the memory. It will go into memory and retrieve all of the stored data from memory before continuing.

What is LiME?

The Linux memory extractor, sometimes referred to as LiME, is a powerful piece of software. It's what you use to extract the memory from Linux. This piece of software is also known as the driver, also referred to as the module. This is because RAM is a device, which complicates things further.

We need some form of driver to access the device so we can try to read the contents of it. LiME is an example of a driver, and if you're familiar with Linux you may know that in order to make any driver function, you need to load that driver with the assistance of the kernel.

Within the context of Linux, a driver is also referred to as a module. So LiME is a Linux kernel module. We have access to what is known as a kernel loadable module, which allows us to install the module on the operating system.

We have covered enough background. Now, let's look at how we can extract the contents of the RAM. We'll go through the process step-by-step in a hands-on way.

Setup and Installations

So, the only thing we need is the LiME driver. Here's the link to download this particular module: https://github.com/gursimarsm/LiME.

Now, boot up your Linux system (I use RedHat Enterprise Linux). You can use the free -h command to check the amount of RAM memory that's being used, that's available, and other details. Mine looks like this:

Output from running the free -m command

To access RAM, we need some software where the kernel can load some extra modules. In our case, the module name is LiME. So, the software we install are called “kernel-devel”, and “kernel-headers”. These two pieces of software are what we need to install in order to perform our subsequent actions, that is to use the LiME module.

If you want to install the software, you should have "yum" configured. For context, yum is a command you can use to install the software in the RedHat Linux operating system. I'll demo how to configure it in the appendix for reference.

Installation

So, now that you've installed that software, you need one more piece of software because you have to download some drivers from GitHub. So, now you need to install Git if you don't already have it. You can do this using the command yum install git. You also need to configure your account so that you can work with it.

# git config --global user.name "Your Name" 

# git config --global user.email "you@example.com"

I shared the repository above. It's a loadable kernel module (LKM). It lets you acquire the entire memory from your Linux operating system or any kind of language operating system (including Android devices because Android is based on Linux as well).

You can download the module using the **# g**it clone**** [**https://github.com/gursimar**sm**/LiME**](https://github.com/gursimarsm/LiME) command.

After downloading that, you need to move into the directory of the software. You'll find multiple folders there. But, to run the main code, you need to move to the "src" directory.

In this directory, you'll find multiple programs based on the C language. So, in order to make use of the files, you'll need to compile them. To do that, you can use the make command. Install that like this:

# yum install make 

# yum install gcc

In the directory /LiME/src/, run the make command to compile the entire code.

If you encounter an error, it might be because we are using the latest version of LiME, and it comes with a new feature called orc metadata generate. To implement this feature, you have to install one more thing that's part of LiME called elfutils-libelf-devel. You can do that using yum like you can see below:

How to install elfutils-libelf-devel

After that's done, if we now run the make command it will ask the GCC compiler to compile the entire code. After the compilation, it will create one final object file called the kernel object file, and that is the final module in LiME.

Output

You can find this file in the same directory by using the ls command.

How to Use the Module

With this module, the kernel now has the capability to capture or read the entire RAM. By default, we can't read the entire RAM in one go, but now because of the LiME module, we can.

To learn more about the LiME module, you can use the modinfo command. Type modinfo along with lime. This will show you some more details like where the file is available, and it also displays all the modules or drivers that come with some kind of extra parameters. Every parameter has some benefits.

modinfo

Here we are going to use two parameters which are very important: path and format.

path means when we read the entire RAM, we have to store the data of the RAM in some file. So, to specify the destination file we would like to create, we have to give that particular information over here.

The next parameter, format, specifies the format in which we want to read the RAM data. So, in this case, we want to read the format of the RAM as it is. The data stored in the RAM is mostly in binary, and we want to read the entire data in that binary format only and capture it in its raw form.

So, the format will be raw and stored in the file wherever we give the path.

Finally, it's time to read the data from the RAM. So, let's come to the main command that will help us start reading the entire RAM.

Demonstration

Type in your password for your Gmail account in Chrome for this demonstration. This will help you learn how to capture the data from the RAM and also if your password is encrypted.

To verify these two things, move to the command prompt and check if the data is still on the RAM. You'll have to load a particular module using the command insmod. This will help you insert the module.

Copy the complete path of the module and paste it along with the insmod command.

insmod command

This module will get loaded with the help of the kernel. The module will start capturing the entire data from the RAM and it'll store it in a file, for example, myram.data

It will also load the entire memory dump or RAM dump into this file and which format we want to capture. So, the format will be the raw format.

We'll use these two parameters (don't worry about this for now). We need only two parameters to perform, and now as soon as we hit this command, whatever data we have will be captured and stored in this particular file. This command typically takes a few seconds, depending on the CPU speed and the amount of data we have in the RAM.

Command

How to read the data

Now, we have this file myram.data and the entire data of the RAM is stored in this file. Because we captured this data in the raw format, the data is going to be in binary. If we try to read this data from this file directly, as human beings, we can't read it even if we try it with the initial lines using the head command to read some of the top 10 lines.

Output

So, we can use the “cat” command, which will read the entire data. But, again, the same thing is going to happen – it will read the entire data, but the data will be displayed in the binary format. Then we need to use the pipe function with this command and combine it with another new command called strings:

Command

String is a command that will convert the data into regular text in a human-readable format.

Output

The list will go on and on. You can interrupt it using Ctl+C.

Right now, it won't mean much seeing and reading the entire data. We know some data that are there on the RAM is the password called mywebpasswordgmail. So, just to confirm that this data is available on the RAM we can use one more pipe along with the grep command. The grep command helps us sort the data.

cat /myram.data | strings | grep mywebpasswordgmail

Now, we are searching for this string in the entire data. It will convert the data into regular text, and wherever that particular string shows up, grep will grab that line and let us start searching, then show us this data.

So, as you can see from this simple example, whatever you type on your keyboard can also go into the RAM – even if it's your password or any kind of secure site you are surfing, your data is there on the RAM. It doesn't matter what program you run. If you type using the keyboard everything will load on the RAM and can be extracted. This is called the memory dump.

LiME provides us with many other powerful capabilities. Right now, we are capturing the data directly from the system where we perform the actions. But we can also run LiME on the system and it can capture the data in real-time and send the data over the network to another computer.

What does this mean? Think of it this way: for example, somebody opens a website and they're typing something in real-time. This entire message is being transmitted in real-time to another computer.

We're not talking about key loggers, we are just talking about the RAM. Whatever is happening when any program is running, the database is storing some data. Programs are reading data from other parts of the hard disk. And whatever is happening on the RAM can be captured in real-time by the system and sent over the network to other computers.

Conclusion

We’ve finally come to the end of this article. I hope you've enjoyed it and have learned something new.

I’m always open to suggestions and discussions on LinkedIn. Hit me up with direct messages.

If you’ve enjoyed my writing and want to keep me motivated, consider leaving starts on GitHub and endorse me for relevant skills on LinkedIn.

Till the next one, stay safe and keep learning.

In fact, it is thanks to firmware that:

• Printers work
• Defibrillators work
• Car radios works
• and more …

Based on the examples above, you probably already have some idea of what firmware is. But you don't have a clear definition of it.

In order to truly understand what firmware is, we must first understand software, then hardware, and finally we can jump into firmware.

In this tutorial, I'll explain each topic with an analogy. By doing so, everyone can understand.

It doesn't matter if you're just getting into technology!

With that, I would like to make sure that everyone understands what software, hardware, and firmware is. I will not elaborate on the technical terms.

In this article we will explore:

• What exactly is software?
• What exactly is hardware?
• What exactly is firmware?

What is Software?

_Photo by [Pexels](https://www.pexels.com/@kubra-dogu-80605500?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" rel="noopener">Kübra Doğu from <a href="https://www.pexels.com/photo/food-wood-dawn-coffee-9222655/?utm_content=attributionCopyText&utm_medium=referral&utmsource=pexels" rel="noopener)

Imagine, if you will, that you have no idea what to make for dinner today.

Luckily, you find an old cookbook you have and decide to cook one of the recipes in it.

The cookbook has many recipes. Each of these recipes has its own instructions.

In the cookbook, a recipe can be seen as a set of steps (or instructions) that together make a meal.

Photo by Luis Quintero on Pexels

You can also create your own meals based on your experience in cooking many different recipes, right?

Software is no different.

Software programs can be seen as a set of instructions that work together to form a program.

 global  _main
    extern  _printf

    section .text
_main:
    push    message
    call    _printf
    add     esp, 4
    ret
message:
    db  'Hello, World', 10, 0

Then, applications are a big sets of instructions that perform specific tasks.

Operating systems are big sets of instructions that coordinate software and hardware resources.

• Cookbook = software
• Dinner cookbook = type of software (application or operating system)
• Recipe = program

You need a recipe to make dinner. You must follow each step in the cookbook to create a recipe.

Once you have completed all the steps, your dinner is ready.

You need software to accomplish a particular task. A computer has to follow all instructions for the software to function.

Therefore, the software is running either while the instructions are being followed or after they have been completed.

What is Hardware?

_Photo by [Pexels](https://www.pexels.com/@elevate?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" rel="noopener">ELEVATE from <a href="https://www.pexels.com/photo/chef-preparing-vegetable-dish-on-tree-slab-1267320/?utm_content=attributionCopyText&utm_medium=referral&utmsource=pexels" rel="noopener)

In order to make dinner, you need a series of steps from the cookbook that tell you how to make a particular meal.

You also need various tools to cook with - like pots and pans, knives, and the food itself. This is like hardware.

So a cookbook gives you instructions that allow you to cook.

For hardware to work, it needs software (a set of instructions) to tell it what to do.

Software then, gives instructions to hardware that lets it work.

• Meal prep tools = hardware
• Recipe = software

Without software, you can't make hardware work.

Without a recipe, you won't know what to do with your various tools and ingredients to make a meal.

Like hardware without software, you can also eat a meal with just uncooked food. Gross.

In the same way that there are various types of meals, there are also various types of computer hardware.

For example:

• CPU
• RAM
• GPU
• and so much more…

Comparison of processes

What is Firmware?

_Photo by [Pexels](https://www.pexels.com/@ella-olsson-572949?utm_content=attributionCopyText&utm_medium=referral&utm_source=pexels" rel="noopener">Ella Olsson from <a href="https://www.pexels.com/photo/close-up-photo-of-chocolate-mousse-3026810/?utm_content=attributionCopyText&utm_medium=referral&utmsource=pexels" rel="noopener)

A program is a set of instructions read by a computer.

Let's say you just want to make a snack or dessert. You probably don't need as many ingredients as when making a dinner for your family, right?

Let's say you want software that runs on a microwave. You don't need all the hardware the computer has to make the microwave work, right? You just need that specific to making the microwave work.

Or say you want software running on a printer. You don't need all the hardware the computer has to make the printer work right? Just the software for the printer.

• Microwave software = firmware
• Printers software = firmware

So this means that firmware is nothing more than software, but in a hardware device. Not in a computer.

Firmware lets very specific hardware complete very specific tasks.

Wrapping up

Thanks for reading! Now you know more about:

• Software
• Hardware
• Firmware

Microprocessor photo by Pok Rie from Pexels

The non-volatile nature of hard drives means they don’t lose data, even if power is lost. Due to this, they help computers store files and other data for a long time – as long as they don’t get damaged or corrupted.

Since the first release of hard drives by IBM in 1956, hard drives have evolved from being the size of a refrigerator and having a storage capacity of just 5MB to ones that are pocket-sized and have up to 4 TB of storage capacity.

In this article, I will cover the different types of hard drives so you can choose the best for your computer.

But firstly, let's look at interfaces – the connecting part between the computer and the hard drive.

Types of Interfaces

• Parallel Advanced Technology Attachment (PATA)
• Serial Advanced Technology Attachment (SATA)
• Small Computer System Interface (SCSI)
• NVMe (Non-volatile Memory Express)

These names come from the way they connect to the computer. So, there are PATA hard drives, SATA hard drives, SCSI hard drives, and NVMe drives.

In this article, I’m now going to elaborate on each of these interfaces and types of hard drives as concisely as possible.

Parallel Advanced Technology Attachment (PATA)

The PATA interfaces were first introduced to the market by Compaq and Western Digital in 1986. They can have up to 80GB capacity and transfer data as fast as 133 MB/S.

They were named Parallel Advanced Technology Attachment because they use a parallel ATA interface to connect to the computer. Apart from PATA, they are also called Integrated Drive Electronics (IDE) and Enhanced Integrated Drive Electronics (EIDE).

PATA interfaces are made of mechanical moving parts and are based on parallel signaling technology – meaning they transmit multiple bits of data simultaneously.

Serial Advanced Technology Attachment (SATA)

In recent times, a lot of desktop and laptop computers have gotten SATA interfaces because they have superseded PATA interfaces in size, power consumption, and even better pricing.

The mode of connection to a computer remains the same as PATA, but instead of parallel signaling technology for data transmission, they use serial signaling technology. This means that they transfer data one bit at a time.

A notable advantage SATA interfaces have over PATA interfaces is the transmission of data at a rate of 150 – 300 MB/S. In addition, they have thinner cables and a cable limit of 1 meter.

Small Computer System Interface (SCSI)

SCSI interface is an upgrade over SATA and PATA interfaces for many reasons such as round-the-clock operations, speed, storage, and several others.

For connection, SCSI hard drives use a small computer system interface – which is a standard for connecting peripheral devices such as printers, scanners, and others.

Best of all, they allow the connection of peripheral devices such as printers, scanners, and other hard drives. In addition, they transmit data at 320 MB/S and you can connect them internally or externally.

Connections through SCSI on personal computers have now been replaced by the Universal Serial BUS (USB). This means that SCSI is no longer used as consumer hardware.

NVMe (Non-volatile Memory Express)

NVMe interface is a revolution. It is built for high demanding and computing-intensive tasks So, it is an upgrade over the interfaces already discussed.

Because of its high performance and scalability, you'll find it mostly in data centers and newer computers. There are now SSDs using the NVMe interface.

Its many advantages over other interfaces are:

• lower power consumption
• multiple command queues
• reduced latency and input/output overhead – leading to better performance
• utilization of CPU to full potential

One of the disadvantages of NVMe interfaces is that they're more expensive than other interfaces.

Types of Hard Drives

Currently, there are two common types of hard drive:

• Hard Disk Drive (HDD)
• Solid State Drive (SSD)

A hard drive utilizes any of the interfaces such as PATA, SATA, SCSI. Today, there are SSDs that utilize the NVMe interface.

Let's look at the two types of hard drives in detail.

Hard Disk Drive (HDD)

Hard disk drives are not that new and you will find them installed in older computers. They consist of a moving part that rotates during reading and writing operations, so they usually make noise.

These days, you may not see many newer desktop and laptop computers with hard disk drives, but they remain popular because of their storage space. 16 GB, 32 GB, and 64 GB are the lowest you can find out there. There are 500 GB, 1 TB, 2TB, and more than 4 TB hard drives.

This enormous storage space is the reason hard disk drives may go nowhere any time soon. There are even external hard disk drives you can use to backup your files.

Solid State Drive (SSD)

SSD hard drives are one of the latest hard drive technologies at the time of writing this article. Most newer computers have SSDs instead of HDDs.

Unlike the hard drive technologies before SSD drives, they don’t consist of moving parts and they don’t use magnetism for storing data. So, they don't make noise like hard disk drives (HDDs).

Instead, they use integrated circuits (ICs) just like third-generation computers. This makes them more durable, faster, and less prone to damage and corruption.

SSD hard drives have a notable advantage of transferring data at speed of 550 MB/S and allow faster boot times than the types of hard drives before them.

Solid state drives also have enormous sizes, but they are very expensive when compared to hard disk drives.

Conclusion

This article explained what different types of hard drives are and how they work, so you can learn more about hard drives and choose the best one for your needs.

From PATA to SATA, SCSI and NVMe, hard drive interfaces continue to evolve and research to make better ones is ongoing.

There is a new variation of SSD hard drives called NVMe (Non-volatile Memory Express) SSDs that has the capacity to transfer data as fast as 3.5 GB/S. This makes them the best choice for video editing and high-resolution gaming, though they require more power than the actual SSDs.

Thank you for reading.

If you find this article helpful, don’t hesitate to share it with your friends and family.

Like USB flash drives, SSDs use flash memory to store data. This type of storage means that SSDs are very fast, silent, and resistant to shock.

While SSDs have come down in price, they are still much more expensive and often have lower capacities than HDDs (hard disk drives).

SSDs are often inside a computer attached to the motherboard. But there are some external SSDs that connect to the computer with a USB cable.

SSDs are a non-volatile type of storage. This means that, unlike RAM, SSDs will retain any data that's written to them, even after the computer is shut down.

Related Tech Terms:

• HDD Solid State Drive Definition
• RAM Definition
• PRAM Definition

HDDs consist of one or more magnetic platters sealed in an air-tight casing to protect it from dust. There is a magnetic head attached to an arm that moves across the rotating platter and writes data to it. The same magnetic head can also read data that was written to the disk.

HDDs are often inside a computer attached to the motherboard, or in an external case connected by a USB cable.

While HDDs are much slower than modern SSDs (solid state drives), they can have higher capacities, and are often cheaper. Because storage is cheaper for HDDs, they are often used to store data that isn't used often, or as long term backup.

HDDs are a non-volatile type of storage. This means that, unlike RAM, HDDs will retain any data that's written to them, even after you shut down the computer.

Related Tech Terms:

• SSD Solid State Drive Definition
• RAM Definition
• PRAM Definition

RAM stores important information that the computer needs to access often so that everything runs smoothly. All modern computers and phones need some amount of RAM to function.

Though computers and other devices have other forms of storage like an HDD (hard disk drive) or SSD (solid state drive), RAM is much faster. In fact, RAM is about 30 times faster than modern SSDs.

While RAM is very fast, it is a type of volatile memory. This means that it only stores information while the computer is on. Unlike an HDD or SSD, once you shut down your computer, everything stored in RAM is lost.

Related Tech Terms:

• PRAM Definition
• HDD Hard Disk Drive Definition
• SSD Solid State Drive Definition

Modern Mac computers don't use PRAM. Instead, they use NVRAM, or non-volatile random access memory.

But PRAM and NVRAM serve the same function. They both store some important information about your system like the startup disk, timezone, and so on.

If you're having some issues with your Mac computer, you may want to reset the PRAM / NVRAM. Here's how to do that:

1. Shut down your Mac computer
2. Turn on the computer, and immediately hold down these keys: Option + Command + P + R
3. Hold down the keys until you hear the startup sound after about 20 seconds

Here's a video that goes over how to reset the PRAM / NVRAM and SMC (system management controller):

Related Tech Terms:

• Macintosh Definition
• RAM Definition

Like a human brain, the CPU controls all the functions of the computer.

The CPU's job is to listen for input data from devices like a mouse or other software. Then it looks up instructions for that data, and executes those instructions.

For example, if you type the character "a" on your computer, your CPU will look up how to handle your button press. Once it receives instructions back, it executes your button press, and sends out the output "a".

Modern CPUs can handle billions, or even trillions of these instructions per second.

CPUs are made up of tens of thousands of tiny rods called transistors. Each transistor has either an on (yes) or off (no) state, and form the basis of binary that all computers work with.

With enough transistors asking these simple yes/no questions, the CPU can perform complex tasks.

Modern CPUs are often made up of different cores that make it easier to multitask. Each core is just another CPU on the same chip.

For example, a dual-core CPU has two CPUs on the same chip. These days there are quad-core (4), hexa-core (6), or even hexadeca-core (16) CPUs.

Modern CPUs can also use a process called multi-threading or hyper-threading to be more efficient. This is the process of splitting a CPU up into virtual cores called threads.

For example, if you have a dual-core processor, you might see four cores if you check your computer's system monitor.

These physical cores and virtual cores / threads can make your computer much faster in some cases.

Games usually work better on a single, powerful core. But other programs like video editing software is much faster with more cores and threads.

Check out this video for a high-level overview of how the CPU handles all the inputs and outputs for your computer:

Related Tech Terms:

• Hardware Definition
• Operating System Definition
• Boolean Definition

LCD is a generic term for this type of display, which can come in the form of TVs or computer monitors.

LCDs work by using a combination of a backlight, polarizers, liquid crystals, and color filters. By adjusting the amount of electricity the goes to the liquid crystals, the LCD can control the color of each pixel.

Here's a video that breaks down this process:

Related Tech Terms:

• Hardware Definition

Things like the CPU (central processing unit), RAM (random access memory), motherboard, and case are all considered hardware. Computer hardware can also include things that are not required for the computer to function, like a monitor and mouse.

The term hardware is often contrasted with software.

Software refers to collections of instructions and/or data that run on hardware. Software is "soft" in the sense that it can be rewritten.

Computer hardware is "hard" because it's physical, and is difficult to change once it's been produced.

Related Tech Terms:

• Software Definition
• LCD Definition