channel address support

[ghaith]

Support for channel address can be implemented in several steps:

• [x] #621
• A new AST element is created, but the codegen will replace its value with 0
• [ ] #647
• Regions can be defined as M<Size>, G<Size> or with simply a number
• The M region are locally shared data
• The G region are globally shared data, this region can be defined from the outside
• Numbered regions represent hardware, they can be accessed by either the I or Q symbols (%IX1.2) will access region 1 starting from bit 2
• [ ] #648
• A region in the body is simply a pointer access to that region defined by the rules of access (%MX2 is accessing bit 2 of the locally shared data)
• A region accessed in a variable declaration with AT marks that the variable being declared is an auto pointer to that location.

Originally posted by @ghaith in https://github.com/PLC-lang/rusty/issues/621#issuecomment-1313292591

[rhythmchicago]

Hello! While defining a hardware address (Example: bBlink AT %IX10 : BOOL) compiles fine, it doesn't seem clear the effect of that address. You mention locally and globally shared data, but I'm not sure how I could access that and update it with data from the outside world. Could you elaborate?

[ghaith]

Hello @rhythmchicago

Only the parsing is implemented here the plan is to have global symbols for the variables you define so they could be accessed like normal variables from the outside or loaded as sections in the memory by the loader. But we still did not get there yet.

For now you could access global variables as if they were memory so you don't need the address definition. Just compile with debug symbols if you are loading via a runtime or define a header file for your global variables to access them from different languages

[rhythmchicago]

Ok. Thanks!

[andergisomon]

Hello @rhythmchicago

Only the parsing is implemented here the plan is to have global symbols for the variables you define so they could be accessed like normal variables from the outside or loaded as sections in the memory by the loader. But we still did not get there yet.

For now you could access global variables as if they were memory so you don't need the address definition. Just compile with debug symbols if you are loading via a runtime or define a header file for your global variables to access them from different languages

Can you elaborate more on using a header file for accessing global variables from different languages?

[ghaith]

Hello @andergisomon,

since this post we changed some behavior in the compiler.

You can declare hardware addresses by using the AT symbol:

VAR_GLOBAL
  myChannel AT %IX1.1 : BOOL;
END_VAR

will declare a global variable called __PI_1_1 of type BOOL and will make myChannel an auto pointer to that variable. Assigning myChannel will assign to the variable and vice versa.

To access global variables from an external language, let's take extend the above example:

VAR_GLOBAL
  myChannel AT %ID1.1  : DINT;
  myVar : DINT;
END_VAR

If the following is compiled as an object, and linked together with a C application for example, then the variables are available as symbols:

❯ nm demo.o
0000000000000000 T __init___demo_st
0000000000000008 B myChannel
0000000000000000 B myVar
0000000000000004 B __PI_1_1

You can now declare a header file for your application:

extern int myVar;
extern int* myChannel;
extern int __PI_1_1;

These variable are now accessible to your C application. The other way is also possible. If variables are available in an object file you can declare them as external for PLC and use them:

int myVar;
int* myRef;

{external}
VAR_GLOBAL
  myVar : DINT;
  myRef : REF_TO DINT; 
END_VAR

[andergisomon]

Thanks, exactly what I was looking for.