From 7b82824c3f3af1d6bc2d9824aae2cc2979ca8180 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 3 Jul 2017 16:50:01 +0200 Subject: [PATCH] note about peripherals --- arch.example.tex | 6 +++++- conclusion.conclusion.tex | 4 +++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch.example.tex b/arch.example.tex index ad8c4db..0a05087 100644 --- 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 --- 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. -- 2.20.1