Change computer

Started new post
Post about how glados.no is created
2020-12-29 23:00:49 +01:00 · 2020-12-26 18:53:35 +01:00
103 changed files with 90 additions and 985 deletions
--- a/2
+++ b/2
@@ -7,7 +7,7 @@ source "https://rubygems.org"
 #
 # This will help ensure the proper Jekyll version is running.
 # Happy Jekylling!
-gem "jekyll", "~> 4.2.0"
+gem "jekyll", "~> 4.1.1"
 # This is the default theme for new Jekyll sites. You may change this to anything you like.
 # If you want to use GitHub Pages, remove the "gem "jekyll"" above and
--- a/_config.yml
+++ b/_config.yml
@@ -32,10 +32,11 @@ author:
  git_username:  oyvindskaaden
 collections:
  posts:
    excerpt_separator: <!--more-->
    permalink: 
 markdown:         kramdown
@@ -52,7 +53,7 @@ defaults:
      type: "posts"
    values:
      layout: layouts/post
-      permalink: /prosjekter/:categories/:year/:month/:day/:title
+      permalink: /prosjekter/:year/:month/:day/:title
  -
    scope:
      path: "ntnu/*"
--- a/_data/ntnu-courses.yml
+++ b/_data/ntnu-courses.yml
@@ -1,89 +1,51 @@
 # 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-18
    -
      course: tiø4252
      desc: Teknologiledelse, våren 2021.
      updated: 2021-05-13
 # Høsten 2020
-
+- 
-  name: Høsten 2020
+  course: tfe4152
-  href: 20h
+  desc: Design av integrerte kretser, høsten 2020.
-  courses:
+  updated: 2020-12-16
-    - 
+  href: tfe4152/summary
-      course: tfe4152
+- 
-      desc: Design av integrerte kretser, høsten 2020.
+  course: ttt4120
-      updated: 2020-12-16
+  desc: Digital signalbehandling, høsten 2020.
-      href: tfe4152/summary
+  updated: 2020-12-06
-    - 
+  href: ttt4120/summary
-      course: ttt4120
+- 
-      desc: Digital signalbehandling, høsten 2020.
+  course: mfel3010
-      updated: 2020-12-06
+  desc: Medisin for teknologi- og realfagsstudenter, høsten 2020.
-      href: ttt4120/summary
+  updated: 2020-11-25
-    - 
+  href: mfel3010/summary
-      course: mfel3010
+- 
-      desc: Medisin for teknologi- og realfagsstudenter, høsten 2020.
+  course: tfe4146
-      updated: 2020-11-25
+  desc: Halvlederkomponenter, høsten 2020.
-      href: mfel3010/summary
+  updated: 2020-11-23
-    - 
+  href: tfe4146/summary
      course: tfe4146
      desc: Halvlederkomponenter, høsten 2020.
      updated: 2020-11-23
      href: tfe4146/summary
 # Våren 2020
-
+- 
-  name: Våren 2020
+  course: ttt4270
-  href: 20v
+  desc: Elektronisk systemdesign, prosjekt, våren 2020.
-  courses:
+  updated: 2020-05-05
    - 
      course: ttt4270
      desc: Elektronisk systemdesign, prosjekt, våren 2020.
      updated: 2020-05-05
 # Høsten 2019
-
+- 
-  name: Høsten 2019
+  course: ttt4265
-  href: 19h
+  desc: Elektronisk systemdesign og -analyse II, høsten 2019.
-  courses:
+  updated: 2019-12-02
-    - 
+- 
-      course: ttt4265
+  course: tdt4160
-      desc: Elektronisk systemdesign og -analyse II, høsten 2019.
+  desc: Datamaskiner og digitalteknikk, høsten 2019.
-      updated: 2019-12-02
+  updated: 2019-11-28
    - 
      course: tdt4160
      desc: Datamaskiner og digitalteknikk, høsten 2019.
      updated: 2019-11-28
 # Våren 2019
