En professionel Guide til debugging-værktøjer og teknikker til IoT-enheder

Udviklingen af et embedded system, hvor software og hardware skal fungerer i synergi, er blevet ekstremt kompleks og udfordrende, selv for hvad der kan virke som de mest enkle Internet of Things (IoT)-enheder. Så meget, at når noget går galt - som det uundgåeligt vil - tager det normalt ikke et par timer a finde fejlen, men kan i stedet tage uger eller måneder. Disse forsinkelser tilføjer udviklingsomkostninger, forhindrer et produkt i at komme på markedet til tiden, forsinker produktionsplaner og ødelægger forsyningskæder og forretningsplaner.

Den bedste måde at reducere den tid der bruges på fejlfinding (debugging) og holde et projekt på sporet er at bruge en kombination af hardware-debuggere og frit tilgængelig software til at få indsigt i, hvordan et system fungere, og hvor problemerne opstår. Som sådan, for fagfolk og hobbyfolk, hjælper det meget at have de rigtige værktøjer til jobbet for at få det gjort hurtigt og korrekt.

Denne artikel vil diskutere udviklingsværktøjer og software, der kan bruges til at debugge og analysere en IoT-enheds ydeevne. Vi vil bruge et udviklingskort fra STMicroelectronics som et eksempel på en IoT-enhed og bruge SEGGER Microcontroller Systems' værktøjer og software til at forstå og debugge systemet. Vi vil også diskutere flere tips og tricks til, hvordan man minimerer debugging så et IoT-projekt kan levereds til tiden.

Den typiske IoT-enhed, der skal debugges

IoT-enheder er blevet udbredt i næsten alle brancher, fra det smarte hjem til industriel overvågningskontrol. Trods de mange forskellige applikationer er der typisk flere komponenter, som en IoT-enhed har brug for. Disse inkluderer:

• En mikroprocessor
• En radio for konnektivitet
• Sensorer

En udvikler ønsker ikke at definere deres eget kort til at udforske debug-teknikker eller til at teste stykker af deres applikationskode. Det er for tidskrævende. I stedet er det smartere at arbejde på et billigt udviklingskort som STMicroelectronics' B-L4S5I-IOT01A Discovery Kit til IoT-noder. Kortet har næsten alt, hvad der findes på en typisk IoT-enhed (figur 1).

Figur 1: STMicroelectronics B-L4S5I-IOT01A Discovery Kit til IoT-noder indeholder alle de komponenter, der typisk kræves i en IoT-enhed. (Billedkilde: STMicroelectronics)

Kortet inkluderer STM32L4S5VIT6 som er en Arm® Cortex®-M4 mikrokontroller, der kører ved 120 megahertz (MHz). Dette understøttes af op til 2 megabyte (Mbyte) flash og 640 kilobyte (Kbyte) RAM. Hvad der er vigtigt i forbindelse med denne øvelse er at kortet indeholder Wi-Fi og et væld af sensorer, der kan bruges til at lave en hurtigt mock-up IoT-testenhed.

Professionelle debugging-værktøjer

Næsten alle udviklingskort leveres med en indbygget JTAG/SWD-interface, så udviklere ikke behøver at gå ud og hente deres egen programmør. I stedet kan de arbejde med udviklingskortet direkte ud af kassen. Mens dette er fantastisk til markedsføringsformål, er det ikke speciel fantastisk til reel debugging: indbyggede debuggere er ofte versioner som skaleret dramatisk ned og har begrænsninger, såsom antallet af breakpoints og baud-hastighed. For de uindviede virker disse begrænsninger måske ikke som et problem, men ved at have ubegrænsede antal breakpoints undgår man at skulle aktivere og deaktivere breakpoints konstant, og applikationssporing (mere om sporing i softwareværktøjsafsnittet) kræver hurtige baudhastigheder.

Der er flere forskellige værktøjer til rådighed, der kan give en professionel debug-oplevelse, men selve værktøjerne er kun halvdelen af løsningen. Værktøjerne skal understøttes af god software. Et sæt værktøjer, der skiller sig ud, set fra et hardware- og softwareperspektiv, er SEGGER J-Link-serie. Denne serie har en debugger version til næsten enhver type udvikler, lige fra studerende og hobbyfolk til hardcore fagfolk.

Der er to modeller, som erfaring har vist at være de mest nyttige for den generelle udvikler: J-Link-base og J-Link Ultra+ (Figur 2). Formfaktormæssigt er de to enheder identiske, men J-Link Ultra+ giver en udvikler hurtigere downloadhastigheder til RAM (3 Mbytes/s vs. 1.0 Mbyte/s) og en hurtigere SWD-interfacehastighed (100 MHz i stedet for 30 MHz). De hurtigere hastigheder gør hele forskellen, når en udvikler ønsker at trace deres applikation for at få indsigt i performance, RTO'ERNES adfærd og debugge systemet.

Figur 2: SEGGER J-Link Ultra+ giver udviklere en forbedret debugging-oplevelse igennem et 50 MHz interface. (Billedkilde: SEGGER Microcontroller Systems)

Det smarte ved J-Link og B-L4S5I-IOT01A-udviklingskortet er, at de kan forbindes via et Tag-Connect TC2050-IC-NL kabel og TC2050-CLIP-3PACK fastholdelsesklips. Disse gør det muligt at tilslutte en debugger til udviklingskortet stift-puden (nails pad) (figur 3). Det kan være nødvendigt at tilpasse J-Link's 20-benede konnektor til det 10-benede konnektor på TC-2050-kablet. En mulighed, der kan bruges til dette, er 8.06.04 J-Link 10-polet stift-adapter.

