EEPROM Variables (EE_Vars.pbp)

[MitchStipp2]

Hi Darrel,
I am working on a piece of code that uses the Timer 1 to create a timed interupt for turning on and off LEDs. The PIC is a 16F887. I wish use the EEPROM for saving information. All of the code seems to work well until I include and try to use the EEPROM Variables (EE_Vars.pbp). The EE_Vars seem to operate as expected - however my Timer 1 interupt runs erratically and sometimes halts. The time base is rather brief (1 mS) and I am using an external resonator as clock source (20MHz). I am using your "DT_INTS-14.bas" and "ReEnterPBP.bas" to support the Timer 1 interupt.
I am curious as to what I am doing wrong. The best diagnostic indication I have was sending the OSCCON variable to the port D. The values indicated that the PIC was going to internal LF oscillator when it should have been using the external resonator. Can you give me some wise counsel???

Thanks in advance, Mitch

[Darrel Taylor]

It's difficult to say with "large chunk of code left out .." in the routine that's having a problem.

I don't see any usage of the EE_Var routines, other than the declarations.
Are you trying to use them inside the interrupt handler? In the missing code?
<br>

[Darrel Taylor]

After a closer inspection, it looks like you are probably overflowing the Stack.

When the Timer triggers an interrupt, that uses 1 level.
When it gets to the handler, it GOSUB's to TimerIO. That's level 2.
An Array operation uses 3 levels internally for a total of 5 levels.

Then in the Main loop, you also GOSUB MonitorIO, so you are already 4 levels deep when it gets interrupted.

16F's only have 8 stack levels.

[MitchStipp2]

I can provide the chunk of code if you would like to review it, however your point about the stack is well taken and "me thinks" you are on target. I will see if I can simplify. Thanks

[Byte_Butcher]

I'm sure everyone on the planet (except me) already knows about this, but since I just blew a couple hours trying to figure this out I figured I'd post it here incase it trips up someone else...

I've been playing with Darrel's EE_Vars.pbp, trying to make it work. (I'm using PBP/MCS)

The sample file "EE_1_Example.bas" worked PERFECT, after I changed the LCD formatting for my hardware.

But then I tried it with one of my existing programs, and it wouldn't compile... MCS kept whining about "Symbol not previously defined (Byte)"

At one point I ended up with 2 apparently identical lines of code, and 1 worked and the other didn't. ???

As it turns out, it was because of incorrect case in my variable definition. But what threw me was that part of the declaration wants UPPER case and part wants LOWER case.


This works fine:

wastedtime       var  byte : @  EE_var  _wastedtime, BYTE, 139

This does not work:

wastedtime       var  byte : @  EE_var  _wastedtime, byte, 139

This does not work:

wastedtime       var  BYTE : @  EE_var  _wastedtime, BYTE, 139

This does not work:

wastedtime       var  BYTE : @  EE_var  _wastedtime, byte, 139

Of course it would have been much easier to figure out if the "Uppercase All" option for the reserved word formatting hadn't been on. But of course since it makes all the reserved words BOLD uppercase it all looked the same. I couldn't figure out why with 2 apparently identical lines, one would work and the other not. Once I turned off the Uppercase All option, then it became clear that BYTE was not in the same case...

So... why does it demand lowercase on one side of the definition and uppercase on the other?


Steve

[Darrel Taylor]

So... why does it demand lowercase on one side of the definition and uppercase on the other?

It doesn't.

The only one that has to be in upper case is the one in the EE_var declaration. (right side)
There is a "case sensitive" note in post#4, EE_var section.

Case doesn't matter on the VAR statement.

I've double checked it here to be sure.

[Byte_Butcher]

It doesn't.

The only one that has to be in upper case is the one in the EE_var declaration. (right side)
There is a "case sensitive" note in post#4, EE_var section.

Case doesn't matter on the VAR statement.

I've double checked it here to be sure.

Well Darrel, you're absolutely right of course ...

I tried it about 100 times and couldn't get it to work. Then other real life problems cropped up and I had to set it aside for a couple weeks .

Now that I've got time to work with it again, it works *perfectly*, just as advertised.

There was obviously a problem with that little lump of gray matter between my ears, but it seems to be better now...

Sorry to bother you. Thanks for your help.

Steve