Problem with external constants [OK]

[Dany]

Hi, I have encountered a problem when using external constants as values in a constant table (using P18F4620).

The code of the main program:

Code: Select all

program Externals_test;

uses TestExtUnit;

begin
    Test;
end.

The code of unit "TestExtUnit":

Code: Select all

unit TestExtUnit;

const UsbManufacturer        : string[20]; external;
      UsbProduct             : string[20]; external;
      UsbSerialNo            : string[20]; external;
      VENDOR_ID              : word; external;
      PRODUCT_ID             : word; external;
      DEVICE_REL_NR          : word; external;

var Ptr: ^const byte;
    Wrd: word;

procedure Test;

implementation

const Table1: array[3] of word =     // <------------ content of the table is all zeroes
      (
      (VENDOR_ID),
      (PRODUCT_ID),
      (DEVICE_REL_NR)
      );

      Table2: array[5] of word = (1,2,3,4,5);
      
      Table3: array[5] of word =     // <------------ content of the table is all zeroes
      (
      (VENDOR_ID),
      (PRODUCT_ID),
      (DEVICE_REL_NR)
      );
      
      Table4: array[5] of word = (1,2,3,4,5);
      
procedure Test;
begin
  Ptr := @UsbManufacturer;
  Wrd := @UsbProduct;
  Wrd := Vendor_ID;              // <------------ OK
  Wrd := Product_id;             // <------------- Ok
  Wrd := DEVICE_REL_NR;          // <------------- Ok
  Ptr := @Table1;
  Ptr := @Table2;
  Ptr := @Table3;
  Ptr := @Table4;
end;

end.

The code of unit "USB_HID_ProjectItems" (which is entered as part of the project in the projectmanager):

Code: Select all

Unit USB_HID_ProjectItems;

const

UsbManufacturer : string[20] = 'Me and myself';
UsbProduct      : string[20] = 'My Product';
UsbSerialNo     : string[20] = '077';
VENDOR_ID       : word       = $1234;
PRODUCT_ID      : word       = $23;
DEVICE_REL_NR   : word       = 0101;

implementation

end.

As you can see I use in unit "TestExtUnit" the constants VENDOR_ID, PRODUCT_ID and DEVICE_REL_NR (which are externall defined -- in unit "" --) both in Table1 and Table3, and I also get their values in the main routine in variable "Wrd".

Now the problem:
- The tables 1 and 3 are filled with all zeroes (not the constant value I expected):

Code: Select all

;TestExtUnit.mpas,21 :: TestExtUnit_Table1
0x00D4	0x0000 ;TestExtUnit_Table1+0
0x00D6	0x0000 ;TestExtUnit_Table1+2
0x00D8	0x0000 ;TestExtUnit_Table1+4

- The "Wrd" values in the main routine are on the other hand OK (seen in the debugger).

So, apparently there is a problem when using external constants as values in a constant table. If the constants are not declared as "external", but unit "USB_HID_ProjectItems" is put in the "uses" clause of "TestExtUnit" then also the values in the tables are Ok.

Thanks in advance!

[zristic]

Thanks Dany. Will be fixed asap.
ALso, if I find the workaround I will post it here.

[zristic]

Hi,
Sorry for a bit of delay. Here is the workaround until we fix the issue:

Instead of:

Code: Select all

const UsbManufacturer        : string[20]; external;
      UsbProduct             : string[20]; external;
      UsbSerialNo            : string[20]; external;
      VENDOR_ID              : word; external;
      PRODUCT_ID             : word; external;
      DEVICE_REL_NR          : word; external;

use this:

Code: Select all

 uses USB_HID_ProjectItems;

But i guess you've figured it out already.

[Dany]

Hi,
Sorry for a bit of delay. Here is the workaround until we fix the issue:

Instead of:

Code: Select all

const UsbManufacturer        : string[20]; external;
      UsbProduct             : string[20]; external;
      UsbSerialNo            : string[20]; external;
      VENDOR_ID              : word; external;
      PRODUCT_ID             : word; external;
      DEVICE_REL_NR          : word; external;

use this:

