Hello Martine, thank you for that hint. Is it sufficient to enable that modul in the Makefile.dep file in the main-folder, or should I add this to the Makefile in my example/..../Makefiles? Are there any changes needed elsewhere?
Thanks a lot, Bernhard
Hi,
Bernhard Nägele <bernhard@naegele-privat.de> writes:
thank you for that hint. Is it sufficient to enable that modul in the Makefile.dep file in the main-folder, or should I add this to the Makefile in my example/..../Makefiles? Are there any changes needed elsewhere?
it is pretty insignificant where you enable it. You can even set USEMODULE=gnrc_sixlowpan_iphc_nhc as a local environment variable to make with the same effect (which IMHO is the cleanest approach since it does not change any files, so in case you forget about that it isn't hurting you afterwards ;-)):
USEMODULE=gnrc_sixlowpan_iphc_nhc make clean flash term
Important is that you clean before you build, because gnrc_sixlowpan_iphc_nhc is a pseudo-module that takes different #ifdef paths without changing a file.
To my knowledge no further changes are needed to communicate with other 6LoWPAN implementations.
Cheers, Martine
Hi,
Hi,
Bernhard Nägele <bernhard@naegele-privat.de> writes: > thank you for that hint. Is it sufficient to enable that modul in the > Makefile.dep file in the main-folder, or should I add this to the Makefile > in my example/..../Makefiles? Are there any changes needed elsewhere?
it is pretty insignificant where you enable it. You can even set USEMODULE=gnrc_sixlowpan_iphc_nhc as a local environment variable to make with the same effect (which IMHO is the cleanest approach since it does not change any files, so in case you forget about that it isn't hurting you afterwards ;-)):
btw:
I want to change the default handling here inside the Linux kernel.
Compression for nhc at transmit side is turned off and can be turned on by a debugfs UAPI which doesn't exist right now. Same handling like the "compression flag" for rfc6775 stateful compression, just adapted for nhc.
Receive handling is default on for nhc de-compression.
This is a small open task inside the linux-kernel, everybody is welcome to send-patches, see [0].
I currently have other priorities e.g. short address handling.
- Alex
Hello RIOT-Developers,
I've sent already a message about the topic of using a low-power-/low-frequency timer as a source for xtimer in february, but I want to discuss this topic again. The STM32L0 series of ST microcontrollers provide such a timer (LPTIM - like it is also available on Kinetis controllers). I want to use the STM32L0 STOP-Mode for getting very low power-consumpion in the breaks between measurements. The idea is to wake up the microcontroller periodically from the low-power STOP-Mode (with LPTIM used as wake-up-timer) like it is done in the xtimer_usleep_until example. However - I greped through the RIOT code and I have seen that the xtimer is used somewhere else also for inserting some small delays. If you use the low-speed timer of the microcontroller as source of the xtimer you loose the fine granularity for those "short delays". Wouln't it be a good idea (for the whole project) to define two separate timers - one for short delays (u-second granularity) and one for power-saving-modes? What is your idea about that? How could this problem be solved with the existing implementation?
Thanks a lot!
Best regards, Bernhard