More notes on firmware size

This commit is contained in:
jaseg 2021-07-30 18:45:07 +02:00
parent b04cde4131
commit 524d12257f

View file

@ -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 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. 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 Since we are only building a prototype we did not optimize firmware code size. Since we do not require any peripherals
compiled code size of our firmware implementation is slightly larger than we would like. The overall most heavy-weight except for an ADC and since our code is not speed-constrained, code size is likely to be the main factor affecting
operations are the SHA512 implementation from libsodium and the FFT from ARM's CMSIS signal processing library. per-unit cost in an in-field deployment of our concept. With this in mind, at around \SI{64}{\kilo\byte}, the compiled
Especially the SHA512 implementation has large potential for size optimization because it is highly optimized for speed code size of our demonstrator firmware implementation is slightly larger than we would like. The overall most
using extensive manual loop unrolling. Despite being larger than what we initially targeted, this firmware is still heavy-weight operations are the SHA512 implementation from libsodium and the FFT from ARM's CMSIS signal processing
small compared to the firmware space available in commercially deployed smart meters. We estimate that even without library. Especially the SHA512 implementation has large potential for size optimization because it is highly optimized
additional optimizations, our PoC firmware is already within the realm of firmware size that could be implemented in a for speed using extensive manual loop unrolling. Despite being larger than what we initially targeted, this firmware is
commercially viable safety reset controller. 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} \section{Conclusion}
\label{sec_conclusion} \label{sec_conclusion}