För att undersöka hur programmet exekveras på målsystemet behövs en verifika-tionsmetod. Det som avses är att kunna undersöka att programmet startar korrekt process vid korrekt tidpunkt, samt att processernas exekveringstid inte förhindrar funktionen av programmet. För att de två alternativen skall kunna jämföras skapas en gemensam specifikation för programmet, som sedan undersöks med de alterna-tiva metoderna. Programmet (kallat simpleDetect) är en enkel detektionsalgoritm, med extra funktioner för att hantera HMI i en KAR.
Programmet fungerar enligt följande: ADC samplar kontinuerligt i 10kHz. Vid överskridet tröskelvärde lagras 100 datapunkter. Funktionen för adc-sampling be-nämns func_adcSample() . Efter varje sampling kontrolleras värdet i en annan funktion med benämning func_detect(). Om tröskelvärdet är överskridet startar f unc_detect() lagring. Efter lagring genomförs en detektionsalgoritm med data-punkterna som indata, också den i func_detect(). HMI kontrolleras och uppdateras i en process som exekveras på interupt från knapp eller efter func_detect() slagit fast att ett skott avlossats. Den funktionen benämns func_hmi(). Programmet har därmed tre faser; 1. Kontinuerlig sampling (kallat normalläge), 2. Spara samples (kallad sparläge), 3. Analysera sparade samples (kallad analysläge). Programmet visas i ett diagram i figur 6.8. Metoden skall undersöka tidsåtgång för exekve-ring av samtliga funktioner (tf unc_adcSample, tf unc_detect, tf unc_hmi) samt verifiering av starten av exekveringen för varje funktion (tStartF unc_adcSample, tStartF unc_hmi, tStartF unc_detect). Metoden skall dessutom säkerställa att de separata funktionerna inte krockar vid exekveringen så att programmet fungerar som tänkt. Det är också av intresse att metoden kan verifiera hur ofta CPUn är i lågkraftsläge (tCP U of f) då ingen process körs mellan funktionsexekveringen. Då kan metoden användas för att undersöka batteritiden för en KAR.
6.3.1 Alternativ 1
För att utan extern utrustning kontrollera tf unc_adcSample, tf unc_detect, tf unc_hmi, används en timer. Timern uppdateras utan att ta tid från CPUn. I början av var-je funktion kontrolleras värdet på timern och skrivs till en variabel. När all re-levant kod i funktionen har körts läses timerns värde ut igen. Värdenas skillnad sparas och blir det antal klockcykler som funktionen har allokerat. Enligt följande:
tf unc = tstop− tstart. Tre statiska variabler skapas i programmet för att spara un-dan exekveringstiden för varje funktion. På liknande vis loggas starttiden för varje funktion, där timerns värden skrivs till en variabel när funktionen startas. För att kunna läsa ut variablerna från MSP430 används CCStudio. Då värden skrivs över så stegas programmet igenom i debugg-miljö, då även timers stoppas. På så sätt kan värden manuellt läsas ut.
Resultatet visar att i normalläge skiljer sig exekveringstiden mycket lite från gång
6.3. VERIFIERING, PROGRAMEXEKVERING
Figur 6.8. Funktions diagram för programmet simpleDetect
till gång. Även start tiderna (det vill sägs exekveringsfrekvensen) av funktionerna är konsekventa. Vilket är ett viktigt resultat för korrekt sampling i tid. Resultatet visas i tabell 6.2 och 6.3. Tiderna är konverterade från timerns värden till µs. Kon-verteringen sker genom att dividera timerns värde med klockcykeln. Resultatet för körning när tröskelvärdet har överskridits visar att func_detect() då tar mer tid i anspråk. När sedan hela loggdatat har sparats undan så körs func_detect() en sista gång där resultatet utvärderas och func_hmi() åkallas. Vilket syns i att tf unc_detect
blir längre. För att tydligöra de olika tidsskillnaderna importerades värden från oli-ka delar av exekveringen i MATLAB. Där funktionernas status plottades mot tiden.
Plotten visas i figur 6.9. Där visas exekveringen från de tre lägena i programmet.
Värden från plotten finns i tabell 6.4.
Funktion/prov 1 2 3 4 5 tf unc_adcSample 22.6µs 22.7µs 34µs 22.7µs 22.5µs tf unc_detect 12.0µs 12.0µs 11.8µs 12.0µs 11.7µs
Tabell 6.2. Körtiderna under normalläge utan att tröskelvärdet överskridits
Funktion/prov 1 2 3 4 5
tStartF unc_adcSample 0.0µs 99µs 200µs 300µs 400µs tStartF unc_detect 34µs 134µs 234µs 334µs 434µs
Tabell 6.3. Start tider under normalläge utan att tröskelvärdet överskridits
Tid [ms]
↓ Start loggning ↓ Start analys logdata
↑ Start HMI SimpleDetect exekvering
func_adcSample func_detect func_hmi
Figur 6.9. Plot av funktionsexekvering i simpleDetects. Värde 1 betyder att funktio-nen exekveras och värde 0 betyder att den inte exekveras. Tre stadier i programmet (normalläge, sparläge, och analysläge) avdelade med svarta horisontella linjer. Där det egentligen hade varit mer exekveringar av f unc_adcSample() och f unc_detect() i mellan.
Funktion 1 2 3 4 5 6
tStartf unc_adcSample 0.0µs 99µs 200µs 300µs 400µs 500µs tf unc_adcSample 22.6µs 22.7µs 23.0µs 22.7µs 22.5µs 22.5µs tStartf unc_detect 34µs 134µs 234µs 334µs 434µs 530µs tf unc_detect 12.0µs 12.0µs 11.8µs 16.5µs 15.0µs 230µs
tStartf unc_hmi 0.0µs 0.0µs 0.0µs 0.0µs 0.0µs 696µs
tf unc_hmi 0.0µs 0.0µs 0.0µs 0.0µs 0.0µs 62.25µs
Tabell 6.4. Tiderna från figur 6.9
6.3. VERIFIERING, PROGRAMEXEKVERING
Figur 6.10. Graf från WaveForms, med f unc_adcSample() överst och f unc_detect() undertill.
ff unc_adcSample 9.921kHz 9.956kHz 9.986kHz 9.986kHz tf unc_adcSample 17.39µs 18.26µs 18.53µs 18.36µs tf unc_detect 11.98µs 10.43µs 10.43µs 11.26µs
Tabell 6.5. Exekveringstid och frekvens i normalläge mätt med alternativ2, från 4 prov.
6.3.2 Alternativ 2
Med extern utrustning kan tiderna valideras genom att läsa av µCs utgångar, också kallat I/O. En I/O-pinne allokeras för varje funktion. När funktionen startar höjs spänningen på allokerad pinne och sänkas efter relevant kod har exekverats. AD har totalt åtta logiska ingångar och två kanalers oscilloskop som kan används för att läsa av I/O-pinnarna. För att verifiera funktionsexekveringen vid normal samp-ling används oscilloskopets 2 kanaler. Från WaveForms kunde en graf läsas ut som illustrerar funktionsexekveringen, som visas i figur 6.10. Där visas endast exekve-ringen av func_adcSample() and func_detect() i normalläge. Värden från grafen har lästs ut och noterats i tabell 6.5. ff unc_adcSample är exekveringsfrekvensen av f unc_adcSample(). Från WaveForms är det enkelt att grafiskt analysera exekve-ringstid och starttider för respektive funktion. Det är tydligt att samplingen sker i önskad frekvens och att funktionerna inte krockar. ADs logik-ingångar kopplades till funktionernas pinnar för alla funktioners exekvering skulle kunna verifieras. Då kunde sparläget och analysläget också fångas på bild. Figur 6.11 visar sparläget och analysläget. I tabell 6.6 visas exekveringstiden samt exekveringsfrekvens i spar- och analysläget. Som i alternativ 1 visas det att analysläget tar längre tid än sampling-en. Skillnaderna mellan metodernas uppmättat tider visas i tabell 6.7. Där framgår att tidern skiljer sig lite åt. De skillnader som finns kan förklaras med mätfel och att åtgärden som möjliggör avläsningen av tiden också spelar in. Ett undantag är tf unc_detect i analysläget som skiljer sig åt stort mellan de två mätmetoderna.
Analysläge: tf unc_hmi 57µs 58µs 58µs 58µs Sparläge: tf unc_detect 15.1µs 16.2µs 15.2µs 14.3µs Analysläge: tf unc_detect 351µs 346µs 350µs 356µs
Tabell 6.6. Exekveringstid spar- och analysläge mätt med alternativ2, från 4 prov
Figur 6.11. Graf från WaveForms logik-ingångar. Slutet av en mätsession där f unc_detect() är i analysläge
funktion normalläge sparläge analysläge alt1 tf unc_adcSample 22.5µs 22.5µs 22.5µs alt2 tf unc_adcSample 18.1µs 18.1µs 18.1µs alt1 tf unc_detect 11.9µs 15.5µs 230µs alt2 tf unc_detect 12.0µs 15.1µs 356µs
alt1 tf unc_hmi 62µs
alt2 tf unc_hmi 58µs
Tabell 6.7. Jämförelse mellan alternativ 1 och 2. Värdena i tabellen är ett medelvärde av de uppmätta tiderna för varje läge