Skip to main content

Interrupt Mimarisi

Genel Bakış​

B107AA R6’da interrupt mimarisi, sahadan gelen olayları (şebeke faz var/yok, kontaktör durumları, termik atması vb.) “kaçırmadan” yakalayıp, bu olayları deterministik bir şekilde firmware’in ana akışına taşımak için tasarlanmıştır.

Bu sayfada anlatılan yaklaşımın temel fikri şudur:

  • ISR mümkün olduğunca kısa tutulur.
  • ISR içinde “iş yapmak” yerine yalnızca olayı işaretle (timestamp + flag) ve ana döngüde işle.
  • Girdi katmanındaki opto/RC filtre nedeniyle zaten “fiziksel” tarafta bir miktar yumuşatma vardır; firmware tarafında ek bir debounce/validasyon yapılır.

Bu mimari, R5’te sahada karşılaşılan yalancı tetikleme, anlık gerilim çökmesi ve PLC/pano kaynaklı parazit senaryolarında daha stabil davranmak için yeniden ele alınmıştır.

Tasarım Hedefleri​

  • Olay kaçırmamak: Kısa süreli faz düşümü / kontaktör titreşimi gibi durumlar loglanabilmeli.
  • Deterministik çalışma: ISR süreleri sınırlı, ölçülebilir ve sabit olmalı.
  • Gürültü dayanımı: Pano içi parazit, zayıf nötr/toprak, kontaktör arkı gibi durumlarda stabil algılama.
  • Ölçeklenebilirlik: 8 kanal HV sense + diğer MCU çevre birimleri (RTC, GSM, enerji analizörü vb.) aynı çatı altında yönetilebilmeli.

Sistem Topolojisi​

Bu doküman özellikle MCU tarafındaki interrupt akışını tanımlar.

  • 8 adet saha girişi (R/S/T fazları, kontaktör/termik vb.) → izolasyon/giriş katmanı → 3V3 lojik seviyesinde MCU girişleri.
  • MCU: ATmega2560 (3V3)
  • 8 kanal girişin tamamı MCU’nun aynı port grubuna toplanarak pin-change interrupt ile izlenir.

8 kanalın tek tek harici interrupt’a bağlanması yerine pin-change yaklaşımı seçilmiştir; böylece pin sayısı ve routing sadeleşir.

Interrupt Kaynakları​

R6 firmware’inde hedef, CPU’nun “boşta” iken gereksiz iş yapmaması ve yalnızca olay olduğunda devreye girmesidir. Bu yüzden ana döngü (loop) çoğu zaman bekleme/idle karakterindedir; iş akışı interrupt’larla tetiklenen bayraklar üzerinden ilerler.

Aşağıdaki interrupt kaynakları R6’da aktif olarak kullanılmaktadır:

8 Kanal Girdi Katmanı​

  • Amaç: Panodaki elektriksel değişimleri (faz var/yok, kontaktör/termik vb.) algılamak.
  • Donanım: 8 kanal giriş MCU’da aynı port üzerinde gruplanmıştır.
  • Firmware yaklaşımı: PORTK üzerinde pin‑change interrupt (PCINT) ile her türlü seviye değişimi yakalanır.

8 kanalın aynı port üzerinde tutulması; tek ISR ile tüm kanalları snapshot alıp “hangi bit değişti” bilgisini çıkarmayı kolaylaştırır. Detaylar “Girdi Algılama” bölümünde incelenmiştir.

RTC Alarm Interrupt​

  • Amaç: RTC üzerinde kurulan zamanlı alarmları yakalamak ve periyodik görevleri tetiklemek.
  • Kullanım: Telemetri gönderim periyotları (pompa çalışıyorken 5 dk, çalışmıyorken 15 dk gibi) RTC alarm ile belirlenir.

GSM Ring/RI Interrupt​

  • Amaç: GSM modüle gelen bir komut/uyarı durumunda MCU’yu bilgilendirip UART kanalını yalnızca gerektiğinde okumak.
  • Kullanım: GSM UART’ın sürekli polling ile okunması yerine, RI/RING interrupt geldiğinde ilgili RX buffer okunur ve komut işlenir.

