01Miten projektin opetus alkoi

Kaikki alkoi tavallisesta työstä: ESP32-ohjelmat FreeRTOSin päällä ja kielimalli apuna omalla koneella. Malli oli apuna, mutta sen heikkoudet tulivat nopeasti vastaan — muistinhallinta lipsui, web-käyttöliittymästä jäi osia pois, ja vastausta sai odottaa pitkään. Mututuntuma ei riitä. Jos haluaa tietää, mikä malli oikeasti osaa sulautettua koodia — ja voiko sitä opettaa paremmaksi — tarvitaan mittari.

Siitä syntyi projektin ydinajatus: yksi mittari, joka toimii sekä kokeiluna että koulutuksena. Sama benchmark, joka mittaa mallin, tuottaa myös opetusdatan — tehtävineen, piilotetuine testeineen ja tarkistettuine ratkaisuineen. Kun opetusdata ja mittari noudattavat samoja sääntöjä, tulokset ovat verrattavissa alusta loppuun.

02Mittari, jota ei voi huijata

fbench mittaa, kuinka hyvin kielimalli kirjoittaa ESP32-S3-firmwarea (ESP-IDF v6, FreeRTOS). Siinä on 38 tehtävää ja 79 pisteytettävää kohdetta 11 alueelta. Jokainen tulos tulee automaattisesta tarkistuksesta: kääntäjältä, simulaattorilta tai staattisesta tarkistuksesta — ei toiselta mallilta.

Kooditehtävän pisteet koostuvat painotetuista osista — osa, joka ei koske tehtävää, ohjataan pois ja loput normalisoidaan:

03Opetusdata: parametriset tehtäväperheet

Käsinkirjoitettu esimerkkidata ei riitä — eikä sitä voi luottaa mallin keksimään. Sen sijaan jokainen tehtäväperhe on parametrinen generattori: Python-moduuli, joka arpoo parametrit (jonon pituus, kuluttajien määrä, jakson pituus, prioriteetit, rakenteen kentät, burst-koko, jopa API-funktioiden nimet) ja tuottaa instanssin viidestä osasta:

• tehtävänannon (mallille),
• piilotetun simulaattoritestin (C, mallilta piilotettu),
• viitatusratkaisun,
• rikkoutuneen variantin — perheen tyypillinen virhe (esim. estävä kutsu ISR:ssä), ja
• ESP-IDF-tulospisteen.

Alkuperäisiä perheitä on kymmenen — tuottaja–kuluttaja, jaksollinen, token bucket, ISR-laskuri, mailbox, deadman, barrier ja RPC — sekä kaksi, jotka pidetään vain testijoukossa: rwlock ja msgbuf_isr. Toisessa testijoukossa on kahdeksan täysin uutta perhettä (mukana queueset ja notifybits), joita malli ei ole nähnyt koskaan.

Ratkaisut kirjoittaa opettaja — mutta vain tarkistettuna

Ratkaisut kirjoitti opettajamalli: ensin gpt-oss-120b (pilvipääte, 632 yritystä, 3 h 49 min — 223 hyväksyttiin heti ja 166 korjauksen jälkeen) ja myöhemmin DeepSeek V4.1 Flash OpenRouterin kautta (noin 9 dollaria). Instanssi hyväksytään vain, jos:

• opettajan ratkaisu läpäisee simulaattoritestin kahdesti,
• rikottu versio kääntyy mutta kaatuu testissä, ja
• ratkaisu läpäisee IDF-käännöksen ja staattiset tarkistukset.

Hylätty ratkaisu saa yhden korjauskierroksen: opettaja näkee käännösvirheet ja epäonnistuneiden tarkistusten nimet, mutta eikään koskaan testikoodia. Hyväksytyt korjaukset tallennettiin myös virhe → korjaus-keskusteluina opetusdataan — malli oppii näkemään virheen ja kirjoittamaan sen pois.

04Miten data validoidaan

"Automaattinen testi" ei vielä tarkoita "oikea". Siksi jokainen muutos (mutation) ja ratkaisu kulkee neljän validointitason läpi, ja jokainen taso on raskaampi edellistä. Mitään ei mene opetukseen, jos se ei mene läpi.

Taso 1 — FreeRTOS-host-simulaattori

Ratkaisu käännetään FreeRTOS-Kernelin POSIX-portin päälle ESP-IDF-yhteensopivuuskerroksen kanssa. Linkkerin kaanarit tallentavat kaikki epäilyttävät tapahtumat: estävät kutsut keskeytyksessä, logit ja allokaatiot ISR-kontekstissa, heapin käyttötapa, portYIELD_FROM_ISR:n käytöt. Kaaostila laittaa satunnaissuikeita semaforin oton jälkeen, josta lukkiutumiset ja kilpailutilanteet tulevat toistettaviksi. Nopeus: noin 2 sekuntia testiä kohden.

