Example gathering raw data & processing separately?

[ActuallyHappening]

Hello,
Thank you for taking the time to write a Rust implementation of the MLX90640 @paxswill! It has saved me potentially days of time and is allowing me to refactor some slow micro python code (using Adafruit MLX90640 implementation here ported to micro python, not easy)

I have a "strange" use case for this library.
I am targeting a low memory device (Adafruit ESP32 Feather HUZZAH32) with the rate limiting factor being memory not computational speed.

Aim

• Take raw data from MLX90640 camera
• Process raw data completely separately, on different machine
• Both machines are assumed to be running this Rust library

I could dig around in the source code of this library for a while and eventually devise a solution, but I wanted to raise this as an issue first.

Is this possible with the current state of the project?

Thanks for any help

(How this fits into my personal project as a whole:)

• Taking raw data from adafruit mlx90640 thermal camera
• Transferring over BLE using this library
• Processing on a tauri desktop/iOS app
• Processing raw rgb values using ffmpeg (calling CLI API directly from Rust, no wrappers) into images / video

[paxswill]

On the surface, it sounds doable, but I'm a little concerned that you can't even run this library in the first place on the device. That device should have enough RAM: looking at the product sheet, it has 520KB, and this library should only need around 12KB of active memory to work (all that being said, I haven't used this on an embedded device yet, but I do have a few sitting around I just haven't gotten around to using).

Backing up a bit, the major limiting factors with this library on an embedded device are

1. How much memory it takes to load both the initial calibration data and the per-frame data off of the camera.
2. How long it takes to read the per-frame data off over I2C. The FrameRate docs touch on this a little bit, but starting and stopping an I2C transaction has overhead that can add up if you're doing it a lot.
3. How fast the device can process each frame of data after it's been loaded over I2C. If you open the spreadsheet included in this repo (mlx9064x_timing.ods) the last few columns show the minimum I2C clock speed needed to transfer the frame data. In the FrameRate docs I call out 64 FPS/Hz in chess mode on the MLX90640 as "technically possible", but not reasonable: there's only 95.68ms to perform all of the calculations before you have to start transferring the next frame of data.

For the application you're describing point 1 can be simplified a bit as you only need the one frame of data to be stored at a time. Points 2 and 3 might be difficult as you're also having to turn around and transfer the data off of the device using nimble (no idea how fast nimble is), but depending on the frame rate you're using you might run out of time before you need to start loading the next frame of data off the camera.

For the temperatures -> RGB (and generation of an image, etc) I'm doing that in r-u-still-there (note, the license for r-u-still-there is AGPL) with colorous and some super basic drawing into a buffer, converting to JPEG with mozjpeg, and serving it up as MJPEG with hyper.

[ActuallyHappening]

Thanks for the reply, after a bit more prodding around I have realised the most of my available memory is already taken by esp-idf-sys and the bindings it generates (most of which I don't use anyway).
Instead of being a good programmer and digging deeper into compilers, I'll take the easy route and run this on a Raspberry Pi 3B+

Yet to get a hello_world thermal frame as of yet, will post here with more experience :)