Best communication protocol for multi-master communication - Page 1
Forum section: electronics / general

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 09:02:30 pm
content: Evening folks,I'm designing a microcontroller based control system for a model railway. It'll control points and signals, and take feedback from track occupancy detectors and of course a user interface.As all of these will be scattered around the layout, I've been trying to find a communication protocol which would be suitable - the obvious one is i2c, but it of course can't communicate over large distances without bus buffers. Those, I've found, wouldn't seem to work with true multi-master communication, as they split the signals into 4 unidirectional lines for transmission. The multi-master would be the best way I think to work, so that items such as block occupancy can be immediately transmitted to the control module without having to poll continuously.So my question is this - what would be the best communication protocol in member's opinions? Is there a way to get i2c multi-master to work in a multi-drop configuration over long distances (up to 10-15m), or which other protocol would be recommended? Preferably one which can easily be implemented on many different MCUs :-)Cheers in advance!Sent from my ONEPLUS A3003 using Tapatalk

author: nctnico
author_rank: Super Contributor
timestamp: October 14, 2018, 09:07:50 pm
content: UART over RS485 or CAN are good candidates. If you use a text based UART protocol it will be easy to debug as well. OTOH you could use ethernet protocol over RS485 as well using a UART. There are several small IP stacks for use in microcontrollers but UDP would be sufficient. You can use libpcap to capture network traffic from your real ethernet network and bridge it (with some filtering) with the UART over RS485 ethernet network. I've build something like this over a decade ago.

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 09:12:18 pm
content: Quote from: nctnico on October 14, 2018, 09:07:50 pmRS485 sounds good - however, is there clash detection built in in the same way as i2c? I know CAN has it, but it's harder to find MCUs with it natively built in, so obviously I'd prefer 485 in that caseSent from my ONEPLUS A3003 using Tapatalk

author: nctnico
author_rank: Super Contributor
timestamp: October 14, 2018, 09:20:09 pm
content: With anything else but CAN you'll have to implement the collission detection yourself. I solved that by reading the data back and verifying it against the data being send.

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 09:21:19 pm
content: Quote from: nctnico on October 14, 2018, 09:20:09 pmThat would seemingly work... I'll do some research and testing then :-)Cheers!Sent from my ONEPLUS A3003 using Tapatalk

author: ajb
author_rank: Super Contributor
timestamp: October 14, 2018, 09:34:08 pm
content: Do you actually need multimaster? A polled system is likely to be simpler and easier to debug. You can do things like global or group based polling to detect when a device needs attention to speed up response times if necessary.Note that in any system where collisions are expected, checksums or other validation methods are mandatory.

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 09:37:35 pm
content: Quote from: ajb on October 14, 2018, 09:34:08 pmWell in theory collisions wouldn't occur at all if I used polling. The structure is reasonably simple - user interfaces, which interface only with the command module. This interfaces with one other module which carries out purely logic calculations, for the model railway interlocking. The command module also controls and takes input from all the various "actuators" around the layout.How efficient would polling be, and how could it be implemented? I'm estimating that during a running session, I could have anything up to 4 track circuit status changes per second, plus of course user inputs. These all ideally need to be detected as quickly as possible, especially the track circuits.Sent from my ONEPLUS A3003 using Tapatalk

