finish day 3

_data/ntnu-courses.yml

@@ -11,6 +11,14 @@
       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-04
 
 # Høsten 2020
 -

_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

@@ -4,4 +4,8 @@ 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-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

@@ -4,6 +4,12 @@ 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-12](./lectures/2021-01-12/) - Intro
+
+[2021-01-14](./lectures/2021-01-14/) - Bølger forts.

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

@@ -0,0 +1,200 @@
+---
+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

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-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

@@ -8,3 +8,5 @@ description: "Sensorer og instrumentering"
 
 [2021-01-11](./lectures/2021-01-11/) - Intro og målesikkerhet
 
+[2021-01-18](./lectures/2021-01-18/) - Usikkerhet og feilforplantning
+