I2C issue

[Charles Linquis]

The I2C slave I posted uses DT-INTs. It is the only way you can have a slave running that can do something else at the same time.

[cncmachineguy]

Charles, Do you mean to say interrupts are the only way, and you use DT_INT? I am really going to have to get more into them, I would like to get another 60% from PBP

[cncmachineguy]

BTW, I am assuming you are doing this with PBP3. have you tried 2.6 to see if it is a new issue?

[Charles Linquis]

I haven't tried 2.6, but I have looked at the libraries. They are the same in the I2C area. They have another issue as well that I have mentioned before.
Many devices require you to turn on clock stretching (DEFINE I2C_HOLD 1). This is so they have enough time to process whatever you send to them. The slave holds SCL low until it is ready to accept the next byte. The master waits until the SCL goes high and sends the byte. But PBP has no timeout. If a device holds SCL low forever, your program is hung - forever. A similar situation exists if the I2C device is powered from a different power supply than the PIC master. If the slave has no power, it holds SCL and SDA low. I2CWRITE sends (or tries to send) data to the slave and waits for the SCL to go high, which it won't. Result = dead system. The work-around is to ALWAYS check for SCL and SDA to be high before any I2C read or write.

And if you are serious about not using DT-INTs extensively, you should. Yes, you can still do things the old fashioned way of saving/restoring registers, but Darrel has done all the hard work for you. You can use both ASM and PBP interrupts. My 'template' for all new code has the DT-INTs framework. I generally have an ASM interrupt on TMR0 that runs at a 1mS rate. If I need to make certain
I don't miss a pushbutton or some other input, I just put it in the ISR. I can 'latch' the input there and check for it in my main program loop. If I have to respond to something quick, I put the response in the ISR. All the while, I increment a var called MasterClock. I can measure time in ms between any two events. I also use it to time my main loops. For example: You can only read an I2C temperature sensor every 200-300 milliseconds. You can run your main loop as fast as you want, but when MasterClock > 300 you read the sensor, clear MasterClock and keep going. I generally don't use PAUSE at all, and my little PIC responds instantly to all important inputs.

[cncmachineguy]

I am being shown the light, I have found the switch and am trying to turn it on WRT DT_INT. My mantra is nothing in the ISR should need any PBP system variables (but I could be wrong there, still trying to figure out what uses them and what doesn't). So all my ISR's are ASM, but using PBP commands ie porta=portb.

As for the context saving, all the 16f1xxx and maybe all the 18's already do it for me. So as long as I deal with BSR life is good. But the ease of not looking up all the PIR.somebodys for the INT query does appeal to me. So like I said, I found the switch to turn the light on.

[Charles Linquis]

Yes, the 18Fs save context in an ASM int, but of course PBP is another matter. Sooner or later you will find that writing an ASM ISR is just too complicated, or else the PBP routine is already done for you. Then, figuring out what to save / restore gets to be a bit of a problem (unless you brute-force it and always save everything). The beauty of DT-INTs is that you can have one structure for both ASM and PBP interrupts, and it decodes the INT source for you if you have 5 or 6 of them like I often do.
Because more registers are saved, PBP ints take about twice as long to get into/out of than ASM ints, but if you most always run at 40MHz +, like I usually do, it seldom matters.