Kompilerbarhet
Byggs koden utan modifikationer med west build mot rätt board-target? Saknade includes, felaktiga Kconfig-flaggor och påhittade header-filer ger avdrag.
Vikt 30 %
Den här sajten finns för att göra ett svårt val lite enklare. Vilket AI-verktyg skriver faktiskt användbar kod för nRF-plattformen — och vilket producerar hallucinerade register, påhittade API:er och sleep-lägesbuggar? Vi testar, dokumenterar och publicerar resultaten.
De flesta AI-jämförelser på nätet är generella: ”skriv en React-komponent”, ”förklara rekursion”. Men för oss som jobbar nära hårdvara — med radio-stackar, strömbudgetar och timing-kritiska avbrott — säger sådana tester nästan ingenting. Den här sajten fyller glappet med nRF-specifika benchmarks, utan affiliate-länkar och utan att någon leverantör betalat för placering.
Sajten tar inte emot provision, sponsring eller gratislicenser. Alla verktyg testas via betalda standardkonton.
Varje testprompt publiceras ordagrant så att du själv kan köra den i valfri modell och verifiera resultatet.
Koden kompileras, flashas och mäts på faktiska DK-kort — inte bara betygsatt visuellt i en editor.
Varje verktyg får samma prompts, samma kontext (nRF Connect SDK v2.x, Zephyr RTOS) och samma tid på sig. Resultatet poängsätts i fyra viktade dimensioner som tillsammans ger en slutlig bedömning.
Byggs koden utan modifikationer med west build mot rätt board-target? Saknade includes, felaktiga Kconfig-flaggor och påhittade header-filer ger avdrag.
Gör koden det som efterfrågades när den körs på hårdvara? Vi loggar via RTT, samplar GPIO med logikanalysator och verifierar BLE-trafik med sniffer.
Används rätt abstraktioner — k_work, devicetree-bindings, gpio_dt_spec — eller blandas HAL-anrop på låg nivå med Zephyr-API:er på ett rörigt sätt?
Resulterande ström mäts med Power Profiler Kit II under sleep. Verktyg som producerar ”fungerande” kod som drar 4 mA i idle får kraftiga avdrag.
Scenarierna är valda för att täcka de områden där nRF-utvecklare oftast behöver hjälp — och där generella AI-modeller oftast misslyckas. Varje scenario körs tre gånger per verktyg; medelvärdet rapporteras.
Skapa en non-connectable advertiser som sänder ett tillverkarspecifikt dataelement var 500 ms, med korrekt flags och längdbyte.
Konfigurera System OFF med wake-up från GPIO och behåll RAM-retention för ett statusord. Verifiera ström < 2 µA i off-läge.
Trigga på fallande flank, offloada hanteringen från ISR-kontext till en work queue, och debouncea korrekt i mjukvara.
Lägg till en BME280 på SPI1 via overlay, enablea rätt Kconfig och läs data med sensor-API:et.
Implementera Nordic UART Service som central-side-klient, med MTU-förhandling och korrekt notify-callback.
Bygg en app med stöd för smp_svr över BLE, sätt upp swap-algoritm och validera signerad bildrotation.
Sajten är gjord i god tro men inte ofelbar. Om ett testresultat ser konstigt ut, en prompt är orättvist formulerad eller ett verktyg har släppt en ny version som ändrar bilden — hör av dig så kör vi om testet. Syftet är att komma närmare sanningen, inte att försvara gamla slutsatser.