How hard is CAN? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: August 17, 2022, 03:43:53 pm
content: I have no plans to get involved in CAN but my board (32F417) has a provision for it, with an L9616 interface chip optionally on the board.My sole exposure to CAN is with stuff like VAG-COM and various ODB2/CAN cables, for doing useful mods to my VW. It is pretty obvious that VW publish almost nothing and people like VAG-COM have reverse engineered the bitfields, by changing bits and seeing what has changed on the car. So the whole system is proprietary.I have also seen CAN used in avionics (Garmin mostly) and again it is totally proprietary, as is their ETH usage.So it may be that just about all CAN applications are proprietary, and for the most part the only people who can interface to a product are those who made it... Everybody I have seen use CAN was using it purely for their own interconnects.Is that really true?The protocols also seem damn complicated, although nothing can be as horrible as ETH+LWIP etc.Is the above a reasonable summary?Many years ago, the electronics mags were full of CAN this and CAN that, and it was going to take over the world, kill off RS232, RS422, RS485, you name it. It ended up used almost entirely in automotive although it seems to have branched out a bit.

author: uer166
author_rank: Super Contributor
timestamp: August 17, 2022, 03:55:24 pm
content: That's not a reasonable summary at all; you need maybe 100 lines of code total to make it work. They're relatively complicated peripherals but nothing like Ethernet or USB, much closer to the UART side.CAN is only a physical layer and a low-level frame standard that's fully documented (not sure why you mention it's closed). What you actually send in the packets is up to you, so of course there is no inter-operability between stuff. It's used all over in automotive and industrial applications, and does have some advantages over RS485.To save you some trouble: STM32 CAN FD peripherals are Bosch M_CAN IP I believe, so the documentation for that applies.

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2022, 04:08:07 pm
content: CAN itself is easy, but meaning of the data is proprietary. Same thing applies to UART. Many systems have proprietary data sent over UART too.CAN was not going to "kill" other interfaces and it was specifically designed for automotive use, so of course it found most of the uses in automotive environment.And yes, a lot of devices on the market have the same exact IP. All Atmel/Microchip stuff is M_CAN too. Same driver code just works across all those devices. The relevant datasheet section is usually just a copy-paste of the Bosch datasheet. And in some cases vendors take some creative liberties with the text, so having original Bosch datasheet handy helps.

author: uer166
author_rank: Super Contributor
timestamp: August 17, 2022, 04:11:16 pm
content: Ah, yes, the data is largely proprietary. In the same way you can't necessarily use a IP camera without their software, you probably can't connect to a car and get meaningful data without an ID/data/format database such as a DBC file.

author: eutectique
author_rank: Frequent Contributor
timestamp: August 17, 2022, 04:39:58 pm
content: As was already said, CAN is the physical layer. On top of this sit a lot of more complex and expensive stuff.UDSandJ1939-- used widely in automotive, agriculture, material handling. Can coexist on the same wire.ISOBUS-- based on J1939, main use is agricultural machinery and implements. The main driving idea behind this protocol is to bring consent and consistency to the wild zoo of incompatible proprietary implementations. Say, an ISOBUS display installed in a CNH tractor can control an attached John Deere's manure dispenser. Generally speaking, any independent manufacturer of manure dispensers is welcome to the party, subject to ISOBUS certification.Then comesCANopen-- used in industrial automation.Your product would probably require some sort of certification (apart from the obligatory EMC/EMI), if you want it installed on a machine or a factory floor.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 17, 2022, 05:41:39 pm
content: CAN is really good, simple and easy to understand, but of course not the optimum solution for every job.Compared to UART for example, you get:* Multi-node bus* Packaging of data with 8-byte payload PLUS a hardware level identifier which you can use to describe content / node id / whatever and which also doubles as a priority level.CAN is optimum in cases where you flood relatively short data packets (but usually longer than 1 byte, so benefit from the packetization) from multiple sources and want to "subscribe" to them. There is no guarantee of getting packets through, and no usable form of acknowledgement, so most typically you just design the systems to have timeouts in case required data is not received in time. CAN itself is simple and low level, what you do with it and how is up to you.Also CAN peripherals in microcontrollers are often very powerful, allowing built-in filtration (for example: ignore data not matching whatever ID) and whatnot, but the flip side is, there are quite a few registers to configure, and quite a few state charts to understand (e.g.: you have to enable configuration mode, then enable running mode, or whatever). For example, the CAN peripheral in STM32H7 series is quite complicated because it is so flexible, you have to configure the memory layout you want to use for it. It takes easily 1-2 full days to get started with it (compare to ½ hours of UART peripheral).Luckily, you can see there are not too many CAN peripherals; not many MCU manufacturers did their own, but licensed something already made, so you can find the exact same CAN peripheral, with exact same documentation (maybe with different visual style) in MCUs of different companies.

author: JPortici
author_rank: Super Contributor
timestamp: August 17, 2022, 06:19:00 pm
content: Quote from: peter-h on August 17, 2022, 03:43:53 pmbasicallyQuoteoh, you're in for some funhttps://support.ixiacom.com/sites/default/files/resources/whitepaper/ixia-automotive-ethernet-primer-whitepaper_1.pdfnowadays most diagnostic and programming is done over ethernet. You can still do part of it over CAN, probably because legislation (OBD and such) and support for legacy toolsThere are some standards like CANOpen or CiA and there are brands that adhere to thoseThere are protocols for networking over CAN/LIN/K-Line/whatever to implement multiframe messages and node-to-node communication which are mostly universal (though BWM like to have its own variation of the protocols)but can itself is actually not that hard, i wouldn't think of anything else if i wanted to connect multiple nodes and have something that does arbitration on its own. you don't even need transceivers in some scenarios (short distances, same board)

