Hi, ----- Le 16 Juil 20, à 14:17, Maas, Marcel <marcel.m...@stud.hs-emden-leer.de> a écrit :
> we are currently deciding on the right OS for a project we are working on and > have come to some questions regarding the low power capabilities of RIOT. > Our Dev platform: > -> STM32 LoRa and Sigfox Discovery kit (B-L072Z-LRWAN1, > https://www.st.com/en/evaluation-tools/b-l072z-lrwan1.html) Good choice, this board is very well supported by RIOT. If you plan to use the battery on the back of the board, note that you will have to cut a bridge on the board (I don't remember which one but it's explained in the datasheet). To reach minimal power consumption, you should also cut the on-board user LED. > Most of the time the MCU should be in standby mode to have achive the lowest > current consumption possible. But in that mode everything in RAM is lost. That > means we would have to save the LoRaWAN configuration and approx. 250 byte of > our own data to flash. > Our question is: How does RIOT handle the standby mode? The STANDBY mode is supported in STM32 L0. The only thing to do is to define PM_BLOCKER_INITIAL where standby mode is unblocked (e.g set it to 0x01010100). > - Do we have to rewrite the LoRaWAN stack? As already answered on the list, the Loramac-node stack [1] is supported as an external package [2]. There are also good examples in [3] and [4] to easily start playing with LoRaWAN on RIOT. > - Will our application restart, when using standby or is program data, > counter, > etc. saved and our app will continiue where it left? In standby mode, yes the application restarts after wakeup. So you indeed need to store important state information in a non-volatile memory. The CPU in the B-L072Z-LRWAN1 board provides an internal EEPROM that can be used for that purpose. See [2], it's an old PR that adapted the lorawan examples to support standby mode and ABP activation mode. It's bit outdated but can be a good starting point as it shows how to use the non-volatile memory to not loose the MAC state between reboots. > - Might custom firmware be the better choice? There is no parallelism in our > app > and we won't need the console. The RIOT API plus the one built on top of loramac-node makes it super easy to write a LoRaWAN application. It will also be more portable than a custom firmware. Note that RIOT also provides an in-house but still limited (only EU868 region is supported at the moment) version of the lorawan stack, see example in [6]. Regards, Alex [1] https://github.com/Lora-net/LoRaMac-node [2] [ http://doc.riot-os.org/group__pkg__semtech-loramac.html | http://doc.riot-os.org/group__pkg__semtech-loramac.html ] [3] https://github.com/RIOT-OS/RIOT/tree/master/examples/lorawan [4] https://github.com/RIOT-OS/RIOT/tree/master/tests/pkg_semtech-loramac [5] [ https://github.com/RIOT-OS/RIOT/pull/11237 | https://github.com/RIOT-OS/RIOT/pull/11237 ] [6] https://github.com/RIOT-OS/RIOT/tree/master/examples/gnrc_lorawan > Thank you and with best regards, > Marcel Maas > Low power modes -> AN445 > (https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-ultra-low-power-mcus/stm32l0-series/stm32l0x2/stm32l072cz.html#resource) > _______________________________________________ > users mailing list > users@riot-os.org > https://lists.riot-os.org/mailman/listinfo/users
_______________________________________________ users mailing list users@riot-os.org https://lists.riot-os.org/mailman/listinfo/users
