Egység 3 / 9

Beágyazott rendszerek és mikrokontroller kód

Nyereség:

  • Lehetőség a regiszter, megszakítás és időzítés követelményeinek meghatározására a mikrokontroller számára egyértelmű prompt segítségével
  • Lehetőség az AI által előállított C/Arduino kód ellenőrzésére a regiszterbeállítások, a puffer túlcsordulás és a valós idejű korlátok tekintetében
  • A generált kód hardveren (oszcilloszkóp, soros port) történő méréssel történő ellenőrzésének képessége

A beágyazott rendszerek fejlesztése az a hely, ahol a szoftver és a hardver találkozik: a regiszterbit helytelen beállítása, a megszakítás túl hosszú tartása vagy a puffer túlcsordulása furcsa, nehezen reprodukálható hibákat okoz a terepen, még akkor is, ha a kód "lefordít" és fut. Az AI valóban gyorsító ezen a területen; Előállíthat kezdeti vázakat, hardveres absztrakciós függvényeket, állapotgépeket és kommunikációs rutinokat. De a mesterséges intelligencia nem látja a kártya adatlapját, nem ismeri az órajel frekvenciáját, és nem érzékeli a valós idő korlátozásait. Ebben az egységben bemutatjuk, hogyan lehet egyértelműen meghatározni a mikrokontroller munkáját az AI-hoz, hogyan ellenőrizhető a generált C/Arduino kód, és miért érdemes mindent hardveren mérni.

A követelmény egyértelmű meghatározása: lajstromozás, vágás, időzítés

Nem fog működni, ha azt mondjuk az AI-nak, hogy „gyújtson fel egy LED-et”; Melyik kártya, melyik tű, melyik órajel, melyik időzítés? Amikor beágyazott feladatot rendel az AI-hoz, használja ezt a keretrendszert: hardver (MCU család, óra, pin), funkció (mi fog történni), megszorítás (időzítés, teljesítmény, memória) és interfész (regiszter, HAL, Arduino könyvtár).

Gyenge felszólítás / Erős felszólítás

GYENGE: "PWM előállítása STM32-vel." (Eredmény: melyik időzítő, melyik frekvencia, melyik érintkező nem egyértelmű; általános, valószínűleg hibás regiszter nevű kód.) ERŐS: "20 kHz-es, 0-100%-ban állítható terhelésű PWM előállítása a TIM3 CH1-en (PA6) az STM32F103-hoz (72 MHz-es rendszeróra). Írja be regiszterszinten (nem a HAL-hoz). a megjegyzés sorban - Állítsa be a funkciót 0 és 100 között.

A különbség az, hogy az erőteljes prompt arra készteti a modellt, hogy mutassa a számítást és felfedje az óra feltételezését. Így az előskálázó/ARR értékeket függetlenül ellenőrizheti:

20 kHz-es PWM (72 MHz órajel): Timer_clock = 72 MHz Ha előskálázót akarunk = 72-1 → számláló órajel = 1 MHzARR = (1 MHz / 20 kHz) - 1 = 50 - 1 = 49 Ellenőrzés: 1e6 / (49+1) = 20 00

AI-kód auditálása: mire kell figyelni?

Csak azért, mert a generált kód lefordítható, még nem jelenti azt, hogy megfelelően működik. Kövesse ezt az ellenőrző listát:

ellenőrzési terület

Mit kell keresni

Regisztrálás/bit beállítások

Pontosan kompatibilis az adatlappal, korrekt bitmaszk

Megszakítás (ISR)

Rövid? Nincs blokkoló késés? Illékony anyagot használnak?

puffer/tömb

Van határellenőrzés? Túlcsordulás veszélye?

időzítés

Késleltetéssel vagy időzítővel? Teljesül-e a tényleges időkorlát?

Típus és szélesség

8/16/32 bites túlcsordulás, aláírt/előjel nélküli zavar

hatalom/őrkutya

Végtelen hurok etető őrkutya?

A szolgáltatásmegszakítási rutinok (ISR) a leggyakoribb hibaforrások. Az AI néha késleltetést vagy hosszú hurkot helyez el az ISR-ben. Ez más megszakítások kimaradásához és a watchdog visszaállításához vezet. Szabály: Az ISR-nek a lehető legrövidebbnek kell lennie; A fő feladat egy zászló felállítása és a fő hurokra való áthelyezése.

// GYENGE (az AI néha ezt produkálja): Blocker függvény az ISR-ben void TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; read_sensor(); // sokáig tarthat - BAD CASE_Delay(10); // késleltetés az ISR-ben - NAGYON ROSSZ }}// ERŐS: ISR rövid; a job átkerül a fő hurokra uint8_t tick_flag = 0; // volatile CONDITIONvoid TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; tick_flag = 1; //csak állítsa be a jelzőt }}// a fő ciklusban:if (tick_flag) { tick_flag = 0; read_sensor(); }