author: Berni
author_rank: Super Contributor
timestamp: August 17, 2022, 07:45:50 pm
content: CAN is just the physical layer protocol. Nobody is going to sue you for sending things the 'wrong things' over it, it's job is to get the bits across the wire, but what you put into those bits is up to you. Just like UART or RS485 or Etheret can carry any traffic you like.There is a good reason there are multiple kinds of protocols, each one is designed for a specific kind of thing.UART: Simple as can be 2 wires directly taking TTL signals, no chips neededRS232: Same as UART but with level shifter chips that give it more voltage level and more resilience to damage.RS485: Also UART but over differential so it can go really far over twisted pair.RS422: Like RS485 but full duplex so don't have to wait for silence on the busCAN: Like RS485 but with built in arbitration that lets large numbers of devices talk on a bus but never collide (Tho this limits speeds and wire lengths)BASE100 Ethernet: Like RS422 but way faster and with galvanic isolation to fix ground loop problems.Single pair Ethernet: Like BASE100 but more like RS485 by needing just one pair.10GBASE Ethernet: Like BASE100 but with twice the wires with 100x the speed, but only works over short cables.USB 1.0: Like RS485 but at a standard 100Kbit or 12Mbit baudrate and extra standaridsed negotiation logic and standardised power connections. Short cables only.USB 2.0 Like USB 1.0 but way faster....etcAll these interfaces can be used to connect two (or more) devices and carry data between them. Each has its own pros and cons, you just pick the one that fits the application best. Nobody said that you MUST use BASE100 Ethernet for TCP/IP. You can use it to send any proprietary data between two devices (It just won't work with off the shelf network switches), if you need a reliable way to send 100Mbit of data over 200m of twisted pair with galvanic isolation... there you go. And you do see protocols used in this way here and there. Just because TCP/IP is the most popular use of Ethernet doesn't make it the only use.When it comes to CAN there is no distinct "most popular" use for it. What data is sent is fully dependent on what protocol you run in the next layer up. You could use it for SAE J1939 or SAE J2284 or NMEA2000 or CANOpen or CAN Aerospace or ISOBUS or DeviceNet...etc or you could say that none of these protocols cover your particular use case and create PeterCAN™®. In exactly the same way you will see all sorts of higher level protocols running on top of RS232 or RS485.The only case you will get in trouble is if you used a standard and trademarked protocol, like say USB, place the trademarked USB logo on your device and then proceed to do something with the device that is forbidden by the USB specification. You can get sued for trademark infringement of the USB logo because you did not have the permission to use it, because getting permission requires your device to be certified to meet USB specification requirements.

author: DiTBho
author_rank: Super Contributor
timestamp: August 17, 2022, 08:06:11 pm
content: Can is not a network deviceCan is not a char dev deviceThat's the only problem with Linux

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 17, 2022, 08:13:23 pm
content: Quote from: Berni on August 17, 2022, 07:45:50 pmAnd can have multiple devices on one bus, though there is no intrinsic collision detection or arbitrationQuoteRS422 is like RS485 in terms of using differential signal levels, but more like RS232 in typical use cases, in that it is a full-duplex point-to-point link between 2 devices.

author: tszaboo
author_rank: Super Contributor
timestamp: August 17, 2022, 08:37:36 pm
content: Quote from: mikeselectricstuff on August 17, 2022, 08:13:23 pmIt's really my favorite go-to interface. I had as much as 32 devices on 2KM cable, or 64 devices on 4 backplanes going at 25 MBIT/s, while it is as easy to handle as UART.

author: nctnico
author_rank: Super Contributor
timestamp: August 17, 2022, 09:24:53 pm
content: Quote from: peter-h on August 17, 2022, 03:43:53 pmThat sums it up nicely. From what I've seen CAN protocols are modified to meet the needs of the customer that is building the contraption that is going to use the CAN bus. In some cases equipment manufacturers simply specify their CAN message format so you can read it.QuoteThere is nothing complicated about CAN. Devices typically send status update packets with the status encoded in the payload data repeatedly. Basically a broadcast service. A device that listens to the messages, acknowledges reception of the message.

author: uer166
author_rank: Super Contributor
timestamp: August 17, 2022, 10:08:24 pm
content: Quote from: nctnico on August 17, 2022, 09:24:53 pmJust want to add that in practice that doesn't work, because when you have multiple receivers in a network (which is usually the case), they ACK the same message, and you don't know if the right ECU actually received it or not, you only know that one of them ACKed the frame. In practice you use timeouts and whatnot as was mentioned before. CAN is largely used for state-based comms where you just send the same state message every 10ms or whatever in a vehicle such as button states, headlight on or off, etc.

author: nctnico
author_rank: Super Contributor
timestamp: August 17, 2022, 10:39:42 pm
content: Ofcourse you need some time-outs at the receiving side to prevent using a stale state. And at the transmitting side to take a message off the bus that never gets acknowledged.

author: Berni
author_rank: Super Contributor
timestamp: August 18, 2022, 05:38:41 am
content: Yes the acknowledgement only requires one receiving device to ACK the message, and quite often devices will acknowledge everything it sees on a bus.However CAN devices can also NACK a message with a failed CRC or even force abort a message mid way trough if what they are receiving doesn't make sense. They do this by intentionally causing a bus collision, this makes the transmitting node stop and re transmit the message again. So that way it makes sure all nodes actually received the message. The before mentioned ACK/NACK bit also plays a role here because it requires the round trip delay to be within one bit timing, this makes CAN stop working as soon as you use too long cables. So this ensures that the cables are always short enough for the address arbitration at the start to work correctly (Rather than cause weird intermittent issues when the moon aligns and the wrong two devices try to arbitrate at just the right time).These things are perhaps the biggest advantage CAN has over other interfaces. It can detect and fix problems as they happen without the upper application layers even knowing anything went wrong. Combined with differential signaling it makes the bus very very reliable even in noisy environments, exactly what you want in automotive. But at the same time this puts a hard limit on cable length due to the speed of light, hence why CAN is used on vehicles or machines and not in buildings (they are too big). It also has lot of overhead so 1Mbit CAN will only actually transfer up to about 500Kbit of useful payload data. The new CAN-FD standard attempts to mitigate this by doing arbitration at low speed and then data transfer of larger payloads at high speed, but not a lot of things use it so far. Car manufacturers are going single pair Ethernet these days because it is even faster.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2022, 05:42:23 am
content: Quote from: DiTBho on August 17, 2022, 08:06:11 pmThere is no problem in Linux - there is socketcan, well standardized interface which Just Works across UNIX/POSIX systems.With Windows, the problem is huge - you have to basically write a wrapper for every CAN adapter in existence, which is a total PITA.For example, I have chosen to provide support for SocketCAN, KVASER and PCAN interfaces. Nearly 100% adapter coverage in linux, but tiny % on Windows, and there seems to be no way around it.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2022, 05:47:45 am
content: Quote from: nctnico on August 17, 2022, 09:24:53 pmA clarification though: any device that is "on", acknowledges any message. Basically, if any two devices are alive on an N-device bus, every packet gets an ACK, and you can't know which nodes actually received it. For this reason, CAN's acknowledge mechanism is basically useless (if you have foundanyuse it, please share), and causes more confusion than it helps (also for this reason, CAN peripherals typically offer the feature to turn the auto-resend feature off, simplifying things by removing a useless feature).As I stated earlier, CAN-based communications often use timeouts on important data. For example: just decide, by convention, that battery voltage is sent every 100ms. If the battery voltage is not received within 500ms, give an error / run some workaround procedure.

author: Colt45
author_rank: Contributor
timestamp: August 18, 2022, 05:50:06 am
content: SocketCAN is 10/10 A++++++ would buy again

author: ataradov
author_rank: Super Contributor
timestamp: August 18, 2022, 05:56:40 am
content: Quote from: Siwastaja on August 18, 2022, 05:47:45 amIt is useful to eliminate transmitting nodes that may not be able to receive. Those nodes would be stepping on other nodes otherwise.Each NACK increments a counter and the controller must stop transmitting if the counter reached a set limit.NAKs in CAN are indeed not for the application use as in other interfaces, but to maintain integrity of the bus overall. Application should basically ignore individual NAKs and just act on counter overflows.

author: Berni
author_rank: Super Contributor
timestamp: August 18, 2022, 05:57:15 am
content: Quote from: Siwastaja on August 18, 2022, 05:47:45 amAs i explained above the ACK also serves to make the bus stop working as soon as you use too long cables. This makes sure all devices are close enough for the arbitration process to work correctly.The auto-resend is useful because it also resends any messages that got corrupt during transmission or reception.

author: peter-h
author_rank: Super Contributor
timestamp: August 18, 2022, 06:18:05 am
content: Interesting input. Thank you all.I didn't know most of it, though it is unsurprising. So to turn on headlights you send the ON message say every 100ms, for ever. That's why CAN is good for automotiveI've been doing serial comms for > 40 years so I am well familiar with RS232 422 485, and how people blow things up. The major issue with 422/485 is that the chips have a finite max common mode voltage (Vcm) of, generally, -7V to +12V. LT made some -20 to +20, IIRC, but like everything from LT you use it only if you are paid by the hour regardlerss of whether your employer is making moneyAnd everybody has read that just 2 wires are needed, and mostly it kind of works, because with floating device will "adjust" its ground to around the average of the A and B wires, so it works by sheer luck. I always tell customers to have a GND wire and this dramatically improves both comms reliability and how much stuff gets blown up. One can stop the blowing up with voltage clamping (VDRs etc); I buy ~100k a year of those. With CAN, you have the same issue AFAICT (L9616 Vcm -5V to +36V) but not in a metal car because there is a common ground.CAN chips also draw a lot of current - tens of mA AFAICT.Do mfgs use CAN for important things like the "fly by wire" accelerator pedal? My VW (2012) is CAN but the pedal has a pot on it.

author: ataradov
author_rank: Super Contributor
timestamp: August 18, 2022, 06:27:57 am
content: Quote from: peter-h on August 18, 2022, 06:18:05 amA lot of modern systems would use CAN for everything. But there are typically multiple separate CAN networks. What you see on the OBD2 port may not carry safety-critical stuff. Or it may be relayed data for the diagnostics.Quote from: peter-h on August 18, 2022, 06:18:05 amWhere does the pot go? In new cars there is still some sort of encoder, but it connects to the bus as soon as practical.Long wires and analog pots in a car does not sound like a good combo.

author: Jeroen3
author_rank: Super Contributor
timestamp: August 18, 2022, 07:00:21 am
content: CAN bus is great. it provides you with anPublish-subscribe patternthat is basically completely hardware.It implements very easily, most CAN controllers have a number of mailboxes that are memory mapped ready for you to read. For example, Bosch CAN.(not you STM32 bxCAN, you're weird)When you have a simple ms counter tick, you can keep track of the expiration of receiving mailboxes. It's actually very easy to use.Most protocols just extend this model and split up the ID field into system specific flags.The complicated stuff is when you need to transfer more than 8 bytes. You need some fragmenting, sequencing and all relevant higher level stuff to get a block transfer over CAN bus.But it's not more complicated because of CAN, it's complicated because of reliable communication.

author: Berni
author_rank: Super Contributor
timestamp: August 18, 2022, 07:25:29 am
content: Some cars do have digital communication to the pedal, but it is not always practical to have all sensors directly on CAN.Typically you have computer boxes scattered around the car that talk with CAN and then handle multiple sensors/loads from one box. So there might be a box in the back of the car that handles, rear lights, trailer hitch, rear window defogger, fuel tank float etc.. In a similar way a lot of engine specific sensors might go directly to the ECU over a analog wire like the MAF, coolant temp, oil pressure..etc and then the ECU makes them available over CAN by sending them out periodically. So if the throttle is analog then it might be directly connected to the ECU or some other module that is conveniently close to the actual pedal. But if it is analog it will pretty much always have some form of redundant signaling so that shorting out a wire from the gas pedal doesn't make it go full throttle (well until Toyota screws up the software and makes it happen anyway).

author: JPortici
author_rank: Super Contributor
timestamp: August 18, 2022, 07:48:22 am
content: Quote from: peter-h on August 18, 2022, 06:18:05 ami don't remember what the pot is for.. .or you mean the throttle sensor? that is usually a lever moving a magnet on a shaped piece of metal or viceversa, read position with a hall sensor, convert to signal according to whatever scheme.accelerator is connected to one ecu, it may be analog signals with a certain relationship for verification / combination of analog-digital (one wire analog 0-5V one wire square wave with corresponding duty cycle) / digital signal using SENT / older and abandoned current loopif the ECU is not the engine ECU the accelerator position will be sent over canbus. It will probably be sent over canbus anyway as it may be needed to other systems as well (kick down to the transmission ECU)other critical systems, some old models of fuel pump used to be controlled via canbus, in some electric cars the inverter output power is set via canbus

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2022, 09:57:34 am
content: Quote from: Berni on August 18, 2022, 05:57:15 amProblem is, it doesn't guarantee every node successfully received the message, so you need to implement something by yourself anyway - usually just periodic flooding and timeouts, or separate acknowledgement messages (as specified by yourself).What ataradov mentioned, as far as I remember, the error counters are required by the CAN standard itself and thus at least usually implemented by the MCU CAN peripheral. Therein lies a danger, it might still need some software action like the peripheral going automatically to bus off state, but programmer having to manually poll a flag or get an interrupt and try enabling it again.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2022, 10:03:42 am
content: Quote from: peter-h on August 18, 2022, 06:18:05 amYeah, on physical level CAN is very similar to RS485 - no wonder because CAN design is originally motivated by RS485 - but thanks to being newer, it fixes the brainfarts of RS485, namely someone messing up the A/B signal naming at some point so the only way to know which is which is to try. CANH and CANL instead are well defined and everyone follows the standard. Another is the weird tradition of even professional designers not understanding the necessity of GND in RS485 system. Third is the stupid biasing mess of RS485 caused by the poorly thought out idle levels and receiver hysteresis, where newer transceiver chips kinda-sorta fixes the issue, but if communicating with existing devices, you can't know which transceiver they used, so have to really go for that biasing network analysis.CAN fixes all that, just add a 120 Ohm termination resistor between CANH and CANL, connect CANH, CANL and GND respectively to the bus, and everything Just Works.

author: peter-h
author_rank: Super Contributor
timestamp: August 18, 2022, 10:34:23 am
content: OK. Yes, I recognise the issues, which you point out completely correctly!That 120R resistor does draw a lot of current thoughI am also trying to work out what kind of driver support I would need to get CAN to do something useful. With ETH, you have LWIP, and you have to write the low level input/output code (actually you get it from ST, sort of working). With USB, you get a big mess from ST but eventually it works (I have a block device and a VCP running).

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2022, 10:47:47 am
content: Quote from: peter-h on August 18, 2022, 10:34:23 amWell, only when someone's sending, and it's notthatmuch. Dominant differential voltage is around 1.5V-2.0V or so, and if half of the bits are dominant, and half of the total bus bandwidth is being used, that will be 0.5 * 0.5 * 2.0V/60 ohms = 8mA (4mA on each terminator resistor).But you need to choose a resistor with proper power dissipation ratings so that you won't blow it up if CANH/CANL accidentally touches GND or +5V or, worse, 12V. Transceivers are typically designed to survive that.But sure, CAN is not low power.

author: Berni
author_rank: Super Contributor
timestamp: August 18, 2022, 03:34:43 pm
content: Quote from: Siwastaja on August 18, 2022, 09:57:34 amYes if you are looking for the CAN controller to tell you "This message has for sure successfully reached all recipients that want the message" then you indeed can't get that. Implement a separate ACK message in your application layer if you need that. In most cases you don't care if your message got to everyone, what is a cars body control module supposed to do if the fuel tank level sensor reading was not received? It could try to retransmit, but if nobody raised a error on the bus during that failed transmission then likely nobody is even listening so retransmiting won't get the message trough anyway.What the ACK mechanism actually does is that it makes sure every device that is actively participating on the bus has received the message with no errors. If just one CAN device finds the CRC calculation wrong it can intentionally break the ACK section of the message and so force the sender to re transmit it again in hopes of the message making it trough without corruption this time. This does mean that devices that did successfully get the message the first time around will get it twice, but this is usually better than simply not getting anything. All this happens inside the CAN controller, so you can be actively talking on a bus during a thunderstorm storm (that potentially kicks huge transients on the bus every so often), yet no messages get lost and never does a message contain corrupt data. The application layer doesn't need to worry about this, it just works.Yes you can get into bus off conditions and all that, but the driver should know how to deal with it. This is why i test firmware drivers by shorting out stuff randomly as its running. If it locks up for an extended period of time then the driver is shit and needs to be fixed. The I2C controllers on STMs i found are particularly easy to permanently lock up if you as much as look at them the wrong way.Quote from: peter-h on August 18, 2022, 10:34:23 amThe CAN bus is at 0V differential when idle so no current trough the termination. All the current draw is just the idle current of CAN transceivers just listening on the bus. Even when it does transmit it will be pulsing about 1 to 4V onto those 120Ohm and so not a lot of current. This is required to get good speeds over long twisted pairs. Having higher differential impedance required higher impedance cables, but even going to telegraph pole line spacing only gets you to 600 Ohm impedance.RS485 is worse here because it typically requires a biased termination that always draws power in order to keep the bus in the logic high idle state.(But modern transceivers have a zero offset built in to not need that). But is is also a simpler protocol than CAN. So if none of the high reliability bells and whistles that CAN provides are useful for your application then you might as well just use RS485.You don't need LWIP to get Ethernet working. You can send raw Ethernet frames into the PHY and they will get sent out. Connect another MCU to it using a cross Ethernet cable and that frame will be received on the other end. Much the same like you would use CAN. If you use a ethernet hub you could even have more than 2 devices on the bus. You only actually need LWIP once you want to not only conform to the Ethernet physical layer standard but also want to conform to IPv4 so that your device can take part in modern LAN networks (just because IPv4 is the language that switches and routers speak). Yes it brings extra complexity but it also means your device can send a few megabyte sized messages to the other side of the world in less than a second.

author: uer166
author_rank: Super Contributor
timestamp: August 18, 2022, 05:08:16 pm
content: Quote from: Berni on August 18, 2022, 03:34:43 pmAFAIK (and I could be wrong), it's the opposite, if evenonedevice receives the message successfully, it'll get ACKed via a dominant bit. The other nodes where the message may have been corrupted can't force a recessive bit, so the sender has no clue that all but one nodes didn't receive the message.This is a limitation of the dominant/recessive implementation and unless you have one sender and one receiver, the ACK mechanism is not really useful in the real world.

author: woofy
author_rank: Frequent Contributor
timestamp: August 18, 2022, 05:42:22 pm
content: Quote from: Berni on August 18, 2022, 03:34:43 pmAs I understand it, the ACK bit is dominant and a NACK recessive. I don't see how a node with a CRC error can scrub the ACK bit. It can only assert an ACK. Depending on how the node failed in the frame it might not even know where the ACK bit is as far as timing is concerned. All it can do is ignore the message.

author: peter-h
author_rank: Super Contributor
timestamp: August 18, 2022, 06:00:13 pm
content: QuoteYou don't need TCP/IP to use ETH but unless you are using ETH as some sort of private interconnect system, you do need it to produce something usable. I guess there are such private LANs in one-company product domains, especially if you want deterministic timing etc, but this is not common. And in many situations you can build a "private LAN" for a lot less money and complexity than ETH, using e.g. RS485 (which needs a Master, but often that is fine).Which I suppose is where CAN comes in. It is for where galvanic isolation isn't needed, which is only asubsetof "private LANs". Often you want or need isolation just going between two buildings, because the ground potential difference can be pretty big. Especially where mains earth is obtained by connecting to the Neutral wire, and when N is carrying say 10000A spikes, and the two buildings are on different phases... you get the idea. I've been building and selling isolated interface products for decades, and the difference in how many get blown up varies dramatically according to whether isolated or not.Is CAN intended to be multi-master? I know it won't blow up, or even take the chips out of spec (as would be the case with RS485) but is that normal usage?Many years ago I designed a private LAN using a token-passing mechanism, and MIL-1553 transformers on the physical layer. It did ~1mbit/sec app to app. Today you would use ETH for that, but only because of the integration available today. Another private LAN I interfaced to, many years ago, was a 64kbps one used in huge Hitachi heavy-industry PLCs, which used very high power (watts) to give it immense noise immunity. Big ferrite transformers for isolation. I built an interface to it using a Xilinx 3064 FPGA to construct a 64 bit UART, enabling my customer to interface to it via RS422, from PCs running unix.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 18, 2022, 06:03:34 pm
content: Quote from: peter-h on August 18, 2022, 06:00:13 pmThere is no concept of masters or slaves at all.It's just "shout to the common bus, subscribe to things of interest", that's it. You can use it for whatever you want; for some things, such strategy works fundamentally better than for others.

author: hans
author_rank: Super Contributor
timestamp: August 18, 2022, 06:15:58 pm
content: Indeed, there is no master. The message ID is transmitted at the start of the frame. Since a "0" on the bus is dominant, it means that lower bus messages are prioritized. Each transceiver will monitor the bus value and abort transmission if there is a collision as the losing node will see a mismatch on the bus versus it's own data.You could look at it as an open-drain circuit. For example, in I2c clock stretching, the slave can also pull a clock line down for a while till it's done processing. By reading the voltage level of SCL, the master can then wait till the stretch is complete.Pretty much everything on the CAN bus is a broadcast. You have certain data packets transmitted on particular IDs. In theory you could create a 'connection' structure within the 8 bytes of payload, or use like a "server" on a particular message ID which then handouts connections on separate message IDs for the data phase. I don't know, probably someone has done it, but since CAN complexity is all in the proprietary protocol stacks.. it's hard to figure out what's going on unless you have lots of detailed CAN logs and/or a live test system that you can retrigger, modify or replay messages on. But given that 8 bytes of payload is all you got, most systems will need some magic in the protocol stack to retain state across multiple packets (e.g. to implement command and memory packets for a bootloader)

author: nctnico
author_rank: Super Contributor
timestamp: August 18, 2022, 06:50:17 pm
content: Quote from: hans on August 18, 2022, 06:15:58 pmActually I'm working on a project that 'streams' data over the CAN bus using multiple CAN messages of necessary. Since the data integrity is well covered by CAN, the main concern is to check whether the length of what has been send it equal to the length and whether the CAN messages are received in the right order.

author: langwadt
author_rank: Super Contributor
timestamp: August 18, 2022, 06:59:09 pm
content: Quote from: nctnico on August 18, 2022, 06:50:17 pmI adapted this:https://en.wikipedia.org/wiki/ISO_15765-2skipping the Flow control frames

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 18, 2022, 06:59:56 pm
content: Quote from: nctnico on August 18, 2022, 06:50:17 pmI've never used CAN on a project as of yet. How is data integrity handled? Does it automatically compute and transmit CRCs? Or what other means does it use?

author: nctnico
author_rank: Super Contributor
timestamp: August 18, 2022, 07:11:14 pm
content: Quote from: SiliconWizard on August 18, 2022, 06:59:56 pmEvery CAN message has a CRC which is handled by the hardware. If you receive a CAN message from the driver layer, you can be very sure the message has been transported over the CAN network correctly.

author: peter-h
author_rank: Super Contributor
timestamp: August 18, 2022, 08:02:02 pm
content: So you need to serialise the packets, because not getting an ACK does not mean the far end didn't get the message, etc, etc. But presumably you aren't sending data over a large-latency channel (which would need a large reassembly window). With CAN delivery (or non delivery) is probably "instant".What made them choose 8 bytes?

author: ataradov
author_rank: Super Contributor
timestamp: August 18, 2022, 08:10:06 pm
content: Quote from: peter-h on August 18, 2022, 08:02:02 pmThey did not want one device to occupy the bus for too long.CAN FD extended that to 64 bytes. But they also made possible to increase the baudrate in the data phase, so overall duration is still short.

author: nctnico
author_rank: Super Contributor
timestamp: August 18, 2022, 09:06:53 pm
content: Quote from: peter-h on August 18, 2022, 08:02:02 pmI'm not reassembling anything. If a CAN packet gets lost, the entire message needs to be send again as CAN has no way to retransmit messages and I don't want to create the overhead tcp/ip has (for example) where each piece of data also has a two way handshake, sequence numbers, etc. The message that I need to send over CAN are typically small anyway (a few CAN packets at most) so re-sending the entire message is not much overhead. With a high enough bitrate, message transfer is almost instant.

author: uer166
author_rank: Super Contributor
timestamp: August 18, 2022, 09:44:28 pm
content: Quote from: nctnico on August 18, 2022, 09:06:53 pmThis is the way, don't overthink it. You can do an entire firmware update this way, and if it keeps failing repeatedly, the network is way too marginal to be useful.

author: JPortici
author_rank: Super Contributor
timestamp: August 18, 2022, 09:49:44 pm
content: Quote from: peter-h on August 18, 2022, 06:00:13 pmThere are no masters, there are no slaves. There are nodes. Each node broadcast messages in the network, each message will have its ID. Another node that want to read that message will have its filters set up to accept the ID

author: Berni
author_rank: Super Contributor
timestamp: August 19, 2022, 05:10:28 am
content: Here is what a CAN message looks like on a bus:As you can see there is a CRC section and the ACK is actually 2 bits long. It needs to have a dominant bit followed by a recessive bit in order for it to be successful ACK.So the way it works is that all devices calculate the CRC as they are getting it and will ACK when the CRC matches successfully, however if the CRC is wrong it the device can break the ACK section by transmitting back a dominant bit in the area where the ACK should be recessive. This intentionally breaks the message with the intent of causing it to be resent. Even if just ONE device on the whole bus fails a CRC check it will make it fail the ACK. All this happens auto-magicaly inside the CAN controller.Also notice how the dominant ACK bit is surrounded by by recessive bits. This is the mechanism that breaks the bus when you use too long cables. The address arbitration in the beginning requires the wires to be short enough for a 1 bit to make a full round trip to all devices.EDIT:Also at any point can a CAN device respond using a error frame that is 6 dominant bits in a row.This is the equivalent of nuking anything on the bus since a message is not allowed to have 6 consecutive dominant bits anywhere in it. So it destroys the message and forces a reset of state on all devices in order to give the bus the best chance of recovering.This means that if ANY device on the bus sees something on the bus that looks very wrong it can hit the nuke button. This is why messages rarely go missing with no ack or error.

author: ataradov
author_rank: Super Contributor
timestamp: August 19, 2022, 05:40:45 am
content: The node technically should never override ACK Delimiter on its own. It should always be recessive. It may be overridden as a part of the 6-bit error transmission:QuoteAnd for some reason for CRC errors the error is indicated only after the delimieter:QuoteSo, CRC errors and corresponding error flag would be disjointed, making it very hard to use for real error detection. For frames with a CRC error both bits of the ACK field would be correct.This will work fine if you use it as intended - broadcast and forget. Treat error flags as asynchronous resets not tied to any specific transmission.

author: Berni
author_rank: Super Contributor
timestamp: August 19, 2022, 06:00:47 am
content: Ah sorry i was assuming that the CRC error frame is sent instantly much like the other errors are, so that it would break the ACK.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 19, 2022, 12:06:10 pm
content: Quote from: ataradov on August 17, 2022, 04:08:07 pmThis is not correct, at least their dsPIC33CK, PIC32MK and PIC18 use something else and from the looks of it not compatible to each other. The ATSAMC21, ATSAME51 and ATSAME70/ATSAMV70 all use the Bosch M_CAN IP though.And I just found that they have a PIC32CM variant with CAN-FD now: PIC32CM2532JH01 / PIC32CM5164JH01I knew about PIC32CM, but so far I only found the variant without CAN.These are as far as I can tell a rebranded copy-paste job from the ATSAMC2x, only the memory options differ.Oh, there also is a PIC32CM with Cortex M23, Microchip does a bad job at naming controllers.But well, the CAN-FD variants are not in stock anyways.And regarding the STM32 from the OP, a few have CAN-FD now and actually use Bosch M_CAN, like STM32G4 or STM32H7 series.But STM changed it, they use dedicated SRAM and come pre-configured so the functionality is reduced.STM32G4 only have a subset with tiny FIFOs and while the STM32H7 allows for broader configuration it only has 10kiB of dedicated SRAM for two modules combined.So mostly the same but not really.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 19, 2022, 12:50:21 pm
content: Quote from: Rudolph Riedel on August 19, 2022, 12:06:10 pmIMHO, 10KB is a lot for such low-speed interface (CAN FD around ~5Mbps max), even if part of it is "wasted" on filter configuration and not actual FIFOs. At some point, you have to process the data anyway. The flexibility in H7 is great because you can exactly decide how many (1 or 2) and large FIFOs and fixed mailboxes, if any, are used, so nothing of that 10KB is wasted.

author: ataradov
author_rank: Super Contributor
timestamp: August 19, 2022, 03:41:36 pm
content: Quote from: Rudolph Riedel on August 19, 2022, 12:06:10 pmWell, yes. I mostly speaking about ARM devices. I just don't care about other stuff, and 8-bit specifically.Quote from: Rudolph Riedel on August 19, 2022, 12:06:10 pmLOL, yes.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 19, 2022, 04:14:29 pm
content: Quote from: Siwastaja on August 19, 2022, 12:50:21 pmThe thing is, one fully configured unit needs 17kiB, that is 128 11-bit filters (128 words), 64 29 bit filters (128 words), two RX FIFOs with 64 Elements for 64 byte messages (1152 words each), 64 RX buffers (1152 words), 32 element TX Event FIFO (64 words) and 32 TX buffers (576 words).Yes, you do not need all of this, but you are limited when you only have 10kiB to use for two units.2 Units, 1 full RX FIFO each (1152 words), 10 TX buffers each (180 words), 16 filter elements each (32 words) - 10912 bytes - oops.If you have full domain over the memory like with the ATSAME51 you can just setup whatever you need and reduce it a little if you are running low on memory overall. And if you are not using the CAN units they do not use any memory.With the H7 you have to put more planning into your application.

author: peter-h
author_rank: Super Contributor
timestamp: August 19, 2022, 04:53:03 pm
content: QuoteCould someone please explain what this means? 128 11-bit filters?

author: uer166
author_rank: Super Contributor
timestamp: August 19, 2022, 05:12:01 pm
content: Quote from: peter-h on August 19, 2022, 04:53:03 pmNormal CAN IDs are 11-bits. When you send a message, it has that associated ID. Some nodes on the bus care about that message, others don't. CAN peripherals provide a way to only accept frames with the IDs you care about to minimize software loading. I.e. the bus could be full of crap you don't care, but you'll only get CAN messages in the mailbox that you care about via those filters.In that example, the peripheral can do 128 of those 11-bit ID filters.

author: nctnico
author_rank: Super Contributor
timestamp: August 19, 2022, 05:30:02 pm
content: Quote from: uer166 on August 19, 2022, 05:12:01 pmAFAIK the filters can use masks so you can also filter ranges of IDs (at least this works on an STM32F1x chip I'm working with at the moment). So receiving CAN IDs 0x100 to 0x10F takes one filter where the last 4 bits are marked as 'don't care'.

author: uer166
author_rank: Super Contributor
timestamp: August 19, 2022, 05:31:57 pm
content: Quote from: nctnico on August 19, 2022, 05:30:02 pmYup, there's different kinds of acceptance filters, but it's a IP implementation more or less. I've seen even more granular ranges, dual filters, etc. It can get pretty complicated pretty quickly.

author: DiTBho
author_rank: Super Contributor
timestamp: August 20, 2022, 12:11:22 am
content: Found qty=3 Axi-Coldfire-v1 with a built-in CAN.Little nice boards, 20 euro each, brand new.I just need to understand how to- wire them into a CAN network(1)- write a simple applicationNext weeks ...(1) I don't know if the PHY is already on the board or if I have to add it.The MPU has built-in CAN support but CAN PHY should be added externally, I have to check the schematic

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2022, 06:48:34 am
content: Quote from: peter-h on August 19, 2022, 04:53:03 pmThis particular (quite advanced) CAN peripheral works like this:(an example:)* Create an acceptance filter so that message IDs between 123 ... 456 are put in RX FIFO 0* Create an acceptance filter so that message IDs between 0 .. 10 are put in RX FIFO 1, plus interrupt is also generated* Create an acceptance filter so that message IDs where ID & mask == mask, store into a buffer (not FIFO) and generate an interrupt... and you can have 128 of these configurations. I don't think I have ever needed more than... five or so? The fact STM32H7 "only" has 10KB of dedicated CAN RAM means you have to choose how much of that memory you dedicate for suchconfiguration, and how much to the actual message FIFOs / buffers. You can configure it pretty freely.And having a powerful CPU and a fundamentally slow bus like CAN, you can always choose to just receive messages and ignore them in software.But such hardware ability is of course great to have at your disposal.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2022, 06:58:01 am
content: Attached is the simple spreadsheet I use to configure the STM32H7 FDCAN memory layout. Checks if everything fits, and works as a code generator, too.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 20, 2022, 07:50:45 am
content: I've been trying to not say it, but it's a pretty complex protocol, almost CAN't

author: ataradov
author_rank: Super Contributor
timestamp: August 20, 2022, 07:55:34 am
content: The protocol is pretty simple. The controllers are complex because implementers decided to make them this way. There is absolutely no need for this complexity and modern MCUs can easily handle CAN traffic with minimal hardware processing. And thankfully controllers do have "simple" mode where you don't need to think about any of this.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2022, 08:01:22 am
content: It's some kind of tradition to offer very powerful HW features in CAN peripherals. It kind-of made sense when you used say 8-bit AT90CAN128 MCU or similar. Funnily, as the MCU processing power went up and HW acceleration features could have gone down, they didn't, instead we have most advanced HW acceleration features ever, in a low-bandwidth bus, coupled with a high-performance CPU.CAN itself is simpler than sliced bread, especially when you need a common bus - subscription model where messages are not very long so that it's a natural fit.If you need to construct longer datagrams out of several CAN frames, then it's obviouslysomeamount of work, but so is UART which hardware-delimits to 8 bits. CAN's 64-bit payload is 8x better than that, plus especially 29-bit IDs allow you to do both node addressing and data content description very simply, which in UART would require a few bytes of header and a software state machine to deal with all that. So CAN is very easy.But even advanced controllers are not usually that difficult to use. Just instead ofisr_received_message(){message = fifo_pop();if(message.id == 123)// do the thingelse// ignore message}you can:isr_received_message(){message = fifo_pop();// do the thing}andinit(){// configure acceptance filter for id 123, usually just a few lines of code, but of course you need to RTFM which is more work than if(id == 123)}

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 20, 2022, 09:36:38 am
content: The CAN module in the AT90CAN128 or ATMega16M1 was awfull, address the MoB, one data register for the message with its own "address counter".With the M_CAN I usually do not even use an interrupt anymore, I just check the FIFO in my main loop if something arrived between two time-slices.This even works with protocolls like ISO-TP since messages do not need to be answered immediately.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: August 20, 2022, 11:00:36 am
content: Quote from: Rudolph Riedel on August 20, 2022, 09:36:38 amThe whole MOB paging thing wasn'ttoobad, just an inconvenience - at least I thought so.But the CAN peripheral could have been much better documented. To the extent that the best documentation for it is a guide written by some random guy posted on avrfreaks.net. I copied it and put it in a nicely-formatted PDF to save for future reference in case it disappears someday.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 20, 2022, 01:40:11 pm
content: Quote from: Rudolph Riedel on August 20, 2022, 09:36:38 amThis works pretty decently because the slow speed of CAN and large amount of overhead limits the maximum message rate to a predetermined value; even with CAN FD, the arbitration part is still at 1MBPS at most and takes a lot of time per message.So even with a 1-element buffer this would be doable (like with simple controllers); having a FIFO capable of holding tens of messages makes it even more trivial and forgiving.The great thing in M_CAN is, you can configure some specific filter to put the message in different FIFO (or not put it anywhere) and generate an interrupt for that message only, without having to interrupt the system for the bulk of messages. I have been using this as a very foolproof control interface allowing device reset and firmware update. By being the highest priority interrupt in the system, the CAN flasher always Just Works even in presence of bugs hanging the system otherwise.But indeed, mostly I just pop everything from the RX FIFO in some repetitive handler, too. If you can prove the handler runs at some certain interval, it is easy to further prove the FIFO never gets full.

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 20, 2022, 03:02:01 pm
content: Quote from: HwAoRrDk on August 20, 2022, 11:00:36 amWell, awfull in comparision, I don't even know anymore when I implemented the code for the 90CAN128 CAN-controller from the datasheet, must been like 15+ years ago. And then I mostly used the same code for a decade or so, slightly reduced with the 16M1 since it has fewer MoBs.Well, this was AVR and the unit was copied over from some 8051 design I believe.It sure did the job.QuoteThat would have been nice to find something like this. :-)

author: HwAoRrDk
author_rank: Super Contributor
timestamp: August 20, 2022, 04:36:24 pm
content: Quote from: Rudolph Riedel on August 20, 2022, 03:02:01 pmI found it again, the forum thread is still there:https://www.avrfreaks.net/forum/tut-using-8-bit-avr-controller-area-network-can-register

author: peter-h
author_rank: Super Contributor
timestamp: August 23, 2022, 03:19:47 pm
content: The 32F4 has a firmware boot loader which has a CAN option. Has anyone tried to make it work? I read somewhere that the implementation is particularly difficult to use.Maybe if the product has a CAN interfaceonlythen CAN boot loading is a good idea, otherwise anything else should be easier - like RS232

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 23, 2022, 03:47:15 pm
content: This one?https://www.st.com/resource/en/application_note/an3154-can-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdfI really hope that I am reading this wrong, is this bootloader really using CAN-Identifiers for command codes?If yes - what the heck? XCP for example is around for almost 20 years now (and even a lot longer as CCP).

author: Siwastaja
author_rank: Super Contributor
timestamp: August 23, 2022, 04:03:18 pm
content: Even funnier is the CAN bootloader in STM32H7.They had to completely re-design the protocol just for the sake it to prevent anything existing from working.Additionally, they justhadto make it CAN FD only. No fallback to standard CAN. One couldimagineit would be obvious to be able to use standard CAN frames, andadditionallyuse CAN FD frames if faster firmware upload is required - usually it isn't.A total joke.

author: peter-h
author_rank: Super Contributor
timestamp: August 25, 2022, 05:47:29 pm
content: So, how would one load firmware into a 32F4 via CAN? I don't mean build your own programmer with another 32F4

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 26, 2022, 03:37:50 pm
content: Look for a CAN bootloader and flash it with the debugger?Yes, sorry, easier said than done and I have the luxury that a proprietary XCP bootloader kind of fell into my hands a couple of years ago.And a flash tool that works with Vector USB/CAN interfaces.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 26, 2022, 04:30:11 pm
content: Quote from: peter-h on August 25, 2022, 05:47:29 pmGet a USB-CAN interface (popular examples: Kvaser, PCAN; world is also literally full of cheap DIY CAN adapter projects you can buy from their designers) andA) try to find some stm32 CAN bootloader flasher software that supports the CAN bootloader protocol used by the 32F4,B) if you can't find that, read the documentation of the bootloader and write the tool yourself.USB-CAN interfaces are a total CAN (pun intended) of worms on their own; on linux, no problem at all since the interface is standardized (see SocketCAN) and thus, same application software works with any USB-CAN interface; in worst case, you may have to install a thing calleddriver(wow, what a great idea everybody understood, at latest, in the 1990's: provide one common interface plus a separate driver layer!).... except Microsoft; on Windows, total disaster because it's back to early 1990's (remember how every DOS game implemented their own drivers for each sound card?), so you have to write your application code to target one specific brand of USB-CAN interface; or a wrapper layer if you want to support multiple adapters. Luckily the interfaces are usually very simple because, as discussed, CAN itself is very simple.