Figur 3: På B-L4S5I-IOT01A-udviklingskortet kan Tag-Connect-kabelsamlingen tilsluttes via et stift-pude lignende PC-kort forbindelsespunkter (til højre). (Billedkilde: STMicroelectronics)

Når en udvikler har lukket denne sti på hardwaresiden, kan de bruge softwareværktøjerne til at analysere og debugge deres applikation.

Professionelle debugging-softwareværktøjer

Der er en hel del softwareværktøjer, der fungerer ganske godt med SEGGER J-Link og som ikke leveres af SEGGER. Følgende vil vi tage et kig på flere af disse gratis værktøjer og se, hvordan udviklere kan bruge hver af disse debuggere til deres software.

Først er J-Scope. J-Scope er et oscilloskop-lignende værktøj, der viser variablers værdier over tid. Udviklere kan overvåge en enkelt variabel eller adskillige variabler. Bemærk dog, at efterhånden som flere variabler overvåges, kan der udtages færre samplinger inden bufferen er fuld, og data går tabt.

Variabler vælges ved at give J-Scope en .elf fil, der genereres af kompilatoren. Dette giver de hukommelsesplaceringer, der skal læses, og udvikleren kan derefter indstille samplingshastigheder og overvåge, hvordan variablen/variablerne ændrer sig over tid. Et simpelt eksempel på et tre-variabelt trace kan ses i figur 4.

Figur 4: J-Scope kan bruges til at overvåge variabler igennem J-Link, mens et program kører i realtid. (Billedkilde: SEGGER Microcontroller Systems)

Næste er Ozon. Ozon er en debug-interface og performanceanalysator. Udviklere kan indlæse deres .elf fil i værktøjet og udføre debugging på kildeniveau. De kan indstille breakpoints og opdatere deres kode. En særlig nyttig funktion for udviklere er at de også kan udføre trace instruktioner (hvis deres hardware understøtter det) og identificere, hvilken moduler og linjer C-kode som er blevet udført. Dette er især nyttigt til at verificere kodedækning af HiL (hardware-in-loop)-testning.

Ozon kan også hjælpe udviklere med at analysere deres system-performance(figur 5) og visualisere variabler over tid. Dette giver det samme som J-Scope, men på en mere integreret måde. Det kan endda bruges til at overvåge strømforbruget og synkronisere alle disse events på ét sted.

Figur 5: Ozon kan bruges til at trace variabler igennem J-Link, mens et program kører i realtid ud over kodedækning og RTOS-debugging. (Billedkilde: SEGGER Microcontroller Systems)

Et tredje værktøj er SystemView. SystemView giver udviklere mulighed for at analysere deres RTOs-systems runtime-adfærd. Opgaveskift registreres i en trace-buffer og rapporteres derefter til SystemView via debuggeren (figur 5). SystemView viser derefter disse oplysninger på en måde, der giver en udvikler mulighed for at se kontekstskift og måle systemets performance. Dette er også en fremragende måde at visualisere et system og finde fejl og andre problemer.

Figur 6: SystemView giver et link til et RTOS, der giver udviklere mulighed for at måle performance af ​​opgaver og se operationerne i en RTOS. (Billedkilde: SEGGER Microcontroller Systems)

Tips og tricks til debugging af et embedded system

Debugging af en IoT-enhed kræver, at udviklere har både de rigtige værktøjer set fra et hardware- og softwareperspektiv. Begge dele skal være på plads, hvis udviklere skal minimere den tid, de bruger på debugging. For at debugge med succes er der flere “tips og tricks" udviklere, skal huske på f.eks.:

• Brug en professionel debugger, der maksimerer baud-hastigheden. Mængden af nyttige data, der kan indhentes fra et system, afhænger af, hvor hurtigt disse data kan modtages. Langsommere hastigheder resulterer i en længere debugging-tid.
• Konfigurer debug-softwaren tidligt i udviklingscyklussen. Udviklere bør ikke vente, indtil de har et problem med at sætte deres debug-værktøjer op.
• Brug trace-værktøjer fra starten af ​​udviklingen. Dette vil give udviklere mulighed for at overvåge system performance og straks forstå, hvordan softwareændringer påvirker det.
• Udnyt tracing af instruktioner eller programtællerprøvetagning til at forstå systemkodedækning under test. Fejl vil eksistere i betingede grene og kode som ikke er testet.
• Udnyt hurtige overførselsprotokoller for at få data offchip såsom realtids-overførselsbiblioteker (RTT).

Udviklere, der følger disse “tips og tricks", vil opdage, at de sparer en hel del tid og sorg, når de forsøger at udvikle en IoT-enhed.

Konklusion

Software til IoT-enheder er blevet kompleks, men det betyder ikke, at professionelle eller hobbyudviklere skal sidde og debugge systemer konstant. Brug af professionelle udviklingsværktøjer og software kan give udviklerne den indsigt, de har brug for, ikke blot til at debugge et system, men også til at analysere og forbedre deres systemers performance. Ved at investere i disse værktøjer kan brugerne dramatisk reducere den tid, der bruges på debugging, og få deres projekter til at fungere og markedsføre disse inden for en rimelig tidsramme.