author: ajb
author_rank: Super Contributor
timestamp: October 14, 2018, 09:57:01 pm
content: In a simple polling setup, the bus master would send a message to each device on the bus requesting its status. The request message can be as little as two bytes: a 'get status' command, and a station address. The response can be a couple of bytes that either reflect the complete state of a simple device, or that tell the controller whether or not the device requires further attention. You could have a bit that indicates whether the device's status has changed since the last time, another bit that indicates if the device is operating normally or has an error, or whatever. The response could even be variable length, it really depends on how much data a given device can or should supply.If you have, say 8 bytes of poll/response, that amounts to about 80-100 bit times on a UART depending on parity/stop bits, so for 100 devices, a 1Mbd serial link would allow you to poll all devices at 100Hz.If you need faster polling, you can do basic group polling, where the controller sends a message asking if any devices in a given group have any status change to report. Each device that does then replies with its address. If no devices have anything to report, the controller receives no response. If exactly one device has something to report, the master will receive a valid message and will immediately know the address of the device that wants attention. If multiple devices have status to report, then there will be a collision, the controller will receive an invalid message, and thereby know that more than one device wants attention. At that point the master can either poll the entire group, or poll a subset of the group. If your group poll message includes an address range you can even implement a binary search to find which individual devices have responded, but you probably won't have a large enough address space to warrant this. (RDMuses this method to discover devices on a network, but there the address (UID) range is 48 bits, so it makes a lot more sense.)Polling may not make sense for user inputs, it really depends on what kinds of inputs you have. A button/light panel is going to be very different from a sophisticated GUI.

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 10:02:03 pm
content: The UI I'm trying to implement as a completely separate system, the aim being to have different types which all perform the same basic functions - in my case to emulate different real-world signalling panels.I could always put them on a separate bus to the rest of the layout, and have the UI poll the control module for status updates, and send commands.Thanks for the clarification... I suspect I may go with polling... Perhaps go back to i2c, since the communication will essentially be master to slave now anyway...Sent from my ONEPLUS A3003 using Tapatalk

author: ogden
author_rank: Super Contributor
timestamp: October 14, 2018, 10:22:26 pm
content: Quote from: danners430 on October 14, 2018, 10:02:03 pmI2C is bad choice for your 10-15m application, it most likely will have reliability issues. Better just use suggested RS485.

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 10:23:43 pm
content: Quote from: ogden on October 14, 2018, 10:22:26 pmThe main reason I want to use i2c if possible, is that it's natively supported on umpteen different MCUs, whereas I don't think RS485 is... If I were to use PCA9600 bus buffers however, it should in theory work fineSent from my ONEPLUS A3003 using Tapatalk

author: nctnico
author_rank: Super Contributor
timestamp: October 14, 2018, 10:29:30 pm
content: RS485 is just as easy as I2C. With I2C you need to do polling anyhow. With RS485 you can use a text based protocol where a command and response are a single line of text (which ends with CR). This is extremely easy to test, debug and most importantly: to expand.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 14, 2018, 10:43:32 pm
content: +1 for RS485. Besides, you can get much faster communication speeds, there's a lot of RS485 driver ICs over there that are well protected and you can use much longer wires than with I2C.

author: ogden
author_rank: Super Contributor
timestamp: October 14, 2018, 10:48:20 pm
content: Quote from: danners430 on October 14, 2018, 10:23:43 pmTo run RS485, nothing much is needed [for each node]: bus transceiver IC, UART or USART peripheral, one GPIO pin for tranceiver direction switch and small piece of CPU code for bus direction handling. The rest of the code is more or less similar to what you would do with I2C.

author: danners430
author_rank: Regular Contributor
timestamp: October 14, 2018, 10:50:47 pm
content: So I did some research on RS-485, and while my brain now hurts (probably a result of that cider...), I think I have a basic understanding.For the sake of simplicity, I'm guessing I could use a MAX485 to translate simple TTL to RS-485 signals? Useful, as most of the "actuators" in my setup will be basic PICAXE chips, simply because they're really easy to program, cheap and cheerful. However, they only natively accept TTL, and not RS-485... Could still work, but I'd be bit-banging.Sent from my ONEPLUS A3003 using Tapatalk

author: TomS_
author_rank: Frequent Contributor
timestamp: October 15, 2018, 12:22:09 am
content: Quote from: danners430 on October 14, 2018, 10:50:47 pmThat's pretty much it in a nutshell.There are other alternative parts to Maxim, which I find tend to be rather expensive. e.g. I've used the SN75176 from TI in one of my projects.At the end of the day they all achieve the same thing and should be interoperable.

author: mrpackethead
author_rank: Super Contributor
timestamp: October 15, 2018, 12:44:05 am
content: ethernet will be easy. If you do POE you can even power up your devices all over the place, with a single cable. Ethernet is cheap to implement, and you get hte bonus its isolated.

