Darrel Taylor Interrupts I2C Problem

[dcorraliza]

Hello all:

First of all, thanks for that really good software Mr Taylor have developed , it is helping me a lot for developing my software.

The question is my interrupts routines are using PBP code (I2CREAD), but I started defining my interrupts as ASM type. All seems to work fine, but have some issues on HSEROUT calls so I realize that I have to use PBP type interrupts to solve it. But the question is that when I started to use PBP ones all stop working.

During some days I have been investigating this strange situation, and I have found a pseudo workaround that don't explain the issue.

My interrupt handler is that:

INT_READER:
I2CREAD i2c_rdr_SDA, i2c_rdr_SCL, rdr_I2C_DIR_SLAVE , [str RDR_I2C_BUFFER\RDR_I2C_BUFFER_SIZE], INT_READER_ERR
INT_READER_ERR:
@ INT_RETURN

The errors come when i use PBP interrupt. When i use it the I2CREAD routine don't read anything.

The Workaround: I have been making some tests, and the problem disappear if I comment a line in ReEnterPBP-18.bas
The line is at RestorePBP_H routine:

FLAGS = FLAGS_SaveH

When I comment this line all start working. WHY?

As I can see in Mr Taylor's code, this routine is executed once the interrupt routine is finished, so I don't understand why this affect the I2CREAD routine. Maybe this line makes the I2C routines to go "disabled"???? (the FLAGS var is used to control PBP I2C MASTER routines)

Any suggestions will be welcome, thanks in advance...

dcorraliza

[dcorraliza]

Hi all:

Today I have found a different workaround for this issue, but this workaround don't let me to understand what is happening...

The workaround is to add a byte variable to ReEnterPBP-18.bas like that:
HP_Vars VAR WORD[34] ; group vars together for less banking
R0_SaveH VAR HP_Vars[0]
......
......
TBLPTRH_SaveH VAR TBLPTR_H.highbyte
TBLPTRL_SaveH VAR TBLPTR_H.lowbyte
Product_H VAR HP_Vars[33]
nothing VAR byte

With this new variable called "nothing" i can re-enable the at RestorePBP_H routine:

FLAGS = FLAGS_SaveH

And the code keep working properly. Why???????????????

I don't know the reason, but the last time an issue was fixed with a dummy variable definition, was because of banking errors.

Any suggestion???????

The mystery continues.....

dcorraliza

[Darrel Taylor]

Answered in the other forum.
<br>

[dcorraliza]

DT said:
e: ASM vs PBP interrupts
Do you have other I2C statements in the Main program?

If you attempt to execute I2C statements in the interrupt handler, it's possible that another I2C command is already being executed from the main loop.

In which case, everything gets confused.

By commenting the line that you did. When it returns to the main loop, the currently executing I2C statement suddenly thinks it's done with what it was doing, but in actuality, it was the I2C in the interrupt handler that finished, not the one that got interrupted.

[dcorraliza]

Hi Mr Taylor:

Thanks for your response. No, I'm not using i2c out of interrupts routine, but I'm planning to. So I think (the same way yo do) is not a good idea to comment any line in your code. Because of that, here I post you a new "strange workaround" I have found making some tests:

The workaround is to add a byte variable to ReEnterPBP-18.bas like that:
HP_Vars VAR WORD[34] ; group vars together for less banking
R0_SaveH VAR HP_Vars[0]
......
......
TBLPTRH_SaveH VAR TBLPTR_H.highbyte
TBLPTRL_SaveH VAR TBLPTR_H.lowbyte
Product_H VAR HP_Vars[33]
nothing VAR byte

With this new variable called "nothing" I can re-enable the commented line at RestorePBP_H routine:

FLAGS = FLAGS_SaveH

And the code keep working properly. Why???????????????

I don't know the reason, but the last time an issue was fixed with a dummy variable definition, was because of banking errors.

Any suggestion???????

The mystery continues.....

dcorraliza

[dcorraliza]

dcorraliza,

The things you are saying make no sense.

I'm sure you are just seeing the symptoms of the problem, and when they change, you feel that what you changed fixed it. But, more than likely the problem just moved somewhere else.

Only seeing 5 or 6 lines of your 64k code gives me no way of knowing what's going wrong.

Attempting to convert an already existing (very large) program to use Instant Interrupts, almost never works.

When the program was written to begin with. No attention was paid to what can happen with interrupts. The program has already been debugged and known to be working.

Then when you suddenly try to add interrupts, and nothing works anymore. Since you already know the program worked before, it must be Darrel's program that's causing the problem. And any other possibilities are ignored because again. It already works. (on it's own)

DT_INTS is a starting point. If you start writing your program with it. You'll end up with a really cool program in the end.

If you want to apply it to an existing program that wasn't written for interrupts. It's not likely to work.

Sorry,
Darrel Taylor