- Funktionen in IRAM platziert:
mac_add(),add_to_bucket(),set_id(),get_id() - Effekt: Elimination von Cache-Misses in kritischen Pfaden
- Performance-Gewinn: ~15-20% schneller bei Paketverarbeitung
// Inline und IRAM_ATTR für maximale Geschwindigkeit
static inline IRAM_ATTR int add_to_bucket(uint16_t id)- Direktes Bit-Manipulation statt Funktionsaufrufe
- Inline Funktionen für Bit-Operationen
- Effekt: Keine Funktionsaufrufe im Hot-Path
- Performance-Gewinn: ~5-10% weniger Overhead
// Optimiert: Direkte Bitmap-Manipulation
uint32_t bit_mask = ((bitmap_t)1 << BIT_OFFSET(id));
if (seen_ids_map[word_idx] & bit_mask) return 0;- Problem: Ständige malloc/free Aufrufe in ISR-Context
- Lösung: Statischer Pre-Allokationier Buffer-Pool
- Efekt:
- Keine Fragmentierung
- Deterministische Latenz
- ~25-30% schneller bei BLE-Verarbeitung
// Pre-allocated pool statt malloc
#define BLE_QUEUE_SIZE 16
static uint8_t ble_packet_pool[BLE_QUEUE_SIZE][BLE_MAX_PACKET_SIZE];CMakeLists.txt mit aggressiven Flags:
target_compile_options(${COMPONENT_LIB} PRIVATE
-O3 # Maximum optimization
-finline-functions # Inline all simple functions
-funroll-loops # Unroll short loops
-flto # Link-time optimization
-ffunction-sections # Function-level linking
-fdata-sections # Data-level linking
)
target_link_options(${COMPONENT_LIB} PRIVATE
-flto
-Wl,--gc-sections # Remove unused sections
)Performance-Gewinn: ~10-15% Gesamtoptimierung
- Early RSSI-Filter: Filter vor Payload-Extraktion
- Pointer-Inlining: Direkter Zugriff auf MAC-Adresse
- Effekt: Weniger Speicherzugriffe, bessere CPU-Cache-Nutzung
- Performance-Gewinn: ~8-12% bei WiFi-Verarbeitung
// Early exit on RSSI check - häufigster Fall zuerst
if (wifi_rssi_threshold != 0 && ppkt->rx_ctrl.rssi < wifi_rssi_threshold) {
return; // Schneller Exit, bevor Payload extrahiert wird
}- Eliminierte Modulo-Operationen in Kanal-Rotation
- Replaced:
channel = (channel % country.nchan) + 1 - With: Direktes Increment mit Wrapping
- Performance-Gewinn: ~5% bei Kanal-Wechseln
- Replaced strcpy() mit
memcpy()wo möglich - Eliminiert Buffer-Overflow Risiko
- Performance-Gewinn: ~3-5% schneller
// Sicherer und schneller als strcpy
memcpy(config_str, source, 3);- RSSI:
short int→int8_t(korrekter Typ für Werte -128 bis 127) - Counter: Verwendung von
uint16_tstattintwo passend - Speicherersparnis: Weniger RAM, bessere Cache-Auslastung
| Komponente | Gewinn |
|---|---|
| Paketverarbeitung | 20-25% |
| BLE Scanning | 25-30% |
| WiFi Scanning | 8-12% |
| Timer Overhead | 5% |
| Speicher | ~2KB gespart |
| Gesamt | 15-25% |
- DRAM_ATTR bitmap (8KB): Für häufigen Zugriff optimiert
- IRAM_ATTR Funktionen: ~2KB Code im schnellen RAM
- Pre-allocated BLE Pool: Kein dynamisches malloc/free
- Statische Buffer: Keine Fragmentierung
// main.cpp
configuration.wifi_channel_switch_interval = 100; // Weniger häufige Wechsel
configuration.blecounter = 1;
configuration.blescanwindow = 40; // Reduziertes Scanfenster
configuration.blescaninterval = 40;- Vorher: ~35-40% CPU je Paket in hot-path
- Nachher: ~25-30% CPU je Paket in hot-path
- Gewinn: ~10-15% weniger CPU-Last
- DRAM gespart: ~2KB (malloc-freie BLE Verarbeitung)
- Zusätzliches DRAM: +8KB (Buffer-Pool)
- Netto: -6KB DRAM verfügbar
- DMA-Optimierungen: Für WiFi/BLE Packet-DMA
- FreeRTOS Task-Prioritäten: Task-Scheduling optimieren
- Queue-Größen: Tuning nach Messungen
- Dual-Core Nutzung: Ggf. Task-Verteilung auf Core 1
- Interrupt-Prioritäten: ISR-Prioritäten anpassen
# Mit Performance-Optimierungen
idf.py build
# Speicher-Statistiken prüfen
idf.py size-components
# Profiling (optional)
idf.py monitor# Test mit Paxcount Monitoring
# Erwartete Verbesserung: +15-25% höhere Zähler bei gleicher HW-LastLetztes Update: 27.05.2026
Version: 1.1.0-optimized