98 lines
3.3 KiB
Plaintext
98 lines
3.3 KiB
Plaintext
3. backup - > bundan önce, göreceli stabil çalışan baseline.
|
||
• Şimdilik büyük refactor yapmadan, software’de şu küçük önlemleri öneririm:
|
||
|
||
1. Drop logunu doğrulama noktası yap
|
||
RF kesince mutlaka şu tarz log görmeliyiz:
|
||
|
||
tracking channel X drop status=...
|
||
tracking channel X has dropped
|
||
|
||
Bu geliyorsa RTL fix iş görüyor demektir.
|
||
|
||
2. Nav solve için minimum guard ekle
|
||
Nav solve öncesi sadece şu koşulları sağlayan kanalları kullan:
|
||
- software node var,
|
||
- tracking IP BUSY=1,
|
||
- tracking IP LOCK=1,
|
||
- STOP_UNLOCK flag yok,
|
||
- subframe/ephemeris yeterli,
|
||
- measurement fresh.
|
||
|
||
3. Orphan nav solve interrupt’ı sessiz toparla
|
||
get_element_by_ip_number() NULL dönerse sürekli error basmak yerine:
|
||
- slot’u temizle,
|
||
- nav-bit mode’a al,
|
||
- log’u rate-limit et.
|
||
Bunu kısmen yapmıştık; korunmalı.
|
||
|
||
4. Drop gelince ölçümü hemen stale yap
|
||
Sadece linked-list node silmek değil, ilgili PRN/IP için nav solve input’u
|
||
da anında invalid olmalı. Böylece aynı döngüde eski measurement
|
||
kullanılmaz.
|
||
|
||
5. Printf’i azalt
|
||
500 ms nav solve periodda ISR içindeki sürekli log sistemi yavaşlatır. NAV
|
||
SOLVE PERIOD, address, status gibi loglar debug-level veya rate-limit
|
||
altında olmalı.
|
||
|
||
6. Nav solve snapshot kullan
|
||
Solve başlamadan önce aktif kanalları küçük bir array’e kopyala. Solve
|
||
sırasında linked list değişirse hesap etkilenmesin.
|
||
|
||
7. Duplicate PRN/IP kontrolü
|
||
Yeni acquisition sonucu tracking’e atanırken aynı PRN başka bir busy IP’de
|
||
mi kontrol et. Varsa yeni atama yapma veya eski slot’u temizle.
|
||
|
||
8. RF kopma testi için sayaç ekle
|
||
Debug amaçlı:
|
||
- drop_count
|
||
- nav_solve_count
|
||
- orphan_nav_solve_count
|
||
- reacquire_count
|
||
|
||
Bunları UART’ta sürekli değil, belirli aralıkla özet basmak daha iyi.
|
||
|
||
Kısa hali: büyük OS-style refactor’u şimdilik ertele. Yeni RTL ile RF drop/
|
||
reacquire doğruysa software’de sadece freshness guard + log azaltma +
|
||
duplicate/orphan temizliği yeterli olur.
|
||
-------------------------------------------------------------------------------
|
||
4. backup -> 3 un ustune memory leak lar gıderıldı. adres sanitizer c++ ın uzerıne
|
||
|
||
› neler yaptık ?
|
||
|
||
|
||
• gps_system içinde memory leak taraması yaptık.
|
||
|
||
Önce malloc/free/create_matrix/free_matrix kullanımını inceledik. Leak’in
|
||
linked-list tarafında değil, nav çözümü tarafında olduğunu bulduk: src/
|
||
NavEquations.c:451 içinde oluşturulan TA, ATA, invATA, invATA_Left matrixleri,
|
||
convergence durumunda break ile çıkınca free edilmiyordu.
|
||
|
||
Bunu Linux GCC sanitizer ile /tmp/gps_linux_gcc altında doğruladık.
|
||
LeakSanitizer önce şunu verdi:
|
||
|
||
816 byte(s) leaked in 28 allocation(s)
|
||
|
||
Sonra orijinal kodu patchledik: src/NavEquations.c:493
|
||
|
||
free_matrix(TA);
|
||
free_matrix(ATA);
|
||
free_matrix(invATA);
|
||
free_matrix(invATA_Left);
|
||
|
||
if(norm < 1e-4)
|
||
{
|
||
break;
|
||
}
|
||
|
||
Son kontroller:
|
||
|
||
- Bare-metal make başarılı.
|
||
- Linux -fsanitize=address,leak harness artık leak raporu vermiyor.
|
||
- GCC -fanalyzer ile tekrar leak/use-after-free/double-free taraması yaptık;
|
||
yeni leak bulmadı.
|
||
|
||
Kalan not: leak temizlendi, ama malloc başarısız olursa bazı yerlerde null
|
||
check eksik. Bu leak değil, heap tükenince crash riski.
|
||
|