Introduction
These articles are about the default Firmware loaded on VEKTOR Core boards and usable with them. The firmware is build using a real time operating system (RTOS) and contains time-critical components and drivers.
Overview
Configuration
The MCU is downclocked to 256MHz in order to obtain a stable and mathematically easy to divide base clock for critically timed software components. Internal timers are clocked at 64MHz.
With these settings the idle powerconsumption is about 250mA.
Versions
Versioning is done with the X.Y.Zc scheme (Major.Minor.Fix.Channel).
E.g. "1.3.4a" stands for Major: 1, Minor: 3, Fix: 4, Channel: alpha.
Minor versions tend to maintain compatibility (addresses, peripherials), while major versions may break these. Alpha and Beta versions are for evaluation only.
Updates
The new firmware in its whole comprises the Bootloader, RTOS, Drivers and Program logic. Firmware updates may require the update of companion software as well.
Flashing
Firmware flashing is performed using either USV Studio or the ST PRG application. Typically, updating the firmware does not affect the configuration data stored in the EEPROM. If an update does impact this data, it will be clearly indicated on the firmware download page.
Control Logic
MODBUS interface
The main communication/configuration towards and from VEKTOR Core is done via MODBUS Remote Terminal Unit.
As standard in industrial applications, the firmware exposes all functions onto a virtual memory array, starting from address 0 to 3000.
Implemented is the standardized data transmission protocol MODBUS. By default the VEKTOR Core will act as server when communicating through the USB-C Port or the RaspberryPi interface. It will act as client when accessing the RS485 port. Both modes are configurable tho.
When accessing the VEKTOR Core as server, the user is allowed write to certain addresses and only read others. From a purely technical point of view it is possible to also write readonly addresses but these actions will have no effect.
| Port | Protocol | MODBUS Role | Functions |
| USB-C * | CDC | Server | 03,06,16,23 |
| USART1 | RS232 | Server | 03,06,16,23 |
| USART4 | RS232 | Server | 03,06,16,23 |
| USART2 | RS485 | Client | All |
* The USB-C should not be used in production environments. Its use is limited to configuration and diagnostic tasks only.
Generally we keep boolean (Coil) logic as part of Holding registers. All used registers are holding registers.
Similar and related values are kept in contiguous registers.
We offer a wide range of solutions to pass MODBUS communication through various channels like 4G, LoRa etc. For high latency channels like SATCOM, specific adaptations exist.
Customization
Through setting specific registers it possible to reassign the USART1 and USART2 ports to other functions or make them MODBUS Clients.
E.g. in redundant configurations it is possible to make the RS485 listen to the heartbeat of the primary controller as Server, should the heartbeat be lost it will automatically reboot in Client mode and take over the RS485 wire harness of sensors and modules.
The function of the USB-C CDC port is not reassignable and will always act as Server.