Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: CAN project sanity check

  1. #1
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443

    CAN project sanity check

    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 .

  2. #2
    Junior Member
    Join Date
    Jan 2017
    Posts
    17
    Hello,

    Quote Originally Posted by Epyon View Post
    - Apparently there are multiple forks of FlexCAN. Which one would be preferred for a beginner (e.g. most documented or simple API)?
    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.

    Quote Originally Posted by Epyon View Post
    - I have some MCP2551 breakout boards lying around, these can be used with the T3.2 and appropriate library?
    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.

    Quote Originally Posted by Epyon View Post
    - 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?
    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.

    Quote Originally Posted by Epyon View Post
    - 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?
    Yes, the collin80 library allows handler functions and objects.

  3. #3
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    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.

  4. #4
    Junior Member
    Join Date
    Jan 2017
    Posts
    17
    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.

  5. #5
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    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)?

  6. #6
    Junior Member
    Join Date
    Jan 2017
    Posts
    17
    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 by Frank2; 10-15-2017 at 11:24 AM.

  7. #7
    Senior Member Epyon's Avatar
    Join Date
    Apr 2013
    Location
    Belgium
    Posts
    443
    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?

  8. #8
    Junior Member
    Join Date
    Jan 2017
    Posts
    17
    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.
    Last edited by Frank2; 10-16-2017 at 11:28 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •