Merge branch 'dev'

_data/ntnu-courses.yml

@@ -1,51 +1,89 @@
+# Våren 2021
+-
+  name: Våren 2021
+  href: 21v
+  courses:
+    - 
+      course: ttt4280
+      desc: Sensorer og instrumentering, våren 2021.
+      updated: 2021-01-11
+    -
+      course: tfe4130
+      desc: Bølgeforplantning, våren 2021.
+      updated: 2021-01-12
+    -
+      course: ttk4145
+      desc: Sanntidsprogrammering, våren 2021.
+      updated: 2021-05-04
+    -
+      course: tiø4252
+      desc: Teknologiledelse, våren 2021.
+      updated: 2021-05-13
+
 # Høsten 2020
-- 
-  course: tfe4152
-  desc: Design av integrerte kretser, høsten 2020.
-  updated: 2020-12-16
-  href: tfe4152/summary
-- 
-  course: ttt4120
-  desc: Digital signalbehandling, høsten 2020.
-  updated: 2020-12-06
-  href: ttt4120/summary
-- 
-  course: mfel3010
-  desc: Medisin for teknologi- og realfagsstudenter, høsten 2020.
-  updated: 2020-11-25
-  href: mfel3010/summary
-- 
-  course: tfe4146
-  desc: Halvlederkomponenter, høsten 2020.
-  updated: 2020-11-23
-  href: tfe4146/summary
+-
+  name: Høsten 2020
+  href: 20h
+  courses:
+    - 
+      course: tfe4152
+      desc: Design av integrerte kretser, høsten 2020.
+      updated: 2020-12-16
+      href: tfe4152/summary
+    - 
+      course: ttt4120
+      desc: Digital signalbehandling, høsten 2020.
+      updated: 2020-12-06
+      href: ttt4120/summary
+    - 
+      course: mfel3010
+      desc: Medisin for teknologi- og realfagsstudenter, høsten 2020.
+      updated: 2020-11-25
+      href: mfel3010/summary
+    - 
+      course: tfe4146
+      desc: Halvlederkomponenter, høsten 2020.
+      updated: 2020-11-23
+      href: tfe4146/summary
 
 # Våren 2020
-- 
-  course: ttt4270
-  desc: Elektronisk systemdesign, prosjekt, våren 2020.
-  updated: 2020-05-05
+-
+  name: Våren 2020
+  href: 20v
+  courses:
+    - 
+      course: ttt4270
+      desc: Elektronisk systemdesign, prosjekt, våren 2020.
+      updated: 2020-05-05
 
 # Høsten 2019
-- 
-  course: ttt4265
-  desc: Elektronisk systemdesign og -analyse II, høsten 2019.
-  updated: 2019-12-02
-- 
-  course: tdt4160
-  desc: Datamaskiner og digitalteknikk, høsten 2019.
-  updated: 2019-11-28
+-
+  name: Høsten 2019
+  href: 19h
+  courses:
+    - 
+      course: ttt4265
+      desc: Elektronisk systemdesign og -analyse II, høsten 2019.
+      updated: 2019-12-02
+    - 
+      course: tdt4160
+      desc: Datamaskiner og digitalteknikk, høsten 2019.
+      updated: 2019-11-28
 
 # Våren 2019
-- 
-  course: ttt4260
-  desc: Elektronisk systemdesign og -analyse I, våren 2019.
-  updated: 2019-05-05
-- 
-  course: tma4105
-  desc: Matematikk 2, våren 2019.
-  updated: 2019-05-21
-- 
-  course: tdt4102
-  desc: Prosedyre og objektorientert programmering, våren 2019.
-  updated: 2019-05-15
+-
+  name: Våren 2019
+  href: 19v
+  courses:
+    - 
+      course: ttt4260
+      desc: Elektronisk systemdesign og -analyse I, våren 2019.
+      updated: 2019-05-05
+    - 
+      course: tma4105
+      desc: Matematikk 2, våren 2019.
+      updated: 2019-05-21
+    - 
+      course: tdt4102
+      desc: Prosedyre og objektorientert programmering, våren 2019.
+      updated: 2019-05-15