author: peter-h
author_rank: Super Contributor
timestamp: October 19, 2022, 02:11:32 pm
content: I wonder if someone can help me. This may be trivial, or not... I am happy to make a donation to someoneI have a 32F417 driving a L9616 interface chip, whose C_H and C_L pins come out on a terminal block.This is purely a future option in the board I am working on, and no "driver" is being done unless somebody needs CAN, but I would like to detect whether that option (the L9616 chip) has been fitted, and check that the CPU-L9616 connection works.What is the absolute minimum amount of code which will do this?I think the L9616 is like a 2-wire RS485 transceiver, in which case it will loop everything back to itself, but if it disables RX during TX then nothing will come back and it can't be detected. The block diagram suggests that everything on the pins is always receivedbut there is some gating of the transmitter from the RX data. The ASC pin on driven from a GPIO, PC13.TXI and RXO are driven from PD1 and PD0 pins which are the default ones for the 32F4 CAN bus controller. Currently these are inputs, but it may be that once one selects the CAN controller, these pins get automatically initialised as required by that. Some 32F4 pins work that way; some don't and need to be set up.It may not be possible to tell if the chip is an L9616 or some other RS485 chip... Not much can be done about that!It may also be possible to test for this chip without using the CAN controller at all, just by bit-banging the two GPIO pins PD1,PD0. Not ideal, perhaps.I am using Cube IDE.Many thanks in advance