author: ehughes
author_rank: Frequent Contributor
timestamp: October 15, 2018, 12:48:26 am
content: https://www.nxp.com/docs/en/data-sheet/LPC11CX2_CX4.pdf48 pin package, CAN transceivers built it. There is also a driver in ROM for CAN functions. As soon as you have to do collision detection, go with CAN. It saves a lot of hassle. IF you need higher data rate, CAN FD is very nice.

author: lwatts666
author_rank: Unknown
timestamp: October 15, 2018, 01:05:49 am
content: CAN bus is nice, since collision detection and node prioritization is done at the hardware level. As others have said, not all micros have the requisite hardware support.RS485 with a simple token ring protocol would fit the bill, but fully fault tolerant token rings are difficult to implement.If physical node failure tolerance is not a major issue, then a simple sequential master protocol over RS485 can be used. Data packets consists of a packet header containing the source node address, the data payload which may be empty, and a tail, with checksum if required. Node-0 sees no comms for x milliseconds, so sends out its packet. Node-1 sees tail of Node-0's packet, so sends it packet. Node 2 sees tail of Node-1's packet, so sends it packet, and so on. When last node send its data, there is no more comms, so Node-0 starts again. If a packet is corrupt, all nodes shut up, and Node-0 starts again. Major failure mode is where a physical Node fails in the middle of the address range, which will result in all higher addressed nodes never communicating. Failure of Node-0 means nothing communicates, but lack of response make it easy to troubleshoot...

author: rstofer
author_rank: Super Contributor
timestamp: October 15, 2018, 02:23:38 am
content: Here is a multi-master protocol layered over RS485. It handles collisions by listening while talking.http://www.bdmicro.com/code/robin/

author: laneboysrc
author_rank: Contributor
timestamp: October 15, 2018, 02:38:14 am
content: Since this is for a model railway have a look at Lenz's Xpressent protocol. It is based on RS485.Marketing blurb:http://lenzusa.com/1newsite1/XpressnetFAQ.htmlTechnical spec:http://lenzusa.com/1newsite1/Manuals.html#xpressnetEven if your use-case is different you may still get some inspiration out of it.

author: ehughes
author_rank: Frequent Contributor
timestamp: October 15, 2018, 03:08:29 am
content: Sorry to hijack this thread but I have always dreamed of a model rail road around the office. I want an o guaged size to go between desks and make stops (interoffice mail!) Where is the cheapest source for track? It seems to be quite expensive!

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 06:21:54 am
content: Hey guys,Sorry - fell asleepFrom looking at everything, I think I'll go with RS-485 with MAX485s or equivalent. For control, I'll simply have the master polling in a single master setup. For the communication between the control module and the user interface, I'll probably use dual unidirectional TTL lines, as there's no need to poll - just send commands to one another.I'll take a look at Expressnet, see what that comes up with :-)Cheers for the help folks!Sent from my ONEPLUS A3003 using Tapatalk

author: Brianf
author_rank: Regular Contributor
timestamp: October 15, 2018, 07:39:38 am
content: As you are in the UK, you could do worse than look at what MERG have done with CANBUS.

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 07:56:50 am
content: Quote from: Brianf on October 15, 2018, 07:39:38 amAye, I've had a look at MERG... But it's just not as flexible as I'd like - as a maker, I love making things work myself, and I've just not found that flexibility with MERG equipmentSent from my ONEPLUS A3003 using Tapatalk

author: capt bullshot
author_rank: Super Contributor
timestamp: October 15, 2018, 08:07:27 am
content: I second on CAN.One can buy many microcontrollers with built-in CAN controllers today, and the software you'll have to write is way more simple than e.g. I2C or RS485, as the CAN controller does all the work for you.The CAN transceiver chip doesn't cost more than a good RS485 transceiver anyway, so there should no reason not to use CAN. For the 10 to 20m range, a multi-drop configuration of the bus isn't an issue at all. And CAN is multi-master by design.

