Chirp’s latest SDK release features a global renaming from "Chirp Connect" to "Chirp SDK" as well as constant improvements and bug fixing. Another noticeable new feature is the SDKs are now providing deeper insights about memory usage to developers.
Chirp’s SDKs are widely available on a variety of different platforms. While it may not be important to care about an extra few bytes of data being used on Android, iOS or Windows for example, this becomes more of an issue when working with C on Arduino or bare metal platforms where every byte counts.
That’s why we thought it’d be appreciated by developers to get more insight and information from the SDK to help them avoiding bugs and issues related to memory. The rest of this blog deals with the C and Arduino SDKs sharing the same API. Click here to visit our developers docs if you want to know more 😉.
From the developer side
The two new features from this new release are:
1) the possibility to query the heap usage of the SDK at anytime, and
2) detecting memory leaks when deleting it.
Current dynamic memory usage of the SDK :
Working on embedded devices is really challenging when there is low microcontroller power and reduced RAM availability, especially when compared to what can be accessible on smartphones or computers. If you try to port an algorithm that is greedy in memory to an embedded platform, it can quickly become a nightmare to debug your program in low memory conditions.
For transparency and assistance in these situations, chirp_sdk_get_heap_usage is a new addition to the SDK allowing users to know very precisely what is the dynamic memory consumption of the SDK at any time. This function returns the heap usage, in bytes, of the code using Chirp at the time it is called.
This is particular useful for developers working on embedded systems or on Arduino boards. As those systems are low in memory, they can know what the resources used by the SDK are and then compute what is available. Depending on the config being used with the SDK, they can also optimise towards a config which still meet their requirements and uses less memory📉!
Watch the leaks:
An important thing when working with C and managing the memory by yourself is to avoid memory leaks. Nothing’s more annoying than monitoring the memory usage of a program constantly increasing over time and using all of your RAM for nothing. This is likely due to memory which is not properly freed and therefore leaks.
At Chirp we take this very seriously. Our internal test suite checks for memory leaks to ensure this never happens. We also want to make it simple and clear which functions allocate memory and how to free this memory accurately.
Usually, the data the SDK allocates is small for each individual allocation, but repeating such small allocations many times without freeing them makes memory leaks grow significantly. On top of that, tracking memory leaks on embedded platforms can become a real nightmare.
Using the memory manager to eliminate leaks in your code
Some of the function calls within the Chirp C SDK allocate memory that is the user's responsibility to free – for example, chirp_sdk_random_payload. Once you're done with the payload, you must use chirp_sdk_free to delete the memory allocation. If you forget to do so, a dreaded memory leak will occur. 💀
Chirp now makes tracking this kind of memory leak very easy. Starting from version 3.3.1 (for C) and 3.4.0 (for Arduino), when you’re done with our SDK and you call del_chirp_sdk to release the resources used by it (if you’re not you should, really …) you may receive an error code of CHIRP_SDK_MEMORY_LEAKS. This tells you that some memory allocated by our SDK hasn't been freed and that chirp_sdk_free hasn’t been used (enough).
We cannot yet tell you what memory is not freed, but once you find all your forgotten leaky allocations, del_chirp_sdk will return CHIRP_SDK_OK signifying the code using our SDK is leaks free ! 🎉
From our side
All of this has been made possible thanks to a memory module implemented by us, which wrap the allocations and frees. This allows us to track the memory usage in terms of quantity used, eventual memory leaks, and partial memory corruption -- but the latter is still in development.
This wrapper is private at the moment, but we’re aiming to make it publicly available so watch our blog for a part 2 👀!