-
+- 
-  name: Våren 2019
+  course: ttt4260
-  href: 19v
+  desc: Elektronisk systemdesign og -analyse I, våren 2019.
-  courses:
+  updated: 2019-05-05
-    - 
+- 
-      course: ttt4260
+  course: tma4105
-      desc: Elektronisk systemdesign og -analyse I, våren 2019.
+  desc: Matematikk 2, våren 2019.
-      updated: 2019-05-05
+  updated: 2019-05-21
-    - 
+- 
-      course: tma4105
+  course: tdt4102
-      desc: Matematikk 2, våren 2019.
+  desc: Prosedyre og objektorientert programmering, våren 2019.
-      updated: 2019-05-21
+  updated: 2019-05-15
    - 
      course: tdt4102
      desc: Prosedyre og objektorientert programmering, våren 2019.
      updated: 2019-05-15
--- a/_includes/structure/head.html
+++ b/_includes/structure/head.html
@@ -1,5 +1,4 @@
 <head>
 	<meta name="HandheldFriendly" content="True">
 	<meta name="MobileOptimized" content="320">
 	<meta charset="utf-8">
@@ -18,7 +17,6 @@
 		<link rel="stylesheet" href="{{ "/assets/css/default.css" | relative_url }}"/>
 	{% endif %}
 	<title>
 		{% if page.title %}
 				{{ page.title }} &middot; {{ site.title }}
--- a/_includes/structure/nav.html
+++ b/_includes/structure/nav.html
@@ -11,7 +11,7 @@
 			<div class="navbar-nav"><!--ml-auto for høyrejustering-->
 				<!--<a class="nav-item nav-link {% if page.url == '/' %}active{% endif %}" href="/">Hjem</a>-->
 				{% for entry in site.data.nav %}
-					<a class="nav-item nav-link {% if page.url contains entry.href and page.url != / %}active{% endif %}" href="{{ entry.href }}">{{ entry.title }}</a>
+				<a class="nav-item nav-link {% if page.url contains entry.href and page.url != / %}active{% endif %}" href="{{ entry.href }}">{{ entry.title }}</a>
 				{% endfor %}
 			</div>
 			<div class="navbar-nav ml-auto">
--- a/_includes/utils/scripts.html
+++ b/_includes/utils/scripts.html
@@ -2,7 +2,6 @@
 <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>
@@ -11,4 +10,4 @@
  icon: '#',
  };
  anchors.add('h1, h2, h3, h4, h5').remove('.no-anchor');
-</script>
+</script>
--- a/_layouts/layouts/lecture.html
+++ b/_layouts/layouts/lecture.html
@@ -1,20 +0,0 @@
 ---
 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>
