A Mock QCanBusDevice for TDD
I am using TDD to implement a hardware-independent mock QCanBusDevice. We can use MockCanBusDevice in unit, integration and acceptance tests – without access to a… Read More »A Mock QCanBusDevice for TDD
CAN
Introduction to the SAE J1939 Standard
In the early days of controller area networks (CAN), every device manufacturer interpreted CAN frames in its own proprietary way. When you changed the engine of a harvester from Volvo to MAN, you would have to reimplement the communication with the engine from scratch. Fendt tractors wouldn’t be able to communicate with John Deere implements and vice versa. The J1939 standard brought order into this Babylonian chaos and reduced the development efforts significantly.
Read More »Introduction to the SAE J1939 StandardMy talk “A Deep Dive into QtCanBus” at Qt World Summit 2019
The screenshot above shows the home screen of a sugar beet harvester. The home screen receives roughly 50 CAN messages per second and displays the contents of the CAN messages numerically or graphically.
Read More »My talk “A Deep Dive into QtCanBus” at Qt World Summit 2019Speaking CAN: Write Buffer Overflow
In the first post of the Speaking CAN series, we learned how the terminal sends a read-parameter request to the ECU and how the ECU sends a response with the value of the parameter back to the terminal. This works fine, as long as the terminal does not send too many requests too fast.
We set the size txqueuelen of the write or TX buffer to 10, which is the default for many Yocto-based Linux systems. If the terminal writes, say, 50 requests to the CAN bus without any pause, we’ll see several error messages No buffer space available in the log window of the terminal. The terminal caused an overflow of the write buffer in the CAN controller.
If we have a request-and-response scenario, the terminal can wait for the response, before it sends the next request. If the response does not arrive within a certain time, the terminal flags an error.
Avoiding a write buffer overflow becomes more difficult, if the terminal sends out messages without expecting a response or if the terminal expects a response only every, say, 200 messages (e.g., an acknowledgement how many messages the ECU has received). The solution is to configure the CAN controller of the terminal to receive its own messages.
Read More »Speaking CAN: Write Buffer OverflowSpeaking CAN: Request and Response
Controller Area Networks (CANs, for short) are used for the communication between electronic control units (ECUs) in cars, trucks, tractors, harvesters, construction machines, packaging lines and e-bikes. Qt provides the Qt CAN Bus API as part of its QtSerialBus module. Qt CAN Bus provides a clean and simple API to connect to a CAN bus, to send and receive CAN frames over the CAN bus.
When we build an HMI application to control a machine, we need a lot more functionality than the Qt CAN Bus API should offer. The HMI application must not send CAN frames too fast to avoid buffer overflows in the CAN controller. When the HMI application receives, say, more than 200 CAN frames per second and tries to display the changes, it will freeze. The HMI application must be able to recover from CAN bus errors. We do not want to write the code for serialising and deserialising thousands of CAN messages manually, but want to generate this code automatically.
I’ll show solutions to these problems in a loose series of blog posts called Speaking CAN. In this first post, I’ll explain how an HMI application running on a display computer retrieves the value of a parameter from an ECU. The terminal sends a request to the ECU over CAN and receives a response from the ECU over CAN.
Read More »Speaking CAN: Request and Response