Code: Select all

 uses USB_HID_ProjectItems;

But i guess you've figured it out already.

Thanks . I did indeed figured it out already.

[Dany]

Is something changed regarding this in v5.00? It seems above defined problem has been solved.

Now I have something similar in v5.00, but while using an external constant in a "library":
I have to use the "external" definition (1) instead of the "uses" definition (2) (see above posts) when I want to use constants in a library (of which only the .mcl file is to be delivered) that are defined in another project file of which the source is available (so, no "library").

Apparently the value of the constant taken into account in the library (.mcl file) is defined at library compile time using method (2),
and is correctly taken from the project file (in which the constant is defined) using method (1).

So, it seems to be the other way around than in the posts above...

Attached a small project (TestCompiling.zip). The "library" in this case is "MyLib.mcl" which is placed in directory "C:\Users\Public\Documents\Mikroelektronika\mikroPascal PRO for PIC\Uses\P18" (windows7), without its source file.

The call to "MyLibRoutine" in the main unit (program) should give in variable xyz the value of "abc" defined in "UnitOne".

The source file of the "library" is "_MyLib.mpas", as you can see it is renamed to hide its existance (only the .mcl file of a "library" is to be delivered).


Thanks in advance!

[janni]

Apparently the value of the constant taken into account in the library (.mcl file) is defined at library compile time using method (2),
and is correctly taken from the project file (in which the constant is defined) using method (1).

That's exactly how it works.
When a library is available only in precompiled form, it is assumed that it's finished and all units it used were compiled at the same time. After all, the library cannot be recompiled when only mcl file is available. Only library declarations with external keyword form an exception - while linking the library to a project, so declared constants and addresses of so declared variables/routines are replaced with current ones from units that use the library.

In your case a solution is to reverse the hierarchy of units - make UnitOne use your lib (MyLib.mcl) and the main project file use both. In this way, UnitOne will be recompiled every time it changes and MyLib will get current value of the abc constant (naturally, declared as external in MyLib ).

[Dany]

Apparently the value of the constant taken into account in the library (.mcl file) is defined at library compile time using method (2),
and is correctly taken from the project file (in which the constant is defined) using method (1).

That's exactly how it works.
When a library is available only in precompiled form, it is assumed that it's finished and all units it used were compiled at the same time. After all, the library cannot be recompiled when only mcl file is available. Only library declarations with external keyword form an exception - while linking the library to a project, so declared constants and addresses of so declared variables/routines are replaced with current ones from units that use the library.

In your case a solution is to reverse the hierarchy of units - make UnitOne use your lib (MyLib.mcl) and the main project file use both. In this way, UnitOne will be recompiled every time it changes and MyLib will get current value of the abc constant (naturally, declared as external in MyLib ).

Thanks Janni!

I think I will have to adapt a lot of my libraries in case they will be used without source.
As you can see, it was the other way around one time: http://www.mikroe.com/forum/viewtopic.p ... 17&start=2.

[janko.kaljevic]

Hello Dany,

Thanks for reporting this.
This will be fixed as soon as possible.

As Janni said, in this case you will need to recompile your library when you change constant value in source that is used by library.
After fix, this situation will generate error stating that source file is needed for build.

Best regards.

[janni]

Hello Janko,

After fix, this situation will generate error stating that source file is needed for build.

I'd opt for just a warning. An error will make lib development harder . For example, viewing a header file with some constants' declarations to recall what a precompiled lib uses - normal practice while testing a lib - will prevent project compilation.

[Dany]

Hello Janko,

After fix, this situation will generate error stating that source file is needed for build.

I'd opt for just a warning. An error will make lib development harder . For example, viewing a header file with some constants' declarations to recall what a precompiled lib uses - normal practice while testing a lib - will prevent project compilation.

Hi Janko, I agree with Janni, or do not change anything at all is also a valid choice (for me anyway). I know now the mechanism behind it all and I can live with it perfectly.

Thanks Janni and Janko.

[janko.kaljevic]

Hello,

Thanks for suggesting.

At this moment I can confirm that compiler will not generate error in this case in next releases.

Thanks again for your support.

Best regards.