CAN project sanity check

Status
Not open for further replies.
Epyon

Epyon

Well-known member
For my next project, I'm trying to build I/O modules that are compatible with my home automation system which uses CAN bus. All modules have an 8 bit address. Input modules put messages on the bus when certain actions are performed (e.g. pushing a button). Output modules can be programmed to listen to the messages coming from the addresses of selected input modules and then perform an action (e.g. switching a relay). I'm focussing on creating an output module that has more outputs than the vendor currently offers. The protocol is described here. I'll be using a T3.2 for this.

Modules are assigned addresses and programmed through the CAN bus with a proprietary software tool. In a later stadium I want to emulate the program functions as well.

I have worked extensively with serial protocols, but this is my first time touching CAN. Searching the forum yielded in more questions than answers :( , so here's a small sanity check.
- Apparently there are multiple forks of FlexCAN. Which one would be preferred for a beginner (e.g. most documented or simple API)?
- I have some MCP2551 breakout boards lying around, these can be used with the T3.2 and appropriate library? The CAN bus of the home automation system is 12V and probably ISO 11898-3, because the system wiring can be made in bus, star, ring or combinations thereof. If not, any suggestions for transceivers?
- Can I use the Teensy and the CAN transceiver to (nonintrusive) snoop on traffic on the CAN bus in order to test/reverse engineer the HA protocol?
- Is CAN communication on the Teensy event driven, e.g. can I interrupt my program if a message on the CAN bus is detected or do I need to poll a buffer?

Many thanks for all guidance you can give me :) .
 
Hello,

Epyon said:
- Apparently there are multiple forks of FlexCAN. Which one would be preferred for a beginner (e.g. most documented or simple API)?
Click to expand...
Good question. :)
I'am currently using the version included in Teensyduino. It seems to be an older version of the collin80 fork of the library. The collin80 fork is already some versions ahead.
https://github.com/collin80/FlexCAN_Library
Together with this fork
https://github.com/ttlappalainen/FlexCAN_Library
it seems to be the newest fork of FlexCAN. As far as I know this two forks differ only in library internal buffer handling and locking, not in CAN settings in processor registers.

Both seem to address issues where it is important that the Teensy program gets messages in the order they have been received. This is needed to process some protocols. Some versions of FlexCAN seem to mix the order of messages, when using multiple receive mailboxes. If your protocol does only work with single messages or ordering by receive timestamp is an option, you may be able to ignore this differences.

Epyon said:
- I have some MCP2551 breakout boards lying around, these can be used with the T3.2 and appropriate library?
Click to expand...
Short answer: Yes, I am using some MCP2551 too.
Longer answer: There are some generations of this transceiver chips. The 2551 is an old part, there are newer ones, even in this series (MCP2561, MCP2562, ...). But if it's working, it should be ok. Please note that the MCP2551 works with 5 V, there are other chips with single 3,3V or 3,3 V logic and 5 V CAN power supply.

Epyon said:
- Can I use the Teensy and the CAN transceiver to (nonintrusive) snoop on traffic on the CAN bus in order to test/reverse engineer the HA protocol?
Click to expand...
Yes, if you don't send anything the rest of the bus does not care about an additional Teensy. I think the controller can even be set to some kind of "listen only mode", but I think that is more for safety reasons.

Epyon said:
- Is CAN communication on the Teensy event driven, e.g. can I interrupt my program if a message on the CAN bus is detected or do I need to poll a buffer?
Click to expand...
Yes, the collin80 library allows handler functions and objects.
 
Thanks a lot for the information! The concept of 'mailboxes' seems a bit strange to me. This would suggest the library already interprets the messages on the bus in some way, in stead of just relaying every bit on the bus to the main program loop.
 
Well, it's typical for CAN that already the hardware interprets and selects data.

Imagine a car where dozens of controllers share thousands of messages every second on the bus. Not every controller needs to read and understand all this data. A small chip controlling a lamp may be only interested in a single message, where a bit encodes 'lights on' or 'lights off'. So it is using hardware filtering to keep all the other useless stuff out.

The other extreme is some diagnostic interface, that wants to reprogram some kilobytes of flash in a controller via CAN. It has the problem that only eight bytes of data fit in a CAN message. For this reason things like this have been invented:
https://en.wikipedia.org/wiki/ISO_15765-2
This allows sending and receiving up to 4 kB with a stream of CAN messages. For this protocols it's a problem if the library messes up the order of the CAN messages.
 
I understand, but how does the hardware (or the library) know the format and size of the message? Afaik there isn't any global standard for this. E.g. my HA system probably uses its own proprietary message format, and as far as I can see the message (payload) size differs depending the amount of I/O channels each modules has. And what with colliding messages of different priority, where one overrules the other on the bus (which is one of the main advantages of CAN I thought)?
 
The format CAN frames itself is an ISO standard. There are CAN 2.0A and CAN 2.0B messages, with 11 or 29 Bit identifiers. (And CAN FD messages, but not on Teensy.) So the bit format on the line, including checksum, is fixed.

The identifiers and the data bytes are completely free for the application to use. They have no predefined meaning.

There have to be at least two nodes on the bus. If a node sends a message out, it gets an ACK from the other nodes. This does only mean that the hardware has seen the message, not that any other node did something with the data within the message.

If a node wants to send a message, the hardware wait first the bus to be quite for some time. Then it starts sending, with reading on the bus what's there on the line. The "0" bit is stronger than the 1 (= dominant), so if the hardware is writing a "1" but reading a "0" it knows that there is a collision, it stops sending and tries again after some time. The others on the bus don't see this, because they see only the dominant signal.
 
Last edited:
Okay thanks. I was under the impression that the CAN standard only described the physical media access, like the serial RS standards I'm used to, but apparently it also describes the data link.

I've ordered the parts and will update my progress. One more thing though. The HA system bus runs at a rather odd 16.666 kbit/s. I can just set this baud rate on a T3.2 with an MCP2551?
 
I have no experience with this slow baudrates on real CAN busses. Only with 125000 and above.

Maybe you wil have to test different libraries, I'm not shure if anybody tested the baudrate calculation for this speed.

Edit: But 16 MHz / 960 = 16666 so this Baudrate seems to be possible, when I look at this on the collin80 page
Supported baud rates are 50000, 100000, 125000, 250000, 500000, and 1000000 bits per second. If the baud rate is not specified it will default to 250000. Other baud rates are possible but care should be taken to ensure that the desired baud rate is possible. The CAN clock is 16MHz so it must be possible to take 16MHz and divide it evenly.
Click to expand...
 
Last edited:
Thx that's nice CAN Transceiver (i like the mounting idea) but unfortunately for ISO 11898-2 High-Speed/FD CAN/LIN. Did you try on ISO 11989-3 Fault-Tolerant Low-Speed CAN and how/which pull-up resistors did you use to make it work? Could you transmit too or receive only?

That would fullfil my needs already, but of course only AMIS-41682 and TJA1055 can handle fault-tolerant single wire mode (not required in my case)

this is the one buyed (rare) but it is quite expensive compared to other products because it is hand soldered prototype
https://www.ebay.com/sch/i.html?_nkw=tja1055+breakout+board
 
Status
Not open for further replies.
Back
Top