Enheter
1. Introduktion och gränser för AI inom elektro- och elektronikteknik 2. Kretsanalys och designstöd 3. Inbyggda system och mikrokontrollerkod 4. Signalbehandling och dataanalys 5. Styrsystem Design Support 6. Kraftsystem och energianalys 7. PCB-design och hårdvarudokumentation 8. Automation, PLC Logik och Sensor/IoT Data 9. Standardforskning, simulering och ansvarighet med Python
Enhet 3 / 9

Inbyggda system och mikrokontrollerkod

Vinster:

  • Möjlighet att definiera register, avbrott och tidskrav för mikrokontrollern med en tydlig prompt
  • Möjlighet att kontrollera C/Arduino-koden som produceras av AI när det gäller registerinställningar, buffertspill och realtidsbegränsningar
  • Möjlighet att tillämpa vanan att verifiera den genererade koden genom att mäta den på hårdvara (oscilloskop, seriell port)

Utveckling av inbyggda system är där mjukvara och hårdvara skär varandra: att ställa in en registerbit felaktigt, hålla ett avbrott för länge eller att fylla över en buffert kommer att orsaka konstiga, svåråterskapliga fel i fältet, även om koden "kompileras" och körs. AI är verkligen en accelerator inom detta område; Den kan producera initiala skelett, hårdvaruabstraktionsfunktioner, tillståndsmaskiner och kommunikationsrutiner. Men AI ser inte ditt korts datablad, känner inte till din klockfrekvens och känner inte av dina realtidsbegränsningar. I den här enheten kommer vi att täcka hur man tydligt definierar mikrokontrollerarbete till AI, hur man kontrollerar den genererade C/Arduino-koden och varför du bör mäta allt i hårdvara.

Definiera kravet tydligt: Register, Cutting, Timing

Att säga till AI att "tända en lysdiod" fungerar inte; Vilket kort, vilket stift, vilken klockfrekvens, vilken timing? När du tilldelar en inbäddad uppgift till AI, använd detta ramverk: hårdvara (MCU-familj, klocka, stift), funktion (vad kommer att hända), begränsning (timing, ström, minne) och gränssnitt (register, HAL, Arduino-bibliotek).

Svag prompt / Stark prompt

SVAG: "Producera PWM med STM32." (Resultat: vilken timer, vilken frekvens, vilket stift är oklart; allmänt, troligtvis fel registernamnkod.) STARK: "Producera 20 kHz, 0-100% justerbar belastning PWM på TIM3 CH1 (PA6) för STM32F103 (72 MHz systemklocka). Skriv på registernivå (inte HAL HAL och kHRR-värden visar CALC0Z-värdena och CALC0Z-beräkningarna). i kommentarsraden - Ställ in plikten med en funktionsparameter mellan 0-100 - Kommentera varje registerbit som du använder.

Skillnaden är att den kraftfulla prompten får modellen att visa beräkningen och avslöja klockantagandet. Så du kan kontrollera prescaler/ARR-värdena oberoende av varandra:

För 20 kHz PWM (72 MHz klocka): Timer_clock = 72 MHz Om vi vill ha förskalare = 72-1 → räknarklocka = 1 MHzARR = (1 MHz / 20 kHz) - 1 = 50 - 1 = 49Verifiering: 1e6 / (49+1) = 20 000 Hz

Granskning av AI-kod: Vad ska man leta efter?

Bara för att den genererade koden kompilerar betyder det inte att den fungerar korrekt. Följ denna checklista:

kontrollområde

Vad ska man leta efter

Register/bitinställningar

Exakt kompatibel med datablad, korrekt bitmask

Avbrott (ISR)

Är den kort? Ingen blockerare fördröjning? Används flyktigt?

buffert/array

Finns det gränskontroll? Risk för översvämning?

timing

Med fördröjning eller timer? Är den faktiska tidsbegränsningen uppfylld?

Typ och bredd

8/16/32-bitars spill, signerad/osignerad förvirring

makt/vakthund

Oändlig loop matning vakthund?

Avbrottsservicerutiner (ISR) är den vanligaste felkällan. AI lägger ibland delay() eller lång loop inuti ISR. Detta leder till att andra avbrott missas och watchdog återställs. Regel: ISR ska vara så kort som möjligt; Huvuduppgiften bör vara att sätta upp en flagga och flytta den till huvudslingan.