author: fourtytwo42
author_rank: Super Contributor
timestamp: October 15, 2018, 08:42:26 am
content: I implemented a system like this ~20 years ago. One thing to consider is ground shifts and noise, I used a single ended signalling system with very wide noise margins by using relatively high voltages (15V) and a transistor/zener detector with a threshold ~8V (critically the MPU input was a schmit-trigger). All nodes were connected to the same single wire bus that they also pulled up with ~1-5mA, TX was interfaced by an open-collector transistor so any node could pull the bus down but not hard up. The protocol was CSMA (from Ethernet) collisions being detected by the transmitting node checking that when it TXed a '1' that was the result on the bus (nobody else was pulling it down). Messages were kept as simple as possible (not much ram in a PIC16C84) and always repeated, the receiving node detecting errors by comparing the two copies. If the transmitter detected an error it used a random backoff timer before attempting to transmit again. The MPU interface was the standard UART that I seem to recall could clock at up to ~500Kbps. All messages were always repeated at fairly infrequent intervals so data loss at the receiver from an error was only momentary. The system ran on a large layout for around 10 years before life intervened and the whole thing was scrappedIt used geographic rather than physical addressing and was fast and reliable enough to communicate loco speed settings from hand controllers to the layout without any jerking during shunting. Control panel displays simply slurped up interesting info from the bus as did an ancient DOS-PC that ran the block signalling and route selection again due to the tiny memory limitations of then available micro-controllers, the PC placing an upper limit on communications speed.Good luck and have fun

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 08:52:56 am
content: That sounds interesting!!I don't think ground shifts will be too much of an issue, as each module will have its own power supply - but each fed from the DCC bus. I'll be running a separate ground line to each module too, so any ground transients will have a path.As for the MCU itself, I'm thinking a Teensy 3.6 for the main controller, with most other modules which actually control points and signals etc. Being PICAXE chips - easy to program, easy BASIC language and perfectly adequate for this application IMO - just overclock them to 64MHzThe exception to that rule will be my interlocking, which will probably use a PIC18 family processor for speed and RAM space.Sent from my ONEPLUS A3003 using Tapatalk

author: fourtytwo42
author_rank: Super Contributor
timestamp: October 15, 2018, 09:20:58 am
content: Quote from: danners430 on October 15, 2018, 08:52:56 amThat all depends upon what sort of loads are switched using ground as a return path to the power supply, in my case in a common return DC layout that was practically everything, locomotives, point solenoids, turntable motors and any amount of led's! Also radial grounds are not good for communications, better to have a bus that follows the communication path. In my case a heavy ground bus followed the main part of the layout around with stubs into the likes of island terminus stations. You don't say how large your layout is, mine was about 25ft square at the extremes N gauge with around 350 points to give an idea. Points in particular would have local group decoupling (large capacitors) to reduce ground transients.

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 09:26:01 am
content: My layout is approximately the size of a large bedroom, but will be using DCC. The power supply for the electronics will come from the DCC bus, which is effectively 16V DC square wave, so I'll just rectify it using fast reaction diodes, then put it through voltage regulators. As for the points, they'll be Cobalt stall motors, not solenoids, so no large ground transients there - they only draw up to 100mA when operating!Sent from my ONEPLUS A3003 using Tapatalk

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 12:32:52 pm
content: Just a bit of info - I'm thinking I could go with CAN - if I stick with the Teensy 3.6, which has CAN, and PIC18F25/26K83 MCUs for the peripherals, I should be dancing, as they all have native CAN support - makes life nice and easy. Debating now whether to use CAN for the control panel too... In theory it would be a decent idea, because then it can operate by essentially "snooping" on the bus to get statuses etc. It doesn't need data specifically sent to it... If I were really clever with programming, which wouldn't be too hard with such high-end chips, I might even be able to do away with the control module altogether, with individual modules simply working side by side...Thoughts?Sent from my ONEPLUS A3003 using Tapatalk

author: capt bullshot
author_rank: Super Contributor
timestamp: October 15, 2018, 01:57:21 pm
content: Yes, of course CAN would be the natural choice to interface the control panel. Otherwise you'd have to provide a gateway to whatever protocol you'd intend to use for the control panel.BTW there are implementations that just forward CAN packets over ethernet (UDP wise), so you could build or buy a CAN to ethernet gateway and still use your protocol implementation on the control panel side, having just some other layer (UDP) in between to forward the CAN packets. Or one could use some CAN device that is supported by your host OS to interface with your bus. Some of the Banana Pi SBCs have CAN built-in and working linux drivers available.As most of the STM32 controllers have CAN on board, many of their discovery kits could be used as a control panel. There's quite a choice of rather inexpensive STM32 discovery modules offering graphical LCDs of various sizes on board. Some of them need some fantasy to "free" the CAN controller, but it's feasible.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 15, 2018, 02:08:59 pm
content: Quote from: danners430 on October 15, 2018, 12:32:52 pmTypically, devices on the CAN bus transmit informational messages at regular intervals. For example, a sensor may transmit the results of the measurements every second. Other devices, which are interested in this information, catch these messages and store the values locally. CAN module on any device should give you an ability to filter out the messages you're not interested in. This works, in a way, as variables shared over the CAN bus. The devices also respond to control messages which may change their behaviour and/or provoke a response.There are protocols which lets devices negotiate their ids when new devices get connected. Thus, you can build networks with varying sets of devices. If your list of devices is fixed, you do not need this.When debugging, you just connect a sniffer device which lists all the traffic for you and may inject control messages as needed. There's no real security, the debugging device can impersonate messages and they look exactly as if they were transmitted by real nodes. This is what OBD II devices do in the cars.

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 02:10:39 pm
content: I'd suggest for the control panel a simple MCU would be ideal... Something like a Teensy or a PIC with CAN connectivity. Allows me to easily multiplex switches and indicators :-)Sent from my ONEPLUS A3003 using Tapatalk

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 02:19:01 pm
content: So how about this:A mixture of Teensy 3.6 or PIC18F25/26K83 MCUs, all communicating with one another over CAN. No control module, just UI (control panels), interlocking module and "actuation" modules (track circuits, signals, points etc).The only question I have then is how to do one particular thing:On startup, I obviously need the actuators to transmit their current status (point direction, track circuit status), so that the user interface and interlocking can be updated. How would I best do this - should the interlocking poll each device on startup before the system reverts to broadcast?Sent from my ONEPLUS A3003 using Tapatalk

author: capt bullshot
author_rank: Super Contributor
timestamp: October 15, 2018, 02:28:06 pm
content: Each device (no matter if actuator or input) would report its status continously (repeated in short but not too short intervals).So one could attach or power on any device any time later and it'll sync automatically to the whole system status.You'll have to think about CAN bus addressing, since CAN addresses are limited and each packet has a maximum payload of 8 bytes, and what to do if there's more than 8 bytes to transmit. My approach is to split larger data into a series of packets with the first (or first two) byte as an index and the rest 6 or 7 bytes representing the data structure at the offset pointed to by the first (first two) bytes. Maybe you won't need that as I believe your payload data is mostly just a few bits for an actuator or input device.

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 02:38:53 pm
content: Quote from: capt bullshot on October 15, 2018, 02:28:06 pmThat makes sense... So if each device transmitted its status every, say, 1 second (speed isn't really critical when it's just continuous updating), or instantly if there's a change in status, then eventually everything would be updated. As for startup, if I simply programmed each module to send a status on startup, but with a delay unique to each module - for example module 1 transmitted after 1ms, module 2 after 2ms etc. - then I'd eventually have all the statuses after starting up.Quote from: capt bullshot on October 15, 2018, 02:28:06 pmAye, 8 bytes is more than enough. Each command packet will be 2 bytes as far as I can work out - one address byte for each device (point, signal, track circuit) followed by a status - for track circuits that's obviously just a bitvalue, but signals could contain multiple states. In the future I could always expand on this by adding an additional address byte, and an additional data byte - but I doubt I'll ever reach 8 bytes, let alone exceed it.Status packets will be a bit different... But again, 8 bytes will be more than enough.Sent from my ONEPLUS A3003 using Tapatalk