author: Berni
author_rank: Super Contributor
timestamp: October 19, 2022, 04:32:55 pm
content: Yep the easiest way to test is to simply toggle IO pin connected to TXO at a rate of about 1 to 1000kHz. Apply a CAN terminator on the CAN bus pins then poke them with an oscilloscope and you should see the typical CAN voltage levels. At the same time the RXO pin should be toggling in sync with how you drive TXO. The RX1 and ASC pins can be left unconnected.If you want to actually send communication over it then you can try initializing a UART on TXO and RXO. Anythyng you send out should appear on the bus and you should receive it back into the UART (since CAN is always listening on the bus, even when transmitting)

author: Doctorandus_P
author_rank: Super Contributor
timestamp: October 19, 2022, 04:34:00 pm
content: While the data in CAN frames used in the automotive industry is mostly undocumented, CAN is also used in "industry" for things like frequency inverters and servo motor controllers. There are also a bunch of completely Open Source implementations of closed loop stepper motors that use CAN. It may be a good starting point to get to know CAN. If you're not into motors, there are probably lots of other open source projects (including libraries) that use CAN in some way. Studying a working applictation is usually a lot easier then trying to build something from scratch yourself.

author: eutectique
author_rank: Frequent Contributor
timestamp: October 19, 2022, 05:44:03 pm
content: Quote from: peter-h on October 19, 2022, 02:11:32 pmYou can set Tx pin as GPO and Rx pin as GPI, then toggle Tx pin. If the transceiver and termination are fitted, Rx pin will follow Tx.Edit:yep, as already suggested in comment #73 earlier.

