Speeduino tabanlı kendi ECU’mu düşünürken ilk bakışta çok cazip görünen bir soru var: Arduino Mega yerine Teensy 4.1 veya STM32 kullanırsam motor yönetimi otomatik olarak daha hassas ve daha öngörülebilir çalışır mı?
Teensy 4.1'in 600 MHz işlemcisi, klasik Mega'nın 16 MHz'lik AVR'sine göre büyük bir sıçrama. STM32 tarafında da F407, H743 ve G474 gibi birbirinden farklı seçenekler var. Fakat ECU için belirleyici sayı işlemcinin saat hızı değil. Asıl soru, krank dişinin görüldüğü an ile bobin ya da enjektör çıkışının fiziksel olarak değiştiği an arasındaki gecikmenin ne kadar değişken olduğu.
Speeduino kaynak kodunu ve mevcut kartları bu gözle inceledim. Sonuç, işlemci tercihini tek başına karara bağlamıyor; ama nerede ölçüm yapmamız ve nerede mimariyi geliştirmemiz gerektiğini oldukça iyi gösteriyor.
Önce mevcut seçenekler: Speeduino yalnızca Arduino Mega'da çalışmıyor
Resmî Speeduino firmware deposunun derleme yapılandırmasında Teensy 4.1 hedefi bulunuyor. Aynı dosyada STM32F407, STM32F429, STM32F401 ve STM32F411 için de hedefler var. Bu nedenle “STM32 seçersek Speeduino'yu sıfırdan portlamamız gerekir” cümlesi F4 ailesi için doğru değil. H743 veya G474 içinse incelediğim resmî yapılandırmada hazır bir hedef görmedim; bu işlemcileri seçmek ayrı bir port ve doğrulama çalışması anlamına gelir.
Teensy tarafında somut bir donanım referansı da var: resmî Speeduino DropBear V2 klasörü KiCad şemaları, PCB dosyası, BOM ve üretim dosyalarını içeriyor. Bu, prototipe başlamak için değerli. Açık tasarım dosyasının bulunması, kartın bizim hedeflediğimiz her motor ve arıza koşulunda doğrulandığı anlamına gelmiyor.
STM32F407 için üçüncü taraf kartlar da incelenmeye değer. pazi88 STM32 Mega, Speeduino v0.4 tabanlı kartlarda Mega yerine geçmeyi hedefliyor; proje sahibi resmî v0.4 uyumluluğunu test edilmiş olarak işaretlemiş. SPECTRE geliştiricisi Volvo B230FK üzerinde çalıştırdığı giriş ve çıkışları listeliyor, CAN gibi bazı özellikleri ise test edilmemiş olarak bırakıyor. SCG-ECU 2.0 8 enjektör ve 8 ateşleme kanallı başka bir referans; ancak README'deki NonCommercial lisans nedeniyle ticari bir kartı doğrudan bu tasarımdan türetmek uygun bir yol değil. Bu üç örnek, resmî Speeduino ürünleri veya birbirinin yerine geçebilen doğrulanmış kartlar olarak görülmemeli.
Güçlü işlemci, deterministik ECU demek mi?
“Deterministik” derken ortalama olarak hızlı çalışan bir ECU'dan söz etmiyorum. Belirli bir krank açısında üretilecek çıkışın, sistem CAN mesajları işlerken, SD karta log yazarken veya USB üzerinden ayar değiştirirken de tanımlanmış bir en kötü durum gecikmesi içinde gerçekleşmesini kastediyorum.
Örneğin 8.000 RPM'de krankın bir derecesi yaklaşık 20,8 mikrosaniye sürüyor. Varsayımsal 20 mikrosaniyelik çıkış sapması, yaklaşık 0,96 derece krank açısına karşılık gelir. Bu hesap, herhangi bir Speeduino kartında böyle bir sapma ölçüldüğü anlamına gelmiyor. Sadece neden mikrosaniye düzeyindeki gecikmeleri ciddiye almamız gerektiğini gösteriyor.
Teensy 4.1'in üretici sayfası 600 MHz Cortex-M7, 1 MB RAM, kart üzerindeki 8 MB harici Flash, üç CAN denetleyicisi ve 32 DMA kanalı gibi güçlü kaynaklar listeliyor. PJRC teknik sayfası. Bunlar daha fazla iş yapma kapasitesi veriyor. Gerçek zamanlı çıkışın ne kadar tutarlı olduğuna ise yazılım yolu, kesme öncelikleri, pin eşlemeleri ve çıkış sürücüleri karar veriyor.
Speeduino ateşleme ve enjeksiyonu nasıl zamanlıyor?
Kaynak kodda görülen ana yol kabaca şöyle:
- Krank sensöründen bir kenar geliyor ve MCU kesmesi çalışıyor.
- Decoder diş aralığını, senkron durumunu ve motor konumunu güncelliyor.
- Yakıt ve ateşleme olayları donanımsal timer compare değerlerine planlanıyor.
- Compare gerçekleşince bir kesme çalışıyor ve scheduler ilgili çıkışın durumunu değiştiriyor.
Bu akış önemli bir ayrım gösteriyor. Speeduino, Teensy ve STM32 üzerinde donanımsal timer'ları gerçekten kullanıyor. Fakat baktığım STM32 kart kodunda ve Teensy 4.1 kart kodunda compare kesmesi moveToNextState() çağrısıyla yazılım yoluna giriyor. Timer, olayın vaktini işaretliyor; fiziksel çıkış kenarının oluşması kesmenin işlenmesine de bağlı kalıyor.
Bu yüzden “donanım compare kullanıyor” ile “timer pini CPU'dan bağımsız sürüyor” aynı şey değil. İkinci yaklaşım bazı olaylarda daha sıkı zamanlama sağlayabilir; ama dwell, olay iptali, yeniden planlama ve arızada güvenli kapanış gibi davranışlarla birlikte tasarlanması gerekir.
Giriş tarafında da benzer bir fırsat var. Speeduino'nun eksik dişli decoder'ındaki triggerPri_missingTooth() işlevi zaman için micros() okuyor. Yani zaman damgası fiziksel kenar anında donanım tarafından kilitlenmek yerine kesme işlenirken alınıyor. Input capture kullanıldığında timer kenarın gerçek anını saklayabilir; CPU daha sonra işlese bile o zaman bilgisi korunur. Bunun faydasını söylemek için doğru pin/timer eşleşmesi ve gerçek tezgâh ölçümü gerekir.
Timer çözünürlüğü, ateşleme doğruluğu değildir
STM32 kart tanımı scheduler adımını 4 µs olarak ayarlıyor. Teensy 4.1 kart tanımında 600 MHz CPU için 150 MHz bus clock üzerinden yaklaşık 0,853 µs timer adımı hesaplanıyor. STM32 tanımı, Teensy 4.1 tanımı.
Teensy'nin daha ince bir timer adımı var; bu 0,853 µs fiziksel ateşleme doğruluğu demek değil. Kesme gecikmesi, krank açısı kestirimi, sensör şartlandırması ve sürücü devresi toplam sonuca giriyor. İşlemcileri karşılaştırırken boşta timer çözünürlüğünü değil, krank girişinden çıkış kenarına kadar ölçülmüş gecikme dağılımını görmek istiyorum.
Teensy kodunda ayrıca test etmeye değer bir ayrıntı var: QuadTimer TMR1–TMR4 kesme yordamları, birden çok kanal bayrağını if / else if zinciriyle işliyor. Aynı anda iki compare olayı gelirse bir ISR girişinde yalnızca bir dal yürütülür. İkinci olayın sonraki servis davranışını ve bunun anlamlı bir gecikme yaratıp yaratmadığını donanımda ölçmek gerekir. Bunu kaynak koddan bir inceleme noktası olarak çıkarıyorum; doğrulanmış bir motor arızası olarak sunmuyorum. Teensy 4.1 kesme kodu.
STM32 tarafında da topluluk aynı sorularla uğraşıyor. Speeduino deposundaki STM32 optimizasyon deneyi, kesme öncelikleri, donanımsal trigger timestamp, ADC için DMA ve daha hızlı GPIO yazmaları üzerinde çalışıyor. Geliştirici bunların henüz ana dala hazır olmadığını ve çalışan motor üzerinde test edilmediğini açıkça söylüyor. Bu çalışma yol gösterici; mevcut resmî firmware'in tamamlanmış özelliği değil.
F407, H743, G474 ve Teensy 4.1 arasında nasıl düşünürdüm?
| Platform | Güçlü tarafı | Bugünkü Speeduino durumu | Açık soru |
|---|---|---|---|
| Teensy 4.1 | Yüksek işlem kapasitesi, mevcut DropBear referansı | Resmî hedef ve 8+8 kaynak haritası var | Yük altında en kötü durum çıkış gecikmesi ne? |
| STM32F407VE | Hazır F4 portu ve referans kartlar | Resmî F407 hedefi var | Bu portun kritik giriş/çıkış yolları hangi iyileştirmeleri istiyor? |
| STM32H743 | 480 MHz Cortex-M7, geniş bellek ve çevre birimleri | İncelenen resmî yapılandırmada hedef yok | Port ve özel PCB için gereken mühendislik/test maliyeti ne? |
| STM32G474 | Zengin analog kaynaklar ve hassas timer'lar | İncelenen resmî yapılandırmada hedef yok | Ana ECU için pin/RAM bütçesi yeterli mi; yardımcı kontrolcü olarak mı daha iyi? |
H743 için ST, 1 MB SRAM, FD-CAN, ADC'ler ve gelişmiş timer kaynakları listeliyor. G474'ün HRTIM birimi için belirtilen 184 pikosaniye nominal adım etkileyici, fakat bu bir ECU'nun 184 ps krank açısı doğruluğuna sahip olacağını söylemez. Sensör ve tüm zamanlama zinciri çok daha belirleyicidir. ST H743, ST G474.
Burada firmware seçimini işlemci seçiminden ayırmak gerekiyor. Speeduino ile hızlı başlangıç için Teensy 4.1 veya F407 mantıklı. H7 ile uzun vadeli kendi kartımızı tasarlayacaksak Speeduino portunun maliyetini açıkça yazmalıyız. Alternatif olarak rusEFI de incelenebilir; deposundaki derleme sistemi F4, F7 ve H7 yolları içeriyor. Bu bilgi, seçilecek her H7 kartın aynı olgunlukta olduğu anlamına gelmez.
Kendi ECU'muzda değiştirmek isteyeceğim katman
İlk prototipte mevcut Speeduino'nun yakıt hesapları, trigger desenleri ve tuning ekosisteminden yararlanmak akıllıca. Fark yaratmak istediğim yer ise gerçek zamanlı giriş/çıkış katmanı:
- Krank ve kam kenarlarını uygun kanallarda donanımsal input capture ile zamanlamak.
- Ateşleme ve enjeksiyon olayları için en kötü durum gecikme bütçesi yazmak.
- Uygun çıkışlarda donanımsal compare ile pin sürmeyi değerlendirmek; olay iptali ve güvenli kapatmayı korumak.
- CAN, USB, SD ve kalibrasyon yazma işlerinin kritik kesmeleri ne kadar geciktirdiğini ölçmek.
- Senkron kaybı, uzayan dwell, takılı enjektör ve düşük besleme için güvenli davranış tanımlamak.
Sohbette ayrıca iki ürün kademesi düşünmüştük. Core, 4–8 silindirli ekonomik standalone ECU; Pro ise daha fazla fiziksel çıkış, peak-and-hold enjektör, dahili knock/wideband ve elektronik gaz gibi özelliklerle genişleyen ürün olabilir. Bunlar mevcut bir kartın teknik özellikleri değil, ürün hedefleri. Özellikle elektronik gaz kelebeği birkaç ek PWM pininden ibaret değil; sensör tutarlılığı, sürücü, bağımsız arıza izleme ve güvenli kapanış gerektiriyor.
İki ayrı yazılım geliştirmek yerine ortak bir motor kontrol çekirdeği, farklı donanım kartları ve tek tuning uygulaması fikri daha cazip. Ama Teensy'nin mevcut 8+8 kaynak haritasından 16+12 kanala kolayca büyüneceği varsayılmamalı. Kritik krank/kam, ateşleme ve enjeksiyon işlerini ana kartta tutup EGT ve yardımcı telemetriyi CAN modüllerine ayırmak, test edilmesi gereken makul bir başlangıç mimarisi.
İkinci işlemci de düşünülebilir: ana MCU motoru yönetirken yardımcı işlemci ekran, kablosuz bağlantı ve yoğun log işlerini taşır. Bu, ana ECU'nun bağlantı kesildiğinde bağımsız çalışmasına yardımcı olabilir. Tek başına güvenlik garantisi vermez; iki işlemci arasındaki protokolün zaman aşımı ve hata davranışı tasarlanmalıdır. AI destekli tuning yazılımını da gerçek zamanlı kıvılcım kararından ayrı, log analizi ve doğrulanabilir kalibrasyon önerileri için düşünürüm.
Kararı hangi test verecek?
Teensy 4.1'i STM32F407 ile, ileride gerekirse H743 prototipiyle aynı 36-1 krank sinyali altında karşılaştırmak istiyorum. Ölçülecek şey yalnızca ortalama tepki değil:
- 1.000–10.000 RPM ve ani hız değişimlerinde çıkış kenarı sapması;
- aynı anda çalışan yakıt/ateşleme kanallarında en kötü durum gecikmesi;
- CAN, USB, SD log ve kalibrasyon yazma yükünün jitter'a etkisi;
- gürültülü/eksik krank sinyalinde senkron kaybı ve güvenli duruma geçiş;
- maksimum sapma, p99/p99.9 ve kaçırılan son tarih sayısı.
Ölçümler sensör girişinden fiziksel sürücü çıkışına kadar yapılmalı. Ancak o zaman daha yüksek MHz'in, farklı timer mimarisinin veya input capture değişikliğinin gerçek ECU davranışına ne kattığını söyleyebiliriz. Araç üstü denemeden önce tezgâh ve HIL testleri, çıkışların arıza anındaki davranışı ve güç koruması doğrulanmalı.
Şimdiki cevabım
Teensy 4.1 veya STM32F407 üzerinde Speeduino hâlâ büyük ölçüde Speeduino. Donanımsal timer kullanıyor ve daha güçlü kaynaklara erişiyor; buna rağmen incelediğim kritik yollar ortak decoder/scheduler ve kesme işleme yaklaşımını koruyor.
Bu kötü bir başlangıç değil. Tam tersine, çalışan bir açık kaynak tabanını ölçerek geliştirmek için güçlü bir fırsat. Fakat “daha deterministik ECU” iddiasını işlemci etiketiyle kuramam. Bunu ancak donanımsal zaman damgası, dikkatle tasarlanmış çıkış yolu ve ölçülmüş en kötü durum performansı ile savunabilirim.