You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Place holder for the WP9000 CPU Load Optimsations WP, which we can extend to other optimisations such as run-time memory.
We are currently designing against a minimum spec of a generic stm32f405 like we use on the SM1000, which IIRC is 192k RAM/512kbytes flash.
Via email @silseva has provided some fine guidelines for RAM optimisation, something I hadn't considered until now:
The current codec2 implementation takes around 32kB of heap and 15kB of stack; this means we have to dedicate 48kB of RAM only for the codec itself. (Note this is probably Codec2 3200)
Flash usage is not of great concern because MCUs tend to have way more flash space than RAM space (Note this is good - as we would like to use large VQs in new Codec modes)
If possible, it'd be good to have the encode and decode functions to use as less stack as possible. This because some RTOSes does not allow for dynamic allocation of the threads stack, which means that we'd need to reserve a 16kB chunk in the .bss section (which is statically allocated at compile time) for the codec2 thread stack and this leads to an inefficient usage of the RAM space.
The text was updated successfully, but these errors were encountered:
Place holder for the WP9000 CPU Load Optimsations WP, which we can extend to other optimisations such as run-time memory.
We are currently designing against a minimum spec of a generic stm32f405 like we use on the SM1000, which IIRC is 192k RAM/512kbytes flash.
Via email @silseva has provided some fine guidelines for RAM optimisation, something I hadn't considered until now:
The text was updated successfully, but these errors were encountered: