search

paxswill / mlx9064x-rs

Rust library for using Melexis MLX9064* thermal cameras
Apache License 2.0
4 stars 4 forks source link

no_std example #1

Open pdgilbert opened 3 years ago

pdgilbert commented 3 years ago

Do you have an no_std example? I'm just trying to work out what "a fair bit of memory" is, to see what is feasible.

paxswill commented 3 years ago

I don't have a no_std example handy right now, but I might be able give you an idea on the memory requirements. For the MLX90641, the unprocessed calibration data is 1664 bytes. The included Mlx90641Calibration structure takes up around 3206 bytes (-ish, there might be structure padding as well). The memory needed for the MLX90640 is much higher, with the processed calibration structure taking up 7821 bytes. CameraDriver also has an internal buffer of either 384 bytes (for the '641) or 1536 bytes (for the '640) that it uses as the destination when reading data off of the camera, in addition to the either 768 or 3072 bytes needed for the output image from the camera.

So for initial calibration loading for the '641, you need at least 4870 bytes of memory, and to actually get an image you'd need at least 4358 bytes. The '640 comes in a lot heavier, needing over 12K just to get images off of the camera.

A custom CalibrationData implementation can be written to reduce the calibration memory requirements, either by extracting and calculating each value from the source data as needed, or by using some sort of auxiliary storage for the calibration data. The former approach might work for slower frame rates, but I'd be concerned about calculating the per-pixel calibration values for every frame (some of those values are floats as well, which can be a lot slower depending on your device). The latter approach is probably what I'd choose, especially as there was some discussion about it in the official C++ library's repo: melexis/mlx90640-library#3

To be honest, I'd skipped over the buffer in CameraDriver, and will be creating an issue to track how to remove it and reduce the memory usage there. It'll take some thinking/planning and maybe some unsafe code as it'll be taking a buffer of u8 pairs as input, and writing f32 values to that buffer...hmm.

pdgilbert commented 3 years ago

Thanks for the explanation. If you get around to a no_std example would you please comment here so I get pinged. I looked very briefly at the code and thought there may be room for memory saving by using time in milliseconds as u32 rather and seconds as floating. That is a very uneducated and not researched suggestion, so you probably know better.