Building Real-Time Firmware Around CAN

Controller integration in an existing controls environment.

PAL-K’s electric-truck controls environment used CAN communication among motor-control, vehicle-control, DC-DC, and logging contexts. My work focused on making the selected gateway-controller implementation function within that existing context.

From selection to controller behavior.

I helped select the STW ESX.4cs-gw gateway controller and wrote its application software in C/C++ using STW BIOS/C libraries. I used openSYDE and logi.CAD3 in the compilation, configuration, and deployment workflow, integrated CAN matrices, and worked with a PCAN/DB9/USB laptop diagnostic path.

Tasks, events, and shared state.

I created periodic and event-driven RTOS tasks. Incoming CAN messages triggered callbacks and events, while shared variables, flags, and inter-task communication kept the application’s operating-state model up to date. The software used that CAN-derived state to coordinate runtime control behavior and outbound communication with external controllers.

The high-voltage control work had sub-second response requirements. I worked within the controller’s proprietary real-time environment; the application work did not involve designing an RTOS scheduler.

The CAN configuration included 23 message-direction entries. A dedicated fourth CAN port fed a PC listener/parser for logging and a browser-facing status monitor.

Initialization required a deeper method.

The controller initialization was a major learning curve relative to my STM32 and ESP32 experience. I worked through topology configuration and generated platform support, then configured message reservation, pointers, RX/TX behavior, callbacks, DLC, RTR, identifiers, and data handling.

The normal system rate was 500 kbps. I also used a 125 kbps configurability test; later, an ARAI dynamometer environment operated at 250 kbps, making bitrate flexibility practically relevant. In the described lab setup, the Daimler VCU was unavailable, so a laptop generated VCU commands while I tested the communications path.

Documentation became a practical debugging tool.

This was my first substantial exposure to CAN. Working through an unfamiliar industrial controller and vendor toolchain showed me that embedded integration depends on understanding both the protocol and the configuration details around it. Each initialization step became easier to isolate once I understood how the topology, generated support, and controller settings fit together.