Solved: Linker error when using 16F628A: workaround needed.

[Dany]

Hi, this problem is already reported to mE and acknowledged by them.
It only occurs when I compile/build a project using the 16F628A, and e.g. not when compiling the same code for the 18F2550. I use mP v 8.3 Bèta.

The problem is the following: the compilation of the code below goes Ok, but in the linking phase I get a linker error:

_DescrConst: constant not found.

This is the code:

Code: Select all

program TestDescrConstuctorOffset;

const
 DescrConst : array[10] of byte =
 (
  3, // len of descriptor 0
  2,
  3,
  5, // len of descriptor 1
  20,
  30,
  40,
  50,
  2,  // len of descriptor 2
  200
  );

var I: word;

begin
  I := @DescrConst;
end.

As soon as one tries to use the constant array in some way (here by using its address) the problem occurs.

My question now is: does anyone knows any workaround for this phenomenon?
Thanks in advance!

[piort]

hi,
what happens if you declare you constant like that ?

Code: Select all

const
 DescrConst : array[10] of byte = (3,2,3,5,20,30,40,50,2,200);

I'm not sure at 100% but maybe is a prob with comment inside the declaration...

HTH a bit

[janni]

As soon as one tries to use the constant array in some way (here by using its address) the problem occurs.

Simple assignments will work (like bb := DescrConst[1] as they're done without placing the constant in ROM. The bug is indeed limited to PIC16 processors, but there is hardly a simple workaround if the compiler cannot save constants.

The only simple solution I see is to declare a variable and initialise it with the same data as the constant was supposed to contain.

BTW, there is a way to force the compiler to save your array in ROM, but it may be not worth using. You could describe what you want to achieve first.

[Dany]

hi,
what happens if you declare you constant like that ?

Code: Select all

const
 DescrConst : array[10] of byte = (3,2,3,5,20,30,40,50,2,200);

I'm not sure at 100% but maybe is a prob with comment inside the declaration...

Hi piort, thanks for the suggestion. No success though, the same problem persists.

[Dany]

As soon as one tries to use the constant array in some way (here by using its address) the problem occurs.

Simple assignments will work (like bb := DescrConst[1] as they're done without placing the constant in ROM.

Hi Janni, thanks for your reply.

This indeed gives no problem:

Code: Select all

  I := DescrConst[3];
  J := DescrConst[5];

but
this gives the linker problem:

Code: Select all

  for I := 0 to SizeOf(DescrConst) - 1 do
  begin
    J := DescrConst[I];
    // do something with J
  end;

and also this code generates the error:

Code: Select all

  for I := 0 to 9 do
  begin
    J := DescrConst[I];
    // do something with J
  end;

So, simply trying to step through the array is already too much asked for...

The bug is indeed limited to PIC16 processors, but there is hardly a simple workaround if the compiler cannot save constants.

Simple assignment is indeed sometimes Ok, but see my examples above: sometimes it is not Ok.

The only simple solution I see is to declare a variable and initialise it with the same data as the constant was supposed to contain.

That is indeed a work around, but this is a tradeoff between rom and ram usage. For some larger non changing data structures I want of course to use arrays in constant memory...

BTW, there is a way to force the compiler to save your array in ROM, but it may be not worth using.

Ha. What way?

You could describe what you want to achieve first.

Well, an example: I tried to make a "7 segments" library. This library would hold an array of the binary value of each segment (a..dp) and then also an array with the codes of which segments to use for each hex number to display:

Code: Select all

const // __7SegmentBits:
      __a  = $1;	 // bit 0
      __b  = $2;	 // bit 1
      __c  = $4;	 // bit 2
      __d  = $8;	 // bit 3
      __e  = $16;  // bit 4
      __f  = $32;	 // bit 5
      __g  = $64;	 // bit 6
      __dp = $128; // bit 7

      __7SegmentCharacters: array[0..$0F] of byte = // each character is the sum of a number of segments
       (      
        __a + __b + __c + __d + __e + __f,	// character "0"
	      __b + __c,				                  // character "1"
	      __a + __b + __g + __e + __d,		    // character "2"
        __a + __b + __g + __c + __d,        // character "3"
	      __f + __g + __b + __c,			        // character "4"
	      __a + __f + __g + __c + __d,		    // character "5"
	      __a + __f + __e + __d + __c + __g,	// character "6"
	      __a + __b + __c,			              // character "7"
	      __a + __b + __c + __d + __e + __f,	// character "8"
	      __a + __b + __g + __f + __c + __d,	// character "9"
	      __a + __f + __e + __g + __b + __c,	// character "A"
	      __f + __g + __c + __d + __e,		    // character "B"
	      __a + __f + __e + __d,			        // character "C"
	      __b + __g + __e + __d + __c,		    // character "D"
	      __a + __f + __g + __e + __d,		    // character "E"
	      __a + __f + __g + __e			          // character "F"
       );

As soon as I try to address "__7SegmentCharacters" the linker error occurs...

[yo2lio]

MP 7.0 !!!!!!!!!!!!!!!!!

[janni]

MP 7.0 !!!!!!!!!!!!!!!!!

Yeah, we share that sentiment . There wasn't much to fix in version 7 to make it bug-free. Unfortunately, mE was busy with new concept that took longer than expected, so eventually the makeshift v8 was born .

So, simply trying to step through the array is already too much asked for...

As I said before, the compiler does not save constants to Flash. Constants may be used only when their values may be assigned during compilation. So, yes, this J := DescrConst; won't compile as the value is not known in compilation time.

Well, an example: I tried to make a "7 segments" library. This library would hold an array of the binary value of each segment (a..dp) and then also an array with the codes of which segments to use for each hex number to display

Well, it won't be worth it with the workaround. You would not be able to use constructs like __b + __c with it, just plain numbers. If you have to use PIC16, then go back to v7 of mP.

[Dany]

If you have to use PIC16, then go back to v7 of mP.

Thanks Yo2lio and Janni!

p.s. Is it possible to have 2 mP versions at the same time on the PC?

[janni]

Yes, it is.

[Dany]

Thanks. I installed mP v7.0 next to mP v8.3. With v7.0 the problem does indeed not occur! Thanks! Problem solved.