Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
To the exalted masters of the software I2C include file. Are we sure that the logic of the interrupt disable business is correct? If nothing else, the name of the constant that controls this seems backwards.
I'm currently trying to do some I2C inside an interrupt routine. The interrupts only occur once per second, meaning that there's plenty of time to get the one or two I2C things done before the next interrupt.
And my interrupts keep getting disabled and stay that way, just by using an I2C command.
Maybe a better question is:
"Should the software I2C even address the issue of interrupts? Might it not give better control if it were up to the programmer to decide when to enable or disable them?"
What do you think?
Anyway, I'm getting nowhere fast with what ought to be straightforward. Maybe I'll try some radical surgery tonight.
Re interrupts. I had the same issue with the original software I2C code.
#define I2C_DISABLE_INTERRUPTS ON - This will pass interrupt control to the main program. This means that the calls to the I2C methods will not change the state of the interrupts. Or, that was my intent.
I found trying to do I2C inside an interrupt routine did not work, because of timing etc. and that all the code from Microchip (that I found at the time) did not implement i2C within interrupts - so, I used the methods as shown in my port of the F1 Evaluation Board.
Also, I recompiled the F1 Evaluation Board last week as part of the Hot Release and the I2C code worked ok on the F1 Evaluation Board which has multiple I2C devices.
Finally, the constant may be backwards.... sorry but it made sense at the time. I tend to share these ideas now prior to implementation. :-)