--- a/_posts/2020-12-26-glados.no.md
+++ b/_posts/2020-12-26-glados.no.md
@@ -0,0 +1,32 @@
 ---
 title:  "glados.no"
 description: Hvordan generere nettsider med git og jekyll
 date:   2020-12-26
 categories: glados
 tags: website glados jekyll git gitea
 ---
 Hvordan er egentlig [glados.no](https://glados.no) satt opp som en kontinuerlig integrasjon ved hjelp av jekyll, bootstrap og git.
 <!--MORE-->
 ## Prinsipp
 Jeg er er en ganske lat person, men jeg ønsker å lage en velutformet personlig nettside med alt fra personlige prosjekter til fag på NTNU.
 Derfor ønsker jeg å sette opp en statisk nettsidegenerator som gjør det enkelt for meg å oppdatere og legge nye til til på nettstedet. 
 ### Statisk nettsidegenerator
 En bra løsning på dette problemet er å bruke en statisk nettsidegenerator. 
 Da er det mulig å skrive hele nettsteder i det enkle språket markdown, som bruker en syntaks for å beskrive hvilke elementer som brukes. 
 Språket brukes på alt fra GitHub (på README filene) til å skrive større dokumentasjon med Pandoc.
 Det finens uttallige forskjellige generatorer, men de to store (i dag) er [jekyll](https://jekyllrb.com/) og [HUGO](https://gohugo.io/). 
 Begge baserer seg på markdown, har en ganske lik filstruktur og er begge brukt masse. 
 Jekyll brukes faktisk for å generere [Github Pages](https://pages.github.com/). 
 ### Versjonskontroll
--- a/about.md
+++ b/about.md
@@ -1,11 +1,7 @@
 ---
-layout: layouts/list
+layout: layouts/page
 title: Om
 permalink: /om/
 ---
-Mitt navn er Øyvind Skaaden. Jeg er 22 år gammel og studerer Elektronisk systemdesign og innovasjon på NTNU.
+Mitt navn er Øyvind Skaaden. Jeg er 21 å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/).
--- a/assets/css/components/theme.css
+++ b/assets/css/components/theme.css
@@ -102,7 +102,6 @@ blockquote {
 a {
  color: var(--link-color);
  text-decoration: none;
 }
 a:hover {
--- a/assets/css/home.css
+++ b/assets/css/home.css
@@ -27,13 +27,7 @@
  min-height: calc(100vh - 47.75rem);
 }
-/*
+.home-link>a {
 .home-link a{
  text-decoration: none;
 }
 */
 a.home-link:hover{
  text-decoration: none;
 }
--- a/index.html
+++ b/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 class="home-link" href="{{ home.href }}">
+      <a 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 %}
--- a/ntnu/21v/tfe4130/lectures/2021-01-12/2021-01-12.md
+++ b/ntnu/21v/tfe4130/lectures/2021-01-12/2021-01-12.md
@@ -1,74 +0,0 @@
 ---
 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 $$
--- a/ntnu/21v/tfe4130/lectures/2021-01-14/2021-01-14.md
+++ b/ntnu/21v/tfe4130/lectures/2021-01-14/2021-01-14.md
@@ -1,24 +0,0 @@
 ---
 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.
--- a/ntnu/21v/tfe4130/tfe4130.md
+++ b/ntnu/21v/tfe4130/tfe4130.md
@@ -1,15 +0,0 @@
 ---
 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.
--- a/ntnu/21v/tiø4252/tiø4252.md
+++ b/ntnu/21v/tiø4252/tiø4252.md
@@ -1,68 +0,0 @@
 ---
 title: TIØ4252
 description: Teknologiledelse, våren 2021
 date: 2021-05-13
 ---
 ## Formelark
 Formelark i TIØ4252 kan finnes [her][formel].
 Kildekoden ligger på [git][git_formel].
 [formel]:https://git.glados.no/oyvindskaaden/TIO4252/raw/branch/main/formelark/formelark.pdf
 [git_formel]:https://git.glados.no/oyvindskaaden/TIO4252/src/branch/main/formelark/
 ## 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
--- a/ntnu/21v/ttk4145/summary/figures/fault-path.svg
+++ b/ntnu/21v/ttk4145/summary/figures/fault-path.svg
--- a/ntnu/21v/ttk4145/summary/figures/fault-tolarance.svg
+++ b/ntnu/21v/ttk4145/summary/figures/fault-tolarance.svg
--- a/ntnu/21v/ttk4145/summary/summary.md
+++ b/ntnu/21v/ttk4145/summary/summary.md
@@ -1,540 +0,0 @@
 ---
 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 java %}
 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 java %}
 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 java %}
 /**
    * 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 java%}
 while(lock==1) {}
 lock = 1;
    // We may run
 lock = 0;
 {% endhighlight %}
 **Better solution**
 {% highlight java%}
 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.
 ##### Two bad solutions
 {% highlight java%}
 t1(){
    while(busy == 1) suspend();
    busy = 1;   // It is free; tak it - No
        // Run
    busy = 0;   // Release resource
    resume t2 // No
 }
 {% endhighlight %}
 or 
 {% highlight java%}
 t1(){
    while(TestNSet(busy, 1) == 1) suspend();
        // We own resource
        // Run
    busy = 0;
    resume t2 // No
 }
 {% endhighlight %}
 ##### The suspend/resume problem
 {% highlight java%}
 // Global variables
 bool g_initDone = False;
 // Threads
 t1(){                           t2(){
    /* Do init */                   if (g_initDone == False) {
    g_initDone = True;                  Suspend();
    resume(t2)                      }
    // Continue executing           // Continue exectuting
 }                               }
 {% endhighlight %}
 #### Priorities
 * Threads mey have different *priorities*. (A sortet run-queue, or more of them.)
 * Only if there are no running threads on a higher priority, a thread will run.
 * We are not aiming for some sens of fairness (!). But predictability.
 * And priorities supports schedulability proofs.
 * But we open ourselves up to *starvation*. A thread may not ever get to run, even if it is runnable.
 #### Application-level syncronization
 **SO, the application programmer needs some syncronozation primitives...**
 * `sleep()`? - Ok
 * Publish `suspend` and `resume` - No
 * Events (`wait` and `signal`) - Just named versions of suspend & resume semantics.
  * Fixes the need to know aboud "thread objects". But no
 * ...or "Condition variables" - same
 ### Semaphores
 **A counting semaphore**
 * `signal(SEM)` increases the counter (possibly resuming a thread waiting for the semaphore)
 * `wait(SEM)` decrements the counter - will block (be suspended) `if SEM == 0`
  * The semaphores value can not be negative
 * Of course; These calls are protected from interleaving by disabling the timer interrupt
 **We solve beautifully:**
 * Mutual Exclusion
 * Conditional Synchronization (ref `suspend`/`resume`)
 * Basic resource allocation
 **Semaphore variations**
 * `wait` and `signal` nay take parameter value to add or subtract
 * `getValue(SEM)` returning the value of the semaphore. (Fishy)
 * BInary semaphores (`signal` will fail `if SEM == 1`)
 * Who is woken at `signal` (FIFO, Arbitrary, Highest priority)
 * The mutex
  * binary
  * ownership
  * allows mulitple waits by owner
  * regions (may be released by Javas `wait` or POSIX condition variables)
 * RTFM
 **Semaphore challenges**
 * Breaks modules (both ways)
  * Does not scale!
 * Deadlocks
  * Global analysis --> Does not scale
 * Can not release "temporarily
 * "Limited expressive power". Some reasonalbe problems are hard to solve
  * Ref ["The Little Book of Semaphores"](https://greenteapress.com/semaphores/LittleBookOfSemaphores.pdf)
 ### Why shared-variable synchronization
 **Why not?**
 * "Shared variables" is bad code quality
  * Ref global variables, and data members in module interfaces
 * An obvious bottleneck? Scales terribly
 * "Variables" are passive objects
  * They can not protect themselves
 * Why use synchronization when it is communication we need?
 * Technology transfers badly to distibuted systems
 * ... and this is before we start discussing how hard it is
 **Why?**
 * Part of the "real-time" design pattern
  * "One thread per timing demand" 
  * We do have scheduling proofs and best practises
 * Timing analysis is global anyway
  * Scalability and deadlock analysis may not be the limiting constraint
 * HW is shared memory architecture
  * Infrastucture is avalible
 * Communication systems requires infrastucture that we may not have
 #### *All* resources are shared!
 * Memory, certainly
 * "Hidden" memory used by libraries (.. your own modules and the kernel)
  * If the library takes care of this itself, it is called *"reentrant"*
 * Sensors and actuators
 * "CPU" - Computing capacity 
  * *This* is real-time programming; We solve it by *Scheduling*
 * ... any other interface
 #### Some standard problems/pit-falls
 * **Race condition**: A bug that surfaces by unfortunate timing or order of events
 * **Deadlock:** system in circular wait
  * Special case of livelock
  * Does not use CPU
 * **Livelock:** system locked in a subset of states 
  * like deadlock, but we use CPU
  * Busy-Waiting is a livelock
 * **Starvation:** A thread does "by accident" not get the necessary resources
 #### Features in syncronization
 * Critical Section - Code that must not be interupted
 * Mutual Exclusion - More piecesof code that must not interrupt each other
 * Bounded buffer - Buffer with full/empty synchronization
 * Read/Write Locks
  * Readers can interleave eachother
  * Writers have mutual exclusion
 * Condition Syncronization - Blocking on event or status
  * Guards etc.
 * Resource allocation
  * More than mutual exclution!
  * Ref: The lock manager
 * Rendezvouz/barriere - Synchronization point
  * Ref: AA "end boundary"
 * Communication
 * Broadcast
 * ...
--- a/ntnu/21v/ttk4145/ttk4145.md
+++ b/ntnu/21v/ttk4145/ttk4145.md
@@ -1,15 +0,0 @@
 ---
 layout: layouts/list
 title: "TTK4145"
 description: "Sanntidsprogrammering"
 ---
 ## Oppsummering
 [Oppsummering](summary/) av faget TTK4145.
 ## Prosjekt
 ## Øvinger
--- a/ntnu/21v/ttt4280/lab/1/1.md
+++ b/ntnu/21v/ttt4280/lab/1/1.md
@@ -1,34 +0,0 @@
 ---
 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)
