Project 3.12 Section 3 ⚡ Embedded Relevance: Core <random> std::mt19937 uniform_int_distribution Mersenne Twister Distributions

3.12 Modern C++ <random> Engines (std::mt19937) vs Distributions (uniform_int_distribution)

Executive Summary: Exploring the Modern C++ library introduced in C++11. We contrast legacy C rand() with modern random engines (Mersenne Twister std::mt19937) and statistical distribution mappers (std::uniform_int_distribution), analyzing the 2.5KB RAM state footprint of mt19937 vs lightweight Xorshift32 PRNGs for microcontrollers.

💻 1. Annotated Source Code

#include <iostream>
#include <cstdlib>   // for rand() and srand()
#include <ctime>     // for time()
using namespace std;

int main() {

	srand(time(nullptr));   //seeds the RNG with the current time

	int val1 = rand() % 10;   //0 to 9
	int val2 = rand() % 10 + 1;  //1 to 10

	cout << val1 << endl;
	cout << val2 << endl;

	return 0;
}

📐 2. Architecture & UML Class Model

📐 Hardware TRNG vs PRNG Linear Congruential Model

+ Public - Private # Protected

<<compilation-unit>> RandomGenerator RNG Engine

Attributes / Data Members

-seedValue : uint32_t

Operations / Methods

+seed(s: uint32_t) : void

+getRandRange(min: int, max: int) : int32_t

<<hardware-driver>> HwTrngDriver STM32 TRNG Peripheral

Attributes / Data Members

+RNG_CR : volatile uint32_t*

+RNG_SR : volatile uint32_t*

+RNG_DR : volatile uint32_t*

Operations / Methods

+getTrueRandomWord() : uint32_t

🔗 Architectural Relationships & Hierarchy

RandomGenerator ─ ─ > entropy source ─ ─ > HwTrngDriver

📚 3. Core C++ Concepts Deep-Dive

1. Engine vs Distribution Separation

C++11 cleanly separates random number generation into two orthogonal concepts:

Random Engine: Generates a sequence of pseudo-random bits (e.g. std::mt19937).
Distribution: Maps bits into a target mathematical distribution without modulo bias (e.g. std::uniform_int_distribution<int>(1, 6)).

⚡ 4. Embedded Systems & Hardware Reality

1. The RAM Footprint of `std::mt19937`

The Mersenne Twister (std::mt19937) maintains a 624-word state vector (2,496 bytes of SRAM). In a 2KB RAM microcontroller, a single mt19937 instance exhausts the entire system RAM! Embedded firmware uses lightweight Xorshift32 (4 bytes of RAM) instead.

💡 5. Production-Ready Embedded Refactoring

Ultra-lightweight Xorshift32 PRNG (4 Bytes of SRAM Total):

💡 Production-Ready Refactor

#include <cstdint>

// Marsaglia Xorshift32: High-quality randomness; 4 bytes RAM; 3 clock cycles!
uint32_t xorshift32(uint32_t& state) noexcept {
    uint32_t x = state;
    x ^= x << 13;
    x ^= x >> 17;
    x ^= x << 5;
    state = x;
    return x;
}

📝 Knowledge Verification Quiz

Test your understanding of the C++ concepts and embedded microcontroller trade-offs covered in this guide. Click any option for instant feedback.

Q1. How much RAM state memory does a std::mt19937 (Mersenne Twister) instance consume?

A Approximately 2,500 bytes (624 32-bit state words)

B 4 bytes

C 16 bytes

D 64 kilobytes

Detailed Explanation: std::mt19937 stores 624 32-bit state integers plus an index ($624 \times 4 + 4 \approx 2,500$ bytes), making it too large for microcontrollers with 2KB-4KB of RAM.

Q2. What is the memory footprint and execution speed of a Xorshift32 PRNG?

A Consumes exactly 4 bytes of RAM (1 uint32_t state) and executes in 3 clock cycles using simple XOR and bit-shift operations

B Consumes 1MB of heap

C Takes 1,000 cycles

D Requires an external EEPROM

Detailed Explanation: Xorshift32 uses a single 32-bit integer state and 3 ALU instructions (shift and XOR), executing in ~3 clock cycles with 4 bytes of RAM.

Q3. What does std::uniform_int_distribution<int>(1, 10) guarantee?

A A flat, uniform probability distribution across integers 1 to 10 with zero modulo bias

B Only even numbers are generated

C Numbers are sorted in ascending order

D Numbers are generated in 1 clock cycle

Detailed Explanation: std::uniform_int_distribution samples the engine and applies rejection sampling to guarantee statistically uniform, unbiased distributions.

Q4. Why should a random engine and its distribution be passed to generator functions rather than recreated on every call?

A Re-instantiating the engine every call resets its state or re-seeds it with the same timestamp, producing repetitive identical sequences

B To prevent compiler syntax warnings

C To allow floating point operations

D To move the engine to Flash memory

Detailed Explanation: Recreating engines on each call resets their internal sequence, generating duplicate values if called within the same timer tick.