Taso 2 — QEMU

Espressifin QEMU 9.2.2 ajaa oikean ESP-IDF-käännöksen virtuaalichipissä, yhdellä tai kahdella ydillä. Se paljastaa asioita, joita host-simulaattorin yksiydinmalli ei voi: stack-kaanari koki stack_too_small 26/26, mutta monet kriittisten osien poistot ja muistivuodot pysyvät havaitsematta — myös kahdella ydillä. Yön aikana ajoi noin 3 658 QEMU-testiä.

Taso 3 — oikeat laitteet

board_validate.sh ajaa jokaisen mutationin oikeilla laitteilla: eval-joukko ESP32-S3:lla (609 ajoa) ja koulutusjoukko jaettuna ESP32-a/b-laudoille (noin 1 400 ajoa per lauta). Laitehavainnot lasketaan ilman vahvistusajoa, koska laitteiston aikakatkaisut eivät riipu isäntäkoneen kuormasta. Lukuja: 609 + noin 2 800 laiteajoa; logit datagen/out/board_validate_*.log, tuomiot review_mutations_tiers.jsonlin.

Taso 4 — paikallinen päätösmalli (toinen mielipide)

Viimeinen taso on koodikatselmusmerkinnöiden toinen mielipide: kysytään paikalliselta päätösmallilta, onko merkitty "virhe" todella virhe kyseisellä rivillä. Kokeiltiin ensin Laya (421M, ModernBERT, paikallinen llama-palvelin, ~33 ms) — mitattiin 30 katselmatiedostolla (149 todellista merkintää) ja rikotulla kopioilla. Tulos: AUC 0,64 — "liian heikko validoimaan". Sääntö kirjattiin: uuden paikallisen tuomarin pitää ylittää AUC 0,85 samassa kalibroinnissa. Qwen3.8-27B (Q3_K_XL, logprobs, ±15 rivin ikkuna) saavutti AUC 0,963 ja otettiin käyttöön: kynnys p(TRUE) ≥ 0,1 pitää 89 % todellisista merkinnöistä ja hylkää vain 8 % rikotuista.

05Miten tulokset verrataan

Kaikki mallit ajetaan samassa tehtäväjoukossa, samalla profiililla (mallikohtainen lämpötila: Qwen 0,6 / 0,8, gpt-oss 1,0), ja kohina vastustetaan toistoilla: kolme toistoa per kohde, tulokset keskiarvoitetaan. ./bench.py report rakentaa results/report.html: taulukon, aluekohtaisen lämpökartan ja mallikohtaisen Weaknesses-listan (useimmin epäonnistuneet tarkistukset, esim. isr_button_debounce: short_glitch_ignored). Pisteiden rinnalla mitataan myös strict pass (tehtäviä, joissa jokainen osa oli 100 %) ja IDF build ok (osuus, joka kääntyy oikealle kohdelaitteelle) — yleispisteiden ohella ne paljastavat, mitä malli oikeasti osaa.

Päävertailu (pisteet / 100)

Näkemättömät perheet osoittavat yleistymisen: rwlock 30 → 63, msgbuf_isr 33 → 85, queueset 7 → 28, notifybits 46 → 60. Opetetuissa perheissä malli olisi voinut oppia kaavat — näkemättömät kertovat, oppiiko se FreeRTOSia.

Mittaukset, jotka opettivat

• Ajattelu on hintaa vastaan. Qwen3.8-27B täydellä ajattelulla sai vain 26 pistettä: 24:stä 79 vastauksesta token-budjetti loppui ennen kuin koodia syntyi. Vertailun perustana on ajattelu pois — koulutetussa muodossa.
• Yksi toisto pettää. Versioissa v3/v4 bugidata paransi bugien löytämistä, mutta koodin laatu putosi (testijoukko 2: 72,7 → 57,2). Kun v2 mittattiin uudelleen kolmella toistolla (69,3), ero paljastui todelliseksi. Yksittäinen toisto olisi valinnut väärän reseptin.
• Leikkaus paljastuu. Trunkeeratut vastaukset (finish_reason=length) raportoidaan erikseen jokaisessa ajossa — muuten matala piste voisi tulla tokenbudjetista, ei osaamattomuudesta.
• Uudelleenpisteytys ilman uudelleenajoa. Kun testit muuttuvat, ./bench.py eval results/<run> pisteyttää varastetut vastaukset uudelleen — mallia ei tarvitse ajaa uudelleen.

