En hands-on guide för utvecklare som bygger på Nordics nRF-plattform. Lär dig varför varje mikroamper räknas, vad du ska kräva av ett AI-verktyg, och hur du formulerar prompts som faktiskt genererar produktionsklar, energieffektiv kod.
Nordic Semiconductors nRF-familj (nRF52, nRF53, nRF54, nRF91) driver i dag miljontals BLE-sensorer, wearables, medicinska enheter och LTE-M/NB-IoT-produkter. Det som skiljer dem från generiska MCU:er är den aggressiva optimeringen för batteridrift — men möjligheten realiseras bara om firmware respekterar strömbudgeten.
En CR2032 på 230 mAh ska räcka i 2–5 år. Det ger ett genomsnitt på bara 5–13 µA. En vanlig misstag — en obortstängd UART eller felkonfigurerad regulator — kan dubbla förbrukningen och halvera livslängden över en natt.
Varje advertising-interval, connection parameter och radio-packet-längd påverkar strömbudgeten direkt. Att gå från 100 ms till 1 000 ms advertising kan sänka snittförbrukningen med en storleksordning — utan att försämra UX märkbart.
En typisk sensor är aktiv < 0,1 % av tiden. Resten tillbringar den i System ON Idle, System OFF eller Low-Power Sleep. Rätt sömn-läge är inte en optimering — det är själva arkitekturen.
Rätt instruerat kan ett LLM upptäcka slarviga GPIO-pinnar som lämnas floating, oavslutade I²C-transaktioner, eller en TIMER som aldrig stoppas. Men bara om verktyget faktiskt förstår nRF-stacken på djupet.
Generiska kod-LLM:er kan skriva hyggligt C — men firmware för nRF är en annan disciplin. Här är kriterierna som skiljer ett användbart verktyg från ett som bara hallucinerar register-adresser.
Här är tre fungerande prompt-mallar vi använder dagligen. Var specifik med chip, SDK-version och strömbudget — ju mer kontext du ger, desto mindre hallucinerar modellen.
När enheten ska sova i timmar eller dagar och bara vakna på en knapptryckning är System OFF rätt verktyg. Men var tydlig med RAM retention och wake-source.
Perfekt när du har en SPI-sensor som bara används var 30:e sekund. Låt AI konfigurera PM_DEVICE_RUNTIME och suspend/resume-cyklerna.
För en battery-powered beacon vill du ha lång interval, lågt TX-power och korrekt privacy. Be AI motivera varje val.
Fem saker utvecklare ofta frågar oss när de börjar använda AI för nRF-utveckling.
Nej — och det ska den inte heller. OPP ger dig faktiska mätvärden från Nordics labb. AI är ett komplement som hjälper dig skriva kod som utnyttjar de lägen OPP beskriver. Använd AI för att generera koden, och OPP eller en riktig PPK2 för att verifiera att verkligheten matchar förväntningarna.
Två skyddsnät: använd ett verktyg som kan referera till Nordics officiella product specifications i sin kontext, och kompilera alltid innan du kör. En felaktig register-adress fångas oftast redan av kompilatorn eftersom MDK-headerfilerna är strikt typade. Vi rekommenderar också att be AI inkludera en kommentar med sidreferens till datasheet — stämmer inte referensen så stämmer troligen inte koden heller.
Tumregel: om projektet är i NCS/Zephyr, börja alltid med Zephyr-driver (device_get_binding, device-tree, PM-integration). Fall tillbaka till nrfx HAL bara när du behöver en nRF-specifik funktion som Zephyr-abstraktionen inte exponerar — t.ex. PPI/DPPI-kedjor eller TIMER/RTC capture-compare med exakt timing. Blanda inte de två på samma peripheral.
nRF54-serien introducerar en ny arkitektur (GRTC istället för RTC, nya power domains, GPIO-mapping ändrad). Många LLM:er är tränade tungt på nRF52-exempel. Lösning: ange ALLTID exakt chipvariant och SDK-version i din prompt, och be verktyget flagga om något av det du frågar om har ändrats för din target. ”Verifiera mot nRF54L15 — använd GRTC, inte RTC.” är en bra avslutande rad.
Det beror helt på utgångsläget. I team som är nya på nRF ser vi typiskt 40–70 % reduktion efter en första optimeringsrunda — mest för att AI konsekvent föreslår System OFF, PM_DEVICE_RUNTIME och längre advertising-interval. I erfarna team är vinsten oftast 5–15 %, men värdet ligger då i tid: det som tog två dagar att researcha i Nordics DevZone tar 20 minuter med rätt prompt. Verifiera alltid med en PPK2 — en god tumregel är att inte lita på siffror du inte själv har mätt.