author: peter-h
author_rank: Super Contributor
timestamp: October 19, 2022, 06:12:42 pm
content: What if there is no termination?

author: Berni
author_rank: Super Contributor
timestamp: October 19, 2022, 08:00:48 pm
content: Quote from: peter-h on October 19, 2022, 06:12:42 pmThen you get weird problems just like using a I2C bus with no pullups.The CAN transceiver only pushes a voltage onto the bus when transmitting a dominant stage or it lets go of the bus otherwise. So the termination pulls the bus back to 0V. This is just a 120 Ohm resistor across CAN H and CAN L

author: Siwastaja
author_rank: Super Contributor
timestamp: October 20, 2022, 11:56:31 am
content: Yes, CAN termination resistor(s) have two different purposes:1) as name suggests, termination. This is relevant in long transmission lines to prevent overshoot and ringing.2) passive drive of one of the signal levels, just like pull-up resistor does in open-drain buses. You could call itpull-togetherresistorIf your bus is physically short and/or you are fine with substandard signal integrity, CAN is robust enough to work without termination. It can't work withoutpull-together, though, just like I2C won't work without pull-up. For this purpose, one resistorsomewhereis enough. It doesn't need to be exactly the expected 120|120 = 60 ohms. Single 120 ohms somewhere on the bus works on lab table for testing. Or 100 ohms or 150 ohms if you ran out of 120-ohm resistors.

