Hello,
We are developing NDN stack for IoT devices (https://github.com/named-data-iot/ndn-lite) called NDN-Lite, and want to port this library to RIOT as external package but encountered some problems.
Our previous RIOT package implementation ndn-riot (https://github.com/named-data-iot/ndn-riot) abused dynamic memory allocation, which caused performance issues. We tried to avoid this in this new one and no malloc() by now. But applications are hard to run because our library has large size structs (200B ~ 500B) but the default main thread stack is not so big (for nRF52840, around 1500B I think?).
Separating into different threads is considered before. But it would be great if one single thread is enough, so our library can have consistent feature across different platforms.
Are there any suggestions to solve this? Our team really want to port our library to RIOT so users can develop things over an IoT OS.
Best,
Tianyuan
Hello Tianyuan,
Hello,
We are developing NDN stack for IoT devices (GitHub - named-data-iot/ndn-lite: A lightweight NDN protocol stack with high-level application support including security bootstrapping, access control, trust management, etc.) called NDN-Lite, and want to port this library to RIOT as external package but encountered some problems.
Our previous RIOT package implementation ndn-riot (GitHub - named-data-iot/ndn-riot: NDN stack module for RIOT-OS) abused dynamic memory allocation, which caused performance issues. We tried to avoid this in this new one and no malloc() by now. But applications are hard to run because our library has large size structs (200B ~ 500B) but the default main thread stack is not so big (for nRF52840, around 1500B I think?).
Separating into different threads is considered before. But it would be great if one single thread is enough, so our library can have consistent feature across different platforms.
Are there any suggestions to solve this? Our team really want to port our library to RIOT so users can develop things over an IoT OS.
Great to hear about this effort!
The solution to this problem is actually quite simple: if you allocate
the data structures globally, hence outside of the main function, then
they will end up on the global stack instead of in the main thread's
stack.
I am personally quite interested in the integration of ndn-lite. If you
want, then I can help reviewing the current state.
Cheers,
Cenk