CODESYS on an ARM board: the runtime is the missing piece

What a CODESYS target actually needs

Trace one application from the engineering PC to a field signal and count the steps:

1. The development system on the PC compiles the IEC application.
2. The download crosses the link to the target device, typically an Ethernet link of 100 Mbit/s or a serial link at 115200 baud.
3. The runtime on the target loads and executes the application cyclically, for example on a 10 ms task interval.
4. The runtime reaches physical I/O through a driver: a standard fieldbus driver, or one you write.

On a board running a generic Linux or Windows CE image the chain stops at step 2. Nothing on the target answers the download because no runtime exists there. Support for an ARM core in the ecosystem is a statement about what can be ported; the core and the OS are necessary conditions, and the runtime is what turns the board into an IEC 61131-3 controller.

The development system installs free of charge. The runtime is the licensed, engineered side, and it is where your decision lives.

The three parameters and the link that define a port

A runtime is adapted to three things, plus the link your login travels over. Read every value from the board documentation before you contact anyone about a toolkit:

Every row needs a written value. An empty memory or link row leaves the port scope undefined, and no vendor can quote against it.

How the runtime gets onto the board

The vehicle is the CODESYS Runtime Toolkit, licensed as a buyout. The purchase brings the documentation and the SDK, and you implement and adapt the runtime to your hardware together with the vendor. Work in this order:

1. Agree the target in writing: core, operating system, memory.
2. Build the runtime against the board's support package or cross toolchain.
3. Install it and start it as a process or service that comes back on its own after power-up.
4. Log in from the development system and download an empty application.

Until the login works, stay at the communication layer: a failed login is a link fault, not an I/O fault. The toolkit line moves with the ecosystem, and the maintained runtime products track it release for release.

How I/O reaches the application

The runtime knows nothing about which pin is a digital input. Binding signals to the application happens in a driver, and there are two routes:

• Standard fieldbus drivers. CAN, EtherCAT and Modbus are the named routes for external I/O. You configure them in the development system; the board needs a working interface for the chosen bus in its OS.
• Your own driver. For the board's own pins and on-board peripherals, you write the driver in IEC code or C/C++, and the toolkit engagement covers how.

For one-off client projects, take external I/O over a standard bus so the driver work stays in configuration. A hand-written driver is worth the engineering only when the signals live on the board's own pins. What the application then drives on the floor, and where a small screen fits beside it, is its own decision; the andon board guide covers the screen side.

Worked example: an ARM920T board with Linux on the datasheet

Inputs. CPU core: ARM920T, printed on the board datasheet. Operating system: Linux, one of two OS options the support package offers; Windows CE is the other. Memory: the datasheet RAM table shows 64 MB RAM and 128 MB flash, illustrative figures you substitute with your board's printed values, then compare against the runtime footprint in the toolkit documentation. Link: 100 Mbit/s Ethernet per the support package driver list.

Rule. An application executes on the target only when all four chain steps close, and a runtime exists per CPU, OS and memory combination. Datasheet support for a core and an OS states feasibility, so a port conversation needs all three parameters in writing.

Arithmetic. Chain steps closed today: step 1 closes on the PC, so 1 of 4 steps. Steps 2 to 4 have no runtime to receive them, so 3 of 4 are blocked. Port parameters in writing: core and OS, 2 of 3; the memory row is filled by the 64 MB RAM figure, so all 3 rows are quotable once confirmed against the printed tables. A 10 ms cyclic task on this core class is the sort of interval you then prove with a load sweep, not assume.

Result. The board executes no IEC 61131-3 application as it ships, because 3 of the 4 chain steps have nothing to receive them. With the memory row written down, the port specification is complete enough to quote.

Decision. Ask the runtime vendor one question first: does a runtime exist for this core and OS at this memory size? A yes, and you buy the runtime license and skip the toolkit. A no leaves two paths, and the threshold is the board's role: if the board itself is the product, commission the Runtime Toolkit port and put the memory row into the quote; if the projects are a handful of one-off builds, the shipped-runtime platform wins, because the port effort spread over a few jobs costs more per job than ready hardware.

Your options, compared

When to pick something else

Take the port only when the board earns it: unit cost at volume, a form factor nothing else matches, or boards you have already built and stocked. A port is a project with its own schedule; spread across a handful of one-off client builds, it loses to ready hardware once the engineering time is priced in.

Pick CODESYS Virtual Control SL when the application should consolidate onto plant IT hardware, scale with the load, or run in several instances on one host; the vendor documents it for any architecture, in a container or under a hypervisor.

What to ask for

For a port quote: the core, the operating system image you will target, memory from the RAM and flash tables, the link (Ethernet or serial), the fieldbus your field devices speak, and the toolkit build to target. Current release notes name the line: Control for Linux ARM SL 4.11.0.0 already carried toolkit V3.5 SP19 Patch 6, so ask for that build or newer. For a shipped-runtime platform: which runtime product and license the device ships with, and the exact OS image it requires; even evaluation boards the vendor has already ported bind to a specific default OS image, and the vendor's porting documentation spells it out.

If the same quote needs an operator-facing status screen beside the controller, that is a shop-floor display decision, sized by viewing distance and text height.

Prove the chain end to end

Work down the list; each step gates the next:

1. Power-cycle the board and confirm the runtime starts without manual intervention.
2. Log in from the development system. When a step hangs, check whether the runtime is running or stopped before touching anything else.
3. Download a program with one cyclic task on a 10 ms interval and a counter, run it, and watch the counter increment online. That closes the execution question.
4. Force one output and measure the terminal with a meter; apply a known level, for example 24 V DC on a digital input, and read the same value in the online view.
5. Pull the link cable and reconnect. The runtime keeps running and the login returns.
6. Once the application is real, find the runtime's actual cycle-time limit with a load sweep. If the board freezes mid-sweep, capture logs on the device before you reboot.

Recommendation: Treat a datasheet that lists an ARM core and an operating system as a porting feasibility, not as a CODESYS target. Ask the runtime vendor whether a runtime already exists for your core, OS and memory; a yes costs a runtime license and no port. A no sends the board down the Runtime Toolkit route only when the board itself is the product. For one-off client projects, buy hardware that already ships with a runtime, take external I/O over a standard fieldbus, and keep the custom board for the jobs only it can do.

Questions