06Miksi projekti on halpa

Kallein asia olisi kokeilla suoraan isolla mallilla pilvessä. Sen sijaan pieni 9B-malli kotikoneella on koko projektin kokeilu-alusta: se on riittävän hyvä, että sen tulokset ennustavat ison mallin, ja riittävän halpa, että sitä voi ajaa kahdeksan eri versiota. Kotikone: kaksi 16 GT:n RTX 5060 Ti:tä. QLoRA-adapteri mahtuu 16 GT kortille, ja adapteri itsessään on 166 MT (9B) tai 467 MT (27B).

Yhteensä koulutusdata + lopullinen koulutus: alle 25 dollaria. Validoinnin "pilvi" on oma yö ja omat laitteet: QEMU ~3 658 ajoa, laitteet ~3 400 ajoa. Projektista jäi sääntö: halpa tarpeeksi iteroimaan, kallis tarpeeksi savutestaamaan ensin — jokaisen 27B-kokeen edessä on aina 5 max-steps-savutesti.

07Lopullisen mallin opetus (27B)

27B ei mahdu 16 GT kortille koulutettavaksi, joten lopullinen koulutus ajettiin Modalissa H100 80 GT:lla — sama train_qlora.py-skripti, sama v2-data, sama resepti kuin kotikoneella. Asetelma: unsloth/Qwen3.8-27B-unsloth-bnb-4bit, oppimisnopeus 7e-5, max-seq 4096, 2 epochia. Tulos: 494 askelta, 1 h 33 min, eval-loss 0,087, adapteri 467 MT GGUF. Vain skripti ja SFT-tiedostot lähetettiin pilveen — pidätetty data ja avaimet jäivät kotiin.

Adapteri tuotiin takaisin kotiin: Qwen3.8-27B Q6_K_L -base + DFlash-draft, molemmat GPU:t, ei ajattelua (kuten koulutettu), nimellä qwen38-27b-freertos-v2 llama-swap-palvelussa — 40–50 tokenia sekunnissa.

Tulokset

Alueittain (pääbenchmark, perus → säädetty): tasks 28 → 76, sync 53 → 65, memory 49 → 58, isr 45 → 62. Paikallinen, kapealle alalle koulutettu 27B ylitti pilvipalvelun gpt-oss-120b:n kapeilla FreeRTOS-tehtävillä — ja tekee sen kotikoneella, 40–50 tok/s, ilman token-hintoja.

Rehellisesti: mikä ei parantunut

• Bugien etsintä heikkeni (67 → 46, 9B:llä 61 → 38) ja tietovisa laski hieman (91 → 88). Syyt: v2-reseptin bugidatassa oli liian vähän virheitä per näyte (1,2 vs. benchmarkin 7,2), kapea operaattorivalikoima ja "erojen havaitseminen"-lyhyt polku. Korjaus on käynnissä: itseadistillointi hylkäysnäytteineen, mutaatiot koodiin, jota malli ei itse kirjoittanut, realistiset virheiden lukumäärät (4–10) ja 59 tiedoston pidätetty bugeval-joukko. Parhaan adapterin (v7) F1 on 75,0 (recall 0,72 / precision 0,80) — yhä alle perusmallin 61:n, ja se tiedostetaan.
• Luvut eivät tule oikealta raudalta Wi-Fi-, Bluetooth- ja oheislaitetehtävissä: ne mitataan oikealla käännöksellä ja vaatimustarkistuksilla, ei radiota käyttäen. Simulaattori on yksiydininen, joten kahden ytimen todellisia kilpailutilanteita ei nähdä.
• Yksi käännösvirhe heiluttaa 3-tehtävän aluetta ~20 pistettä. Siksi toistoja — ja siksi pienen alueen tuloksia ei tulkita ilman kontekstia.

08ESP32-laitteet projektissa

Projektin rauta on tarkoituksella halpaa, saatavilla olevaa ja luotettavaa ESP32-sarjaa — samaa perhettä, jota tuhannat tuotteet käyttävät. Laitekanta:

Laiteella on kolme eri roolia, jokaisella eri hinta:

• Oikea ESP-IDF-käännös jokaisessa kooditehtävässä — ei vaadi laitteistoa, mutta paljastaa keksityt ja vanhentuneet API:t ilman, että laitetta koskaan nähdään. Tämä on idf_build-osion koko pointti.
• QEMU ajaa oikean käännöksen virtuaalichipissä: stack-kaanarit, ajastimet, 1–2 ydin — silta simulaattorin ja raudan välillä.
• Oikea laitteisto on viimeinen validointitaso: jokainen mutation ajetaan laitteessa, ja uudet laitteistoperheet (I2C/SPI-paineanneuri, 1-Wire-lämpötila, ultrasonic, AT-modemi) syntyvät rigoista.