RS‑485 Interrupt​

  • Amaç: RS‑485 üzerinden gelen komut isteğini algılamak ve RS‑485 kanalını okumak.
  • Not: RS‑485 RX tarafı ring‑buffer’a alınır; parsing/komut işleme ana akışta yapılır.

Enerji Analizörü Interrupt’ları​

  • Amaç: Enerji katmanında oluşan limit aşımları, eşik olayları veya “alarm” koşulları için hızlı bildirim almak.
  • Kullanım: Bu iki kanal, enerji analizörü tarafında tetiklenen olayları “anlık” işaretler; detay okuma/raporlama ana akışta yapılır.

R5’ten kaldırılan interrupt kaynakları​

R6 revizyonunda aşağıdaki interrupt kaynakları firmware akışından çıkarılmıştır:

  • T/H sensör interrupt’ları
  • Battery gauge interrupt’ları
  • Şarj yönetim (charger) interrupt’ları

Bu kaldırma ile amaç; kesme sayısını azaltıp, sahada en kritik olan “girdi + zaman + haberleşme + enerji alarm” ekseninde daha deterministik bir akış sağlamaktır.

Firmware Akış Prensibi​

R6’da ISR’ler yalnızca bir bayrak (flag) / event bit tetikler. ISR içinde uzun fonksiyon çalıştırılmaz.

  • ISR: olay geldi bilgisini işaretler (gerekirse hızlı bir snapshot alır)
  • Loop: önceliklendirme ve gerçek iş burada yapılır (okuma, paket hazırlama, modem komutu, kayıt, vb.)

Bu yaklaşımın faydası: ISR süreleri kısa kalır, farklı interrupt’ların birbirini geciktirme riski azalır.

Debounce​

Saha ortamında parazit kaynaklı yalancı tetikleme mümkündür. Debounce için iki yöntem vardır:

  1. Önerilen yöntem (deterministik): ISR yalnız flag set eder, doğrulama/validasyon t_valid penceresi ile loop’ta yapılır.
  2. Alternatif (riskli): ISR içinde kısa bir bekleme ile tekrar okuma.

ISR içinde “bekleyip okuma” (busy‑wait) yapılması genelde önerilmez; çünkü ISR süresini büyütür ve diğer interrupt’ların gecikmesini artırır. Bu nedenle bu projede debounce/validasyonun loop tarafında yapılması hedeflenir.

8 Kanal Girişlerin ISR Akışı​

Snapshot Mantığı​

Port okuması tek seferde yapılır:

  • now = PINx (ilgili port okunur)
  • changed = now XOR prev
  • prev = now

changed içinde 1 olan bitler, o interrupt’ta değişen kanalları gösterir.

Neden Snapshot?​

  • Tek tek pin okumaya göre daha hızlıdır.
  • Aynı interrupt içinde birden fazla kanal değişmişse hepsi yakalanır.
  • ISR süresi kanal sayısından bağımsız olarak çok küçük kalır.

Debounce ve Validasyon Stratejisi​

Saha girişleri opto ve RC filtre ile zaten yumuşatılmış olsa da, pano kaynaklı parazitler kısa süreli “zıplama” üretebilir.

Bu yüzden firmware tarafında iki katmanlı bir yaklaşım önerilir:

  1. Anlık olay kaydı (ISR): Her değişim event olarak düşer.
  2. Doğrulama (Main loop): Olaydan sonra belirli bir süre geçince tekrar okunur ve stabil ise “gerçek olay” kabul edilir.

Not: Debounce/validasyonun ISR içinde “bekleyerek” yapılması ISR süresini büyüttüğü için tercih edilmez. Bu doküman, validasyon penceresinin ana döngüde uygulanmasını baz alır.

