Skip to main content
FW version: Stable

Communication stack

communications

Supported communication interfaces​

Each YOS device supports multiple communication intefaces, allowing to connect various peripherals, such as display, sensors, BMS or another controller. All of these interfaces can be also used for controller setting, state monitoring and firmware update over internet. Communication was designed specifically for hard real-time system needs, with minimal latency and perfect synchronization of multiple controllers in one system. Another focus is the pursuit of abstraction from the used physical layer. Commonly, we support these communication interfaces:

  • SWD
  • USB
  • Bluetooth
  • UDP/IP
  • UART (up to 4x)
  • CAN Bus (up to 2x)
  • LIN Bus (up to 2x)

Device address​

Each device has its own address. This address is common for all communication interfaces - it is a logicalm link-level address of device, not address of communication interface. By default, address of each device is set to 0, it can be changed by command setaddr. Change of address takes place after reboot.

info

Address, as well as interface and protocol configuration (managed through 'msgconf' and 'protoconf') are held in a dedicated, non-volatile storage that is persistent throughout firmware flashing.

Message properties​

Message is basic communication block. Communication from all interfaces is translated to standardized format of message with following segments (some segments are optional):

  • Length
  • Sender address (for unicast and multicast messages)
  • Receiver address (for unicast and hidecast messages)
  • Service ID (SID)
  • Flags, message type
  • Payload

Service protocol​

The system provides a proprietary service protocol to interact with the device. This protocol has been designed for low-latency, connection-less reliable data probing, configuring and upgrading in-application. It comprises a series of processes operating within the device, which are by default connected to all communication interfaces. However, these can be deactivated or substituted on specific interfaces upon request. This suite of services enables users to adjust settings, perform debugging, or update the firmware. The service protocol operates independently of the interface, allowing it to be connected to multiple communication interfaces at the same time. It does not depend on any item description files or object definitions. Instead, the device-specific data model is dynamically loaded from the device during runtime.

The following services run inside the YOS device (as a part of the service protocol):

  • PWR (power) controls the device's power state. It can power on, power off or restart the device. It also controls debugging output. It is used by term, emGUI, yosctl and bl_srm.
  • FWD (forward) forwards messages from one interface to another. It allows communication between devices that are not directly connected. Used by the msg_fwd interface driver.
  • ID (identification) transfers device metadata (HWID, SWID, UUID ...). Used by auth, emGUI, yosctl and bl_srm.
  • BL (bootloader) reads, erases, writes and configures firmware, used by bl_srm.
  • FS (filesystem) filesystem transfer, used by emGUI and yosctl.
  • RPC (remote procedure call) executing commands in the device, used by emGUI and yosctl.
  • STREAM (ASCII environment) default standard input/output streaming, used by term.
  • PLOT (real-time data sampling) data transfer for real-time viewing and logging state variables, used by the scope.

Process (application) protocol​

Process communication protocol is another set of running services in the YOS device. It is used for sending device's internal state variables (such as motor voltages, currents or control inputs) out via desired communication interfaces. It can be also used for setting parameters and sending commands for the process control during device normal operation. This feature is optional and can be turned on / off on request; in most firmware branches is turned off by default.

Process protocol is application specific. Nevertheless, siliXcon usually implements set of services that standardizes the following:

  • Driver block : Driver internal states (such as voltages, currents or speed) can be send out from YOS device. Parameters and commands can be issued.
  • Common I/O block : states of control inputs and outputs (such as throttle, brake or buttons) can be send out of YOS device. Parameters and commands can be issued.
info

Custom services can be added to a custom release upon request (ModBus, ModBus/TCP, OBD/OBDII, CANOpen, Can Aerospace, DeviceNET ...) Whole process communication protocol is described in detail in corresponding utility/driver manual.