Change CAN bitrate up to 8 Mbit/s - Page 1
Forum section: electronics / general

author: Joker
author_rank: Newbie
timestamp: October 13, 2022, 10:52:06 am
content: Hello guys,I have a question about the CAN/CAN-FD standard.As we all know, CAN-FD turns up the bitrate for the payload section only. Can we increase the bitrate for the whole Frame with the arbitration, payload, trailer, etc. The whole BUS contains only CAN-FD transceivers.The protocol overhead of CAN is quite high, and if only a few bytes are sent, the arbitration + trailer part is higher than the payload, which is sent with max 1 Mbit/s.Could it work if I use a CAN-FD transceiver and increase the whole bitrate up to 8 Mbit/s or more?Thanks

author: JPortici
author_rank: Super Contributor
timestamp: October 13, 2022, 11:01:13 am
content: I want to say probably, but it depends on whether the controller can run at a higher frequency. Also, the whole network has to run the same way, you can't have only one or two nodes doing that.Anyway can is not expected to exchange a big amount of data, in fact other protocols are being used in that case. Protocols based on ethernet for example.

author: Joker
author_rank: Newbie
timestamp: October 13, 2022, 11:07:39 am
content: Quote from: JPortici on October 13, 2022, 11:01:13 amIt should be hard realtime capable, robust and fault tolerant. Ethernet based protocols are not the best standards to go with. I was thinking about flexray aswell, but it would be cheaper to get CAN-FD transceivers and increase their bitrate.

author: GeorgeCh
author_rank: Contributor
timestamp: October 13, 2022, 11:55:37 am
content: Hello,I work quite often with CAN/CANFD and as far as I known, in the CAN FD specification is specified/implied that the arbitration phase is based on the standard CAN specification. In this case the maximum bitrate for the arbitration phase would be, as you stated, 1Mb/s.Maybe there might be some transceivers/controllers but I haven't had the pleasure of working with them.If I may ask, how much data are you expecting to exchange? For example in an automotive application, a 500K/2Mb CANFD network its able to support more than 7 Nodes, each one with multiple DLC 64, 10ms periodic frames.Also, if you seek realtime, maybe ethercat would be a better solution than ethernet.Personal note:I hate flexray, I have more than a few gray hairs because of it, I don't recommend it

author: Joker
author_rank: Newbie
timestamp: October 13, 2022, 12:30:14 pm
content: It would be a specific application up to 50+ devices with periodic frames about every 50-65 us. Payload would be 8-12 bytes.

author: eutectique
author_rank: Frequent Contributor
timestamp: October 13, 2022, 03:26:09 pm
content: Quote from: Joker on October 13, 2022, 12:30:14 pmYou can obviously try to get as high baud rate as you like, but this would violate the standard (relatively minor thing to worry about in your private network) and would probably be out of spec of your CAN controller (not to be confused with CAN transceiver). As many node as you like would probably stress the transceiver, but check the specs, again.

author: GeorgeCh
author_rank: Contributor
timestamp: October 13, 2022, 03:54:12 pm
content: I think CANFD might be a stretch. As eutectique pointed out this would be out of spec and I'm not sure you will find a CAN Controller that would be tolerant. But, if you find something out that works, please share it, I would be interested to see how it works.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: October 13, 2022, 08:34:20 pm
content: Quote from: Joker on October 13, 2022, 10:52:06 amWhat MCU are you using ?You would need to check the CAN peripheral on your MCU, as they likely vary in how they manage the change in speed.I would expect this to be somewhat black-box hidden, as they will focus on the standard, not some niche usages.Other approaches may be more productive12 bytes in 65us is a data flow rate of ~1.5Mb,* Use standard CAN setting, (on a CAN-FD capable part, as that is likely faster inherently) but increase the CAN peripheral clock, to overclock std-CAN operating with CAN-FD transceivers, into 2~5Mbps times.* Use standard CAN -> CAN-FD handover, but increase the CAN peripheral clock, to overclock if actually needed.I see AD have 12Mbps rated isolated CAN-FD interface drivers, so those give margin in both speed and robust operation, and faster payload may gain you enough time to tolerate standard arbitration.* Use UART in 9 bit address/packet mode, with CAN-FD data transceivers, or newer RS485 transceivers. (many now have auto-direction control, a simple monostable that remove drive after xx us )If you have open choice on MCU, I'd look for a higher end one with fast peripherals. Maybe something like Nuvoton M463 series ? - it manages HS-USB and CAN-FDM253 48Mhz MCU : CAN FD- 1 set of CAN FD controller with up to 64 data bytes per message- Compliant with CAN protocol version 2.0 part A, B and ISO 11898-1: 2015- Programmable receive and transmit FIFO- Accessible 1-Kbyte RAM memory to allocate up to 256 wordsM463 200MHz MCU 2 sets of CAN FD (may be a bit new?)Conform with CAN protocol version 2.0 part A, B and ISO 11898-1: 2015CAN FD with up to 64 data bytes supportedTwo configurable Receive FIFOsSeparate signaling on reception of High Priority MessagesConfigurable Transmit FIFO, Transmit Queue, Transmit Event FIFODirect Message RAM access for CPUProgrammable loop-back test modeMaskable module interruptsTwo clock domains (CAN Core clock and AHB clock)Power-down support

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: October 14, 2022, 09:42:32 pm
content: Quote from: PCB.Wiz on October 13, 2022, 08:34:20 pmI find these interesting, in particular the M463.Unfortunately I can not find a distributor for these (EMEA).

