Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no_std example #1

Open
pdgilbert opened this issue Nov 3, 2021 · 2 comments
Open

no_std example #1

pdgilbert opened this issue Nov 3, 2021 · 2 comments

Comments

@pdgilbert
Copy link

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
Copy link
Owner

paxswill commented Nov 4, 2021

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants