Interrupts disabled during call to prevent re-entrancy...

[barryg]

I have an i2c slave routine that is interrupt-driven. I also have a watchdog running in the application's main loop. If i2c activity ceases for a certain length of time, a watchdog attempts to fix it. First, by putting a character with i2c_write(). If that doesn't free it up, the SSP is disabled and enabled, thus resetting it. That i2c_write(), though, throws a warning--the one in the title of this message.

Now the best way to "fix" this would be to code it in such a way that it doen't risk re-entrancy. If someone knows a good way to do that, I would try it. But, otherwise, I felt I could live with suppressing the warning, for that one statement:

[Ttelmah]

The warning, is just that, _a warning_, not a major problem. All that will happen, is that whenever an I2C_WRITE is used in the main, a disable_interrupt instruction will automatically be inserted in front of it, and an enable_interrupt after it. The code will run fine, _provided this is not happening on some routine that involves a long 'handling' time_. For a single call like this, which is not called at all in the normal cause of events, just ignore the warning.
The code will compile fine with the warning present.
The warning is triggered by the two routines being the same (in the interrupt handler and in the main), and so needs to be ignored for the whole program, and not just the single location shown.

Best Wishes

[barryg]

You are right, and the program does work fine. But I would like to be able to produce a "clean" compile. A bit obsessive, perhaps, but being engineers is what got us into this business in the first place

I also found I could supress the warning by inserting the ignore in the last line of main(). That supresses the warning when compiler makes its determination. But, of course it will suppress any warning of that type that may come along.

I thought it was worth asking about, anyway.

[RLScott]

If i2c_write is not too long, perhaps you could write a separate version of that function for the ISR and the main program. Since you only call i2c_write from the main program when the ISR activity has timed out, there is no real danger of accessing the serial port hardware from both places at once.

Robert Scott
Ypsilanti, Michigan