_includes/utils/scripts.html

@@ -2,6 +2,7 @@
 <script src="{{ "/assets/js/jquery-3.5.1.min.js" | relative_url }}"></script>
 <script src="{{ "/assets/js/bootstrap.bundle.min.js" | relative_url }}"></script>
 <script src="{{ "/assets/js/bootstrap-toc.min.js" | relative_url }}"></script>
+
 <!--Anchors-->
 <script src="{{ "/assets/js/anchor.min.js" | relative_url }}"></script>
 <script>
@@ -10,4 +11,4 @@
   icon: '#',
   };
   anchors.add('h1, h2, h3, h4, h5').remove('.no-anchor');
-</script>
+</script>

_layouts/layouts/lecture.html

@@ -0,0 +1,20 @@
+---
+layout: default
+---
+<div class="jumbotron">
+	<div class="container">
+		<h1 class="no-anchor" data-toc-skip>{{ page.title }}</h1>
+		<p>{{ page.description }}</p>
+		<small>Forelesningsdato {{ page.date | date: "%d.%m.%Y" }}</small>
+	</div>
+</div>
+<div class="container" id="main">
+	<div class="row row-offcanvas row-offcanvas-right">
+		<div class="col-xs-12 col-sm-12 col-md-9">
+			{{ content }}
+		</div>
+		<div class="col-md-3 d-none d-md-block" id="sidebar">
+			<nav id="toc" data-toggle="toc" class="sticky-top" style="z-index:1"></nav>
+		</div>
+	</div>
+</div>

about.md

@@ -1,7 +1,11 @@
 ---
-layout: layouts/page
+layout: layouts/list
 title: Om
 permalink: /om/
 ---
 