--- a/ntnu/21v/ttt4280/lab/1/figures/TTT4280
+++ b/ntnu/21v/ttt4280/lab/1/figures/TTT4280
--- a/ntnu/21v/ttt4280/lectures/2021-01-11/2021-01-11.md
+++ b/ntnu/21v/ttt4280/lectures/2021-01-11/2021-01-11.md
@@ -1,57 +0,0 @@
 ---
 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)
--- a/ntnu/21v/ttt4280/lectures/2021-01-11/figures/grunnmodell.jpg
+++ b/ntnu/21v/ttt4280/lectures/2021-01-11/figures/grunnmodell.jpg
--- a/ntnu/21v/ttt4280/lectures/2021-01-11/figures/true-prec.jpg
+++ b/ntnu/21v/ttt4280/lectures/2021-01-11/figures/true-prec.jpg
--- a/ntnu/21v/ttt4280/lectures/2021-01-18/2021-01-18.md
+++ b/ntnu/21v/ttt4280/lectures/2021-01-18/2021-01-18.md
@@ -1,8 +0,0 @@
 ---
 layout: layouts/lecture
 title: "TTT4280"
 description: "Usikkerhet og feilforplantning"
 date: "2021-01-18"
 math: true
 ---
--- a/ntnu/21v/ttt4280/ttt4280.md
+++ b/ntnu/21v/ttt4280/ttt4280.md
@@ -1,12 +0,0 @@
 ---
 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