author: NorthGuy
author_rank: Super Contributor
timestamp: October 15, 2018, 04:19:40 pm
content: Quote from: danners430 on October 15, 2018, 02:38:53 pmYou don't need to worry about delays. You just prepare a packed and queue it. The controller will take care of the rest. However, it will not work unless there's at least one more device on the CAN bus. Otherwise there will be no ACK.

author: capt bullshot
author_rank: Super Contributor
timestamp: October 15, 2018, 04:23:37 pm
content: Yes, that looks good. You won't need a different delay on startup, the CAN controller will handle that for you. Anyway, choose higher priority CAN addresses for the "fast" status change and command packets and low priority addresses for the cyclic updates. As NorthGuy pointed out, maybe you need to take care of the controller going "permanent offline" if it is the only one on the bus. Usually this is an configuration issue.

author: danners430
author_rank: Regular Contributor
timestamp: October 15, 2018, 04:35:53 pm
content: Sounds good - time, I think to do some proper learning for CAN!Sent from my ONEPLUS A3003 using Tapatalk

author: mrpackethead
author_rank: Super Contributor
timestamp: October 15, 2018, 08:07:27 pm
content: ethernet is so easy, Just plug it in, and start communicting between the various devices at what ever speed you need. easy to program some UDP sockets.. and so cheap these days.. No special interfaces requried to plug into a PC either..

author: jnz
author_rank: Frequent Contributor
timestamp: October 15, 2018, 08:27:33 pm
content: Quote from: mrpackethead on October 15, 2018, 08:07:27 pmEthernet is not multimaster.IMO, if you have work to do and get done, CAN. If you have more time to tinker or need a specific chip / lower cost, RS485.There are issues with CAN specifically that you should be using it in a cyclic mode where each module has it's own address or range. This becomes an issue when you have lots of modules programmed identically and need to negotiate their own IDs at boot.

author: mrpackethead
author_rank: Super Contributor
timestamp: October 15, 2018, 08:59:20 pm
content: Quote from: jnz on October 15, 2018, 08:27:33 pmQuoteLots of differnet MCU's, no real distance limits.. And the OP asked for other protocols. So much code avaialble to do the job, and lots of people who know how to make it work. Cheaper to implement than RS485.

author: ogden
author_rank: Super Contributor
timestamp: October 15, 2018, 09:22:09 pm
content: Quote from: mrpackethead on October 15, 2018, 08:59:20 pmPlease explain why you think so.

author: mrpackethead
author_rank: Super Contributor
timestamp: October 15, 2018, 10:14:52 pm
content: Quote from: ogden on October 15, 2018, 09:22:09 pmbecause the sum of cost of parts is less than doing RS485. Adding Galvanic Isolation ( which you shoudl do ) to RS485 adds considerable cost to building it. Yeah, you can just bang a transceiver on the end, but then its not really built properly. ethernet is isolated by the transformer. You can create a ethernet attached Micro Controller for under $5. Try doign a properly contructed 485 for that cost.

author: ogden
author_rank: Super Contributor
timestamp: October 15, 2018, 11:08:40 pm
content: Quote from: mrpackethead on October 15, 2018, 10:14:52 pmPlease don't invent nonexistent requirements. "Properly built" rs485 does not mean galvanic isolation, nor OP mentioned such.QuoteWould be nice that you show BOM as well. rs485 transceiver: 1.3$, many kinds of MCU with UART: <= 1$, connector 0.1$. That's it for rs485, ~2.5$

