aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJulian T <julian@jtle.dk>2020-06-07 16:16:57 +0200
committerJulian T <julian@jtle.dk>2020-06-07 16:16:57 +0200
commit6cb9bec1e0241fe64afdad9a520f026a9c25ea91 (patch)
tree79a97b71c047e27496a8e99ff5c78acee0679c30
parentf7c5a5999405170f809ff6ee62c8274d61cfbb76 (diff)
Completed embedded 9'th assignment
-rw-r--r--sem4/embedded/eksamnen/M9f1.pngbin0 -> 31743 bytes
-rw-r--r--sem4/embedded/eksamnen/M9f2.pngbin0 -> 40457 bytes
-rw-r--r--sem4/embedded/eksamnen/M9f3.pngbin0 -> 35688 bytes
-rw-r--r--sem4/embedded/eksamnen/M9f4.pngbin0 -> 42336 bytes
-rw-r--r--sem4/embedded/eksamnen/M9f5.pngbin0 -> 35960 bytes
-rw-r--r--sem4/embedded/eksamnen/M9opg.adoc104
-rw-r--r--sem4/embedded/eksamnen/notes.adoc29
7 files changed, 133 insertions, 0 deletions
diff --git a/sem4/embedded/eksamnen/M9f1.png b/sem4/embedded/eksamnen/M9f1.png
new file mode 100644
index 0000000..4fe0a63
--- /dev/null
+++ b/sem4/embedded/eksamnen/M9f1.png
Binary files differ
diff --git a/sem4/embedded/eksamnen/M9f2.png b/sem4/embedded/eksamnen/M9f2.png
new file mode 100644
index 0000000..6a6f691
--- /dev/null
+++ b/sem4/embedded/eksamnen/M9f2.png
Binary files differ
diff --git a/sem4/embedded/eksamnen/M9f3.png b/sem4/embedded/eksamnen/M9f3.png
new file mode 100644
index 0000000..0789f0c
--- /dev/null
+++ b/sem4/embedded/eksamnen/M9f3.png
Binary files differ
diff --git a/sem4/embedded/eksamnen/M9f4.png b/sem4/embedded/eksamnen/M9f4.png
new file mode 100644
index 0000000..e00baa2
--- /dev/null
+++ b/sem4/embedded/eksamnen/M9f4.png
Binary files differ
diff --git a/sem4/embedded/eksamnen/M9f5.png b/sem4/embedded/eksamnen/M9f5.png
new file mode 100644
index 0000000..b1636e3
--- /dev/null
+++ b/sem4/embedded/eksamnen/M9f5.png
Binary files differ
diff --git a/sem4/embedded/eksamnen/M9opg.adoc b/sem4/embedded/eksamnen/M9opg.adoc
new file mode 100644
index 0000000..4564c25
--- /dev/null
+++ b/sem4/embedded/eksamnen/M9opg.adoc
@@ -0,0 +1,104 @@
+= Opgaver til M9
+
+The following single-CPU-realtime system is to executed on a Real Time Operating System (RTOS) with preemptive FP scheduling and immediate ceiling:
+
+1. 4 alarms with mimimum interarrival time: 10 min., execution time 10 mS.
+2. 1 user input with minimum interarrival time 1/4 sec. and mean interarrival time 2 sec., execution time 10 mS.
+3. 1 network input with minimum interarrival time 10 mS, and mean interarrival time 10 sec., execution time 30 mS.
+4. 1 real-time control of time critical system, sampling time 100 mS, execution time 10 mS.
+5. 1 real-time control of time critical system, sampling time 1 sec. execution time 10 mS.
+6. 1 screen clock, update frequency 1/10 1/sec.., execution time 20 mS.
+7. User input and 2. realtime control share a common datastructure; accesstime 10 mS.
+
+Suggest:
+
+- Deadlines for all tasks
+- A fixed priority order
+- The use of aperiodic/sporadic servers for some tasks
+
+Check feasibility of your design w.r.t. deadlines.
+
+== Løsning
+
+____
+_Deadlines for all tasks_
+____
+
+- *T1* det er vigtigt at den handle hurtigt på denne alarm.
+ Derfor skal den have 50 mSec.
+- *T2* dette er rimelig soft, så derfor behøver man ikke en meget lav deadline.
+ Her kunne man lade deadline være 1.2 sekundter.
+- *T3* dette er igen soft men det kommer ret hurtigt.
+ Event kan events komme ret hurtigt så en deadline på 0.3 s vil give mening.
+- *T4* vil have en deadline samme som periode på 100 ms.
+- *T5* vil have en på 1 sec.
+- *T6* vil have en på 10 sec.
+
+____
+_A fixed priority order_
+____
+
+Her er der flere der har deadlines under period, så derfor vil DMA give mening.
+
+(T1, T4, T3, T5, T2, T6)
+
+____
+_The use of aperiodic/sporadic servers for some tasks_
+____
+
+*T3* og *T4* giver mening at køre med _sporadic server_ eftersom de har en minimum interval time.
+
+____
+_Check feasibility of your design w.r.t. deadlines._
+____
+
+Her regner jeg completion time ud for hver task.
+
+----
+C1 = 10
+----
+
+Dette er feasable.
+
+----
+C4 = 10 + ceil(C4/(1000 * 60 * 10)) * 10
+----
+
+image::M9f1.png[]
+
+Denne er feasable da 20 ms er under deadline og næste periode.
+
+----
+C3 = 30 + ceil(C3/(1000 * 60 * 10)) * 10 + ceil(C3/100) * 10
+----
+
+image::M9f2.png[]
+
+Her kan man se at den ikke er færdig før min, så der kan komme queing.
+Tilgengeld er den højere end mean periode, så derfor må den komme på plads efter noget tid.
+
+----
+C5 = 10 + ceil(C5/(1000 * 60 * 10)) * 10 + ceil(C5/100) * 10 + ceil(C5/(10*1000)) * 30 + 10
+----
+
+image::M9f3.png[]
+
+Denne er også feasable.
+
+----
+C2 = 10 + ceil(C2/(1000 * 60 * 10)) * 10 + ceil(C2/100) * 10 + ceil(C2/(10*1000)) * 30 + ceil(C2/1000) * 10
+----
+
+image::M9f4.png[]
+
+Dette er også feasable.
+
+----
+C6 = 20 + ceil(C6/(1000 * 60 * 10)) * 10 + ceil(C6/100) * 10 + ceil(C6/(10*1000)) * 30 + ceil(C6/1000) * 10 + ceil(C6/2000) * 10
+----
+
+
+image::M9f5.png[]
+
+Dette er også feasable
+
diff --git a/sem4/embedded/eksamnen/notes.adoc b/sem4/embedded/eksamnen/notes.adoc
index 0b33bb7..5ff6874 100644
--- a/sem4/embedded/eksamnen/notes.adoc
+++ b/sem4/embedded/eksamnen/notes.adoc
@@ -226,3 +226,32 @@ Derfor bruger man _Static Ressource Priority Ordering_ hvor man bruger prioritie
____
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.
+