Added the OEM Module to the Lepton Interface.

[BenKluwe]

Only Power down and Power on have been tested.
Power down works, Power on does not work.

[kekiefer]

Thanks for sending this, Ben. I have a couple questions/comments.

1. Where did this modules come from? Are you the author, or did they come from a FLIR SDK? If it's the latter, we should to maintain FLIR's copyright information.

2. Why does the OEM module's base address differ from the one that came from FLIR that is included in the purethermal source? (which you can find here: https://github.com/groupgets/purethermal1-firmware/blob/master/Middlewares/lepton_sdk/Inc/LEPTON_OEM.h)

3. Don't commit trivial changes to LEPTON_I2C_Reg.h, this makes it difficult to understand the diff of the file.

[kekiefer]

Well scratch comment 2, I took a second look at the one in the purethermal source and see that there each register access adds the 0x4000 offset (OEM bit). It does still beg the question why these are different.

[BenKluwe]

Hi, Sorry, I didn't realise that you had already implemented these two files. 1. What do you mean with 'come from a FLIR SDK'? I used the Software ID document to create the file. I suppose that means I should include the copyright information? If so I'll add a commit now. 2. Ah, well, the only change I made was add the Power Register. Ben

…

On 22.03.2017 15:37, Kurt Kiefer wrote: Thanks for sending this, Ben. I have a couple questions/comments. 1. Where did this modules come from? Are you the author, or did they come from a FLIR SDK? If it's the latter, we should to maintain FLIR's copyright information. 2. Why does the OEM module's base address differ from the one that came from FLIR that is included in the purethermal source? (which you can find here: https://github.com/groupgets/purethermal1-firmware/blob/master/Middlewares/lepton_sdk/Inc/LEPTON_OEM.h) 3. Don't commit trivial changes to |LEPTON_I2C_Reg.h|, this makes it difficult to understand the diff of the file. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcd2dh2XgR3QlEF5VuIpS34JzsPvmvLks5roUA9gaJpZM4MlXcp>.

[BenKluwe]

There is no point in pulling this in if it is already in the purethermal1 firmware, but it might be worth copying over the LEPTON_OEM.{c,h} and LEPTON_RAD.{c,h} files to here.

I changed the base address because it was a simpler method than adding it to every command id. Technically, it does not make a difference because you either obscure the Base ID or the Command ID. So adding a comment why a 0x4000 offset is there makes alot more sense than asking why the offset is there in the first place.

[kekiefer]

Thanks Ben, since you did implement these, then there was no need to include FLIR's copyright info. That was the question!

That being said, it sounds like you might as well just pull in the files from the purethermal firmware as they came from FLIR. Maybe the power on command will behave better? If you want to submit a new pull request that includes those files I'll merge it in.

[BenKluwe]

I tried. Unfortunately, the purethermal1 firmware does exactly the same as my code did, i.e. write 0x0 to the power register. In the Software IDD it says:
The power ON command is executed by the SDK (not the camera) by writing a ZERO (0x0000) to the Camera I2C Device ID (see 2.1.3).
Unfortunately, that is the only mention of the Camera I2C Device ID that I can find in the document. It would make sense that the power register is the correct register to write to, but it doesn't work. When I run the power off command the Lepton stays active on the I2C, as I it shows up when I use i2cdetect -y 1.
It's a very much needed feature because the Lepton is quite unstable as it runs sometimes for minutes, tens of minutes, an hour to three hours is what I've been able to get out of it so far before it starts sending garbage image data over the SPI.