---
title: "Pi'nin Sonsuzluğundan Arduino Flash'a: Donanımda Gerçek Rastlantı Nasıl Taklit Edilir?"
description: "Her projeye başladığımda kafamın bir köşesinde hep o \"mükemmel kontrol\" takıntısı belirir. Bir yandan da doğanın kaotik güzelliğini, yani gerçekten…"
date: 2026-11-04T09:47:42Z
updated: 2026-11-04T09:47:42Z
author: "Alper Kaya"
site: "Sıfırdan Kod Satırına"
language: "tr"
tags: ["arduino", "mikrodenetleyici", "rastgele-sayı-üretimi", "donanım", "fizik"]
url: "https://devirmakina99.nasilalinir.com/pi-nin-sonsuzlugundan-arduino-flash-a-donanimda-gercek-rastlanti-nasil-taklit"
---

# Pi'nin Sonsuzluğundan Arduino Flash'a: Donanımda Gerçek Rastlantı Nasıl Taklit Edilir?

Her projeye başladığımda kafamın bir köşesinde hep o "mükemmel kontrol" takıntısı belirir. Bir yandan da doğanın kaotik güzelliğini, yani gerçekten öngörülemezliği yakalamak isterim. Fizikteki entropiden yazılımdaki bir `rand()` çağrısına kadar, rastlantının tanımı sürekli değişiyor. Peki, mikrodenetleyici gibi sınırlandırılmış bir ortamda, bilgisayarın ürettiği o kusursuz matematiksel rastgelelikten ziyade, "yaşanmış" bir rastlantıyı nasıl yakalarız?

Bu makale, benim kişisel olarak geçtiğim bir labirentten geçiyor: Dijital dünyada üretilen sayısal rastgelelik ile donanımın sunduğu fiziksel belirsizliği eşleştirmek. Eğer amacınız sadece bir simülasyonda oyunun dengesini bozmaksa, iyi tohumlanmış (seeded) bir algoritma yeterlidir. Ama eğer projelerinizde, örneğin bir sensör dizisi veya gürültü ile beslenen bir karar mekanizması varsa, basit `millis()` döngüsünüza güvenmek sadece kaosa şişirilmiş bir simülasyondur.

## Yazılımsal Tuzaklar: Pseudorandomness vs. True Randomness

Çoğu başlangıç seviyesi projede karşılaşılan en büyük yanılgı budur. Bizim kütüphanelerimizdeki çoğu zaman `rand()` fonksiyonu, aslında bir **sözde rastgele sayı üretecidır (PRNG)**. Yani, belli bir başlangıç değeri olan ve tamamen deterministik bir matematiksel formülle ilerleyen bir tahmindir. Bu, bilgisayarın hesaplama gücünün sonucudur ve teorik olarak başlangıç noktanızı bilirseniz tüm diziyi yeniden oluşturabilirsiniz.

Bu durum, özellikle kritik bir IoT uygulamasında veya kriptografik olmayan ancak yine de tahmin edilemezlik gerektiren bir durumda büyük bir mimari kusurdur.

## Donanımdan Geriye Beslenme: Gerçek Belirsizlik Kaynağı Aramak

Benim yaklaşımım her zaman, eğer bir belirsizlik gerekiyorsa, bu belirsizliği en mümkün olan en düşük seviyede bulmaktır. Mikrodenetleyicinin kendisi, zamanla ve fiziksel olaylarla etkileşime girdiği için doğal bir "gürültü kaynağıdır."

İşte bu noktada devre kartı tasarımı devreye giriyor. Basitçe bir analog okuma yapmak, dijital algoritmanın öngördüğünden çok daha zengin ve "gerçek" bir girdi sağlar.

**Pratik Uygulama Adımları (Bir ADC Okuması Üzerinden):**

1. **Giriş Sinyalinin Belirsizliği:** Seri bir devre tasarlayın. Örneğin, sıcaklık sensöründen gelen değerin veya potansiyometrenin okumasını yapıyorsunuz. Bu okumayı, sinyalin mükemmel değil, fiziksel gürültüye (termal gürültü, elektromanyetik girişim vb.) maruz kaldığı bir zamanda alın.
2. **Örnekleme ve Sayısallaştırma:** Bu analog gerilimi bir Analogdan Dijitale Çevirici (ADC) ile dijital değere dönüştürün. Bu, o anki fiziksel entropiyi yakalamaktır.
3. **Filtreleme ve Besleme:** Eğer bu ham okumayı doğrudan sonraki karar mekanizmasına beslerseniz, o karar gerçekten donanımın o anki "ruh haline" bağlı olacaktır. Bu ham ADC değeri, sonraki bir PRNG'nin başlangıç tohumu (seed) olarak kullanılabilir veya doğrudan sisteminize girdi sağlayabilir.

Burada yapılan şey, *yazılımın* rastgelelik üretmesi değil; *donanımın* fiziksel sınırlarından kaynaklanan doğal gürültüyü, yazılımın anlayabileceği bir sayısal değere zorla dönüştürmesidir.

Bu süreç, bir yazılım mimarisinde sadece kod satırları değil, PCB üzerindeki dirençlerin toleransı ve güç kaynağının kararlılığı gibi fiziksel detayların bile birer "algoritma parametresi" olduğu gerçeğini kabul etmeyi gerektirir. Ve bu, mühendisliğin en tatmin edici kısımlarından biri benim için.