-Mitt navn er Øyvind Skaaden. Jeg er 21 år gammel og studerer Elektronisk systemdesign og innovasjon på NTNU.
+Mitt navn er Øyvind Skaaden. Jeg er 22 år gammel og studerer Elektronisk systemdesign og innovasjon på NTNU.
+
+Jeg er stor fan av open-source og prøver så godt jeg kan å fremme dette. 
+
+Jeg har både en [github](https://github.com/oyvindskaaden) og en [personlig git](https://git.glados.no/).

assets/css/components/theme.css

@@ -102,6 +102,7 @@ blockquote {
 
 a {
   color: var(--link-color);
+  text-decoration: none;
 }
 
 a:hover {

assets/css/home.css

@@ -27,7 +27,13 @@
   min-height: calc(100vh - 47.75rem);
 }
 
-.home-link>a {
+/*
+.home-link a{
+  text-decoration: none;
+}
+*/
+
+a.home-link:hover{
   text-decoration: none;
 }
 

index.html

@@ -7,12 +7,12 @@ description: Personlig nettside for Øyvind Skaaden. Inneholder det meste av per
   <div class="row">
     {% for home in site.data.home %}
     <div class="col-md-4">
-      <a href="{{ home.href }}">
+      <a class="home-link" href="{{ home.href }}">
         <div class="icon">
           <i class="fas {{ home.icon }}"></i>
         </div>
+        <h3 class="no-anchor home-link">{{ home.title }}</h3>
       </a>
-      <h3 class="no-anchor home-link"><a class="" href="{{ home.href }}">{{ home.title }}</a></h3>
       <p>{{ home.description }}</p>
     </div>
     {% endfor %}

ntnu/21v/tfe4130/lectures/2021-01-12/2021-01-12.md

@@ -0,0 +1,74 @@
+---
+title: "TFE4130 - 1D Bølger"
+description: "2021-01-12"
+math: true
+---
+
+## Hva er bølger?
+
+Bevegelse av partikler i et medium.
+
+Dispersive gjør at signalet kan endre seg over tid og strekning.
+Bølgehastigheten er avhengig av frekvensen.
+
+Ikke-dispersive betyr at bølgen beveger seg med samme hastighet hele tiden, og vil derfor være lik ved alle distanser.
+
+Bølger kan inteferere.
+
+Kurset handler mest om EM-bølger, men mekaniske bølger er enklere.
+Det er da kun trykk som beskriver en bølge, mot en vektor med flere komponenter i EM-bølger.
+
+Velocity potential:
+
+$$WIP$$
+
+Velocities at depth:
+
+$$WIP$$
+
+Dispersjonsrelasjonen i havbølger
+
+$$ \omega^2 = gk \tanh kd $$
+
+Der $g$ er tyngdeakserelasjonen, $k$ er bølgetallet og $d$ er dybden.
+
+### Forskjellige typer bølger
+
+Longitudinale: Langsgående bølger.
+
+Transversale: Bølger som beveger seg normalt på propageringsretningen.
+
+### Matematisk
+
+Bølgene er løsningen på bølgelikningen i forskjellige dimensjoner.
+
+$$ \ddot{u} = \frac{\partial^2 u}{\partial t^2} = c^2 \nabla^2 u $$
+
+Denne løses som en partiell differensiallikning.
+
+En ikke-dispersiv hamonisk bølge er definert:
+
+$$ p(x, t) = \hat{p} \sin(\omega t - kx) $$
+
+Der $\omega = 2\pi f$ er frekvensen, $k = \tfrac{\omega}{c}$ er bølgekonstanten, $c$ er propageringshastigheten og $\hat{p}$ er bølgeamplituden.
+
+## Lydbølger
+
+Lydbølger er endringer i lydtrykket rundt standardtrykket/det statiske trykket. 
+
+$$ \underbrace{P_\text{total}(x,t)}_{\text{Lufttrykk, [Pa]}} = \underbrace{P_\text{atm}}_\text{Statisk trykk} + \underbrace{p(x,t)}_\text{endringer i trykket, lyd} $$
+
+
+Bølgelikningen for lydbølger:
+
+$$ \frac{\partial^2 p}{\partial x^2} - \frac{1}{c^2} \frac{\partial^2 p}{\partial t^2} $$
+
+## Helmholtz' likning
+
+Spesialtilfelle av bølgelikningen når bølgen er en harmonisk svingning.
+
+$$ p(x,t) = p(x) e^{j\omega t} $$
+
+Den tidsavhengige faktoren kan faktoriseres ut av likningen og vi står igjen med en ODE.
+
+$$ \frac{\partial^2 p(x)}{\partial x^2} + k^2 p(x) = 0 $$

ntnu/21v/tfe4130/lectures/2021-01-14/2021-01-14.md

@@ -0,0 +1,24 @@
+---
+layout: layouts/lecture
+title: "TFE4130"
+description: "1D Bølger forts."
+date: "2021-01-14"
+math: true
+---
+
+## Akustisk impedanse
+
+## Akustisk intensitet
+
+$$ \boldsymbol{I} = \frac{1}{T}\int_0^T p_\text{real}\boldsymbol{v}_\text{real}(t) dt $$
+
+FOr en planbølge
+
+$$ I_x = \frac{p_\text{rms}}{p_x c}$$
+
+## Refleksjon og transmisjon
+
+Dersom en børge beveger seg over en grenseflate mellom to forskjellige impedanser.
+
+* Trykket nå være kontinuerlig over grenseflaten
+* Farten over grenseflaten må være konstant.

ntnu/21v/tfe4130/tfe4130.md

@@ -0,0 +1,15 @@
+---
+layout: layouts/list
+title: "TFE4130"
+description: "Bølgeforplantning"
+---
+
+## Filer og annet
+
+Alle øvinger og andre viktige filer ligger på [git](https://git.glados.no/oyvindskaaden/TFE4130).
+
+## Forelesninger
+
+[2021-01-12](./lectures/2021-01-12/) - Intro
+
+[2021-01-14](./lectures/2021-01-14/) - Bølger forts.

ntnu/21v/tiø4252/tiø4252.md

@@ -0,0 +1,63 @@
+---
+title: TIØ4252
+description: Teknologiledelse, våren 2021
+date: 2021-05-13
+---
+
+
+## Formelark
+
+Kommer straks.
+
+## Eksamen
+
+Alle filer er tilgjengelig på [git][git].
+
+[git]: https://git.glados.no/oyvindskaaden/TIO4252
+
+Kombinert løsningsforslag for alle eksamener finnes [her][LF_alle].
+
+[LF_alle]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/LF.pdf
+
+| År   | Eksamen | Oppgave       | LF       |
+| :--- | :------ | :------------ | :------- |
+| 2020 | Høst    | [Oppgave][1]  | [LF][2]  |
+| 2020 | Sommer  | [Oppgave][3]  | [LF][4]  |
+| 2020 | Vår     | [Oppgave][5]  | [LF][6]  |
+| 2019 | Høst    | [Oppgave][7]  | [LF][8]  |
+| 2019 | Sommer  | [Oppgave][9]  | [LF][10] |
+| 2018 | Høst    | [Oppgave][11] | [LF][12] |
+| 2018 | Sommer  | [Oppgave][13] | [LF][14] |
+| 2018 | Vår     | [Oppgave][15] | [LF][16] |
+| 2017 | Høst    | [Oppgave][17] | [LF][18] |
+| 2017 | Vår     | [Oppgave][19] | [LF][20] |
+| 2014 | Sommer  | [Oppgave][21] | [LF][22] |
+| 2013 | Sommer  | [Oppgave][23] | [LF][24] |
+{: .table-responsive-lg .table }
+
+[1]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20H/Eksamen_20H.pdf
+[2]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20H/Losning_20H.pdf
+[3]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20S/Eksamen_20S.pdf
+[4]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20S/Losning_20S.pdf
+[5]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20V/Eksamen_20V.pdf
+[6]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/20V/Losning_20V.pdf
+[7]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19H/Eksamen_19H.pdf
+[8]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19H/Losning_19H.pdf
+[9]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19S/Eksamen_19S.pdf
+[10]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/19S/Losning_19S.pdf
+[11]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18H/Eksamen_18H.pdf
+[12]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18H/Losning_18H.pdf
+[13]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18S/Eksamen_18S.pdf
+[14]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18S/Losning_18S.pdf
+[15]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18V/Eksamen_18V.pdf
+[16]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/18V/Losning_18V.pdf
+[17]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17H/Eksamen_17H.pdf
+[18]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17H/Losning_17H.pdf
+[19]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17V/Eksamen_17V.pdf
+[20]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/17V/Losning_17V.pdf
+[21]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/14S/Eksamen_14S.pdf
+[22]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/14S/Losning_14S.pdf
+[23]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/13S/Eksamen_13S.pdf
+[24]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/eksamen/13S/Losning_13S.pdf
+
+

ntnu/21v/ttk4145/summary/summary.md

@@ -0,0 +1,376 @@
+---
+title: "Oppsumering av TTK4145"
+description: "Lot of theory and discussion, some fomulas, spring 2021."
+date: 2021-05-04
+math: true
+---
+
+## Fault tolerance
+
+Hard to capture faults. 
+
+
+### Bugs
+
+* 1 bug per 50 lines before testing
+* 1 bug per 500 at release
+* 1 bug per 550 after a year, the constant
+
+1. Make the program work within specs.
+2. Run/Tests of the program-
+3. Errors happen
+4. Locate errors
+    * Incomplete spec
+    * Missing handleling of som situation
+5. Fix code
+
+### Traditional error handeling
+
+{% highlight c %}
+FILE *
+openConfigFile(){
+    FILE * f = fopen("/path/to/config.conf");
+    if (f == NULL) {
+        switch(errno){
+            case ENOMEM: {
+                ...
+                break;
+            }
+            case ENOTDIR: {
+                ...
+                break;
+            }
+            // Do this for all errors
+        }
+    }
+}
+{% endhighlight %}
+
+### Causes of errors
+
+* Incomplete specification
+* Software bugs
+* HW problems
+* Communication problems
+
+### Fault tolerance in real time systems
+
+The problem with traditional errorhandleing is that errors can happen at any possible time.
+This is extremely hard to test. 
+
+This is some of the error handling real time programming have.
+
+* Handling of unexpected errors
+* More threads hanles errors
+* Can not test the conventional way
+    * Can only show extistence of errors
+    * Can not find errors in specification
+    * Can not find race conditions
+
+The fault path is shown under.
+
+![Fault tolerance](figures/fault-path.svg)
+
+With fault tolerance the path looks something more like the figure under.
+
+![Fault tolerance](figures/fault-tolarance.svg)
+
+### Error handling
+
+Keep it simple!
+
+The error modes is a part of the module interface.
+
+One way is to handle all errors the same way.
+Handle the as if it was the worst error.
+Crash and start again.
+
+A different approach is to check that everything is OK.
+
+To test how the systems responds for a unknown error is to insert a failed acceptance test (a not OK signal).
+
+### Redundancy
+
+* If I have $N$ copies of my data, it is possible to handle that one is destroyed.
+* Sending $N$ messages, trying $N$ times.
+
+**Static redundancy**
+
+* $N$ active copies. Sending $N$ messages if it is necessary or not.
+* Detecting errors is not important.
+* Handles cosmic rays easily.
+
+**Dynammic redunancy**
+
+* Relies on detecting the error and recovering
+    * Resend if timeout and not receiving "ack"
+    * Go with default if no messages have been received
+* The acceptancetest must be good.
+
+
+### Fault model
+
+#### Example with storage functions.
+
+**Step 1: Failure modes**
+
+Find the failure modes: What could go wrong?
+
+* **Write**: May return "I failed". Does not know why it faield
+* **Read**: May return "I failed". Does not know why it failed.
+
+**Step 2: Detect, Simplify, Inject errors**
+
+* Write information on where/what/how the process is doing.
+* All errors --> Fail
+* Inject errors
+
+**Step 3: Handling with redundancy**
+
+* Have multiple copies of the the information
+    * Use only the newest
+
+#### Example with communication function
+
+**Step 1: Failure modes**
+
+* Message
+    * Lost
+    * Delayed
+    * Corrupted
+    * Duplicated
+    * Wrong recipient
+
+**Step 2: Detection, Merging of errormodes and error injection**
+
+* Adding information to message
+    * Checksum
+    * Session ID
+    * Sequence number
+* Adding "ack" on well recieved messages
+* All errors will be treaded as "Lost message"
+* Injection
+    * Occasionally throw away some messages
+
+**Step 3: Handling with redundancy**
+
+* Timeout 
+* Retransmit message
+
+#### Example with processes and caculations
+
+A calculation is an abstract, so how can we talk generally about the failure modes.
+
+**Step 1: Failure modes**
+
+One failure mode
+
+**Step 2: Detect, simplify, inject errors**
+
+All failed acceptance tests will "PANIC" or "STOP".
+
+**Step 3: Handling with redundancy**
+
+There are three solutions:
+
+1. Checkpoint restart
+    * Do all the work incuding the acceptance test
+    * Wait with the "side effects"
+    * Store a checkpoint
+    * Do the "side effects"
+2. Process pairs
+        * Crash and let an another process take over
+3. Presistent processes
+
+
+## Transactions
+
+A transaction is a design framework for Damage Confinement and Error Recovery.
+
+* An *atomic action*, just without the backward recovery error mode as standard mode
+* invincible and instantaneous "calculation" seen from the outside
+* A transformation from one consistent state to another'
+* A modular computation
+
+### Four features: ACID
+
+* **A**tomicity: Either all side effects happens or none
+* **C**oncistency: Leaves the system in a consistent state when finished
+* **I**solation: Errors does not spread
+* **D**urability: Results are not lost
+
+### Atomic Actions
+
+**Resumption vs. Termination mode**
+* If we continue where we were (e.g. after the interrupt) --> *Resumption*
+* If we continue somewhere else (i.e. terminating what we where doing) --> Termination
+
+**Async Notification (AN) = Low level thread interaction**
+* Async event handling. ("Signals") (resumption)
+    * Modeled after a HW interrupt
+    * Can be sent to the correct thread
+    * Can be handled, ignored, blocked --> The domain can be controlled.
+    * Often lead to polling
+        * Could rather skip the signal and poll a status variable or a message queue
+        * Useless
+* ATC --> Async transfer of Control (termination)
+    * Canceling threads
+    * setjmpt/longjmp could convert signals to ATC (not really, but still)
+    * ADA: a strictured mechanism for ATV is integraded with the selected statement
+    * RT Java: A structured mechanism for ATC is integraded with the exception-handling mechanism
+
+#### Cancelling threads
+
+**Yes, killing threads is ATC!**
+
+* Can make termination model by letting domain be a thread
+    * "Create a `doWork` thread, and kill it if the action fails"
+* Ca still control domain by disabling "cancelstate"
+
+**But, but, but: It leaves ut in undifined state!?**
+* Not if we have...
+    * Full control over changed state (like logs or recovery points) or some other way of recovering well.
+    * A lock manager that can unlock on behalf of killed thread
+    * Some control of where we were killed (like nok in the middle of a lock manager or log call)
+* An this is what we have!
+
+
+## Shared variable synchronization
+
+### Non-Preemptive scheduling
+
+Controlling a pump filling a tank.
+
+**Spec:**
+* Every second: measure the water level of the tank and generate the reference to the pump
+* 10 times a second: Set the power of the pump motor
+* Do some GUI: let the human control the process
+
+#### A trivial solution: "Cyclic Exectutive"
+
+{% highlight c %}
+oldTime = now();
+i = 0;
+while(true) {
+    i = i + 1;
+    if (i % 10 == 0) {
+        i = 0;
+        calculatePumpReference();
+    }
+    controlPump();
+    do {
+        handleUserEvent();
+    } while(now() < oldTime + 0.1);
+    oldTime = oldTime + 0.1;
+}
+{% endhighlight %}
+
+**Drawbacks**
+
+* OK tasks?
+* Timing hard to tune (what if pump sampling should be $\pi$/10?)
+* Overload (what if `calucaltePumpReference` uses more than 1/10 seconds?)
+* How to add new tasks? (Everything is coupled)
+* Waste of time in the do-loop?
+* What is priority of `handleUserEvents`?
+* How are erros, exceptions, alarms etc. handled?
+
+#### Better soulution with Non-preemptive scheduler
+
+* *3 taskts* administered by a scheduler
+* The scheduler takes care of who runs and timing
+* Scheduler often inculuded in OSes
+* Introducing priorities
+
+{% highlight c %}
+/**
+    * scheduler_registerThread(function, time, priority)
+    * Higher priority numer means higher priority in scheduler
+    */
+main() {
+        scheduler_registrerThread(controlPump, 0.1, 3);
+        scheduler_registrerThread(calculatePumpReference, 1, 2);
+        scheduler_registrerThread(handleUserEvents, 0.2, 1);
+        scheduler_mainLoop();
+}
+{% endhighlight %}
+
+**Some notes on priorities**
+* Priority is generally not important; rather, the main rule is to give higher priority to shorter-deadline tasks. 
+    * This allows tasks to reach its deadlines.
+* ... but this is not always the case - if e.g. the tasks are cooperating
+* We still handle overload badly
+* And: What connection between deadline and priority to start with?
+    * Is this a good dependency seen from a code quality perspective?
+
+### Pros and cons of nonpreemptive scheduling
+
+| **Pros**                                       | **Cons**                                                                   |
+| :--------------------------------------------- | :------------------------------------------------------------------------- |
+| Simple, intuitive, predictable                 | C macro hell                                                               |
+| No kernel                                      | Threads must cooperate <-- a form of dependency breaking module boundaries |
+| Fast switching times                           | Heavy threads must be divided                                              |
+| Some elegant sunchronization patterns possible | Can we handle blocking of library functions?                               |
+|                                                | Unrobust to errors                                                         |
+|                                                | Unrobust to (heavy) error handling                                         |
+|                                                | Hard to tune at end of project                                             |
+{: .table-responsive-lg .table }
+
+
+
+### Preemptive Kernel
+
+* Preemption, thread objects and the timer interrupt
+* Enabling synchronization: Busy waiting, tes-and-set, disabling the timer interrupt
+* Blocking and suspend & resume
+* An API for synchronization? Semaphores!
+
+
+#### Preemption
+
+* Make a handler for a timer interrupt
+* Store all registers (including IP & SP) in a "thread object"
+* Organize queue of processes (Round Robin e.g. - a collection of thread objects?)
+* Can synchronize by: while(!ready); (busy wating, "spin locks")
+
+**Bad solution**
+
+{% highlight c%}
+while(lock==1) {}
+lock = 1;
+    // We may run
+lock = 0;
+{% endhighlight %}
+
+**Better solution**
+
+{% highlight c%}
+void t1() {
+    flag1 = 1;  // Declare my intention
+    turn  = 2;  // But try to be polite
+    while(flag2 == 1 && turn == 2) {}
+    // We may run
+    flag1 = 0;
+}
+{% endhighlight %}
+
+##### Looking more closely at the arsenal
+
+**How can we make basic synchronization under preemption?**
+
+* Spin locks (wasting time and cpu)
+* Test&Set (swap) assembly instruction (atomic, but not obvious)
+* Disable interrupt (steals control from OS/scheduler)
+
+**But**
+* If we disable the timer interrupt we don not have preemption any more
+* And... Are these good abstractions in the application programmer domain?
+
+#### Blocked threads
+
+**Let us introduce another queue; the collection of threads not running, waiting for something**
+
+* Fixes the bad performance of spin locks. Is conceptually better.
+* "Suspend" moves a thread object from "run" queue to "blocked" queue
+* "Resume" moves it back.
+

ntnu/21v/ttk4145/ttk4145.md

@@ -0,0 +1,15 @@
+---
+layout: layouts/list
+title: "TTK4145"
+description: "Sanntidsprogrammering"
+---
+
+## Oppsummering
+
+[Oppsummering](summary/) av faget TTK4145.
+
+## Prosjekt
+
+## Øvinger
+
+

ntnu/21v/ttt4280/lab/1/1.md

@@ -0,0 +1,34 @@
+---
+layout: layouts/lecture
+title: "TTT4280"
+description: "Labforelesning 1"
+date: "2021-01-18"
+math: false
+---
+
+## Laboratorium
+
+### System
+
+* Raspberry Pi
+* Linux
+* A/D omformere
+* Python
+
+### Oppgaver
+
+* Systemoppsett
+  * Klargjøre rPi og instrumenteringskrets
+* Akustikk
+  * Beregne retning til lydkilde
+* Radar
+  * Doppler
+* Optikk
+
+## Laboppgave 1
+
+1. Tegne blokkdiagram
+2. Studere datablat for ADC
+3. Drøfte fordeler med DMA
+
+![Blokk](figures/TTT4280%20-%20Lab%20Blokk.png)

ntnu/21v/ttt4280/lectures/2021-01-11/2021-01-11.md

@@ -0,0 +1,57 @@
+---
+title: "TTT4280 - Måleusikkerhet"
+description: "2021-01-11"
+math: true
+---
+
+## Faglig innhold
+
+* Måleusikkerhet
+* Støyanalyse
+* Sensorer og aktuatorer
+* Sensortyper
+
+## Hva er sensorer
+
+Noe som kan lese den fysiske verdenen til noe vi kan prosessere.
+
+Finnes mange forskjellige sensorer. Flere i biler, telefoner, klokker osv.
+
+Tidligere ble det estimert at vi skulle ha ca 50 milliarder sensorer i 2020. 
+
+## Måleusikkerhet
+
+Bruk av sensor = Utføre en måling.
+
+...og måleverdier har en usikkerhet.
+
+I visse situasjoner har måleusikkerheten masse å si, i andre har det ikke så mye å si.
+
+Sensitivitet er en måling for å ikke gjøre en Type II feil (alarmen løser **ikke** ut).
+
+Spesifisitet er en måling for å ikke gjøre en Type I feil (**falsk** alarm).
+
+
+
+### Grunnmodell for måleprosess
+
+![Grunnmodell](figures/grunnmodell.jpg)
+
+I realiteten er det støy i alle ledd.
+
+Sannsynligheten for at et sensorsystem gir riktig svar påvirkes av (minst) to faktorer:
+
+* Hvor entydig er underliggende sammenhenger?
+* Hvor nøyaktig kan vi måle de fysiske størrelsene?
+
+$$ \text{SNR} = \frac{\text{(Effekten for) sann verdi}}{\text{(Effekten for) støy}} $$
+
+### Målefeil
+
+Stokastiske feil (Type A feil) påvirker målingens *presisjon*. 
+Presisjonen beskriver hvor reproduserbar en måling er.
+
+Systematiske feil (Type B feil) påvirker målingens *sannhet*. 
+Sannheten er en måling på hvor langt unna den sanne verdien en måling er.
+
+![Målefeil](figures/true-prec.jpg)

ntnu/21v/ttt4280/lectures/2021-01-18/2021-01-18.md

@@ -0,0 +1,8 @@
+---
+layout: layouts/lecture
+title: "TTT4280"
+description: "Usikkerhet og feilforplantning"
+date: "2021-01-18"
+math: true
+---
+

ntnu/21v/ttt4280/ttt4280.md

@@ -0,0 +1,12 @@
+---
+layout: layouts/list
+title: "TTT4280"
+description: "Sensorer og instrumentering"
+---
+
+## Forelesninger
+
+[2021-01-11](./lectures/2021-01-11/) - Intro og målesikkerhet
+
+[2021-01-18](./lectures/2021-01-18/) - Usikkerhet og feilforplantning
+

ntnu/ntnu.html

@@ -4,13 +4,15 @@ title: "NTNU"
 description: "Alt som har med studier på NTNU å gjøre."
 ---
 
-{% assign courses = site.data.ntnu-courses | sort: 'update' %}
+{% for semester in site.data.ntnu-courses %}
+<h2>{{ semester.name }}</h2>
+{% assign courses = semester.courses | sort: 'updated' | reverse %}
 <div class="row row-cols-1 row-cols-md-3">
 {% for course in courses %}
   <div class="col mb-4">
     <div class="card h-100">
       <div class="card-body">
-        <h5 class="card-title no-anchor" data-toc-skip><a href="{% if course.href %}{{ course.href }}{% else %}{{ course.course }}{% endif %}">{{ course.course | upcase }}</a></h5>
+        <h5 class="card-title no-anchor" data-toc-skip><a href="{{ semester.href }}/{% if course.href %}{{ course.href }}{% else %}{{ course.course }}{% endif %}">{{ course.course | upcase }}</a></h5>
         <p class="card-text">{{ course.desc }}</p>
       </div>
       <div class="card-footer">
@@ -19,4 +21,5 @@ description: "Alt som har med studier på NTNU å gjøre."
     </div>
   </div>
 {% endfor %}
-</div>
+</div>
+{% endfor %}