Page 2 of 3

Re: 16f887 page problem.

PostPosted: Thu Mar 22, 2018 6:59 pm
by CaliforniaSlacker
Maybe it is just a stack problem.

Have you looked at how deep the stack is and when it would throw out one too many calls or jumps?

Anyhow hope you figure it out.

Re: 16f887 page problem.

PostPosted: Thu Mar 22, 2018 7:16 pm
by Adco
If I could somehow embed all my display strings into the program eeprom memory, that would solve my problem, I think. Perhaps I need a separate program that writes the data into memory and then access that memory when I need it. There are no paging limits when reading from eeprom. You just set the address and read.

I just have to know where each string starts and ends. A start address and 00h as an end marker.

Could work.

Or, I can change chips. A 18f4580 is pin compatible but cost more than double. No pages!

Re: 16f887 page problem.

PostPosted: Thu Mar 22, 2018 7:30 pm
by CaliforniaSlacker
We're getting an insight into how Microchip makes their money at least.

They have been laying in wait for you!

That may have been why they developed that chip. I mean use wise not money wise.

18F is 16 bit just to help you with 'transition'.

Probably not a harsh a change as 24F or dsPIC.

On the other hand why not live in the lap of luxury?

See if their is a pin compatible 32MX or other then you would be set for 10-15 years.

There might be rewards to go with the pain of learning new higher level chip.

Correction:18F4580 is probably just fine.Some of these others are surface mount unless you are a whiz at soldering those or send them out.

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 7:15 am
by Adco
I'm going to try the following....

Org 900
DT "this is string 1"
Org 910
DT "this is string 2"

Hopefully, the assembler places these string in program eeprom. I might need some other syntax than DT. Perhaps DE or DB. I will then view the list file and see the ascii values in memory at those locations. If I do, it will be easy to extract the strings out of program eeprom. Just set up the pointers and PGD and read it in.

If that works then the world is my pic chip!

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 8:22 am
by CaliforniaSlacker
Looked in my book at eeprom section.

If your program is just reading from the eeprom it should be safe.

Book says writing to the eeprom is 'dangerous'.

Says to disable global interrupts while you are doing it.

That's what I found out about it.

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 9:01 am
by Adco
I've managed to place all my strings into a page. It works!!!! All I have to do is keep track of each string by orging it correctly and making a note of it. I know the read will be easy. Just load address, do a few needed actions and the data will pop out.

A simple loop routine will retrieve the data and output to the display until I read a 00h in, then I know that is the end of the string.

Easy Peasy. Why didn't they tell us about this earlier. Most of the forums discussing this issue talk about PCLATH and pagesel $ etc. Not much about retrieving data tables from eeprom. Because the eeprom address registers are 2 bytes wide, there is no limit to how far it can reach without having to set pages or worry about long calls. And, a bonus if needed is that the data is 14 bits wide as well! You can even store 2 simple ascii characters in one location! How about that?

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 9:56 am
by CaliforniaSlacker
Good!

Maybe that is what the eeprom is for.

Data that takes up a lot of room in program memory.

I am not sure it is accessed as fast as program memory.

Like I said earlier this is a little further down the road than I've gotten with PICs.

Hope it works!

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 12:34 pm
by ric
CaliforniaSlacker wrote:'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.

This is rubbish.
Adco, please do not pay attention to this poster, he knows even less about these parts than you do.

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 12:38 pm
by ric
Adco wrote:I've managed to place all my strings into a page. It works!!!! All I have to do is keep track of each string by orging it correctly and making a note of it. I know the read will be easy. Just load address, do a few needed actions and the data will pop out.

A simple loop routine will retrieve the data and output to the display until I read a 00h in, then I know that is the end of the string.

You need to get your terminology right.
Those strings are going into FLASH memory, not EEPROM.
It is possible to put a few strings into EEPROM, but not the way you're doing it. FLASH is better anyway if you don't need to write to the strings.
It's even possible to pack two (7-bit) ASCII characters per FLASH location if you get pushed for space.

Easy Peasy. Why didn't they tell us about this earlier. Most of the forums discussing this issue talk about PCLATH and pagesel $ etc. Not much about retrieving data tables from eeprom. Because the eeprom address registers are 2 bytes wide, there is no limit to how far it can reach without having to set pages or worry about long calls. And, a bonus if needed is that the data is 14 bits wide as well! You can even store 2 simple ascii characters in one location! How about that?

At a guess, you have been looking at some very old tutorials, before Microchip extended the EEPROM access registers to also be able to read FLASH memory.
That started with the PIC16F877 chips, which came before the PIC16F887 chips.
Both are VERY VERY old.
The newer PIC16F1xxx family chips can now read FLASH memory just using the FSR registers, which is even simpler.

For your other problems, note the answer to your post on the Microchip forum. http://www.microchip.com/forums/m1044437.aspx

Re: 16f887 page problem.

PostPosted: Fri Mar 23, 2018 1:26 pm
by Adco
ric wrote:
Adco wrote:I've managed to place all my strings into a page. It works!!!! All I have to do is keep track of each string by orging it correctly and making a note of it. I know the read will be easy. Just load address, do a few needed actions and the data will pop out.

A simple loop routine will retrieve the data and output to the display until I read a 00h in, then I know that is the end of the string.

You need to get your terminology right.
Those strings are going into FLASH memory, not EEPROM.
It is possible to put a few strings into EEPROM, but not the way you're doing it. FLASH is better anyway if you don't need to write to the strings.
It's even possible to pack two (7-bit) ASCII characters per FLASH location if you get pushed for space.

Easy Peasy. Why didn't they tell us about this earlier. Most of the forums discussing this issue talk about PCLATH and pagesel $ etc. Not much about retrieving data tables from eeprom. Because the eeprom address registers are 2 bytes wide, there is no limit to how far it can reach without having to set pages or worry about long calls. And, a bonus if needed is that the data is 14 bits wide as well! You can even store 2 simple ascii characters in one location! How about that?

At a guess, you have been looking at some very old tutorials, before Microchip extended the EEPROM access registers to also be able to read FLASH memory.
That started with the PIC16F877 chips, which came before the PIC16F887 chips.
Both are VERY VERY old.
The newer PIC16F1xxx family chips can now read FLASH memory just using the FSR registers, which is even simpler.

For your other problems, note the answer to your post on the Microchip forum. http://www.microchip.com/forums/m1044437.aspx

You are correct about the terminology! It is the Flash Program memory that I am using. I have sorted the whole issue out. It works better and easier than I expected. And I have saved a huge amount of program space. No more jumps to the middle of nowhere! I just have to be careful and keep track of all the orgs that I now have. This has increased my knowledge base tremendously. Each new project teaches plenty.