note about peripherals

diff --git a/arch.example.tex b/arch.example.tex
index ad8c4db..0a05087 100644 (file)
--- a/arch.example.tex
+++ b/arch.example.tex
@@ -137,7 +137,6 @@ functionality.
        | BCValidHB
        | BCGetSP02
        | BCValidSP02
-       | ...
 
 instance hb ByteCode where
        getHb = tell` [BCGetHB]
@@ -150,6 +149,11 @@ instance hb ByteCode where
 The bytecode instructions are added but still the functionality needs to be
 added to the device interface to be implemented by clients. The following
 addition to \CI{interface.h} and the interpreter shows the added instructions.
+When adding a peripheral, the devices not having the peripheral do not need to
+have their code recompiled. New instructions always get a higher bytecode
+number if added correctly. The peripheral byte in the device specification by
+default shows a negative flag for every peripheral. Only the peripherals added
+will be flagged positive.
 
 \begin{lstlisting}[caption={Adding the device interface}]
 // interface.h

diff --git a/conclusion.conclusion.tex b/conclusion.conclusion.tex
index 4fde493..6845813 100644 (file)
--- a/conclusion.conclusion.tex
+++ b/conclusion.conclusion.tex
@@ -23,4 +23,6 @@ techniques such as generating \gls{C} code are not suitable for dynamic
 design fail-over mechanisms. When a device is assigned a \gls{Task} but another
 device suddenly becomes unusable, the \gls{iTasks} system can reassign a new
 \gls{mTask}-\gls{Task} to another device that is also suitable for running the
-\gls{Task} without needing to recompile the code.
+\gls{Task} without needing to recompile the code. It also showed that adding
+peripherals is not a time consuming task and does not even requires
+recompilation of clients not having the peripheral.