diff options
-rw-r--r-- | paper/safety-reset-paper.tex | 18 |
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} |