Mitä laitteistoa ei voi mitata: Wi-Fi, BLE, I2C, UART, ADC, LEDC. Ne saavat pistensa oikealta käännökseltä ja vaatimustarkistuksilta, ja puhtaan logiikan (backoff-matematiikka, lomakkeen jäsennys) on eristetty host-testattavaan tiedostoon. Se on rajan, mitä voidaan mitata luotettavasti ja mitä ei — ja se kerrotaan tulosten yhteydessä aina.

09RL-menetelmä: RLCD

Tarkkuus heti alkuun: fbenchin koulutus itsessään on valvottua (QLoRA/SFT) — palkintosignaalia siinä ei ole. Projektin vahvistusopetuskäyttö on päätösmalli, jota käytettiin koodikatselmusmerkintöjen paikallisena toisena mielipiteenä (taso 4). Sen koulutusmenetelmä on RLCD — Reinforcement Learning for Calibrated Decisions, kuten malli convaiinnovations/laya (Apache 2.0) dokumentoi:

• Policy on jakauma, ei teksti. Malli ei generöi — se raportoi kunkin vaihtoehdon todennäköisyydet yhdellä eteneväisellä kululla (~33 ms). Ei tekstiä, ei parseerausta, ei hallusinaatioita.
• Eksplorointi: nollakeskinen Gaussin-kohina logitteihin ennen otantaa.
• Palkinto on strikti oikea pisteesääntö (log + spherical; järjestyskysymyksille ranked probability score). Sillä on matemaattinen ominaisuus: odotuspalkinto maksimoidaan ainoastaan rehellisten todennäköisyyksien raportoinnilla. Päättely tai yliarvostus pienentää odotuspalkintoa — palkintohakua ei voi harhautella.
• Päivitys: REINFORCE ryhmäkeskiarvobaseeinella (GRPO-tyyli); monikierroksisissa keskusteluissa TD(λ=1.0).

RLCD käytössä tässä projektissa

Päätösmalli pyörittiin kokonaan paikallisesti (llama-palvelin, /v1/systemone) — koodikatselmusdatan ei sallittu poistua koneelta. Laya (421M) mitattiin 30 katselmatiedostolla (149 todellista merkintää) ja rikotulla kopioilla: AUC 0,64 → hylättiin (kynnys > 0,85). Qwen3.8-27B (Q3_K_XL) mitattiin samalla protokolalla: AUC 0,963 → otettiin käyttöön, kynnys p(TRUE) ≥ 0,1. Tämä on RLCD:n koko pointti käytännössä: mallin todennäköisyys on käytettävissä tuomion kynnäksinä, koska koulutus on palkinnut rehellisyyden — ja kalibrointi osoitti ennen käyttöä, kenen todennäköisyyksiä voi luottaa.

10Mitä opin

1. Tarkista kaikki automaattisesti. Kun pisteet tulevat kääntäjältä ja testeiltä, vastaus on joko oikein tai väärin, ja jokainen virhe jäljitettävissä. Anna testeille myös rikottuja ratkaisuja — jos testi ei kaada niitä, se ei mitaa mitään.
2. Pidä osa perheistä vain testissä. Ensimmäinen 9B-parannus näkyi opetuksissa perheissä, mutta ei näkemättömissä: malli oli oppinut kaavat, ei FreeRTOSia. Ilman kanarioita tätä ei olisi huomattu.
3. Toista kohinalliset mittaukset. Kolme toistoa erotti todellisen eron sattumasta — ja valitsi oikean reseptin 27B-ajoon.
4. Kokeile ensin pienellä mallilla. 9B-iteraatiot kotikoneella olivat ilmaisia verrattuna 27B-pilveen, ja niiden perusteella valittu resepti toimi suoraan.
5. Oleta, että vuoto hyödynnetään. Hiekkalaatikoton koodausagentti löysi piilotetut testit ja luki ne. Agentti ajetaan nyt bubblewrapissa, jossa testit näkyvät tyhjinä hakemistona.
6. 30 GT koneella muisti loppuu. Kun toinen malli ja selaimet varasivat muistia, isomman mallin lataaminen sai systemd-oomd:n tappamaan kaiken. Nyt: yksi malli kerrallaan, muisti tarkistetaan ennen latausta, ja palvelimelle on valvontakoodi, joka nostaa sen automaattisesti näytönohjaimen aikakatkaisun jälkeen.