Instant Interrupts - Revisited

[Darrel Taylor]

And a good habit it is.

I also tend to put initialization code in the Include files that need to run before the main program starts. So the top is the best, and don't jump over them.

DT

[Charles Linquis]

This is what I have. This is before I decare any other variables. I figure I'm not using anything close to 128 bytes. Any other ideas?
I AM declaring a LOT of variables after this block, however.


MasterClock VAR WORD bankA system
FanClock VAR WORD bankA system
Fan1Counter VAR WORD bankA system
Fan2Counter VAR WORD bankA system
Fan3Counter VAR WORD bankA system
Fan4Counter VAR WORD bankA system
Fan5Counter VAR WORD bankA system
Fan6Counter VAR WORD bankA system
Fan7Counter VAR WORD bankA system
Fan8Counter VAR WORD bankA system
Fan9Counter VAR WORD bankA system
changedB VAR BYTE bankA system
OldPortB VAR BYTE bankA system
changedC VAR BYTE bankA system
Temp VAR BYTE bankA system
TPE VAR BYTE bankA system

[Darrel Taylor]

I found that if I select a 16F877A, instead of an 18F part, I get the exact same errors. Could Be?

DT

[Charles Linquis]

18F8720

If you want to try it yourself, send me your email address to

[email protected]

[Darrel Taylor]

Charles,

Got the program. It's a monster.

And, I've learned a couple things today. First, Microchip pulled a fast one on me.

Chips like the 18F252/452/1220 etc. etc. have 128 bytes designated in the lower half of BANKA, ranging from 00h to 7Fh.

But, the larger chips such as 18Fxx20's only have 96 bytes, 00h to 5Fh. It's really odd, because they've taken the extra space, and turned it into "Note 1: Unimplemented registers are read as ‘0’.". I guess they're saving it for Future Use.

That wasn't very nice of them.

Second, it seems the SYSTEM modifier is doing some things that I didn't expect.
Sometimes I use the SYSTEM to simply remove the Underscore from variable names in ASM routines. But, it appears that SYSTEM does a little more than that with these chips.

If a variable is declared as...

<pre>Avar VAR BYTE SYSTEM ; without specifying the bank</pre>it will be placed in BANKA, even though BANKA wasn't specified.

This seems to happen because PBP sorts things alphabetically, and with SYSTEM removing the underscore it causes them to be sorted in with the BANKA SYSTEM variables.

Same thing happens with the PBxx BIT variables too. And, the complex octal formulas have created 12 temp (T) word variables, that also go in BANKA.

So BANKA is filling up with stuff that wasn't designated as BANKA, and now that there's less BANKA available, it's running out of room.

This problem also continues out into the other banks too. In ReEnterPBP-18, I have...

<pre>HP_Vars VAR WORD[22] BANK0</pre>Which you would think will automatically go into BANK0 before it starts allocating other variables, but it doesn't. It only fits in BANK0 if it also happens to line up alphabetically. So all variables from _A... to _H... get assigned first. Then HP_Vars throws an error.

Adding SYSTEM after it...

HP_Vars VAR WORD[22] BANK0 SYSTEM

Removes the underscore, and allows it to "sort" into the list before all the _A.._Z variables, and therefore fits in BANK0 just fine.

At this point, I'm stopping short of calling it a Bug in PBP, because maybe it's just different than what I'm expecting. However, when you declare a variable in BANK0, you would expect it to be placed there! But that's not necessarily what happens.

<hr>Now then, what to do about it.

On my end, I've pulled as much as I could out of BANKA and BANK0, and specified BANKs for all system variables. This should help with the smaller BANKA. Still need a few in there but its only about 6 bytes. I've updated the files on the website. Please download them again.
http://www.pbpgroup.com/modules/wfse...p?articleid=21

On your end, since you don't actually use the BANKA modifier in your ASM routines (except for a couple PORTB accesses) all your BANKA variables would be just as happy in BANK0. But I think there's still enough room now if you want to leave them.

But the biggest thing to do is with the temp vars. This line...

IF (((OCT [0]-48)*100) + ((OCT [1]-48)*10) + (OCT [2] -48) > 255) OR (((OCT [3]-48)*100) + ((OCT [4]-48)*10) + (OCT [5] -48) > 255) OR (((OCT [6]-48)*100) + ((OCT[7]-48)*10) + (OCT [8] -48) > 255) OR (((OCT [9]-48)*100) + ((OCT [10]-48)*10) + (OCT [11] -48) > 255) THEN

Is creating 12 temp vars (T1-12). ReEnterPBP-18 is only set up for 7. So you'll either need to cut the formula into smaller pieces, or modify the ReEnterPBP-18 files to be able to handle that many temp vars. I'd recommend cutting it.

There were some other things missing, but I assume that was from not being able to compile it.

Thanks for the "HUGE" program example, It's easy to miss that kind of stuff with the little ones.

Added: Forgot to mention, Don't jump over the INT_LIST and INT_ENABLEs. They have to actually execute, to work properly.

<br>

[Charles Linquis]

Darrel,

Thanks for all the work!

I keep telling people that I probably have the "world's biggest running PBP program", maybe now I have a witness.

The reason it wouldn't compile is that I was in the process of working DT_Ints into the program but didn't have everything completed. Sometimes, I know that there are unresolved issues, but I hit "compile" anyway so that the compiler can do some of the work of finding errors for me.

Now, I'll have to see if I can make it all work at my end. I'll let you know.

Again, thanks for your help.

[Charles Linquis]

Darrel,

It compiles and assembles "clean". I changed my test for invalid IP addresses.
T5 is the last temp variable used.

Now I just have to "wire" in the ISR's to the rest of the program and test.


YAAAAAAAAAAY !