SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino - Introduction

This post is part of a series about SAE J1939 ECU Programming & Vehicle Bus Simulation with Arduino.

It is important to know that neither the Arduino Uno nor the Arduino Mega 2560, even though perfect for prototyping due to low price and ease of programming, are not, in their bare form, an industrial-strength solution, not only in terms of environmental specs (e.g. temperature range, etc.) but also in regards to execution speed and, specifically with the Uno, memory resources.

For instance, when it comes to CAN Bus applications at 1 Mbit/sec and high data traffic, the Arduino Uno will reach its limits quickly. In addition, both versions, the Uno and the Mega 2560, are in their current form not suitable for a full CAN-to-USB gateway application due to speed restrictions of the on-board USB interface (See also next chapter).

The picture changes, however, when it comes to SAE J1939 applications, which require only a baud rate of 250 Kbit/sec. In all consequence, the Arduino Uno is well suited for SAE J1939 monitoring and simulation applications in regards to execution speed.

However, its limited memory resources, specifically the sparse 2k bytes of SRAM make it, unfortunately, impossible to implement and run a full-featured J1939 protocol stack. I will, nevertheless, present a solution (i.e. a limited version of the ARD1939 protocol stack) in the chapters to follow.

The problem is presented by the Transport Protocol (TP) according to SAE J1939/21, managing the transmission of data frames larger than the standard CAN Bus 8 byte format. The TP supports up to 1785 bytes per message, and you will need at least twice that buffer size, since the SAE specification demands that a J1939 control application (CA) supports two sessions (BAM Session and RTS/CTS Session) concurrently. Even with extensive code tweaking, for instance, running only one concurrent session, there is no solution that would get you around using these 1785 bytes, and the remaining 263 bytes are easily exhausted.

Nevertheless, the Arduino Uno is very well suited for an implementation with no or limited TP support. In the case of the ARD1939 protocol stack (which will be introduced in a later chapter) the maximum data frame length is limited to 256 bytes, which is still more than useful for mere test and simulation purposes.

When it comes to the mere monitoring of J1939 vehicle data traffic (which does not require a J1939 protocol stack implementation), the Arduino Uno is just as suitable as any other, high-powered processor system.

In order to support a full SAE J1939 protocol stack implementation, I used the Arduino Mega 2560 due to its close compatibility with the Arduino Uno, specifically the operating voltage of 5 V. It presents another low-cost solution but with significantly increased memory resources (8kB of SRAM instead of 2kB).

Other systems, such as the Arduino Due, provide better CPU performance with significantly increased memory resources at roughly the same price as the Mega 2560.

However, we are also entering the grey zone of Arduino Shield compatibility. According to the Arduino website (arduino.cc), the Due is compatible with all Arduino shields that work at 3.3V. The reality is that the vast majority of shields currently work at 5V. The official Arduino website is not a great help, either. It only states that the Mega 2560 is designed to be compatible with most shields designed for the Uno, in all consequence a very vague statement.

In my case it turned out that, initially, neither one of the two CAN Bus Shields (Seeed Studio and SK Pang) were recognized by the Mega 2560 (using the same software that runs on the Uno). The trouble with the Arduino Mega 2560 and the Seeed Studio CAN shield was due to an incompatible SPI interface pin assignment, which Seeed Studio corrected with newer versions.

In case of the Due, the problem lies in the 3.3V operating voltage, which prohibits the use of shields that run at 5V. In addition, the Due has actually its own dedicated CAN interface, theoretically eliminating the use of an additional CAN shield. However, at the time of this writing, there was no programming interface (code) available. To worsen the situation, the CAN interface lacks the necessary CAN transceiver, making it useless for any CAN application, unless you buy (or create) an external breakout board.

And yes, there are many more Arduino options with better performance and increased memory resources, but digging through all possible hardware designs and testing the most promising scenarios can be an expensive and time-consuming project.

In the chapters to follow I will present several variations on how to use the Arduino Uno and Arduino Mega 2560 for SAE J1939 applications:

• SAE J1939 Simulation and Monitoring Examples: These programming samples come with virtually no restriction in regards to their functionality, and, as long as the code samples are being kept within a reasonable range, there should be no technical problem in terms of memory size.
• Simple SAE J1939 to PC Gateway: This application will work on both versions, Uno and Mega2560, since it does not involve a protocol stack implementation on the Arduino. The application simply passes 29-Bit CAN messages between the Arduino and the PC.
• ARD1939 – Embedded J1939 Protocol Stack for Arduino: ARD1939 supports the full SAE J1939 protocol stack including the Address Claim Procedure (SAE J1939/81) and the Transport Protocol (TP, SAE J1939/21), however, in case of the Arduino Uno the maximum message length is (due to memory size problems as explained earlier) 256 bytes. The version for the Arduino Mega 2560 comes with no restrictions in regards to message lengths, i.e. it does support the standard of up to 1785 bytes per message.

SAE J1939 has become the accepted industry standard and the vehicle network technology of choice for off-highway machines in applications such as construction, material handling, and forestry machines. J1939 is a higher-layer protocol based on Controller Area Network (CAN). It provides serial data communications between microprocessor systems (also called Electronic Control Units - ECU) in any kind of heavy duty vehicles. The messages exchanged between these units can be data such as vehicle road speed, torque control message from the transmission to the engine, oil temperature, and many more.

A Comprehensible Guide to J1939 is the first work on J1939 besides the SAE J1939 standards collection. It provides profound information on the J1939 message format and network management combined with a high level of readability.

Read more...