Ran the old SSM2 benchmark code on a Euro4 diesel ECU again. This time I included 10,400 baud mode as our library already supports this. (We do CAN/ISO15765 high speed mostly so serial stuff is low priority, no continous mode aka “fast poll” support yet.)
Interface device: Tactrix Openport 2.0, drivers installed by EcuFlash 1.43.3252 Beta (2011-04-10).
Same single SSM2 A8 request message as in 2010-Nov test.
|Protocol||Baudrate [bit/s]||Count||Samplerate [1/s]||P1_MAX [J2534 value]||P1_MAX [ms]|
|SSM2 via Serial||4,800||313||5.22||61||3|
|SSM2 via CAN||500,000||6001||100.02|
1) Tested lowest value to get stable fully correct receive messages.
According to this result, 10,400 baud mode is hardly worth the effort, just 108% speed. Theoretically it should be roughly twice as fast vs. 4,800 baud.
My guess is, the ECU software has not really been designed for higher serial speeds. Not sure why the switch method exists, could be leftover code. It is not uncommon for dead code getting included in software builds. As far as the ECU’s CPU is concerned, serial communication involves more code and overall complexity than CAN. Subroutines responsible for transmitting serial bytes might not be called at a frequent enough interval to cope with higher speeds. I’ve also had to increase P1_MAX (J2534 spec inter-byte timeout) in order to receive correct responses at all times.
There’s a very slight CAN speed improvement compared to 2010-Nov test result. Probably due to J2534 driver improvements.