Contiki energy estimation mechanism (energest) currently has support for 10 different enum energest_type values. However, all CPU energy estimation goes under either CPU or LPM. This model is very inadequate for the newer platforms such as JN516x and CC2650 where the platform-specific Contiki code supports both "simple" and "deep" sleep levels, and these levels have vastly different energy consumptions.
The first step would be to introduce something like ENERGEST_TYPE_DEEP_LPM in addition to ENERGEST_TYPE_LPM and extend apps/powertrace output accordingly. However, this still would fail to account all the different possible energy levels of e.g. CC2650 where there are multiple power domains that can be turned on/off separately.
What do you think is the best way to approach this?
We could maybe consider platform-specific redefinitions of energest_type to support arbitrary number of sleep modes and H/W states? Possibly with a string associated to it for nice powertrace output.
Contiki energy estimation mechanism (
energest
) currently has support for 10 differentenum energest_type
values. However, all CPU energy estimation goes under eitherCPU
orLPM
. This model is very inadequate for the newer platforms such as JN516x and CC2650 where the platform-specific Contiki code supports both "simple" and "deep" sleep levels, and these levels have vastly different energy consumptions.The first step would be to introduce something like
ENERGEST_TYPE_DEEP_LPM
in addition toENERGEST_TYPE_LPM
and extendapps/powertrace
output accordingly. However, this still would fail to account all the different possible energy levels of e.g. CC2650 where there are multiple power domains that can be turned on/off separately.What do you think is the best way to approach this?