author: nctnico
author_rank: Super Contributor
timestamp: October 15, 2018, 11:38:18 pm
content: Quote from: mrpackethead on October 15, 2018, 10:14:52 pmRS485 isn't supposed to be isolated. But if you want you can use an NRZ modulated transmission signal and add a small (&cheap) signal transformer in between. Another option is to use optocouplers (like in Midi) which allows to create an isolated interface between two UARTs very cheaply.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 08:22:13 am
content: Just saying by the way, whatever protocol gets chosen, and at the moment I'm looking very hard at CAN, it's going to be transmitted over twister pair ethernet cable - probably CAT5 or higher, so it'll be shielded anyway.Sent from my ONEPLUS A3003 using Tapatalk

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 01:58:26 pm
content: So I've been researching the CAN standard, and have discovered something in the physical layer: namely that the characteristic impedance should be 120 ohm. Is that achieved by the 120 ohm terminations, or do I have to find a cable with that impedance? For example cat 5 only has 100 ohm...Sent from my ONEPLUS A3003 using Tapatalk

author: ogden
author_rank: Super Contributor
timestamp: October 16, 2018, 02:27:23 pm
content: Quote from: danners430 on October 16, 2018, 01:58:26 pmIdeal impedance match is not needed. Note that most Cat5 cables are specified 100 +/- 15 Ohms. Just terminate using 110 ohm resistors or so. BTW I would use 2-pair Cat3 UTP cable which is not so bulky as Cat5 4-pair.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 02:32:28 pm
content: Aye, but I have plans for the rest of the rest of the twisted pairs *evil cackle*Nah, I'm gonna use the rest of the cable for future-proofing - allows me to use a second protocol in the future, or even use ethernet as well as CAN. Certainly in the future I intent to connect the layout to a computer, and eventually as an IoT device to my local network. And since that only requires 2 twisted pairs, I might as wellSent from my ONEPLUS A3003 using Tapatalk

author: Siwastaja
author_rank: Super Contributor
timestamp: October 16, 2018, 02:44:31 pm
content: CAN is just fine with quite a lot of line impedance mismatch, CAT5 is not only acceptable, but actually very good. CAN is slow and has edge rate control, hence the impedance matching on the cable, while theoretically still valid, bears little significance unless you are aiming for very long links (tens of meters). This is by design.Framing is worth a consideration in any message system. UART (what you would use through RS485) naturally delimits at 8 bits. CAN frames at 8 bytes (64 bits) max. Properly hardware-implemented SPI has practically no limit, so the framing is SPI's strong point - although it's not usually properly hardware-implemented, and any multi-master kludges suck on SPI, so that's about it...In any case, it'salwaysa bit easier when you can limit the message size below the framing length. This way, you don't need to know where your message starts and where it ends, you don't need state, and your parser is the easiest thing on the planet. In UART, that's seldom possible (although sometimes it is, you can fit quite a lot of commands in 8 bits for example!), but the 8 bytes in CAN is often enough to do quite a lot, especially since you can utilize the wide address space as your "header", to signify different commands / subsystems / tasks / message types / whatever, leaving more of that 8 bytes for the actual payload data!Hardware-wise, RS422/RS485 and CAN are both very simple, robust, cheap, and easy to deploy. Whichever is just fine. Both would also be somewhat cheaper solutions than Ethernet; especially if you consider the software complexity. Ethernet becomes an attractive off-the-shelf solution when you need isolation, or high datarates beyond a few Mbps.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 02:46:56 pm
content: All sounds good - I mentioned ethernet simply as a future project, which is the reason why I'm using CAT5 cable.I'm having a look round the internet, however, and I'm struggling to find information on how to implement CAN on a microcontroller - in my case a PIC. Can anyone point me to a good tutorial?Sent from my ONEPLUS A3003 using Tapatalk

author: NorthGuy
author_rank: Super Contributor
timestamp: October 16, 2018, 03:07:20 pm
content: Quote from: danners430 on October 16, 2018, 02:46:56 pmCAN modules are different. For peculiarities, it's best to read data sheets and app notes for your particular MCU.If you want to connect your CAN bus to the PC or to the Internet in the future, you can just add a node to your CAN bus for communication purposes - USB, wired Ethernet, Wi-Fi, Bluetooth, whatever - or several of them. No need for special provisions now.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 03:36:24 pm
content: I've had a look at the datasheet, and can't find anything useful for me... It's a PIC18F25, which has a CAN module built in.Sent from my ONEPLUS A3003 using Tapatalk

