Getting started with Rusty

[andyfozzy]

Hi,

I am Andrew, a software developer, working on a project involving PLCs. We would like to be able to use Rusty to run our PLC code on microcontrollers and computers.

I work mostly in Rust, and my colleague, Asterios, works mostly on the PLCs in ST, so this is a good fit for us.

I appreciate the effort you have put into this project, and would be interested in supporting and helping to improve it.

To get started, we have a few questions, mostly about the json description file:

1. When using multiple files in an ST project, do the dependency files only need to be put in the "files" section of the json file, or do they also need to be in the "libraries" section?
2. What are the meaning of the parameters (name, path, include_path, project) in the "libraries" section? The only information I have is from your examples, which are currently broken, and don't provide much detail.
3. How do we include libraries the StandardFunctions into our own project?
4. Does the {external} tag indicate a wrapper for a system C function? This is my guess, but any more information would be appreciated. Edit: This is mostly answered by your external function documentation.

Regards,
Andrew

[ghaith]

Hello Andrew,

Thank you for your interest in the project.
The build description file was added recently to make it easier to build full projects with multiple library dependencies.
It will eventually still change to make things clearer and easier, however, the main concept is that anything done in the build description can also be done using the normal rustyc command

When using multiple files in an ST project, do the dependency files only need to be put in the "files" section of the json file, or do they also need to be in the "libraries" section?

The files section of the JSON is where all the files to compile will go, these are typically your project source files, not the libraries.
ST files will by default have dependencies on everything that is defined in your project or libraries, you do not need to declare dependencies twice.
Also note that the "files" and "include_path" both support globs, so something like "src/*.st" should also work. We noticed, however, that it's not always consistent and we might include a way to include full directories without blobs at a later point.

What are the meaning of the parameters (name, path, include_path, project) in the "libraries" section?

• "name": The name of the library to be linked, this is then passed to the linker with the -l flag, so on a Linux, the library foo would be linked with the command -lfoo and the compiled name of such a library is usually libfoo.so
• "path": The path of where the compiled library exists (the .so file)
• "include_path": The files from the library that need to be included in the project (they will be treated as {external})
• "package": "Copy" if the library should be copied to the build location, or "System" if the library is available on the system and thus does not need to be copied.

How do we include libraries the StandardFunctions into our own project?

The library has to be compiled to your target arch, this for now will have to be a system with rust std support.
After that you can use the following in the libraries section:

{
    "name" : "iec61131std",
    "path" : "/path/to/lib/binaries",
    "package" : "System",
    "include_path" : [
        "/path/to/lib/include/*.st"
    ]
}

Does the {external} tag indicate a wrapper for a system C function? This is my guess, but any more information would be appreciated.

{external} instructs the compiler to only take the declaration part of a POU (ST element) into consideration. This is mainly used for interfacing with external functions (such as C) but also with libraries. In fact, when we include library paths, we include them as {external}.
For global variables, external marks the variable as external, thus being declared elsewhere.
Functions marked {external} don't have to be system functions, they only need to be linked correctly (-l passed to the linker).

Hope this was helpful.
Please don't hesitate to open issues/discussion points for new problems.

Regards,
Ghaith

[andyfozzy]

Hi Ghaith,

Thank you very much for your detailed reply. That is very helpful. I will be testing this, and intend to implement a basic microcontroller runtime in Rust. I will have to look at no_std support for this use case.

Regards,
Andrew