16f887 page problem.

(instructions, reset, WDT, specifications...) PIC12F6xx, PIC16Fxxx, PIC16F6x, PIC16F7x

16f887 page problem.

Postby Adco » Tue Mar 20, 2018 3:01 pm

Hi. I need some guidance please. I'm using the 16F887 to run a keypad, LCD and a DS1307 RTC. It is becoming a long program

I have placed the main section in page0. The display message routines are in page1 and the display strings are in pages2 & 3. I have orged them as follows: page 0 = 5. page 1=800h. page 2=1000h and page 3=1800h. I am compiling with absolute code.

As soon as my lcalls go past a certain size, the PC jumps to another page. I monitor PCLATH in a window and I can see it changing. PCL is correct but obviously PCLATH is causing the problem. If I keep the call distance less than about 100h, all is good. I have looked at my list file to see the exact size of each page and when it gets to say 900h, trouble starts.

I use the LCALL with pagesel $ after the call. That works fine until the call is too far. Surely the whole 7ffh of each page is accessable by using LCALL.

Help.
Thanks in advance.
Adco
 
Posts: 11
Joined: Tue Mar 20, 2018 2:44 pm
PIC experience: Professional 5+ years with MCHP products

Re: 16f887 page problem.

Postby CaliforniaSlacker » Thu Mar 22, 2018 5:50 am

'The display message routines are in page1 and the display strings are in pages2 & 3'

I don't think that is the right way to do it.

Wait until you get confirmation on this before rewriting program.

The way to do it is put the subroutines at the beginning of file.

Like configuration, declarations and then all subroutines.

Then put the start and main program.

I think this might turn out to be your answer.
CaliforniaSlacker
 
Posts: 21
Joined: Mon Feb 19, 2018 8:01 am

Re: 16f887 page problem.

Postby Adco » Thu Mar 22, 2018 7:14 am

Normally, I structure my programs as you mention. Declarations, variables then subroutines and finally the main program.

In this program, there's not enough space to accommodate everything. It is over 2000 bytes already! I have to place the display string lookup table in other pages. The are many strings as this program is menu driven via the keypad. Lots of prompts to make choices and then perform actions etc.
Adco
 
Posts: 11
Joined: Tue Mar 20, 2018 2:44 pm
PIC experience: Professional 5+ years with MCHP products

Re: 16f887 page problem.

Postby CaliforniaSlacker » Thu Mar 22, 2018 7:38 am

Keep in mind this is beyond my level of experience.

Maybe you need a bigger chip? Think the 18F458 is close to having same pinout as 16F887 and it has 32k of program memory.

So that all your subroutines are in the ''safe zone'. That might be too drastic of a solution though

Here's the rule for 16F54.

'The result is that all subroutines must be placed (or at
least start) in the first half of the page, though you can call them from anywhere
in the page.'

Maybe you are running into the same thing on a different scale.

Note the 'Start in' part. Maybe you can start them in the 16F877's ''safe zone'.
CaliforniaSlacker
 
Posts: 21
Joined: Mon Feb 19, 2018 8:01 am

Re: 16f887 page problem.

Postby Adco » Thu Mar 22, 2018 8:48 am

A bigger newer chip without pages would be ideal. Unfortunately, I have already done the PCB layout and half the program is written. The program can always be modified to a new chip, I guess. I used the 16f887 because I am familiar with it but have never written such a long program before. The thing causing the problem is the LCD strings that have to be displayed. There are many choices that have to be selected in the system.
Adco
 
Posts: 11
Joined: Tue Mar 20, 2018 2:44 pm
PIC experience: Professional 5+ years with MCHP products

Re: 16f887 page problem.

Postby CaliforniaSlacker » Thu Mar 22, 2018 8:59 am

You might be having problems with the stack.

That has just about reached the limits of my learning PIC's.

Is the LCD sub have a lot of RETLW's? Like a lookup table?

I don't think the problem is with that.

There is something about calling sub's from within sub's you have to be careful about.

I hope this helps a little.
CaliforniaSlacker
 
Posts: 21
Joined: Mon Feb 19, 2018 8:01 am

Re: 16f887 page problem.

Postby Adco » Thu Mar 22, 2018 9:45 am

Every bit helps. Makes one think about all aspects.

The LCD tables are all RETLW's. The program jumps to the correct RETLW but returns somewhere else. I can see that PCL is correct but PCLATH hasn't kept the return address. That is the problem. Only happens when LCALL distance gets too far.

My analogy - I have 4 buckets full of water. They are deep. 7ffh deep. My arms can only reach down to about 100h in each bucket. I can see the rest of the water but I can't get my cup to the bottom. My cups never runneth over....
Adco
 
Posts: 11
Joined: Tue Mar 20, 2018 2:44 pm
PIC experience: Professional 5+ years with MCHP products

Re: 16f887 page problem.

Postby Roche » Thu Mar 22, 2018 11:48 am

I would change to a P18. you can likely find a pin for pin equivalent. The last time I used multiple pages I used a set of call vectors at the beginning of page 0. It worked, but ultimately it uses program space to implement, and you end up with unnecessarily complex code.

So close to the top of page 0 there are subroutines like:

V_init_sys
lcall init_sys
clrf PCLATH
return

where init_sys can be in any page. V_init_sys can be called from within page 0, where the main operating code resides. I can't remember the details of how I arrived at that, it was long ago. Even if it means quite a lot of work moving to a P18, I would do it.
Roche
 
Posts: 72
Joined: Fri Jul 11, 2014 12:35 pm
PIC experience: Professional 5+ years with MCHP products

Re: 16f887 page problem.

Postby CaliforniaSlacker » Thu Mar 22, 2018 5:27 pm

'I used the 16f887 because I am familiar'

I like the way you think! I know someone who jumps around from chip to chip and it doesn't look good to me.

Think it is better to have 'a base of operations' or 'go to' chip.

is that C you are using?

I think the 16F877 is one of the top assembler chips but not really a C chip.

it has the 35 instruction set not the later 'optimized for C' instruction set.

C chips have about 12k or bigger program memories.

'C compiler optimized instruction set architecture
84 base instructions with flexible addressing modes'

That's from dsPIC30F2010 sell sheet. That addressing modes might ease what you are doing.

You might have outgrown the 16F877.
CaliforniaSlacker
 
Posts: 21
Joined: Mon Feb 19, 2018 8:01 am

Re: 16f887 page problem.

Postby Adco » Thu Mar 22, 2018 6:49 pm

I'm sure the 16f887 is old but it is a staple in three of my business products. My bad was I never thought about the pages! What also got me that initially everything worked in all the pages and then suddenly things stopped. It's not as if it is gradual in the problem. You add one more display lookup table and bam!

I'm going to try another approach. I'm going to try write the tables into program eeprom and look it up from there. I've just got to work out how to get the data into the memory. I know I am allowed to write to that eeprom but not sure how to actually implement it in real life. I have a few thoughts that need to be worked on.
Adco
 
Posts: 11
Joined: Tue Mar 20, 2018 2:44 pm
PIC experience: Professional 5+ years with MCHP products

Next

Return to 14-Bit Core

Who is online

Users browsing this forum: No registered users and 8 guests

cron