Validasyon penceresi için tipik yaklaşım:

  • t_valid = 20–50 ms (sahaya göre ayarlanır)
valid(ch)={1,∣tnow−tevent∣≥tvalid  ∧  levelnow=levelevent0,aksi halde\text{valid}(ch) = \begin{cases} 1, & |t_{now}-t_{event}| \ge t_{valid} \;\wedge\; level_{now}=level_{event}\\ 0, & \text{aksi halde} \end{cases}

Eğer faz var/yok gibi “kritik” bir olay için daha agresif davranmak istenirse iki eşik kullanılabilir: hızlı raporlama + sonradan doğrulama.

Event Queue Tasarımı​

ISR’den ana döngüye olay taşımak için sabit boyutlu bir ring-buffer kullanılır.

Her event için minimum alanlar:

  • channel_id (1–8)
  • level (0/1)
  • t_us veya t_ms (timestamp)
  • reason (opsiyonel: rising/falling)

Önerilen kural:

  • Queue dolarsa en yeni olayları değil, en eski olayları düşürmek daha tehlikelidir.
  • Bu nedenle overflow durumunda bir overflow_counter tutulur ve loglanır.

Interrupt Öncelik, Gecikme ve Performans​

AVR’de genel kural: ISR çalışırken global interrupt kapalıdır (nested yok). Bu yüzden en kritik metrik en uzun ISR süresi ve toplam interrupt yoğunluğudur.

Pratik Gecikme Bütçesi​

Hedef: pin-change ISR’nin süre bütçesi birkaç mikrosaniye mertebesinde kalsın.

Basit bir model:

Δtlatency≈tcurrent_ISR+tprologue/epilogue+tread_port\Delta t_{latency} \approx t_{current\_ISR} + t_{prologue/epilogue} + t_{read\_port}
  • Timer interrupt’ı çok sık ise t_current_ISR büyür.
  • UART RX’te uzun ISR yapılırsa pin-change gecikir.

Kırmızı çizgi: ISR içinde printf, JSON parse, modem komutu, I2C işlemi gibi uzun işler yok.

Hata Senaryoları ve Güvenli Davranış​

  • Port okuma tutarsızlığı: Çok nadir; ama kritik olaylarda “ikinci okuma” ile doğrulama yapılabilir.
  • Queue overflow: overflow_counter artar → loglanır, telemetriye gönderilir.
  • Aşırı interrupt fırtınası: Timer frekansı düşürülür, giriş validasyon penceresi artırılır.

Test ve Doğrulama​

Sahaya çıkmadan önce önerilen test seti:

  • Kontaktör bobini aç/kapa sırasında parazit testi (yan yana kablo, uzun hat)
  • Faz düşümü simülasyonu (kısa süreli brown-out benzeri)
  • 8 kanal aynı anda değişim (port snapshot doğrulama)
  • Queue overflow testi (yüksek frekans toggling)

Ölçülebilir metrikler:

  • Pin-change ISR süresi (osiloskop ile debug pin toggling)
  • Overflow counter
  • Validasyon sonrası gerçek/yalancı oranı

R5 → R6 Notları​

  • ISR felsefesi netleştirildi: işaretle + sıraya al + ana döngüde işle.
  • Validasyon penceresi sahaya göre parametrelenebilir hale getirildi.
  • Debug ve UART akışı ISR’den ayrıştırıldı (ring-buffer yaklaşımı).
  • T/H, battery gauge ve şarj yönetim kaynaklı interrupt’lar R6’da kaldırıldı (daha düşük kesme yoğunluğu ve daha deterministik akış).

Sonuç​

Bu interrupt mimarisi, B107AA R6’nın pano içi zorlu koşullarında giriş olaylarını güvenilir şekilde yakalayıp, firmware’in ana akışında deterministik olarak işlemesini hedefler.

Bir sonraki sayfada, bu mimarinin firmware implementasyon detaylarını (interrupt mask’leri, ring-buffer boyutu seçimi, debug pinleri, örnek pseudo-code) anlatacağız.