More notes on firmware size
This commit is contained in:
parent
b04cde4131
commit
524d12257f
1 changed files with 10 additions and 8 deletions
|
|
@ -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}
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue