Strange IT behaviour

[MikeBZH]

Hi,

I am trying to generate an audio wave using the PWM of a 18F2685 working at 32 MHz (with PLL)
The sampling rate is about 58 kHz, provided by the PWM.
I'am using PBP 3.0 and a PicKit 2 for debugging.

The waveform is stored in bytes in a table, called TABWF and stored in the program memory.
TABWF ends with $7F.

Some background tasks are executed and are periodiaclly interrupted by the TMR2 used for the PWM.

The IT program simply pushes the current table value to the PWM and increments the table look-up pointer.

Here is how the background program looks (extract) :

NOTE_IT : ; Initialisation
I = 0

INTCON = 000000
PIE1.1 = 1

LOOP :
ReadCODE(TABWF + I), X

IF (X <> $7F) THEN

; some simple maths here

ELSE

I = 0

ENDIF

GOTO LOOP


And the IT Program :

ASM
IT_NOTE :
clrf BSR

movf _X,W

movwf W,CCPR1L

incf _I


retfie FAST
ENDASM


Basic and very simple, but it does not work !
The IT program works, I is correctly incremented but the background program is sticked to the ReadCode instruction.
It looks like the ReadCode instruction execution time is greater that the IT period, so ReadCode is never completed and starts again and again from the beginning.

Any solution to that ?

The hereabove code is a very small part of my application. Actually, the background task is much more complex.
I'm afraid that the program remains sticked to any long execution time BASIC instruction it meets...

Thank you for your help

MikeBZH

[Demon]

nevermind...

Robert

[mark_s]

There's not enough code to figure out your problem. But if I had to guess you need to
increment your address counter by two and not one. This is a difference between the 18F's
and the 16F's. The data sheet explains how the program memory is addressed



For TAB_Adr = TABWF to $7F step 2
READCODE TAB_Adr, X
YOUR GOSUBS
Next TAB_Adr

[MikeBZH]

Hi mark_s,

The data, as read by Readcode are organized in bytes, not in words and declared by DB instructions .
For example, this is a line from the data tables :
DB 67, 67, 82, 67, 66, 67, 65, 67, 66, 81, 65, 66, 64, 63, 62, 61

So the increment must be 1 , not 2.

Sorry, but the example you give is a simple polling program, not synchronized by any interrupt.
This example does not address the issue I raised : How to handle the fact that ReadCode (or any Basic instruction) is restarted again and again by high rate interrupts instead of terminating ?

MikeBZH

[Demon]

Mike,

Like I suggested to someone else, maybe if you made a small test version of your program and keep only the absolute minimum code to run the loop above.

You can populate the table with test data and go on from there.

It would make posting the code so much easier to you, as well as for others to spot potential problems in your logic.


Basic and very simple, but it does not work !

That's the sort of stuff we see in signatures here. :D

Robert

Not as dumb as yesterday!

[MikeBZH]

Demon,

Thank you for your advice.

Of course I did what you suggest : write a very small program and test it and that's how I found that the problem was coming from ReadCode and its execution time.
After 40 years spent in the lab I know the methodology, thanks !

I am just asking for a precise advice/recommandation to the issue I raised. In relation with ReadCode and the interrupts. Nothing else

MikeBZH

[sayzer]

May I suggest that you take a look at this link:
http://www.picbasic.co.uk/forum/showthread.php?t=3891 (http://www.picbasic.co.uk/forum/showthread.php?t=3891&highlight=large+data+table)

[MikeBZH]

I asked directly Darrel Taylor (Technical Support) and he gave be the good answer :

I simply need to clear the interrupt flag (TMR2IF) in PIR1 before leaving the Interrupt Service Routine

Otherwise, the ISR is called again and again. No relation with ReadCode execution time.

Many thanks to you, Darrel.