Hello John,

if it's just about the standards hierarchy, I can help.

1.SAE J1939 is on top. Truck and Construction Equipment usage, although
US Trucks are mainly J1587 (RS485) with J1708 protocol.
1.1 SAEJ1939 defines its own transport protocol to transmit a PGN longer
than 8Bytes.
1.2 Additionally ISO15765 aka "KWP2000 over CAN" defines another
transport protocol closely linked to KWP2000(ISO 14230) or the newer
UDS(ISO14229).
It is basically a wrapper for half-duplex serial communication over CAN.

2.NMEA2000 is the marine adaption of J1939, agriculture equipment often
uses NMEA2000 GPS devices.
2.1 NMEA2000 FAST Packet is another transport protocol for >8Byte
messages. I believe that's what you encountered on the boat. I don't
know the details.

3.ISOBUS(ISO 11783) is the agriculture adaption of J1939
3.1 Since the devices of the agriculture equipment can be used in
multiple combinations, ISOBUS has mechanisms to register new devices to
the CAN bus and so on. AFAIK there is no additional transport protocol.

Regards,
Patrick


Am 05.11.2015 um 19:08 schrieb John Whitmore:
> Newbie here so this could go to kernel newbies mailing list but it is Can
> Related so here goes.
>
> I'm coming at this from the restricted bubble of microcontrollers, but just so
> you know what that produced...
>
> I have a low level library of code which handles all Can frames (I keep
> wanting to say Layer 2 but it's probably not) on my single Can
> Interface. Basically it is a dispatcher which handles all the frames. So the
> main loop of my embedded microcontroller reads a frame and dispatches it.
>
> "Application" code then just registers a handler something like
>
> register_handler(filter, handler_function)
>
> It's fairly basic but it works for me. I'm working on my own networks so don't
> have to worry about the rest of the world. And I was only using 8 Byte
> messages. All my different nodes are basically the low level dispatcher which
> is alway the same and specific handler registrations.
>
> I then started using longer messages (I keep wanting to say Layer 3 but it's
> probably not) and I got lost in a world of F'n standards. I had thought that
> j1939 was for lorries in the US or something. I Ended up going with ISO-15765
> to send longer messages. Because of the way I did my frames I ended up doing
> the same with this protocol:
>
> register_iso15765_handler(filter, iso15765_handler_function)
>
> I have to enable a switch at build time and if ISO-15765 is enabled a frame
> handler is registered:
>
> register_handler(iso15765_frame_filter, iso15765_dispatch_function)
>
> The iso15765 dispatcher now just receives all frames which is assembles into
> messages and dispatches them to interested parties.
> That all worked for what I was trying to do which was reflash units across the
> CanBus network. As a result of that application my Messages are Flash Row
> sized.
>
> As I could now send long messages with ISO-15765 I had a dedicated unit on my
> Can Bus network which acted as a "logger" for the whole bus. Any node that had
> something to log just sent an ISO-15765 message.
>
> We're now getting to Linux as the RaspberryPi came along. I had a CanBus
> logger using ISO-15765 but the unit was a microcontroller which just fired it
> over RS232 to a minicom log running on a laptop. The RaspberryPi had a File
> System!!! 
>
> Because I already had a logger which basically was a call to:
>
> register_iso15765_handler(filter, iso15765_handler_function)
>
> I used SocketCan in RAW mode to grab all frames and ported my frame
> dispatcher. So my ISO-15765 dispatcher which simply registered a frame handler
> is the same code on microcontroller and Linux (RPi) And my CanBus Network
> Logger is similar code as well. In the case of RPi it writes the logging
> messages to the File System, not to RS232.
>
>
> I was happy with Can Frames and ISO-15765 when somebody asked me to do some
> work on a boat. That's NMEA2000 and found that that is based on ISO-11783. Man
> there are too many protocols! ISO-11783 don't encode the length of the message
> :-( And it has a function based addressing scheme :-( AND an extended 29 Bit
> Can Frame can ONLY be either ISO-15765 or ISO-11783 :-(
>
> I can't remember the CAN ID pattern but there are two bits in the extended can
> frame which dictate either ISO-15765 or ISO-11783.
>
> Given the path I've taken I've sort of implemented ISO-11783 the same
> way as I have ISO-15765. So now my microcontroller "Applications" can:
>
> register_handler(iso15765_filter, handler_function)
> register_iso15765_handler(iso15765_filter, iso15765_handler_function)
> register_iso11783_handler(iso11783_filter, iso11783_handler_function)
>
> Only standard 11 bit can ID frames can use the first registration but all my
> nodes use Standard frames for sending data around the network. 8 Bytes is huge
> in my microcontroller world.
>
> I'm not very well versed in Linux but what I've done seems wrong in this
> environment. I mean if I was running my Can Bus Logger and another higher
> layer application I'd have two SocketCan connections with 2 Can Frame
> dispatchers and 2 ISO-15765 dispatchers and 2 ISO-11783 dispatchers. Obviously
> totally wrong.
>
> The advantage from my end is that I can run the same code on microcontrollers
> as RPi. So even if it's wrong it sort of works for me.
>
>
> The only reason I wrote all this is because of the recent discussion on
> J1939. I've never read that standard but my understanding is that I can't use
> that for NMEA2000 data on a boat as NMEA defines their own PGN codes and
> messages. I'm looking at them in the canboat project on github.
>
> I should actually look at the Linux-j1939 API and work through that with a cup
> of tea. I've only really looked at http://elinux.org/J1939 and given my
> limited and restricted background it feels wrong:
>
> ip link set can0 j1939 on
>
> Obviously my arch is wrong in Linux but a Can Bus is a transport network. Same
> as TCP/IP it can transport anything all at the same time. (magic)
>
> I should duck my head back down ;-)
>
>
> John
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html