author: NorthGuy
author_rank: Super Contributor
timestamp: October 15, 2022, 04:21:32 am
content: Arbitration requires round trip, so it must be slow enough to get the response of the peer(s) within the bit time. Data is unidirectional, so it may use much faster bit rate. This is the idea behind CAN FD. The longer your packets, the more you benefit from FD.You can use any bit rate, as long as all the participants use the same rate and the timing constrains are met. The maximum achievable speed of the arbitration phase will depend on the transceiver propagation delays, the length of the bus, and the CAN hardware of the peers. So, you can improve it a bit, say, by using better transceivers. But 8 MHz is probably not realistic.

author: Joker
author_rank: Newbie
timestamp: October 19, 2022, 08:20:05 am
content: I'm using an STM32G4 MCU, which should be capable of increasing the bandwidth accordingly. Already tried it and it worked with CAN-FD with an arbitration rate of 2 Mbit/s. Above 2 Mbit/s it fails.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: October 19, 2022, 07:27:47 pm
content: Quote from: Joker on October 19, 2022, 08:20:05 amIs that boost of the initial arbitration not enough for you ?12 bytes in 65us is a data flow rate of ~1.5Mb, and most bits are sent at the higher FD speed.

author: Joker
author_rank: Newbie
timestamp: October 20, 2022, 01:05:42 pm
content: Quote from: PCB.Wiz on October 19, 2022, 07:27:47 pmIt would be enough for one side of the communication. If I take a CAN-FD packet with 12 Bytes of payload and send it over normal CAN-FD with 1 Mbit/s Arbitration and 8 Mbit/s Payload.The results are:39 us for the arbitration + trailer15.375 us for the payload of 12 BytesOverall message transmit time = 54.375 usTherefore it would be an overall bandwidth of ~3 Mbit/sWith 2 Mbit/s arbitration + trailer, I would cut the 39 us in half -> 19.5 us. So overall message time is 34.87 us.Overall bandwidth is ~ 4.6 Mbit/sI am under 50 us. So I'm happy with this, even I want it faster. ^^

author: NorthGuy
author_rank: Super Contributor
timestamp: October 20, 2022, 02:25:03 pm
content: Quote from: Joker on October 20, 2022, 01:05:42 pmI guess since you're selecting the speed on your own, all devices are yours, and you don't need to conform to an existing network. In this case, there are few things you can do:1. See if your controller can use 11-bit SID instead of 28-bit EID. This will shorten the arbitration phase dramatically.2. Use longer packets. Repeat your calculations with 64-byte data instead of 12-byte data. See how much faster it is. Longer packets require better clock source though.

author: uer166
author_rank: Super Contributor
timestamp: October 20, 2022, 07:28:30 pm
content: Quote from: NorthGuy on October 15, 2022, 04:21:32 amYup, and it's even more of an issue if you have SI/termination issues and you need to wait for the state to settle down within a bit. I wonder if there is a readable graphic of the arbitration constraints. Presumably it's dependent on the timing settings of the sampling point in CAN peripheral, and those are quite flexible.