--- a/ntnu/20h/mfel3010/summary/figures/blodårer.png
+++ b/ntnu/20h/mfel3010/summary/figures/blodårer.png
--- a/ntnu/20h/mfel3010/summary/figures/cellInBody.png
+++ b/ntnu/20h/mfel3010/summary/figures/cellInBody.png
--- a/ntnu/20h/mfel3010/summary/figures/celleMedKaliumNatrium.png
+++ b/ntnu/20h/mfel3010/summary/figures/celleMedKaliumNatrium.png
--- a/ntnu/20h/mfel3010/summary/figures/celleMembran.png
+++ b/ntnu/20h/mfel3010/summary/figures/celleMembran.png
--- a/ntnu/20h/mfel3010/summary/figures/celledeling.png
+++ b/ntnu/20h/mfel3010/summary/figures/celledeling.png
--- a/ntnu/20h/mfel3010/summary/figures/graywhitematerialBrain.png
+++ b/ntnu/20h/mfel3010/summary/figures/graywhitematerialBrain.png
--- a/ntnu/20h/mfel3010/summary/figures/mitokondrie.png
+++ b/ntnu/20h/mfel3010/summary/figures/mitokondrie.png
--- a/ntnu/20h/mfel3010/summary/figures/mutatorGenes.png
+++ b/ntnu/20h/mfel3010/summary/figures/mutatorGenes.png
--- a/ntnu/20h/mfel3010/summary/figures/oragnsOfTheBody.png
+++ b/ntnu/20h/mfel3010/summary/figures/oragnsOfTheBody.png
--- a/ntnu/20h/mfel3010/summary/figures/ribosom.png
+++ b/ntnu/20h/mfel3010/summary/figures/ribosom.png
--- a/ntnu/20h/mfel3010/summary/figures/theBrain.png
+++ b/ntnu/20h/mfel3010/summary/figures/theBrain.png
--- a/ntnu/20h/mfel3010/summary/summary.md
+++ b/ntnu/20h/mfel3010/summary/summary.md
--- a/ntnu/ntnu.html
+++ b/ntnu/ntnu.html
@@ -4,15 +4,13 @@ title: "NTNU"
 description: "Alt som har med studier på NTNU å gjøre."
 ---
