Building ST for microcontrollers

[andyfozzy]

Hello again,

I am trying to build a basic PLC runtime for a microcontroller. However, I get an error when I try using rustyc with the appropriate target. I run this command on a really simple function with no dependencies:
rustyc test.st --target thumbv7em-none-eabihf
and get:
Error: GeneralError { message: "linker not available for target platform: unknown", err_no: linker__generic_error }
If I don't specify a target, it builds and runs fine on my host computer.
I don't know if I am missing a package, or whether this is a bug in ruSTy.

Also, to run ST code on a microcontroller, I will need the Standard Functions to support no_std. I am happy to work on this myself, but if you have any comments or information that would help with this, I would appreciate it.

Andrew

[ghaith]

Hello Andrew,

Regarding the linker, the embedded linker is currently hardcoded for linux, the reason is simply that a quick test for other archs (windows) didn't work right away, and we didn't test it further. You can try to enable it for the different platforms to experiment with it.
If it works, I'd be happy to merge a PR enabling more archs. The code should be in linker.rs
That being said, you don't actually need the embedded linker to work for your target, you can change it to clang or a GCC cross compiler with the --linker flag like this rustyc test.st --target XXX --linker=clang-13

Regarding the standard functions, I would also like the standard functions to support no_std, but we haven't gotten to that yet.
A (WIP) branch on the StandardFunctions adds some STRING function, which also changes the string conversion functions not to allocate.
I think the current blocker is the date time conversion functions and the Counters/Timers. For the date time conversion, we use the rust date structures and these require alloca, I assume these should be re-implemented or an alloca should simply be provided. For the counters/timers, it gets more complicated, we need some type of clock in order to accurately measure elapsed time. My guess is we could abstract that and then a no_std version could be implemented differently for each platform based on a tick and the clock speed of that device.

If you are willing to work on that, we could open up an issue on the StandardFunctions repo where we could set a plan to move to no_std
Roughly it would be something like this:

• Create a no_std feature
• Move std_only code to an std folder in the iec61131 st files collection
• Progressively implement the functions in no_std and move them over

Hope this helps
Ghaith

[andyfozzy]

Hi Ghaith,

Thanks for the information. That looks like a good start.

Regards,
Andrew