author: wek
author_rank: Frequent Contributor
timestamp: October 20, 2022, 09:40:37 pm
content: If I'm not mistaken, CAN PHYs tend to have a weak "pull-together" (nice name!) built in, to prevent spurious transitions on floating bus terminals. The PHY in question says 10-100kHz input differential resistance in recessive (undriven) state. Should be good enough for a slow test.Or am I wrong? I never (ab)used this.JW

author: Berni
author_rank: Super Contributor
timestamp: October 21, 2022, 06:08:26 am
content: It is possible that some transceivers have low enough input resistance for it to work with no terminator, but definitely not all of them.In most cases i seen CAN not work at all with 0 terminators. This is because CAN can go pretty fast and the CAN controller expects the bus to follow pretty closely with what it is transmitting, otherwise it assumes there is something wrong on the bus and it should stop transmitting to prevent it from getting even worse.Actually properly terminating a CAN bus at the ends of every cable run is not that important indeed. The bus is still slow enough that at the short distances it works at the signal reflections don't cause that much of an issue. So it works in many cases as long as there is one terminator somewhere as that pull-together

author: ataradov
author_rank: Super Contributor
timestamp: October 21, 2022, 06:27:29 am
content: Yes, but this is a function of the actual CAN controller. Transceiver would just reflect the state on the RX/TX pins. And if you are just using GPIOs for testing, it would not matter.And I also appreciate the term "pull-together".

author: JPortici
author_rank: Super Contributor
timestamp: October 21, 2022, 07:51:24 am
content: Well there is the Single Wire Can... i only encountered in some instrumentation cluster line, the line goes at a low data rate and the transceiver has to support the function