You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could enable the LVGL side to use Rust memory allocator, if it's available and the feature "alloc" enabled in lvgl-rs. That way we wouldn't need to use our custom Box implementation for that case. We would still need this implementation for cases where all features in lvgl-rs are disabled and we do not have a Box abstraction to handover memory to LVGL C.
The problem we want to solve is that LVGL C always support "dynamically" allocated memory backed by a static array-based backend, just like wee_alloc. LVGL-rs is a library and the choice of allocator must be made by the firmware/application developer. Besides that, the developer might decide that they don't want to have an allocator at all on their Rust firmware. LVGL C will still use their own memory management implementation.
One option is to always require users of LVGL-rs to define a global allocator in their project. This would be a limitation for some use cases?! In that scenario, we wouldn't need the code in mem module at all, since the memory space would be shared by LVGL C and Rust.
The text was updated successfully, but these errors were encountered:
We could enable the LVGL side to use Rust memory allocator, if it's available and the feature "alloc" enabled in lvgl-rs. That way we wouldn't need to use our custom
Box
implementation for that case. We would still need this implementation for cases where all features in lvgl-rs are disabled and we do not have aBox
abstraction to handover memory to LVGL C.Some code example of how this could work is available at: https://github.com/ezrosent/allocators-rs/tree/master/malloc-bind
We could get inspiration from the malloc-bind project and implement a similar solution to be used in embedded devices.
The problem we want to solve is that LVGL C always support "dynamically" allocated memory backed by a static array-based backend, just like wee_alloc. LVGL-rs is a library and the choice of allocator must be made by the firmware/application developer. Besides that, the developer might decide that they don't want to have an allocator at all on their Rust firmware. LVGL C will still use their own memory management implementation.
One option is to always require users of LVGL-rs to define a global allocator in their project. This would be a limitation for some use cases?! In that scenario, we wouldn't need the code in
mem
module at all, since the memory space would be shared by LVGL C and Rust.The text was updated successfully, but these errors were encountered: