this project is to show how to get mlx90640 working without first needing a powerful micro controller with more than 20k of ram. the idea is to have projects be able to be tested and workin on Arduino uno, and if more performance or features are needed then similar code can be used.

also i have code that is not include with the online melexis examples, such as setting sensor in step mode. this allows ram to be read from sensor rather than needing to store it all in mcu, also reading of sensor calibration files data is done in example. however i do not use the calibration data yet. the goal is to have that data stored in mcu eeprom, and read when needed for calc.

results currently of calibrated To sensor output data to Deg C:

*project has been reading sensor data for a while, but i had to go back and run a verification and modify code in /updated folder. this code outputs data the same way as original example code by melexis, it just manages memory more efficiently.

currently the project uses about 5k of ram for 32bit arm processors, and about 720bytes ram on arduino 8bit processors. the 8 bit processors still need math to be modified because of the lower precision of the float storage. i have a 64bit float math library i'm testing on it now. i have verified the results of my code to original and it outputs similar results (on arm). i see  a lot of pow and sqrt functions in the code, and i'm not sure 100% that they are needed and think that the math can be simplified to not needing so many exponent functions and sqrt . also most of the processor time was used just waiting in a while loop until 1 frame of 2 was finished being sampled, then store data in ram, this can take from 2sec down to 1/64. the processor was only doing calc after frame data was completed. so there is a lot of room for efficiency in the process. there is some ram overhead in the frame data, of about 128bytes as each frame has specific variables to manage

with this sensor it is important that it's i2c bus runs below or at maximum 1mhz for arm, and 800khz on Arduino. unlike other sensors this one requires a lot of writes to its registers. it is important that the data not be corrupted in its internal eprom, it is up to the software checks on the Arduino to verify the writes are completed ok, as the melexis sensor will operate with its ram values in its registers until it is reset then it will pull values from flash. i recently destroyed a sensor by pushing it to 4mhz. it initialized ok, but after i reset it, it no longer worked. i assumed it overwrote it's slave address, and i spent time trying to recover it. in the future i may modify code to write to registers slowly, and only increase speed during ram reads to sensor.  again the only verifications are in the Arduino verifying the current eprom address is written too, if it is not written it will rewrite data, it won't know if you wrote somewhere else. normally this wont be an issue as long as speed is within spec, and proper resistance is used for data bus (2.2k) such as sparcfun sensor. i cant emphasize it enough that 1mz data speeds should not be done on breadboarded devices (where resistors are mounted in). the slew rate difference from the added capacitance could cause data corruption. 

Also currently the code just reads from the sensor 1 word of ram data at a time. this is not efficient and will change to reading 32 words at a time. i do know there is some caching in the arm code for the i2c data, but with my own checks reading 32words at a time is still faster than reading 1 word at a time. the addressing requirements of i2c are about 10 bytes of sending, address, and read location, and then how many bytes to send, then just clocking thru 1bit at a time the data. there is no additional addressing requirements for the next ram location as long as it is requested in a group. for the individual reads there is significant overhead. 

the current state of the project is this. it is working on arm using a lot less memory, even the function routines do not need a lot of data to be pushed to the stack, the code it is verified to work similar to the example code on arm. the Arduino version requires math changes to work correctly such as 64bit math, or just keeping values within range of significant accuracy within the device. for example the arduino version sometimes outputs NAN values (not a number)

data is not currently cached for reads. caching data will speed up reads on arduino, and arm (but arm already does some caching)

future goals are: 

cache reads so 32 words (64 bytes chunks) of data are read at once to prevent i2c bottleneck

reduce math requirements for the processing of To data or switch over to 64bit floats (currently in test)

modify and move upsample output code to a function so it is easily modified by user.

improve efficiency by having processor calc To data while it is waiting for results from sensor frame

Document new command functions created that make design more memory efficient

add in code that allows exporting data to display, and writing spi data to lcd display.