:stem: == J1 module 1 ____ Show code and explain for 1,4,5,6 (design and impl ISR, time based debouncing, tick routing, limitations) ____ Se ../m1/int/int.ino. Se ../m1/router/router.ino. == Opgave løsning ____ _Design and implement an interrupt service routine which acts on digital pin 2._ ____ Digital pin 2 i arduino er mapped til atmega328p pin PD2, og er koblet på INT0. Derfor starter vi med at enable INT0. Se for kode ../m1/int/int.ino ---- EIMSK |= 1 << INT0; ---- Derefter kan man lave en interrupt der trigger på rising edge, hvilket man ud fra datasheet kan se er ISC01 og ISC00 i EICRAfor INT0. ---- EICRA |= (1 << ISC01) | (1 << ISC00); ---- Hvis man har sat den rigtige pinmode på 2, vil interrupten nu være aktiveret. ---- ISR(INT0_vect) { do_the_thing(); } ---- Her bruger jeg en normal ISR, hvor gcc håndtere det med at push registre på stakken og sætte dem tilbage igen efter. Dette kan man også se i den compilede fil. image::M1f1.png[] ____ _Or add a timed decision in ISR to prevent more ISR response for the nex xx mseconds._ ____ Dette er gjort ved at gemme tiden for hver gang den kører med millis. Derefter kan man check om det er over 100 ms siden at man sidst kørte. ____ _Design a tick routing which can run a function on given times (and explain code below_ ____ Har lavet en function man kalder for hver tasks man vil tick route. Denne bruger millis() funktionen som bagved bruger timer0. ____ _What is limitations ? like timewise starvation,..._ ____ Man kan tydelig se problemet hvis man sætter task0 til at have et 10000 ms langt delay. Her vil man se starvation i at det hele bliver langsomere. Dette er fordi det ikke er preimtive hvilket betyder at hvis et job bare tager lang tid må de andre bare vente. === Noter Findes forskellige slags realtime afhængig af hvor vigtigt det er at man laver sin opgave inden for deadline. * *Hard* er når en manglende deadline tæller som en system fejl. * *Firm* nogle deadlines på gerne misses, men disse resultater vil være ubrugelige. * *Soft* et resultat er ikke nær så meget værd hvis det er forsent, men kan stadig bruges. == H1 module 2 ____ Exercise 1-11 ____ === Løsning See ../emb_m2/emb_m2.ino ____ _Compute the mean relative error between da and mda_ ____ 0.0052564806 hvilket er okay for at den kun er 16 bit. ____ _Compute the mean relative error between da2 and mda2_ ____ 0.1998619556 her kan man se at fejlen stiger en del. ____ _Iterate "a*=da[i];" over the length of da and measure the execution time (micros())_ ____ Exe time: 1272 ____ _Iterate "mult_float(&f1,&mda[i],&f); memcpy(&f1,&f,2);" over the length of mda and measure the execution time_ ____ Exe time: 828 ____ _Compute the relative difference between results from (7) and (9)_ ____ ---- Abs diff: 444 Rel diff: 0.35 ---- ____ _Implement the fastest version of the trigornometric function "sine" that has below 2% relative error._ ____ Her brugte jeg tayler til at exporimere sin(x). Dette blev ret præcis men var meget langsomere end sin(x). ---- TOTAL STATS rel err : 0.0005467962 own time: 2420 ard time: 134 ---- === Noter *Q-format* er hver man dedikere nogle af bits til decimaler. Det er derfor ikke _floating_ point. *Floating points* er decimal tak med en floating point. Her har man kun et bestemt tal betydende cifre. TODO læs op på error calculus. Totalt uforståeligt i slides. Der findes forskellige måder at have negative tal på. * Signed Her bruger man MSB til at betyde sign. Når den er 1 er det et minutal. Problemet er at der nu er 2 nuller. * 1’s komplement Ligesom _signed_ men når det er negativt er alle bits flippet. Dette gør det meget lettere at lave matematik på det. Her er stadig det problem at der er 2 nuller. * 2’s komplement Ligesom _1.s komplement_ men negative har 1 lagt til. Dette betyder at der kun er 1 nul værdi. == H2 module 3 ____ Exercise 4-7 ____ === Løsning Her har jeg lavet noget test data med to beskeder, dette løser den ret godt. Jeg bruger bare uint8_t til de to først typer. Se ../m3/m3.ino ---- DONE Type :1 Recvid :514 Transducerlevel :88 Quiettime :50 Masters :1 MASTER: 0 rssi :90 txid :5 ixidtime :600 DONE Type :65 Recvid :1 Transducerlevel :136 Quiettime :16 Masters :3 MASTER: 0 rssi :23 txid :68 ixidtime :65535 MASTER: 1 rssi :11 txid :171 ixidtime :65534 MASTER: 2 rssi :3 txid :64 ixidtime :65535 ---- === Noter To forskellige hoved protokoller. * ASCII Let at læse at læse for en person. Det er nemmere at seperere felter. Bare ikke særlig efficient. * Binary Inviklet af seperere felter, da data felter kan indeholder delimiters. Mere efficient. Findes fire forskellige structurelle elementer. * Sequence Flere elementer efter hinnanden. * Alternation Enten den ene eller anden type element. * Repetition Lister af det samme elemtn * Abstraction Structure og egne data typer. *Haming distance* er hvor mange bits er forskellige mellem to bit sekvenser. *Haming distance of protection code* hvor langt der er imellem to sekvenser der stadig er korrekte. Dette kan man kande for _HD_. * Hvis _HD_ er større end _n_ kan man detect _n_ bit errors. * Hvis _HD_ er større end _2n_ kan man fixe _n_ bit errors. Fletcher _HD_ er 2 så man kan detect en bit fejl. == J2 module 4 ____ Show LED13 blink code and explain program. ____ Se ../emb_m4/emb_m4.ino ____ Explain interrupt ____ Se ../emb_m4/jrnl/jrnl.ino Se ../m1/int/int.ino ____ Lack of control maybe bq of non-interruptable ISRs ____ ____ Procesmodel: running,ready,blocked ____ Man kan se at processorne bruger k_sleep, hvilket gør dem blocked. Når de er færdige med at sleep kommer de i ready, og når de så bliver scheduled kommer de i running. ____ semaphore wait and signal ____ Dette kan man bruge til forskellige ting. Critical region:: Man har noget kode der tilgår noget data. Dette kan man låse ved at lave en semafor med en start værdi på 1. Når nogen låser den tager de den værdi. Periodisk timing:: Man kan sætte os til at signal ens semafor hvert x sekundt. Her giver man start værdi 0. Timing og beskeder:: Det er en god måde at synkronisere forskellige task. For eksempel kan en ISR sætte en semafor for at signalere at der er en ny besked. == J3 module 5 ____ What is a semaphore, show code from above and eplaing critical region setup ____ Se ../m5/m5.ino == J4 module 6 ____ Show code for and explain message queues as a buffering tool. ____ Se ../m6/m6.ino == J5 module 6.5 ____ Exercise 1 in part3 on page295 (Pdf is on moodle) ____ === Løsning ____ _Evaluate the timing requirements of the system_ ____ Det er vigtigt at beskederne mellem sensor og DAC kommer ordenligt igennem. Derfor er de dele realtime, mens keypad, display og serial er firm-realtime. Det er ikke soft da det stadig er vigtigt for piloten at det han får at vide er rigtigt og at hans kommandoer sker hurtigt, men ikke så vigtigt som DAC. ____ _Define the major software functions to be carried out by the system as a set of software subsystems._ ____ User interface:: Handles display and keyboard, and gets information from info subsystem. This handles IO with the display and takes input from the user via keypad. Info subsystem:: Collect information sent from CPU and sends this on serial IO and User interface. It therefore handles the serial IO terminator. Processing submodule:: Receives updates from sensor and adc, processes the data and sends it to DAC and Info system. Updates to the info system are done non-blocking and because it's only firm updates are okay to not be sent. Updates to DAC are blocking and must be done before the deadline. ____ _Show all information flow, both between subsystems and to/from IO devices._ ____ Har lavet er på plantuml. image::M65f1.png[] ---- @startuml component [User Interface] as UI component [Info subsystem] as IS component [Processing submodule] as PS interface Keypad interface Display interface DAC interface "Serial IO" as SIO interface ADC interface CPU UI -left- Keypad UI -right-> Display IS -up-> UI UI -down-> PS IS -> SIO PS -right-> IS ADC -up-> PS PS -down- CPU PS -down-> DAC @enduml ---- ____ _How would you design the software if all the code had to be contained within a single sequential program._ ____ Her ville jeg lave en slags tick router og sørre for at alle task kører super hurtigt. For eksempel skulle user interface måske have mere swithing inde i sig selv. ____ _Redesign the software assuming that interrupt-driven activities are allowed._ ____ Interrupt giver mulighed for at køre OS og preimetive multitasking. Jeg vil have hvert subsystem i en task, som så kører med forskellig hastighed. Hvis sensor kommer apriodisk ville det nok være smart at have en interrupt dertil, samt en til keypad. == H3 module 7 ____ Exercise 4-5 ____ Se ./M7opg.adoc === Noter *Scheduling* er når flere opgaver eller jobs skal time shares på en CPU. Et *Schedule* er plan for hvordan disse opgaver skal have tid. Et schedule er *feasable* hvis alle jobs kan køres imellem deres readytime og deadline. Der findes forskellige kategorier. * Fixed schedules Jobs kører på tidspunkter man har bestemt for forhånd. Og dette kører bare i loop. Dette er ret simpelt og effektivt men ikke særlig fleksibelt. + Her behøver man kun lave en plan hen til LCM eller Least Common Multiple af tasks periods. * Round robin Fixed tidsrum er delt ud mellem jobs periodisk. Simpelt og fleksiblet men ikke effekttivt. * Fixed priority Det er altid jobbet med højeste prioritet der kører. Dette er simpelt og fleksibelt, men kun middelt effektivt. * Dynamic priority Her bruger man andre regler til at bestemme hvem der kører. Dette giver de bedste resultater men er også mere komplekst. Utilization er _completion time_ dividere med _period_. Man kan definere CPU utilization som: stem:[U = \sum_{i=1}^N \frac{c_i}{T_i}] _Rate Monotonic Scheduling_ eller *RMA* er når man giver task med lav periode højere prioritet. _Deadline Monotonic_ eller *DMA* sortere efter laveste relative deadline. Dette giver det samme som RMA hvis relative deadlines er lig periode. Hvis deadline er før periode giver den optimale resultater. _Utilization critereon_ er en upper limit stem:[\overline{U}] for utilization hvor RMA er garanteret hvis deadlines er lig periode. stem:[\overline{U} = N \cdot (2^{\frac{1}{N}} - 1)] == H4 module 8 ____ Exercise 1-2 ____ Se ./M8opg.adoc TODO lav arduino ting === Noter _Earliest Deadline First_ eller *EDF* er hvor man tager den med deadline der er tættest på _t_. Dette gør man dynamisk hvilket giver en højere runtime cost end en fixed priority såsom *DMA*. _Hvis man kan finde et feasable schedule er *EDF* også feasable._ _Hvis deadlines er lig perioder er taskset schedulable med *EDF* hvis stem:[U \leq 1]._ Dette kaldes også for *utilization criterion. *Priority Ceiling*, er hvis en task stem:[\tau] prøver at lock en locked task, arver stem:[\tau{}_l] prioriteten. Her er det først når en højere task prøver at lock at den lavere task arver. Dette har forskellige egenskaber, hvis man kan garantere at alle task laver nested locking. - No deadlocks possible - En task venter max duration af critical region for lavere task. *Immediate Ceiling* er mere leightweight, da man istedet siger at hvis en task locker en lock, vil den arve den højst mulige potentielle perioritet. Også selvom der ikke er nogen der venter på den. Denne har samme egenskaber men behøver ikke lige så meget overhead. I et non-preemtive system, vil dette ikke betyde så meget, da ressources bliver unlocked igen i execution perioden for en task. Hvis man har _round_robin_, _static_ eller _dynamic_ scheduling er der ikke nogle prioriteter man kan bruge. Derfor bruger man _Static Ressource Priority Ordering_ hvor man bruger priorities når der sker ressource locking. - Hvis man bruger _static priority_ bestemmer man STPO før. - Hvis man bruger _round robin_ her kigger man på worsk case analysis. - Hvis man bruger _EDF_ her det svært at lave analysis. == H5 module 9 ____ All exercises ____ Se ./M9opg.adoc === Noter Er *System* kan deles ind i *subsystemer* som igen kan deles ind i *objects*. _Subsystems_ deler de forskellige *terminators* op, hvor en termiator er noget der snakker med omverdenen. Et subsystem kan være en server hvilket betyder at den ikke selv laver request, men kun modtager. _Objekter_ kan have forskellige typer: - IO - User role - Control - Data abstraction - Algorithm Man kan forklare et subsystems opførsel med *STD*(State Transistion Diagram). Når man laver et event kan det gøres på forskellige måder. Triggering:: Sender en commando som man derefter venter på (blocking). Enabling:: Sender en commando som bliver startet i baggrunden (unblocking). Disabling:: Stop en commando der blev enabled.