So i have done some research on the two protocols. I was leaning towards I2C but i am afraid that the distance between my peripherals and the master might become a problem during final implementation.

What i am working on is a all inclusive electric drive system for a sail boat. I will have one master unit and two slaves. Mater unit will do the data processing and out put data to peripherals and to a nextion screen. One slave device will be a throttle and direction control. The third unit will be the motor controller. Both slave devices will need bi directional communication. The distance between the master and throttle should be minimal, maybe 3-6 feet depending on how the cable has to be run. The motor control unit could be upwards of 15 to 20 feet as the cable lies.

So i know I2C can have difficulties reaching further distances. I want something that is rock solid and don't have to worry about miscommunication issues. Which leads me to CAN bus.

What i am tiring to figure out is the overall communication scheme of CAN bus, read the wiki and a bunch of other info. My brain is kinda swimming at the moment.

So this is what i see happening, let me know if this should work. Basically i will have constant data being sent from the motor controller to the master unit, motor rpm, temp, and maybe a few other variables. the throttle unit will be mostly idle unless there is a change in the direction or speed control. my concern is that with a constant stream of data coming from the motor controller. Is it possible to set priorities and am i going to have to worry about data over laps? Sorry right now i am just imagining this as a old school phone party line and everyone is yelling out info.

So here is my questions. Is CAN bus the best networking application for this? Can i set priorities in communication, or do i even need to worry about this?

Or am i thinking about this all backwards in the fact that the unit that need information has to request it. so rather than the throttle control unit sending info when it has change throttle position for example, the main control unit has to request data to see if the position has changed?

Is there a Good place to learn more about actually using CAN bus verse how it works?

hi Tyler, you have a lot wrapped up in your posting - I can't begin to try to respond to it all... But here's a few thoughts -

I think CAN is certainly a viable solution. From your description, you probably will not use a lot of bandwidth, so CAN is fine there. A simple twisted pair is usually fine for speeds up to 500 Kb/s, and perhaps even 1Mb/s if the run is short.

NMEA 2000 is a protocol that might be of interest to you. I know of it, but have not worked with it. And since NMEA is short for National Marine Electronics Associations, you can see the alignment to your needs. You can purchase a copy of the standard, but you won't find it freely available (like many of the other possible CAN protocols).

You have likely learned that a CAN message has an identifier, and up to 8-bytes of data (ignoring some of the other bits in the stream). It is essential that no two nodes send the exact same identifier, or they can't tell one from the other and it is about the only way in which nodes "collide" and the data is lost. The data is quite limited to help minimize the "blocking time" that would prevent a higher priority message from being sent.

CAN arbitrates non-destructively - so while it is a party-line, the arbitration ensures that the highest priority packet is delivered successfully, and the lesser priority messages automatically pause until the network is idle and then they try again. With a true party-line, the rate of collisions increases so rapidly that some argue you cannot load the channel more than about 30%. With the arbitration of CAN, you can achieve throughput at about 100% bus load (the lowest priority messages may never be sent in such a situation).

There are many protocols that use CAN, aside from the mentioned NMEA I'm familiar with SAE J1939. In brief, the identifier is 29-bits (11-bits is an alternate). Of those 29-bits they are, by protocol definition, broken down into priority[3], pgn[18], source[8].

The pgn - parameter group number, is a way of saying "message identifier". So, even if not using J1939, the concept remains - each node has a unique address (thus ensuring no 2 or more nodes send the exact same identifier), and you could define various "pgn's" for the types of information you want to send.

If you need to send more than 8-bytes, you can either define new messages for fragments of the data, or you could "serialize" a big blob using a single identifier, typically by embedding a sequence number in each packet (and the remaining bytes in the packet have the data).

Request v. Broadcast - it is not uncommon on many systems that some data is sent periodically - simply broadcast to the network. Other information does not need to be sent like that, so is on-request only.

For a multi-master, each node my periodically broadcast important data. For a master-slave network, the master node might request/command each slave in turn to send their information. Both are viable - some perhaps more suited depending on the system of interest.

A good place to learn about CAN - there are many tutorials, some on the mbed site and many scattered about the web.

Thank you so much for the reply.

Last night i found a document written by Texas Instruments that filled in a lot of the holes in my understanding, which was most of what you covered. I really like the idea of being able to set priorities. Though i was wondering can i set different message priorities for types of messages from a particular device. For example from my motor control unit can i send a low priority, motor speed value, but if there was a fault issue over load or something of the sort the priority could be the highest so that it would pass to the main unit and get addressed.

I think your right that it will fit with my needs, since most of my information will be limited to simple numeric values. I just need to do some more research on passing variables. i like your idea about sending a sequence number, which i could use to validate a full message/ make sure all the info has been received or reject the data in the case that something in between was missed.

One question about protocols, where is the protocol actually stored/ used. Is it on the mbed/ arduino, or is it on the transceiver.

More research to ensue.

Thanks again!

Found some good info.

http://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en558265.pdf

coming from a long background in the IT world, i would also recommend using TCP & ethernet. it would be no issue whatsoever with noise, distances, etc. the hardware, cabling, switches etc are plentiful, reliable and cheap.

WiFi would also be an option but no where near as reliable. CAN will surely work, but will require much more work on your part. but the education you get doing your project will be awesome!

good luck and happy tinkering

CAN is a viable solution. CAN arbitrates non-destructively. It ensures that the highest priority packet is delivered successfully.

how to delete snapchat

Hi, For me, CAN is the best solution for this application: - No need for special cables and connectors, like ethernet. Twisted pair cable with optional shielding. Standard DB9 connectors are ok. - Ultra simple electronics. Use a microcontroller with integrated CAN peripheral, add a 8 pin transceiver and you are done. Some shields for Mbed1768 already integrate everything, - All the low level protocol for collision detection, priority,... is made in hardware. - When you receive a message, you are sure it is valid, CRC checked,... - When you want to send a message, build it, and call send function. - Very simple software. The ID+8bytes basic message should be enough for your application.

For software, CAN is very simple. At low level, there is no source or destination address. There is no master/slave meanings. Either you are a master or a slave, you send a message on the bus, globaly to all modules connected. Every module on the bus receive all messages. Implementation of source/destination or master/slave should be done at software level.

The message is made of 1 ID and up to 8 bytes. The ID is a general purpose value, but also encode priority of message during start of transmission. This is handled by the CAN peripheral.

The ID can be used for everything. You can use it as a destination address. But if you want to broadcast messages, you will need to repeat the message for all destinations. You can use it as a message identifier, or combine values to encode both source, destination, message type and/or broadcast.

Angelo

Bosch originally developed the Controller Area Network (CAN) in 1985 for in-vehicle networks. In the past, automotive manufacturers connected electronic devices in vehicles using point-to-point wiring systems. Manufacturers began using more and more electronics in vehicles, which resulted in bulky wire harnesses that were heavy and expensive. They then replaced dedicated wiring with in-vehicle networks, which reduced wiring cost, complexity, and weight. CAN, a high-integrity serial bus system for networking intelligent devices, emerged as the standard in-vehicle network. The automotive industry quickly adopted CAN and, in 1993, it became the international standard known as ISO 11898. Since 1994, several higher-level protocols have been standardized on CAN, such as CANopen and DeviceNet. Other markets have widely adopted these additional protocols, which are now standards for industrial communications. This white paper focuses on CAN as an in-vehicle network. https://cleanmaster.me/ https://facebooklite.vip/ https://mathway.vip/