Give your gizmo the gift of sight
I'm not familiar with SMBus, I'll have to check it out.
The only issue that I know of with version 6 is that I wasn't maintaining the functionality of optic flow mode 2, so that is probably broken, but it is probably also broken in version 5. I have actually fixed this on my local copy of the code, but I haven't committed it since I was also working on some other changes that aren't ready to commit. I think the most important improvement in version 6 was double buffering, which required some minor changes in I2Csupport. I think it would be safe to work with version 6, I just think it hasn't been evaluated by anyone else.
I've just uploaded revision 7 with the added SMBus compatibility layer and a few other scattered updates, all documented in the changelog.
No changes to the flow computation except commenting out a few unused variables.
I added switches to pause and resume the image grabbing and computation, mainly to be sent just before and after an image read to ensure it all comes from one frame. I also added a command to change the of_scaling, which should be self-explanatory. Everything else was in I2CSupport for adding the SMBus things.
All updates in this revision were of course tested, except going in and actually changing the of_scale variable (but since that addition is so simple I can't see how it could not work).
This is great! Thank You for making that addition.
Out of curiosity- just to make sure have you verified that I2C still works or should one of us test that out (just to make sure).
I haven't been able to test it myself, since I don't have an adapter (yet) that is capable of doing raw I2C. I can't see a reason it wouldn't work, as I only added some statements that trigger with the new commands and didn't change existing code.
You're right it's probably OK. We'll try it out this week.
As I was talking about in the other thread, I've added support for saving calibration values and state variables to EEPROM to save across power cycles, and just committed the change as Revision 8.
I've tested and built this version on two of my sensors and it works as expected, with no changes to any existing functionality or requirement to change existing code that anyone is using to talk to the sensors. The main additions:
* Saved all the variables in the BiasSettings struct to EEPROM along with Amp_Type, and they will be loaded after power cycles. Since this means that the values might not be the defaults when power is applied, I added ATT #30 as a 9 variable output array containing those values. Because of the array structure, the old variable names were converted to pointers that reference the new array locations, to retain readability.
* Saved to EEPROM everything on the application side that would be considered a state variable, i.e. everything that can be set by sending a byte with one of the application commands that isn't a routine or function. ATT was not included, since it changes too often. As with the VC variables, these were also added to an output array #72 that can be read to see what the current states are. Instead of converting the old variables into pointers, I decided to make them into #define "aliases" that can be used exactly as before, but transparently redirect to the array locations, so as to not increase memory use. It's an ugly hack, but it helps readability.
More details about the array orders and specific EEPROM memory locations used can be found in the revision notes. This should sync easily enough with custom versions that anyone may be using, the core functionality of the sensors hasn't been changed at all.
Thank You again for doing this. I apologize I haven't had a chance to look at that code yet- I will do so when the new CYE8's come in...
I'm looking into modifying the firmware to use the vision chips with lenses, and have a question about binning on the F64. In F64PlusInterface.c/.h there's a function smooth_image(row,col) that says it bins the pixels, but when I look at the get_raw_image_16x16() in ApplicationPrototype.c/.h the setup lines of code send the VCF commands for no binning. If I were to want a 16x16 image that binned the extra pixels to create in effect a lower resolution image instead of skipping them, would I change those VCF lines to match those in the smooth_image code? The idea I'm going for is if there's a spot only visible on one pixel, but that pixel would be skipped over in the get_raw_image code, I want it to affect the nearest pixel that is read.