Enheder
1. Introduktion og grænser for kunstig intelligens i elektro- og elektronikteknik 2. Kredsløbsanalyse og designsupport 3. Indlejrede systemer og mikrocontrollerkode 4. Signalbehandling og dataanalyse 5. Styresystemer Design Support 6. Strømsystemer og energianalyse 7. PCB Design og Hardware Dokumentation 8. Automation, PLC Logik og Sensor/IoT Data 9. Standard forskning, simulering og ansvarlighed med Python
Enhed 3 / 9

Indlejrede systemer og mikrocontrollerkode

Gevinster:

  • Evne til at definere register-, interrupt- og timingkrav til mikrocontrolleren med en klar prompt
  • Evne til at kontrollere C/Arduino-koden produceret af AI med hensyn til registerindstillinger, bufferoverløb og realtidsbegrænsninger
  • Evne til at anvende vanen med at verificere den genererede kode ved at måle den på hardware (oscilloskop, seriel port)

Indlejret systemudvikling er, hvor software og hardware krydser hinanden: At indstille en registerbit forkert, holde en interrupt for længe eller overfylde en buffer vil forårsage mærkelige, svære at gengive fejl i feltet, selvom koden "kompileres" og kører. AI er virkelig en accelerator på dette område; Det kan producere indledende skeletter, hardwareabstraktionsfunktioner, tilstandsmaskiner og kommunikationsrutiner. Men AI kan ikke se dit korts datablad, kender ikke din urfrekvens og fornemmer ikke dine realtidsbegrænsninger. I denne enhed vil vi dække, hvordan man klart definerer mikrocontroller-arbejde til AI, hvordan man kontrollerer den genererede C/Arduino-kode, og hvorfor du skal måle alt i hardware.

Tydelig definition af kravet: Register, Cutting, Timing

At bede AI om at "tænde en LED op" virker ikke; Hvilket kort, hvilken pin, hvilken clockfrekvens, hvilken timing? Når du tildeler en indlejret opgave til AI, skal du bruge denne ramme: hardware (MCU-familie, ur, pin), funktion (hvad vil ske), begrænsning (timing, strøm, hukommelse) og grænseflade (register, HAL, Arduino-bibliotek).

Svag prompt / stærk prompt

SVAG: "Producer PWM med STM32." (Resultat: hvilken timer, hvilken frekvens, hvilken pin er uklar; generelt, sandsynligvis forkert registernavnet kode.) STÆRK: "Producer 20 kHz, 0-100% justerbar duty PWM på TIM3 CH1 (PA6) for STM32F103 (72 MHz systemur). Skriv på registerniveau (ikke HAL HAL og kHz-værdier viser CALC0RR-værdien og CALC0Z-værdien). i kommentarlinjen - Indstil pligten med en funktionsparameter mellem 0-100 - Kommenter hver registerbit, du bruger.

Forskellen er, at den kraftige prompt får modellen til at vise beregningen og afsløre urantagelsen. Så du kan kontrollere prescaler/ARR-værdierne uafhængigt:

For 20 kHz PWM (72 MHz ur): Timer_clock = 72 MHzHvis vi ønsker prescaler = 72-1 → tæller = 1 MHzARR = (1 MHz / 20 kHz) - 1 = 50 - 1 = 49Verifikation: 1e6 / (49+1) = 20 000

Revision af AI-kode: Hvad skal man kigge efter?

Bare fordi den genererede kode kompilerer, betyder det ikke, at den fungerer korrekt. Følg denne tjekliste:

kontrolområde

Hvad skal man kigge efter

Indstillinger for register/bit

Præcis kompatibel med datablad, korrekt bitmaske

Interrupt (ISR)

Er den kort? Ingen blokeringsforsinkelse? Bruges flygtige?

buffer/array

Er der grænsekontrol? Risiko for overløb?

timing

Med forsinkelse eller timer? Er den faktiske tidsbegrænsning opfyldt?

Type og bredde

8/16/32-bit overløb, underskrevet/usigneret forvirring

magt/vagthund

Infinite loop fodring vagthund?

Interrupt Service Routines (ISR) er den mest almindelige kilde til fejl. AI sætter nogle gange delay() eller lang loop inde i ISR. Dette fører til, at andre afbrydelser bliver overset og vagthund nulstilles. Regel: ISR skal være så kort som muligt; Hovedopgaven bør være at sætte et flag op og flytte det til hovedsløjfen.