-{% for semester in site.data.ntnu-courses %}
+{% assign courses = site.data.ntnu-courses | sort: 'update' %}
 <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="{{ semester.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="{% 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">
@@ -21,5 +19,4 @@ description: "Alt som har med studier på NTNU å gjøre."
    </div>
  </div>
 {% endfor %}
-</div>
+</div>
 {% endfor %}
--- a/ntnu/19v/tdt4102/tft4102.md
+++ b/ntnu/19v/tdt4102/tft4102.md
--- a/ntnu/20h/tfe4146/summary/figures/BJTFourModes.png
+++ b/ntnu/20h/tfe4146/summary/figures/BJTFourModes.png
--- a/ntnu/20h/tfe4146/summary/figures/BJT_Carriers.png
+++ b/ntnu/20h/tfe4146/summary/figures/BJT_Carriers.png
--- a/ntnu/20h/tfe4146/summary/figures/HallEffect.png
+++ b/ntnu/20h/tfe4146/summary/figures/HallEffect.png
--- a/ntnu/20h/tfe4146/summary/figures/JEFT_Zoom.png
+++ b/ntnu/20h/tfe4146/summary/figures/JEFT_Zoom.png
--- a/ntnu/20h/tfe4146/summary/figures/JEFT_pinchoff.png
+++ b/ntnu/20h/tfe4146/summary/figures/JEFT_pinchoff.png
--- a/ntnu/20h/tfe4146/summary/figures/JFET-GateControl.png
+++ b/ntnu/20h/tfe4146/summary/figures/JFET-GateControl.png
--- a/ntnu/20h/tfe4146/summary/figures/JFET.png
+++ b/ntnu/20h/tfe4146/summary/figures/JFET.png
--- a/ntnu/20h/tfe4146/summary/figures/JFET_Analysis.png
+++ b/ntnu/20h/tfe4146/summary/figures/JFET_Analysis.png
--- a/ntnu/20h/tfe4146/summary/figures/MESFET.png
+++ b/ntnu/20h/tfe4146/summary/figures/MESFET.png
--- a/ntnu/20h/tfe4146/summary/figures/MOSFET.png
+++ b/ntnu/20h/tfe4146/summary/figures/MOSFET.png
--- a/ntnu/20h/tfe4146/summary/figures/alternateDiodeEq.png
+++ b/ntnu/20h/tfe4146/summary/figures/alternateDiodeEq.png
--- a/ntnu/20h/tfe4146/summary/figures/avalanche.png
+++ b/ntnu/20h/tfe4146/summary/figures/avalanche.png
--- a/ntnu/20h/tfe4146/summary/figures/biasPN.png
+++ b/ntnu/20h/tfe4146/summary/figures/biasPN.png
--- a/ntnu/20h/tfe4146/summary/figures/breakdown.png
+++ b/ntnu/20h/tfe4146/summary/figures/breakdown.png
--- a/ntnu/20h/tfe4146/summary/figures/carrierDensity.png
+++ b/ntnu/20h/tfe4146/summary/figures/carrierDensity.png
--- a/ntnu/20h/tfe4146/summary/figures/conductivity.png
+++ b/ntnu/20h/tfe4146/summary/figures/conductivity.png
--- a/ntnu/20h/tfe4146/summary/figures/continuityEq.png
+++ b/ntnu/20h/tfe4146/summary/figures/continuityEq.png
--- a/ntnu/20h/tfe4146/summary/figures/dos.png
+++ b/ntnu/20h/tfe4146/summary/figures/dos.png
--- a/ntnu/20h/tfe4146/summary/figures/fermiDirac.png
+++ b/ntnu/20h/tfe4146/summary/figures/fermiDirac.png
--- a/ntnu/20h/tfe4146/summary/figures/haynes-ShockleyExp.png
+++ b/ntnu/20h/tfe4146/summary/figures/haynes-ShockleyExp.png
--- a/ntnu/20h/tfe4146/summary/figures/haynes-ShockleyTheory.png
+++ b/ntnu/20h/tfe4146/summary/figures/haynes-ShockleyTheory.png
--- a/ntnu/20h/tfe4146/summary/figures/idealMOS.png
+++ b/ntnu/20h/tfe4146/summary/figures/idealMOS.png
--- a/ntnu/20h/tfe4146/summary/figures/intrinsic.png
+++ b/ntnu/20h/tfe4146/summary/figures/intrinsic.png
--- a/ntnu/20h/tfe4146/summary/figures/monirityDist.png
+++ b/ntnu/20h/tfe4146/summary/figures/monirityDist.png
--- a/ntnu/20h/tfe4146/summary/figures/particleBox.png
+++ b/ntnu/20h/tfe4146/summary/figures/particleBox.png
--- a/ntnu/20h/tfe4146/summary/figures/pn-efelt.png
+++ b/ntnu/20h/tfe4146/summary/figures/pn-efelt.png
--- a/ntnu/20h/tfe4146/summary/figures/pn-ladning.png
+++ b/ntnu/20h/tfe4146/summary/figures/pn-ladning.png
--- a/ntnu/20h/tfe4146/summary/figures/pnNatural.png
+++ b/ntnu/20h/tfe4146/summary/figures/pnNatural.png
--- a/ntnu/20h/tfe4146/summary/figures/pnSammen.png
+++ b/ntnu/20h/tfe4146/summary/figures/pnSammen.png
--- a/ntnu/20h/tfe4146/summary/figures/pnSteady.png
+++ b/ntnu/20h/tfe4146/summary/figures/pnSteady.png
--- a/ntnu/20h/tfe4146/summary/figures/pnTegning.png
+++ b/ntnu/20h/tfe4146/summary/figures/pnTegning.png
--- a/ntnu/20h/tfe4146/summary/figures/steadyStateBar.png
+++ b/ntnu/20h/tfe4146/summary/figures/steadyStateBar.png
--- a/ntnu/20h/tfe4146/summary/figures/steadyStatePN.png
+++ b/ntnu/20h/tfe4146/summary/figures/steadyStatePN.png
--- a/ntnu/20h/tfe4146/summary/figures/tetteBonds.png
+++ b/ntnu/20h/tfe4146/summary/figures/tetteBonds.png
--- a/ntnu/20h/tfe4146/summary/figures/virkemåteTransistor.png
+++ b/ntnu/20h/tfe4146/summary/figures/virkemåteTransistor.png
--- a/ntnu/20h/tfe4146/summary/figures/zener.png
+++ b/ntnu/20h/tfe4146/summary/figures/zener.png
--- a/ntnu/20h/tfe4146/summary/summary.md
+++ b/ntnu/20h/tfe4146/summary/summary.md
--- a/ntnu/20h/tfe4152/summary/figures/active.svg
+++ b/ntnu/20h/tfe4152/summary/figures/active.svg
--- a/ntnu/20h/tfe4152/summary/figures/diode.svg
+++ b/ntnu/20h/tfe4152/summary/figures/diode.svg
--- a/ntnu/20h/tfe4152/summary/figures/triode.svg
+++ b/ntnu/20h/tfe4152/summary/figures/triode.svg
--- a/ntnu/20h/tfe4152/summary/summary.md
+++ b/ntnu/20h/tfe4152/summary/summary.md
--- a/ntnu/19v/tma4105/tma4105.md
+++ b/ntnu/19v/tma4105/tma4105.md
--- a/ntnu/20h/ttt4120/summary/figures/DTFTSymmetry.png
+++ b/ntnu/20h/ttt4120/summary/figures/DTFTSymmetry.png
--- a/ntnu/20h/ttt4120/summary/figures/DirectTypeII.svg
+++ b/ntnu/20h/ttt4120/summary/figures/DirectTypeII.svg
--- a/ntnu/20h/ttt4120/summary/figures/IIR_Dir1.svg
+++ b/ntnu/20h/ttt4120/summary/figures/IIR_Dir1.svg
--- a/ntnu/20h/ttt4120/summary/figures/IIR_Dir2.svg
+++ b/ntnu/20h/ttt4120/summary/figures/IIR_Dir2.svg
--- a/ntnu/20h/ttt4120/summary/figures/LinearPhase.svg
+++ b/ntnu/20h/ttt4120/summary/figures/LinearPhase.svg
--- a/ntnu/20h/ttt4120/summary/figures/adder.svg
+++ b/ntnu/20h/ttt4120/summary/figures/adder.svg
--- a/ntnu/20h/ttt4120/summary/figures/constant.svg
+++ b/ntnu/20h/ttt4120/summary/figures/constant.svg
--- a/ntnu/20h/ttt4120/summary/figures/delay.svg
+++ b/ntnu/20h/ttt4120/summary/figures/delay.svg
--- a/ntnu/20h/ttt4120/summary/figures/diagonalConv.png
+++ b/ntnu/20h/ttt4120/summary/figures/diagonalConv.png
--- a/ntnu/20h/ttt4120/summary/figures/directFormI.svg
+++ b/ntnu/20h/ttt4120/summary/figures/directFormI.svg
--- a/ntnu/20h/ttt4120/summary/figures/idealFilter.svg
+++ b/ntnu/20h/ttt4120/summary/figures/idealFilter.svg
--- a/ntnu/20h/ttt4120/summary/figures/impulseResponse.png
+++ b/ntnu/20h/ttt4120/summary/figures/impulseResponse.png
--- a/ntnu/20h/ttt4120/summary/figures/input-output-corr.png
+++ b/ntnu/20h/ttt4120/summary/figures/input-output-corr.png
--- a/ntnu/20h/ttt4120/summary/figures/linearTimeInvariant.png
+++ b/ntnu/20h/ttt4120/summary/figures/linearTimeInvariant.png
--- a/ntnu/20h/ttt4120/summary/figures/longSeq.png
+++ b/ntnu/20h/ttt4120/summary/figures/longSeq.png
--- a/ntnu/20h/ttt4120/summary/figures/z-transform.png
+++ b/ntnu/20h/ttt4120/summary/figures/z-transform.png
--- a/ntnu/20h/ttt4120/summary/summary.md
+++ b/ntnu/20h/ttt4120/summary/summary.md
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Øyvind Skaaden	e891a1124a	Change computer	2020-12-29 23:00:49 +01:00
Øyvind Skaaden	ff28f125a1	Started new post Post about how glados.no is created	2020-12-26 18:53:35 +01:00