MS-II CANbus protocol?

[karlo]

I've been looking at the CAN support in MS-II. Is the current protocol proprietary, or is it based on a standard? I couldn't find anything else that quite resembles it.

I've been looking at controlling a Holset VGT turbo with the MS-II. It talks J1939, which doesn't seem very hard to implement, provided there aren't hardware differences, but it doesn't seem like it. However, it seems worthwhile to understand the current code and what the plans are with it. Are there reasons why J1939 should not be implemented?

[grippo]

There is a format for CAN from the CAN protocal that specifies what the bits are for and how they can be used on a general level. Everyone uses that because it is built into the hardware. On top of that there are all sorts of protocols that can be used. Bruce and I made up the one in the code because we don't want a general purpose protocol because that necessarily means it has stuff in it that isn't needed, and we want the highest possible speed out of it, and we are using a limited processor, not a GHz PPC.

If you want to communicate with MS II then you have to give it a message in the format specified in the code and you will only get back a message in the same format - unless you want to change the code. You are free to change the code however you want, and to develop whatever applications you want for it - in fact we encourage this. What you are not free to do is build your own hardware, put the code in that, and sell it. But if it's for your own use, have at it.

There are many examples in both the MS2 code and GPIO code. The sequencer code talks to a second processor thru CAN and there are even more examples there, although this hasn't been publically released yet. Once the registers are set up all you have to do is set the required variables in the ring buffer and call send_can(). If you use the existing interrupt subroutines in the code, you will automaticall receive data that will automatically be put wherever you want in a table or structure that you can set up on your end.

[karlo]

Sounds good.

I'll need documents on the Delphi Smart Remote Actuators (http://delphi.com/manufacturers/auto/po ... /smartrem/) before it makes sense to start. Should anyone be in possession of these, please let me know.

[joelotz]

Good question!

Sorry I'm a bit slow, but I want to verify what I understand your answer to be... There currently are some SPN/PGN messages hardcoded into the code for the specific functions that you currently use. You don't have a general purpose table full of unused messages because you wanted to keep the processor at optimal speed.

Is this correct?

Also, do you have any documentation regarding the current J1939 messages and expected results or simple look through the code as suggested?

We are thinking about building our own CAN-based I/O board and are just researching what we are up against!

Thanks in advance!

[grippo]

I think I have 3 bits set aside for message type, so there can only be 8 message types. However, one is reserved for meaning "this isn't a particular message type, but the real message type is in the first byte of the 8 data bytes", so you can now get 255 message types if you want. And message type is meant to be very generic. In all my experience with serial comms, 99% of the time you either want to tell the recieving device to put data somewhere or to ask that it send you back data. The data source/ depository is specified by a table/structure/ or block number and a byte offset. But that is my experience. You could have a system where you just wanted to tell a device to do things, lots of different things, and you could possibly put the numerical list right in the header and never have to send any data bytes. And there are many other possibilities. But I have tried to make the protocol as generic as possible, given the constraints of the CAN message size. By that I mean I wanted to minimize the probability of people having to add or change the code to handle the message. For example, I believe someone could build a turbo controller without having to change a single line of code. It can get the data it needs from the existing input and output block and it can send back variables that will be added/ multiplied to the normally calculated fuel and spark. It can control wastegates and N2O from it's own output pins. The GPIO board is similar and makes full use of all pins on it's processor. You could start with this and you would have hardware ready to go, and also have the code you need to talk to the ECU - you could just get rid of the parts you didn't want and wouldn't have to really understand CAN. If I had this I would never have looked at a CAN book, I would have focused on what I wanted to do after CAN was in place.

I never read J1939, we developed the protocol based on our own experience. It is work to go through the code, but it is very doable.