// SWAG (AI producerer nogle gange dette): Blocker-funktion i ISR ​​void TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; read_sensor(); // kan tage lang tid - BAD CASE_Delay(10); // forsinkelse i ISR ​​- MEGET DÅRLIG }}// STÆRK: ISR kort; job flytter til hovedsløjfevolatile uint8_t tick_flag = 0; // volatile CONDITIONvoid TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; tick_flag = 1; //just set flag }}// i hovedløkke:if (tick_flag) { tick_flag = 0; read_sensor(); }

Forsigtig: Enhver variabel, der deles mellem afbrydelsen og hovedsløjfen, skal være flygtig. Ellers kan compileren cache variablen i registret og gå glip af opdateringen. AI glemmer ofte dette søgeord; Se specifikt efter det, når du læser koden.

Bufferoverløb og typefejl

AI kan kopiere data fra den serielle port til et array med fast størrelse uden kontrol af grænser. I et indlejret system betyder dette at knuse sammenhængende hukommelse og uforklarlige nedbrud. Sørg for, at grænsen er kontrolleret ved hver strcpy, array index og DMA buffer. På samme måde nulstilles en 8-bit tæller efter 255; AI kan ignorere dette og stole på en overfyldt konto.

Verifikation i hardware: "Working" er målt, ikke antaget

I et indlejret system er det mest pålidelige bevis måleren, ikke compileren. Bekræft den genererede kode på disse tre måder:

  1. Oscilloskop/logisk analysator: Mål PWM-frekvens, signaltiming og kommunikationsbølgeform. Hvis du ønskede 20 kHz, se 20 kHz på skærmen.
  2. Seriel port (UART) log: Udskriv variabelværdier, tilstandsovergange og fejltællere og sammenlign med forventet adfærd.
  3. Bundet og stresstest: Test om systemet holder under den højeste belastning, hurtigste data og dårligste timing.

Hvis den målte værdi ikke stemmer overens med beregningen, er urantagelsen, prescalerværdien eller registerindstillingen forkert; jage.

Mini etui

Et hold studerende har AI-printet en afstandsmålingskode med en HC-SR04 ultralydssensor. Koden kompilerer, men afstanden giver altid latterlige værdier. Når de forbinder det til oscilloskopet, ser de, at ekkobenet beregner sin timing i millisekunder i stedet for mikrosekunder; AI brugte millis() i stedet for micros(). Denne et-ords fejl forvirrede hele målingen med en faktor på 1000. Når de udskriver den rå ekkotid i den serielle log og sammenligner den med en rigtig lineal, finder de fejlen og retter den. Lektion: kompileret kode er ikke korrekt kode; Måling i hardware afslører fejlen med det samme.

Almindelige fejl

  • Accept af registernavne og bitmasker uden at sammenligne dem med dataarket.
  • Tillader blokeringsforsinkelse eller lang behandling inden for ISR.
  • At glemme flygtige på delte variabler.
  • Bypass buffer og matrixgrænsekontrol; ikke at se overløbet.
  • Stoler på clockfrekvens og timingantagelser uden at verificere dem.
  • Overvejer at koden "virker" uden at måle den med et oscilloskop/seriel log.

Sammenfattende

  • Definer klart den indlejrede opgave med hensyn til hardware, funktion, begrænsninger og interface.
  • Få AI til at beregne timingværdier såsom prescaler/ARR og verificere dem uafhængigt.
  • Hold ISR'er korte, brug volatile på delte variabler.
  • Se specifikt efter fejl i register, buffergrænse og typebredde.
  • "Det virker" er bevist med et oscilloskop, logisk analysator og seriel log, ikke med compileren.
  • Hvis den målte værdi ikke stemmer overens med beregningen, forfølge antagelserne.

Ansøgningsopgave

Med en mikrocontroller du har (Arduino, STM32, ESP32), spørg AI'en om PWM eller en periodisk opgave med en bestemt frekvens. Før du indlæser koden: (1) verificer frekvens-/timingværdierne uafhængigt af kontoen i kommentarlinjen, (2) kontroller for flygtige og blokerende i ISR ​​og delte variabler. Efter upload skal du måle den faktiske frekvens med et oscilloskop eller en logisk analysator og sammenligne den med målet. Hvis der er en afvigelse, skal du finde kilden og rette den, og notere, hvad der blev antaget forkert.

Tidligere Næste