Supported Hardware

[chamobit]

Hello,

Thanks a lot for this project!

I'm wondering if you've been able to test Rusty on a real PLC, such as the Arduino Opta, or on a microcontroller like the RP2040 or RP2350. I'm trying to make a comparison with the OpenPLC (Matiec) based compiler, which uses a form of physical addressing to describe the supported hardware.

Since 2024, I understand that LLVM should be able to generate code for the ARM architecture. However, it would be great to have an end-to-end example of running Rusty-generated Structured Text code on the Arduino Opta, RP2350, or similar devices.

Perhaps such an example already exists, and I've simply been unable to find it in the documentation.

Best regards,

[ghaith]

Hello @chamobit

RuSTy does indeed work on real hardware. I don't know about the Arduino Opta or the RP2350 but cross compiling a target application should work by design since LLVM is a cross compiler there are things to consider however that I will mention at the end.

To compile an application to a different target try the following:

• Compile RuSTy to your own target (windows,linux, mac..)
• Create a project that you want to compile and build it with

plc build --target=<target>

You can add a --sysroot argument if you need a specific sysroot
I would also recommend adding the --linker argument to use a specific linker. Usually you want to use a gcc compiled for your architecture as a linker.

Some things to consider:

• We only target 64bit systems at the moment, this means all pointers are 64bit. This is currently hardcoded but contributions to change this are welcome.
• Since we are targeting 64 bit, date-time types are 64bit
• RuSTy does not include a runtime, therefore you don't have a cyclic application unless you build one with a timer. I would recommend using a runtime that would schedule your PLC application cyclically. You can easily write such an application in C or Rust (or even in ST using rusty)
• To access hardware, you need to provide an abstraction for said hardware, this can be done using the C Interoperability with RuSTy, so provide the access functions in C and call them from your PLC application. See : https://plc-lang.github.io/rusty/libraries/external_functions.html for more information.

[chamobit]

Hello @ghaith thank you very much for your feedback and clarification.

Best Regards

[gaimassimo]

Hi, first of all congratulations for the project.
My goal is to use rusty on an embedded system and make it communicate with peripherals in modbus. From the code I saw that there is a Hardware_binding.rs file; could you tell me, in general, how to proceed so I can contribute to the development of the system.
Thank you very much.

[ghaith]

Hello @gaimassimo

To bind hardware to the an application, you need to have the application (plc) compiled with debug sympols. You can use either --debug or -g to generate debug info. Once the application is running in some sort of runtime, you can use the runtime to read the available symbols using the DWARF format. On way to do this is to use gimli. Now you have direct access to all variables within your cycle for the modbus to read/write.
If you want to use hardware addresses as defined by the norm, just bind the address you want with the AT symbol, for example in a global variable section:

VAR_GLOBAL
  myVar AT %IX1.1 : BOOL;
END_VAR

This will generate an address for the %IX1.1 variable and link myVar to it, so you can use either %IX1.1 or myVar in your code interchangebly. In the binary, myVar will be a pointer to the %IX1.1 variable, which is exposed in the global symbol table or in the DWARF info as __PI_1_1 you can trace the logic for this by following the ConfigVariable struct in ast.rs
The hardware_binding.rs is a good starting point but we ultimately did not end up using it much. What it does it it finds all variables in the project that are marked with I* (templates) in order to later assign them using a configuration file to a correct variable location, possibly at runtime.

For contribution, the best way to start on this topic is documentation, I notice we lack in how to bind hardware to the application.
In addition, as you have a specific usecase, I would say try to implement the usecase you have (communicating with modbus) and see what needs changes based on that, we can then discuss the ideas in separate issues and maybe you could contribute the changes based on that.

Hope this helps.
Best Regards
G.

[gaimassimo]

Many thanbks,
I'll start watching..