CAN bus and ISO 15765-2 transport layer

I am currently working on a simple home automation system. I would like to use CAN bus, as medium connecting different nodes and sensors. In my opinion it is more reliable than Ethernet - it is only a portion of twisted copper wire, no additional infrastructure (switches, routers etc) is needed. Unfortunately CAN have a one flaw (that can be seen as advantage in other circumstances) - it only allows 8 bytes of data per single frame. I would like to use AT commands, so I need to send and receive ASCII strings, usually larger than 8 bytes.

Another words. I need some kind of transport layer, that handle communication between nodes slicing message to many frames and merging them together on the other side of cable. I found description of ISO 15765-2 protocol (also known as ISO-TP). It looks quite interesting. Unfortunately I do not feel up to the task of implementing it myself. I found one C library: https://github.com/openxc/isotp-c

Unfortunately - description leaves no doubt. This version do not yet support multiframe meaasges. :(

Is there any hope for sending longer messages that 8 bytes? It is hard to imagine, that there is no solution for that, although Arduino CAN Shields are quite easy to find.

I am at basically the same point as you, but attempting to be compatible with commercial CAN devices. The common options seem to be DeviceNet (closed, expensive) and CANopen (open, free, not as widely used).

Anyway if you get a copy of the CANopen specification, it contains protocol descriptions for shifting bulk data using multiple frames. It (the multi-packet transfer) is a pretty simple protocol in the grand scheme of things. If you didn't want to implement all of CANopen, you could well just steal that little bit.

The 8 byte limit and the 29 bit limit on message IDs are what made me want to move away from CAN.

I think the 8 byte limit is intentional, because large messages would clog the bus which is.bad when your anti-lock brake system needs to get through.

But for home automation, you might care about reliabilty and want your messages to always get through, but usually you don't care if it takes a little extra time.

The simplest scheme I have seen for sending long messages is to send them as a one byte sequence number and a 7 byte payload. Send the first seven bytes with sequence number 0, send the next 7 with sequence number 1, and then signal the end of the message. Signal the end with a message containing only the sequence number and no data. On the receiving side make sure all the sequence numbers incremented in the correct order.

You could have a message with a higher priority that meant "rewind to position X", which could also double as a request for the whole thing by rewinding to position 0. On the sending side, basically send messages while message counter is less than its final value and rewind when asked.

This kind of thing is hard in CAN because message acknowledgement is low level and doesn't really have a concept of a dropped message, and each message has a fair bit of overhead. CAN is extremely reliable, but you have to make sure whatever you stack on top of it is reliable.

Don't forget you have the option to define your own protocol on top of RS485 or even using CAN transceivers instead of using CAN.