Vigyázat: A megszakítás és a főhurok között megosztott bármely változónak illékonynak kell lennie. Ellenkező esetben előfordulhat, hogy a fordító gyorsítótárba helyezi a változót a regiszterben, és lemarad a frissítésről. Az AI gyakran elfelejti ezt a kulcsszót; Keresse meg kifejezetten a kód olvasásakor.

Puffer túlcsordulás és típushibák

A mesterséges intelligencia a soros portról fix méretű tömbbe másolhat adatokat a határok ellenőrzése nélkül. Egy beágyazott rendszerben ez az összefüggő memória összezúzását és megmagyarázhatatlan összeomlásokat jelenti. Győződjön meg arról, hogy a korlát minden strcpy-nél, tömbindexnél és DMA-puffernél be van jelölve. Hasonlóképpen, egy 8 bites számláló 255 után nullázódik; Az AI figyelmen kívül hagyhatja ezt, és a túlcsorduló fiókra hagyatkozhat.

Ellenőrzés hardverben: "Működik" mérve, nem feltételezve

Egy beágyazott rendszerben a legmegbízhatóbb bizonyíték a mérő, nem a fordító. Ellenőrizze a generált kódot a következő három módon:

  1. Oszcilloszkóp/logikai analizátor: Mérje meg a PWM frekvenciát, a jelidőzítést és a kommunikációs hullámformát. Ha 20 kHz-et szeretne, lásd a 20 kHz-et a képernyőn.
  2. Soros port (UART) napló: Nyomtassa ki a változó értékeket, állapotátmeneteket és hibaszámlálókat, és hasonlítsa össze a várt viselkedéssel.
  3. Kötött és stresszteszt: Tesztelje, hogy a rendszer bírja-e a legnagyobb terhelést, a leggyorsabb adatokat és a legrosszabb időzítést.

Ha a mért érték nem egyezik a számítással, az óra feltételezése, az előskálázó érték vagy a regiszter beállítása hibás; üldözés.

Mini tok

A tanulók egy csapatának AI kinyomtatja a távolságmérési kódot egy HC-SR04 ultrahangos érzékelővel. A kód lefordítja, de a távolság mindig nevetséges értékeket ad. Amikor csatlakoztatják az oszcilloszkóphoz, azt látják, hogy az echo láb az időzítést ezredmásodpercekben számítja ki mikroszekundum helyett; Az AI a millis()-ot használta a micros() helyett. Ez az egyszavas hiba 1000-szeresére megzavarta az egész mérést. Amikor kinyomtatják a nyers visszhangidőt a soros naplóba, és összehasonlítják egy valódi vonalzóval, megtalálják a hibát, és kijavítják. Tanulság: a lefordított kód nem megfelelő kód; A hardveres mérés azonnal feltárja a hibát.

Gyakori hibák

  • Regiszternevek és bitmaszkok elfogadása az adatlappal való összehasonlítás nélkül.
  • Blokkolási késleltetés vagy hosszú feldolgozás engedélyezése az ISR-en belül.
  • A megosztott változók volatilitásának elfelejtése.
  • A puffer és a tömb határainak megkerülése; nem látva a túlcsordulást.
  • Órafrekvenciára és időzítési feltételezésekre hagyatkozva azok ellenőrzése nélkül.
  • Úgy tekintve, hogy a kód "működik" anélkül, hogy oszcilloszkóppal/soros naplóval mérné.

Összefoglalva

  • Világosan határozza meg a beágyazott feladatot a hardver, a funkció, a megszorítások és az interfész szempontjából.
  • Az AI kiszámítja az időzítési értékeket, például az előskálázót/ARR-t, és függetlenül ellenőrizze őket.
  • Legyen rövid az ISR, a megosztott változóknál használjon volatilit.
  • Különösen keresse a regiszter, pufferkorlát és típusszélesség-hibákat.
  • A "működik" oszcilloszkóppal, logikai elemzővel és soros naplóval bizonyított, nem a fordítóval.
  • Ha a mért érték nem egyezik a számítással, kövesse a feltevéseket.

Pályázati feladat

Egy mikrokontrollerrel (Arduino, STM32, ESP32) kérjen az AI-tól PWM-et vagy időszakos feladatot egy bizonyos frekvencián. A kód betöltése előtt: (1) ellenőrizze a frekvencia/időzítési értékeket a fióktól függetlenül a megjegyzés sorban, (2) ellenőrizze az ingadozást és a blokkolást az ISR-ben és a megosztott változókban. Feltöltés után mérje meg a tényleges frekvenciát oszcilloszkóppal vagy logikai analizátorral, és hasonlítsa össze a céllal. Ha eltérés van, keresse meg a forrást, javítsa ki, és jegyezze fel, hogy mit feltételezett rosszul.