author: Siwastaja
author_rank: Super Contributor
timestamp: October 16, 2018, 03:53:51 pm
content: The MCU manual should explain everything you need to know. If not, you are either looking at the wrong manual, or have an unspecified microcontroller, and should change to something that has documentation (or reverse-engineer by trial&error).Sometimes it's just called "datasheet", but sometimes it's called "reference manual". You need it anyway when developing for a microcontroller.The CAN peripherals in MCUs tend to be fairly easy. You configure a few filters you can use to accept/ignore certain CAN IDs, and poll some mailbox status bits, or get an interrupt when a message arrives in the buffer.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 03:55:30 pm
content: The main issue with the PICs is that they're generally programmed in C using a proprietary IDE... So it's really info on how to program them in C I'm after. And yes, I've looked up specifically for the IDE, MPLAB X, and haven't as yet found anything. But obviously I'm still looking.Sent from my ONEPLUS A3003 using Tapatalk

author: Siwastaja
author_rank: Super Contributor
timestamp: October 16, 2018, 04:11:28 pm
content: Oh, you are going to have some learning curve right there. Are you in a hurry? If not, I suggest, take your time. Start small, do your first LED blinker, try to use a timer peripheral to PWM the LED, then do some simple UART thing. Then I think you'll understand the documentation and the C language better and can take the CAN job. It's worth it.About the PIC C compiler being proprietary, yeah, that kinda sucks, and there is no way around it. If this bothers you, you need to look at something else.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 04:14:14 pm
content: I'm actually already slightly used to using C, not much but I know the basics. But I see what you mean :-) PICs are new to me, I've only worked with other micros before. I'll get started :-)Sent from my ONEPLUS A3003 using Tapatalk

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 05:52:07 pm
content: Pulling back in topic here, one idea I have is to run UART over CAN PHY, implement CSMA/CD and some kind of collision recovery.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 05:53:57 pm
content: Quote from: technix on October 16, 2018, 05:52:07 pmSorry... Could you repeat that in English? I'm afraid you've lost me completely!Sent from my ONEPLUS A3003 using Tapatalk

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 06:04:26 pm
content: Quote from: danners430 on October 16, 2018, 05:53:57 pmI believe you understand the OSI network model right? Here in this stack the physical layer is firmly defined and the data link layer is half defined. The physical layer uses CAN's electrical characteristics and signalling, but uses UART as its line code instead of CAN's own. The data link layer doesn't have a complete protocol definition yet, however the protocol need to implement the CSMA/CD algorithm to detect collision, and must be able to handle collision gracefully.Not using CAN's line code and protocol stack while keeping its signalling allows you to dodge the cost and complexity of CAN hardware, while not breaking the collision detection feature.

author: danners430
author_rank: Regular Contributor
timestamp: October 16, 2018, 06:06:44 pm
content: TBH, what advantage would it give? As far as I can tell I'm gonna have to learn a whole lot anyway, and the MCUs I'm looking at support CAN natively - I'm sure once I've done some learning I can find a library or method to easily program and use full CANSent from my ONEPLUS A3003 using Tapatalk

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 06:14:47 pm
content: Quote from: danners430 on October 16, 2018, 06:06:44 pmThe biggest point of UART over CAN PHY is dodging the CAN harware. Sure your current MCU has CAN, but not all MCU has it and it is usually associated with a price premium. For my projects I was using UART over CAN with STM32F030F4P6, its Chinese workalike GD32F130F8P6, or even IAP15W4K61S4. Those are all extremely cheap chips that does not have CAN.It is also a crucial learning experience as CSMA/CD is one of the most basic multiple access protocols used in networking, and unlike its sibling CSMA/CA (as used in Wi-Fi of all things) it allows true peer to peer network where anyone can start speaking politely at any moment on a shared media.