// SVAG (AI producerar ibland detta): Blockerfunktion i ISR ​​void TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; read_sensor(); // kan ta lång tid - BAD CASE_Delay(10); // fördröjning i ISR ​​- MYCKET DÅLIG }}// STARK: ISR kort; jobbet flyttas till huvudslingan uint8_t tick_flag = 0; // volatile CONDITIONvoid TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; tick_flag = 1; //ställ bara in flaggan }}// i huvudslingan:if (tick_flag) { tick_flag = 0; read_sensor(); }

Varning: Alla variabler som delas mellan avbrottet och huvudslingan måste vara flyktiga. Annars kan kompilatorn cachelagra variabeln i registret och missa uppdateringen. AI glömmer ofta detta nyckelord; Leta efter det specifikt när du läser koden.

Buffertspill och typfel

AI kan kopiera data från serieporten till en array med fast storlek utan kontroll av gränser. I ett inbäddat system innebär detta att det sammanhängande minnet krossas och oförklarliga krascher. Se till att gränsen kontrolleras vid varje strcpy, arrayindex och DMA-buffert. På liknande sätt återställs en 8-bitars räknare efter 255; AI kan ignorera detta och lita på ett överfyllt konto.

Verifiering i hårdvara: "Fungerande" är mätt, inte antaget

I ett inbyggt system är det mest tillförlitliga beviset mätaren, inte kompilatorn. Verifiera den genererade koden på dessa tre sätt:

  1. Oscilloskop/logikanalysator: Mät PWM-frekvens, signaltiming och kommunikationsvågform. Om du ville ha 20 kHz, se 20 kHz på skärmen.
  2. Seriell port (UART) logg: Skriv ut variabelvärden, tillståndsövergångar och felräknare och jämför med förväntat beteende.
  3. Bound and stress testing: Testa om systemet håller sig under den högsta belastningen, snabbaste data och sämsta timing.

Om det uppmätta värdet inte stämmer överens med beräkningen är klockantagandet, förskalningsvärdet eller registerinställningen felaktig; jaga.

Minifodral

Ett team av studenter låter AI skriva ut en avståndsmätningskod med en HC-SR04 ultraljudssensor. Koden kompilerar men avståndet ger alltid löjliga värden. När de ansluter det till oscilloskopet ser de att ekobenet beräknar sin timing i millisekunder istället för mikrosekunder; AI använde millis() istället för micros(). Detta ettordsfel förvirrade hela mätningen med en faktor 1000. När de skriver ut den råa ekotiden i serieloggen och jämför den med en riktig linjal, hittar de felet och fixar det. Lektion: kompilerad kod är inte korrekt kod; Mätning i hårdvara avslöjar felet omedelbart.

Vanliga misstag

  • Accepterar registernamn och bitmasker utan att jämföra dem med databladet.
  • Tillåter blockeringsfördröjning eller lång bearbetning inom ISR.
  • Att glömma flyktigt på delade variabler.
  • Förbigå kontroll av buffert och arraygränser; ser inte brädden.
  • Att förlita sig på klockfrekvens och tidsantaganden utan att verifiera dem.
  • Anser att koden "fungerar" utan att mäta den med oscilloskop/seriell logg.

Sammanfattningsvis

  • Definiera tydligt den inbäddade uppgiften i termer av hårdvara, funktion, begränsningar och gränssnitt.
  • Låt AI:n beräkna tidsvärden som förskalare/ARR och verifiera dem oberoende.
  • Håll ISR korta, använd volatile på delade variabler.
  • Leta specifikt efter register, buffertgräns och typbreddsfel.
  • "Det fungerar" är bevisat med ett oscilloskop, logikanalysator och seriell logg, inte med kompilatorn.
  • Om det uppmätta värdet inte stämmer överens med beräkningen, jaga antagandena.

Applikationsuppgift

Med en mikrokontroller du har (Arduino, STM32, ESP32), be AI:n om PWM eller en periodisk uppgift vid en viss frekvens. Innan du laddar koden: (1) verifiera frekvens-/tidsvärdena oberoende av kontot i kommentarsraden, (2) kontrollera om det är flyktigt och blockerande i ISR ​​och delade variabler. Efter uppladdning, mät den faktiska frekvensen med ett oscilloskop eller logikanalysator och jämför den med målet. Om det finns en avvikelse, leta reda på källan och korrigera den och notera vad som antogs vara fel.

Tidigare Nästa