 |
 |
| View previous topic :: View next topic |
| Author |
Message |
danielz85
Joined: 22 Sep 2012
Posts: 37
|
| memory organization in pic16f690 |
 Posted: Sat Oct 27, 2012 5:01 am |
 |
|
hi,
can anyone please explain how come
| Code: | #include <16F690.h>
//#device *=16
#device adc=8
#fuses INTRC_IO, NOWDT, NOBROWNOUT, PUT,NOMCLR
#use delay(clock=8000000)
#use rs232(baud=9600,xmit=pin_A0,rcv=pin_A1)
unsigned int timerIndex=0;
unsigned int bitIndex=0;
unsigned int16 t1[40]={} ;
unsigned int16 t2[30]={} ;
unsigned int16 t3[20]={} ; |
compiles,
whereas
| Code: | #include <16F690.h>
//#device *=16
#device adc=8
#fuses INTRC_IO, NOWDT, NOBROWNOUT, PUT,NOMCLR
#use delay(clock=8000000)
#use rs232(baud=9600,xmit=pin_A0,rcv=pin_A1)
unsigned int timerIndex=0;
unsigned int bitIndex=0;
unsigned int16 t1[40]={} ;
unsigned int16 t2[40]={} ; |
doesn't?
I know that there are 4 - 64Bytes banks, which means I can fit 32 16bit values in one. am I right?
this issue doesn't make sense to me..
thanks alot for you help!
Daniel |
|
 |
John P
Joined: 17 Sep 2003
Posts: 331
|
|
| Posted: Sat Oct 27, 2012 7:21 am |
|
|
"I know that there are 4 - 64Bytes banks, which means I can fit 32 16bit values in one. am I right?"
No. Look at the data sheet and especially FIGURE 2-5. The data banks are larger than 64 bytes, but there are only 3 of them. However, I've found that playing with large (relative to the bank size) arrays, the compiler objects to things that look innocent. You might do better dealing with this by using pointers instead, if you're willing to keep track of what you're actually pointing at. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19551
|
|
| Posted: Sat Oct 27, 2012 9:23 am |
|
|
There are 96 bytes in the first bank (of which the compiler uses perhaps a dozen bytes for it's scratch variables), then two lots of 64 bytes in the higher banks.
Arrays can't be split across banks, so it can fit one 80 byte array, but can't fit two.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Oct 27, 2012 2:52 pm |
|
|
You can study the problem by looking at the .SYM file. If I compile the t2
array with only 39 elements like this
| Code: |
unsigned int16 t1[40]={};
unsigned int16 t2[39]={};
|
the .SYM file shows me:
| Code: |
026-075 t1
0A0-0ED t2
|
t2 is placed at address 0xA0 which is the start of the 2nd bank. But the
compiler appears to want to preserve the last two bytes that are not in
the common area of Bank 2. It wants to preserve 0xEE and 0xEF, perhaps
for some internal use.
You can do a work-around by forcing the compiler to put t2 at 0xA0,
and increase the array size to 40 elements, like this:
| Code: |
unsigned int16 t1[40]={};
unsigned int16 t2[40]={};
#locate t2 = 0xA0
|
Then the .SYM file shows that t2 uses the last two bytes of the non-
common area of RAM Bank 2 (going up to address 0xEF):
| Code: |
026-075 t1
0A0-0EF t2
|
But what effect this has on compiler operation, I don't know. It now can't
use 0xEE and 0xEF for it's own use, or at least I don't think it can. |
|
|
danielz85
Joined: 22 Sep 2012
Posts: 37
|
|
| Posted: Sat Oct 27, 2012 3:30 pm |
|
|
| thanks guys! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19551
|
|
| Posted: Sun Oct 28, 2012 2:49 am |
|
|
If you load the device editor, and look at the memory table, it has address EF, flagged as '0', which means 'not useable by CCS'. Question is 'why'. It has 7F similarly flagged, and 16F. A quick glance at the 689, doesn't have these bytes flagged like this.
A look through the errata sheet, doesn't find anything affecting these bytes.
The table is like this even on really old compilers (went back to some V3 versions).
Typing error?
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
