More notes on firmware size

1 files changed, 10 insertions, 8 deletions

diff --git a/paper/safety-reset-paper.tex b/paper/safety-reset-paper.tex
index 75fca76..f76f4af 100644
--- a/paper/safety-reset-paper.tex
+++ b/paper/safety-reset-paper.tex
@@ -569,14 +569,16 @@ floating point emulation instead of porting over our algorithms to fixed point c
 rate of our systems makes even heavyweight processing such as FFT or our brute force dynamic programming approach to
 DSSS demodulation possible well within our performance constraints.
 
-Since we are only building a prototype we did not optimize firmware code size.  At around \SI{64}{\kilo\byte}, the
-compiled code size of our firmware implementation is slightly larger than we would like. The overall most heavy-weight
-operations are the SHA512 implementation from libsodium and the FFT from ARM's CMSIS signal processing library.
-Especially the SHA512 implementation has large potential for size optimization because it is highly optimized for speed
-using extensive manual loop unrolling. Despite being larger than what we initially targeted, this firmware is still
-small compared to the firmware space available in commercially deployed smart meters. We estimate that even without
-additional optimizations, our PoC firmware is already within the realm of firmware size that could be implemented in a
-commercially viable safety reset controller.
+Since we are only building a prototype we did not optimize firmware code size. Since we do not require any peripherals
+except for an ADC and since our code is not speed-constrained, code size is likely to be the main factor affecting
+per-unit cost in an in-field deployment of our concept. With this in mind, at around \SI{64}{\kilo\byte}, the compiled
+code size of our demonstrator firmware implementation is slightly larger than we would like. The overall most
+heavy-weight operations are the SHA512 implementation from libsodium and the FFT from ARM's CMSIS signal processing
+library.  Especially the SHA512 implementation has large potential for size optimization because it is highly optimized
+for speed using extensive manual loop unrolling. Despite being larger than what we initially targeted, this firmware is
+still small compared to the firmware space available in commercially deployed smart meters. We estimate that even
+without additional optimizations, our PoC firmware is already within the realm of firmware size that could be
+implemented in a commercially viable safety reset controller.
 
 \section{Conclusion}
 \label{sec_conclusion}