One of my friends works on developing heavy equipment and after learning a lot about CAN he told me that it should be more popular among makers and hobbyists because of its versatility and tolerance of noise and bad electrical conditions.
@@ArnaudMEURETthis board is, but you can get inexpensive MCP2515 modules. You can also use an ESP32, which has the CAN bus controller embedded, you only need a transceiver for that.
It’s used in Voron 3d printers with Klipper Firmware for communication with the print head for example. The setup was a pain because I didn’t know anything about can when I modified my Voron. But now it runs and no issues with it.
It's not that simple, if thought through properly there are more economic considerations that decide whether you go one way or the other. CAN was developed as a controller area network that was cheaper to implement than Ethernet. Every node basically needs a CAN controller and an MCU. More often than not the maker community is better served with RS485 using a simple UART. A smart designer looks at over all cost, not just "gee that's cute". I ran a development business for 30+ years that made those decisions for customers.
One could say, dont ask dump question...BUT I like your questions much, because they explains lots of things and goes into deeper understanging protocol without knowing about it anything. You are not just "yes man".
I have to object to the opening frame assumption that it's better than I2C etc. Don't get me wrong, I love CAN and if you want to connect a bunch of smart modules in an electrically hostile environment then there's not a lot better, but if you're looking at a bunch of micros or peripheral devices then I2C, I2S and SPI have significant advantages within their particular reasons for existence. Always remember: "Horses For Courses". All buses were developed for a particular use case and they all have their relevance tied to that use case. You may well use any for almost any other use case but it will be less than optimal. So, in the right environment yes CAN is really cool. For its optimal use case you would be hard pressed to find better.
@@jrstf SPI and CAN are 2 completely different animals and in no way dependent on one another. It just so happens that the CAN chip described here is a peripheral chip that allows you to add CAN to any processor via SPI. There are many microprocessors that have CAN implemented directly on chip and while they may also have SPI, that is in no way connected to a need if you want CAN.
@@jrstf Absolutely, because SPI is so simple to implement that every micro has an SPI bus and only specialised applications require CAN, so there is simply no market for such a device. Think of it this way. 50 transistors needed for an SPI I/F and 500-1000 needed for a decent CAN implementation. So if you were designing a micro and the market has 100% demand for a micro with SPI and 2% for a micro with CAN what would you put in it? Not if you were Microchip and made a lot of real low transistor count micros and missed the boat on making one for the upcoming automotive CAN market would you delay the boat even further or make an add on chip that your customers could use with any of your existing chips while you do the leg work to get your own CAN CPU out? That actually probably sums it all up.
@@jrstf you really don’t seem to understand at all, CAN and SPI are totally different and unrelated, the CAN controller just interfaces with a CAN bus and with the microcontroller through SPI. You gets loads of different kinds of protocol converters. SPI and CAN are in no way dependant on each other, this chip was just created since most MCUs have SPI, as they said, lots of MCUs have CAN controllers built in. What is your point with your comment about nobody making a SPI bus that connects with CAN to an MCU? Why would someone do that? SPI is suitable for simple master to slave (sometimes multiple slaves) communication, CAN is totally different, it is a broadcast kind of communication, any device on the network can transmit or receive at will. Totally different kinds of communication.
Such an amazing interview, it was mesmerizing to watch and learn about all these edge cases of CAN usage. By the way, there is a rising use of CAN in Hobby 3D Printing, instead of passing dozens of cables from the main board to the moving hotend board, often there is a smaller satellite board that is mounted directly on the hotend. Examples of such boards are the BigTreeTech EBB 36/42, BigTreeTech SB2209 as well as their BTT U2C board which is a USB-to-CAN board with 3 transceivers on it and lots of different connectors. Most of their 3D printer controllers boards include a CAN connector as well which can be used in USB-to-CAN-Bridge mode by Klipper (a popular controller software for hobby 3D printers).
Interesting stuff. Thanks Robert and Ken. It would be helpful to look at things like Flexray, CAN-FD, MOST etc. All the vehicle busses are super interesting and changing quickly these days. Ethernet is also becoming common in high end cars now. (PS: I am a design engineer on the Ghost immobiliser, the original aftermarket CAN immobiliser)
@@VndNvwYvvSvv it seems to be more a direct connection to embedded systems for firmware updates, infotainment systems and the odd body controller or gateway. I’ve not seen any mission critical information using Ethernet.
Impedance of ethernet cable for frequencies around few MHz is around 120ohm, the main problem is in the temperature stability. Anyway, very interesting video, I was always afraid of CAN, because it seemed to be too complicated.
I've seen linux CAN bus drivers that link the can bus as an Ethernet device too. Not just as serial. You can then treat the device as a packet-ized data source which seems more natural for CAN bus.
Listening around 25:00 in, I'm very glad that Ethernet does not act like the CAN Bus. Imagine needing all of the systems in the WAN to be perfectly functional (this includes all Ethernet cables being well-built and reliable) in order to use the internet. The Internet would never be up! Between intermittent cables and packet collisions alone, we'd be soooo out of luck.
Ethernet started out as a bus, an ethernet cable, fat or thin, has the same problem as CAN. What he described is a feature of CAN, if you instruct both wheels to change to a certain speed and only one wheel receives the message the driver will be very surprised by a car that is suddenly driving in a circle. CAN automatically avoids this, ethernet does not. The two technologies have very different use cases.
I still remember when offices would use TokenRing instead of Ethernet. Eventually Ethernet won, because it just makes a lot more sense where there is a lot of data at high speeds. But that does not mean CAN is useless, for continuous monitoring of dumb devices CAN is cheap and very effective at what it does.
One huge downside - during the recent chip shortage pretty much all CAN transceivers just disappeared. I'd rather keep using RS485, simpler transceivers and higher speed. Also looking in the direction of LVDS (both on-board and over wires).
Vehicles use the OBD (On Board Diagnostics) software layer protocol which is sent over a multitude of hardware layer protocols, dependent on the manufacturer. CAN is only one of the hardware layers.
Another great option is the Kingst LA1010, cheap but very good for the price! I use it professionally and it's perfectly adequate for signals around a few megahertz.
I think the issue with CAN is that it _looks_ very complicated and frightening to the newcomer, but then degenerates to a bunch of competing standards on top of what’s actually needed to get started. This is something I’m going to have to get stuck into though and have working by the end of the day/week depending on my skill level.
Am I understanding correctly that, using the remote packet, you would request a value to be sent one time versus being subscribed to that value to receive continuously? Or, by sending a remote packet, do you thereby subscribe to continuous updates? If so, how does one unsubscribe - do you send another?
Not subscribed, it's just a request/response. Two packets are the same except of course the request contains no data but does have the flag set. Subscribe makes no sense anyway since packets don't contain destination addresses, the response is broadcast as are all packets.
The selection of needed PDO:s, out of about 800 to select from, is a situation you can find yourself in, if using CAN ( or ethercat ) to run a servo, for example. Not recommended for beginners ( who has to understand all whose options, to be able to select the proper ones for their application ).
hello all, I have a question about CAN bus topology- You know LOXONE and they have technology Loxone TREE (it's CAN bus on 50kbps with IC MAX3..) and they connect this CAN in STAR to STAR and any topology. Question: is it correct to use CAN other topology like daisy chain? It's safe? what do you thing?
... the stubs should be at max 30 cm long! Termination must be set at the very ends of the bus. If you look very close to some short stubs, they might look like a star... 😅
I mentioned the NXP Application Notes. And that rules. If you make your stubs 10 meters long: who cares? CAN BUS is not a star TOPOLGY!!! Hint: take an oscilloscope and check the signal.
@@ragohy I don't see anyone mentioning NXP or 10m stub, so I don't know who are you talking to. But you may want to check ISO 11898-3 if you trying to say CAN star topology is not a thing. And duh, bus is not star... wtf
CAN bus requires all devices to see each bit at the same time and any device can takeover a packet by forcing out a zero in response to the prior bits. So any device can send at any time and a bit must be able to travel the length of the cable and back in one bit time. If Loxone has built repeaters which implement these requirements, thus allowing branches, then more power to them.
No, it's a floating bus that hovers around 2.5v on each side of the bus... the voltage is measured between Hi and Lo... the reason for this is to help remove common mode noise. The other thing to remember in automotive is that the ground is a global chassis ground, so if you absolutely need to ground reference, everything then it's achieved through the chassis but the ground is not needed for CAN transmission... ethernet is the same...
It's only when you suspect your grounds would be on much different levels is when you need to ground two devices together. For example engine cranking and battery in the trunk. The engine controller might few volts apart from battery controller if the ground is not good. The solution is not third wire though. The solution would be making sure the battery (-) and alternator is properly attached to the the chassis. Otherwise you may exceed the common node transceiver limit and it will clip the signal and interrupt the communication. Another maybe better example would be if you have motor driver with CAN. Obviously you will have some ground going to the motor. But imagine it is as long wire with few ohm resistance. If you start pulling few amps, your ground will move against other devices, because voltage drop through the ground wire. Depending on the transceiver you may be fine if ground shifts by few volts. But to make sure everything works for Ng high load, you have to use thicker ground wire again. If two devices were truly separated. For example both battery powered, the grounds would be close to each other even with just two wires, because can transceiver outputs have about 20k resistance to ground. It's large but it it would make ground at the same level.
I would love to use CAN, but it is just too limiting. Most of the built in or cheap controllers do not support CAN FD, so you are limited to 8 bytes payload. Even with CAN FD this is only 64 bytes. Sure, for dedicated stuff it can be ok, but if you want something more flexible, and reconfigurable it is PITA. I am trying to switch from 100Mbps Ethernet (40 devices, everything would fit on
That example with the pico boards was not a good example. It uses micropython with a library that isn’t yet part of the standard rp2 library (judging from what Ken said) and that library abstracts everything away. That software example was useless for understanding CAN. If you are showing people something, keep it as standard as possible, use standard, unmodified libraries and include your custom library separately. This was also a bad example as the CAN bus was set up with a single function call with no parameters, just using default parameters. Yes default parameters can be useful but in an example like this it would have been helpful to just type the parameters too. Since it was just set up with a single function call with no parameters it gives no information about CAN at all. Defaults when setting up something like a CAN bus shouldn’t exist, since they are key properties of the signal, defaults are a good idea in theory but not in practice. Using bitrate as an example, you might get some examples working fine communicating between two of these boards just using the single function call with no parameters to set it up, but then what if you want to connect to a device you didn’t create? It may not work and you may have no idea why, since the issue is the bitrate which is a property of the CAN signal that is completely hidden from you since you are just using defaults. Just using defaults may be easier right at the start but in the long run it is better just learning things like that completely from the start. Learn right at the start you need to set the bitrate and that it needs to be the same for all devices on the network. It’s not that hard. I feel a lot of micropython libraries, including this one, dumb it down too much. Yes simplifying it for people to learn is good but there is also going too far, you have reduced using CAN down to three function calls, setup (with no parameters necessary), transmit and receive, you have hidden far too much in the process especially with defaults. It doesn’t benefit anyone dumbing it down this much. You should learn at least the core properties of the signal, like bitrate, right at the start, there is zero benefit to abstracting away having to set the bitrate. Overall this video just doesn’t seem that useful. The explanations didn’t seem that useful and the code example was useless.
The question that comes to me is, do I really need to know how the notebook works internally to write a comment on youtube? the answer is no. To make use of a communication protocol I do not need to know the internals, i need to know how to make use of it. I do not need to know exactly how the human body works, to take a walk in the park, it is enough to be able to walk. Thats my problem, everybody seems to want to teach us how can bus works, but who cares, please teach us how to easy utilize it in our project.
@@Lisas4us if you think you don't need to know how the bus works then you are a fool and really don't know what you are doing. Your other examples like the notebook and human body are ridiculous and irrelevant. In case you didn't realise, when you are implementing communication between devices you can't really just ignore how the protocol works, especially when the communication method has hardware requirements. Sure just knowing how to use it at a very high and basic level might work for basic hobbyist projects but try any communication method for more than a simple case and you will need to know how they work. If you don't just use premade boards then you need to know how the protocol works and what it needs to work, like the transceivers and termination resistors. For any communication method, to be able to debug issues with the communication method, you need to know how it works. If you want to stay at the level of being an absolute beginner then keep just using premade boards with far too abstract micropython libraries. If you want to actually progress, make your own boards and not get your hands held when programming the boards then you need to learn how the communication protocols work. If you can't handle learning how a simple protocol like CAN works then you aren't going to get far in any form of embedded engineering.
@@conorstewart2214 Well, I agree. That analogy is stupid, since here we actually need to know how something works. We can't limit ourselves to use libraries all the time, but calling him "fool" and "you dont know what you are doing" is not nice, considering you are a experimented EE. I think that only applies for people that really wants to earn a life from this, but other people just likes this as a hobby and they really dont need to know the, lets say, "heavy" things, because its just that, fun. No offense, I say that because I saw your comments on Arduino videos. Valid points for sure, but even if Arduino claims other things, their boards are just toys. No sense on commenting claims about stuff.
I do a lot of Raspberry and arduino, and I watched a couple of can bus tutorials the past couple of years. I have plenty of use for such a communication system, but am always turned down by the way it is explained. Who cares how the signal looks like? Think arduino would have showed us the signal of whats coming out of the USBto TTL converter and tried to explain us on this level how arduino works, never ever anyone would have used it. So to do Can bus, we need a board that can receive and send. A library that can be imported to the project. Pin definitions , and a void function to send something to a board. That would make can bus popular.
I just don't think can is what you're looking for, it wasn't developed to be a plug'n'play solution for entry level hobbyists, nor was it intended to be used directly by consumers, it's meant to be a robust medium distance communication protocol for automotive and industrial applications (i.e. designed for use by professional engineers). It takes a modicum of technical understanding and effort to setup properly. You aren't the intended user, so it won't be easy for you to use.
That's what you get for mentioning vaccines! Seriously, we know many comments are deleted when we see a comment count that is vastly higher than the number of listed comments.
I don't like the way Robert conducts interview. He change the current subject without listening to the end. His questions are superficial, it's worth at least a little preparation for the conversation. I'm sure Ken could tell a lot of interesting things. but here w have to listen for more than an hour to what could be learn in 5 minutes from Wikipedia
Saele are way over priced and not worth it. dreamsourcelab has just as good, in some cases better, for much cheaper -- if you get the high end version, it has much nicer leeds than saele.
One of my friends works on developing heavy equipment and after learning a lot about CAN he told me that it should be more popular among makers and hobbyists because of its versatility and tolerance of noise and bad electrical conditions.
For makers’ budgets, these boards are extremely expensive though!😢
@@ArnaudMEURETthis board is, but you can get inexpensive MCP2515 modules. You can also use an ESP32, which has the CAN bus controller embedded, you only need a transceiver for that.
It’s used in Voron 3d printers with Klipper Firmware for communication with the print head for example.
The setup was a pain because I didn’t know anything about can when I modified my Voron. But now it runs and no issues with it.
It's not that simple, if thought through properly there are more economic considerations that decide whether you go one way or the other. CAN was developed as a controller area network that was cheaper to implement than Ethernet. Every node basically needs a CAN controller and an MCU. More often than not the maker community is better served with RS485 using a simple UART. A smart designer looks at over all cost, not just "gee that's cute". I ran a development business for 30+ years that made those decisions for customers.
We still use i2c or uart because there are tons of sensors that can only read by that protocols
One could say, dont ask dump question...BUT I like your questions much, because they explains lots of things and goes into deeper understanging protocol without knowing about it anything. You are not just "yes man".
A great video that I wish I had seen 10 years ago when I first started working with CAN Bus. Thank you!
I have to object to the opening frame assumption that it's better than I2C etc. Don't get me wrong, I love CAN and if you want to connect a bunch of smart modules in an electrically hostile environment then there's not a lot better, but if you're looking at a bunch of micros or peripheral devices then I2C, I2S and SPI have significant advantages within their particular reasons for existence. Always remember: "Horses For Courses". All buses were developed for a particular use case and they all have their relevance tied to that use case. You may well use any for almost any other use case but it will be less than optimal.
So, in the right environment yes CAN is really cool. For its optimal use case you would be hard pressed to find better.
Well yes since you can't talk to the CAN controller without SPI.
@@jrstf SPI and CAN are 2 completely different animals and in no way dependent on one another. It just so happens that the CAN chip described here is a peripheral chip that allows you to add CAN to any processor via SPI. There are many microprocessors that have CAN implemented directly on chip and while they may also have SPI, that is in no way connected to a need if you want CAN.
@@etmax1 - Okay. But I bet nobody makes a SPI bus that interfaces to the processor with a CAN bus.
@@jrstf Absolutely, because SPI is so simple to implement that every micro has an SPI bus and only specialised applications require CAN, so there is simply no market for such a device. Think of it this way. 50 transistors needed for an SPI I/F and 500-1000 needed for a decent CAN implementation. So if you were designing a micro and the market has 100% demand for a micro with SPI and 2% for a micro with CAN what would you put in it? Not if you were Microchip and made a lot of real low transistor count micros and missed the boat on making one for the upcoming automotive CAN market would you delay the boat even further or make an add on chip that your customers could use with any of your existing chips while you do the leg work to get your own CAN CPU out? That actually probably sums it all up.
@@jrstf you really don’t seem to understand at all, CAN and SPI are totally different and unrelated, the CAN controller just interfaces with a CAN bus and with the microcontroller through SPI. You gets loads of different kinds of protocol converters. SPI and CAN are in no way dependant on each other, this chip was just created since most MCUs have SPI, as they said, lots of MCUs have CAN controllers built in.
What is your point with your comment about nobody making a SPI bus that connects with CAN to an MCU? Why would someone do that? SPI is suitable for simple master to slave (sometimes multiple slaves) communication, CAN is totally different, it is a broadcast kind of communication, any device on the network can transmit or receive at will. Totally different kinds of communication.
Such an amazing interview, it was mesmerizing to watch and learn about all these edge cases of CAN usage. By the way, there is a rising use of CAN in Hobby 3D Printing, instead of passing dozens of cables from the main board to the moving hotend board, often there is a smaller satellite board that is mounted directly on the hotend. Examples of such boards are the BigTreeTech EBB 36/42, BigTreeTech SB2209 as well as their BTT U2C board which is a USB-to-CAN board with 3 transceivers on it and lots of different connectors. Most of their 3D printer controllers boards include a CAN connector as well which can be used in USB-to-CAN-Bridge mode by Klipper (a popular controller software for hobby 3D printers).
Interesting stuff. Thanks Robert and Ken. It would be helpful to look at things like Flexray, CAN-FD, MOST etc. All the vehicle busses are super interesting and changing quickly these days. Ethernet is also becoming common in high end cars now.
(PS: I am a design engineer on the Ghost immobiliser, the original aftermarket CAN immobiliser)
The Ethernet protocol? What a terrible idea
@@VndNvwYvvSvv it seems to be more a direct connection to embedded systems for firmware updates, infotainment systems and the odd body controller or gateway. I’ve not seen any mission critical information using Ethernet.
Impedance of ethernet cable for frequencies around few MHz is around 120ohm, the main problem is in the temperature stability. Anyway, very interesting video, I was always afraid of CAN, because it seemed to be too complicated.
I've seen linux CAN bus drivers that link the can bus as an Ethernet device too. Not just as serial. You can then treat the device as a packet-ized data source which seems more natural for CAN bus.
Very interesting video, the collision avoidance system is quite clever. It's quite elegant. Thanks for sharing!!
Thank you Robert for sharing this kind of content
I would not call it simple by any means and not even Microchip explains it very well. Good discussion, however and Robert asks great questions.
Listening around 25:00 in, I'm very glad that Ethernet does not act like the CAN Bus. Imagine needing all of the systems in the WAN to be perfectly functional (this includes all Ethernet cables being well-built and reliable) in order to use the internet. The Internet would never be up! Between intermittent cables and packet collisions alone, we'd be soooo out of luck.
Ethernet started out as a bus, an ethernet cable, fat or thin, has the same problem as CAN. What he described is a feature of CAN, if you instruct both wheels to change to a certain speed and only one wheel receives the message the driver will be very surprised by a car that is suddenly driving in a circle. CAN automatically avoids this, ethernet does not. The two technologies have very different use cases.
@@jrstf yes I understood that. I was pointing out one good thing about the fact Ethernet wasn't like CAN. Thank you for your reply though 😊 👍
I still remember when offices would use TokenRing instead of Ethernet. Eventually Ethernet won, because it just makes a lot more sense where there is a lot of data at high speeds. But that does not mean CAN is useless, for continuous monitoring of dumb devices CAN is cheap and very effective at what it does.
One huge downside - during the recent chip shortage pretty much all CAN transceivers just disappeared. I'd rather keep using RS485, simpler transceivers and higher speed. Also looking in the direction of LVDS (both on-board and over wires).
Vehicles use the OBD (On Board Diagnostics) software layer protocol which is sent over a multitude of hardware layer protocols, dependent on the manufacturer. CAN is only one of the hardware layers.
Great explanation of CAN bus thanks, I have one of those salea analyzers they are great :)
Another great option is the Kingst LA1010, cheap but very good for the price! I use it professionally and it's perfectly adequate for signals around a few megahertz.
I think the issue with CAN is that it _looks_ very complicated and frightening to the newcomer, but then degenerates to a bunch of competing standards on top of what’s actually needed to get started. This is something I’m going to have to get stuck into though and have working by the end of the day/week depending on my skill level.
Am I understanding correctly that, using the remote packet, you would request a value to be sent one time versus being subscribed to that value to receive continuously? Or, by sending a remote packet, do you thereby subscribe to continuous updates? If so, how does one unsubscribe - do you send another?
Not subscribed, it's just a request/response. Two packets are the same except of course the request contains no data but does have the flag set. Subscribe makes no sense anyway since packets don't contain destination addresses, the response is broadcast as are all packets.
@@jrstf oh, okay. I'm looking forward to learning more and possibly working with this protocol/technology.
The selection of needed PDO:s, out of about 800 to select from, is a situation you can find yourself in, if using CAN ( or ethercat ) to run a servo, for example. Not recommended for beginners ( who has to understand all whose options, to be able to select the proper ones for their application ).
very cool!
IIRC, It's a token ring network? Our ships navigation & systems monitoring are canbus. Neat stuff, Very versitle.
Edit? Isn't auto OBD a form of Canbus?
Wow the saleae has gotten a LOT more expensive. When I got mine they were like $149
I love you
I tried it and i2c and found pjon communication, and since them i use only pjon
hello all, I have a question about CAN bus topology- You know LOXONE and they have technology Loxone TREE (it's CAN bus on 50kbps with IC MAX3..) and they connect this CAN in STAR to STAR and any topology. Question: is it correct to use CAN other topology like daisy chain? It's safe? what do you thing?
... the stubs should be at max 30 cm long! Termination must be set at the very ends of the bus.
If you look very close to some short stubs, they might look like a star... 😅
The standard mentioned 30cm stub for 1Mbps.
I tested 500kbps with one 3m stub and still worked.
50kbps star topology is adequate for the CAN.
I mentioned the NXP Application Notes. And that rules.
If you make your stubs 10 meters long: who cares?
CAN BUS is not a star TOPOLGY!!!
Hint: take an oscilloscope and check the signal.
@@ragohy I don't see anyone mentioning NXP or 10m stub, so I don't know who are you talking to.
But you may want to check ISO 11898-3 if you trying to say CAN star topology is not a thing. And duh, bus is not star... wtf
CAN bus requires all devices to see each bit at the same time and any device can takeover a packet by forcing out a zero in response to the prior bits. So any device can send at any time and a bit must be able to travel the length of the cable and back in one bit time. If Loxone has built repeaters which implement these requirements, thus allowing branches, then more power to them.
Beware of the small CAN to USB 7.00 device since it can't handle a continuous stream of packets .
Please tell me, doesn't CAN bus need 3 wires - I mean 1-H 2-L and 3-GROUND ?
No, it's a floating bus that hovers around 2.5v on each side of the bus... the voltage is measured between Hi and Lo... the reason for this is to help remove common mode noise. The other thing to remember in automotive is that the ground is a global chassis ground, so if you absolutely need to ground reference, everything then it's achieved through the chassis but the ground is not needed for CAN transmission... ethernet is the same...
It's only when you suspect your grounds would be on much different levels is when you need to ground two devices together.
For example engine cranking and battery in the trunk. The engine controller might few volts apart from battery controller if the ground is not good. The solution is not third wire though. The solution would be making sure the battery (-) and alternator is properly attached to the the chassis.
Otherwise you may exceed the common node transceiver limit and it will clip the signal and interrupt the communication.
Another maybe better example would be if you have motor driver with CAN. Obviously you will have some ground going to the motor. But imagine it is as long wire with few ohm resistance. If you start pulling few amps, your ground will move against other devices, because voltage drop through the ground wire. Depending on the transceiver you may be fine if ground shifts by few volts. But to make sure everything works for Ng high load, you have to use thicker ground wire again.
If two devices were truly separated. For example both battery powered, the grounds would be close to each other even with just two wires, because can transceiver outputs have about 20k resistance to ground. It's large but it it would make ground at the same level.
Thank you@@TheVanDerSnow
I would love to use CAN, but it is just too limiting. Most of the built in or cheap controllers do not support CAN FD, so you are limited to 8 bytes payload. Even with CAN FD this is only 64 bytes. Sure, for dedicated stuff it can be ok, but if you want something more flexible, and reconfigurable it is PITA. I am trying to switch from 100Mbps Ethernet (40 devices, everything would fit on
That's all true. CAN is only intended for transferring of a single value, as in reading a sensor or setting a speed.
That example with the pico boards was not a good example. It uses micropython with a library that isn’t yet part of the standard rp2 library (judging from what Ken said) and that library abstracts everything away. That software example was useless for understanding CAN.
If you are showing people something, keep it as standard as possible, use standard, unmodified libraries and include your custom library separately. This was also a bad example as the CAN bus was set up with a single function call with no parameters, just using default parameters. Yes default parameters can be useful but in an example like this it would have been helpful to just type the parameters too. Since it was just set up with a single function call with no parameters it gives no information about CAN at all.
Defaults when setting up something like a CAN bus shouldn’t exist, since they are key properties of the signal, defaults are a good idea in theory but not in practice. Using bitrate as an example, you might get some examples working fine communicating between two of these boards just using the single function call with no parameters to set it up, but then what if you want to connect to a device you didn’t create? It may not work and you may have no idea why, since the issue is the bitrate which is a property of the CAN signal that is completely hidden from you since you are just using defaults. Just using defaults may be easier right at the start but in the long run it is better just learning things like that completely from the start. Learn right at the start you need to set the bitrate and that it needs to be the same for all devices on the network. It’s not that hard.
I feel a lot of micropython libraries, including this one, dumb it down too much. Yes simplifying it for people to learn is good but there is also going too far, you have reduced using CAN down to three function calls, setup (with no parameters necessary), transmit and receive, you have hidden far too much in the process especially with defaults. It doesn’t benefit anyone dumbing it down this much. You should learn at least the core properties of the signal, like bitrate, right at the start, there is zero benefit to abstracting away having to set the bitrate.
Overall this video just doesn’t seem that useful. The explanations didn’t seem that useful and the code example was useless.
The question that comes to me is, do I really need to know how the notebook works internally to write a comment on youtube? the answer is no. To make use of a communication protocol I do not need to know the internals, i need to know how to make use of it. I do not need to know exactly how the human body works, to take a walk in the park, it is enough to be able to walk. Thats my problem, everybody seems to want to teach us how can bus works, but who cares, please teach us how to easy utilize it in our project.
@@Lisas4us if you think you don't need to know how the bus works then you are a fool and really don't know what you are doing. Your other examples like the notebook and human body are ridiculous and irrelevant. In case you didn't realise, when you are implementing communication between devices you can't really just ignore how the protocol works, especially when the communication method has hardware requirements.
Sure just knowing how to use it at a very high and basic level might work for basic hobbyist projects but try any communication method for more than a simple case and you will need to know how they work.
If you don't just use premade boards then you need to know how the protocol works and what it needs to work, like the transceivers and termination resistors.
For any communication method, to be able to debug issues with the communication method, you need to know how it works.
If you want to stay at the level of being an absolute beginner then keep just using premade boards with far too abstract micropython libraries. If you want to actually progress, make your own boards and not get your hands held when programming the boards then you need to learn how the communication protocols work.
If you can't handle learning how a simple protocol like CAN works then you aren't going to get far in any form of embedded engineering.
@@conorstewart2214 Well, I agree. That analogy is stupid, since here we actually need to know how something works. We can't limit ourselves to use libraries all the time, but calling him "fool" and "you dont know what you are doing" is not nice, considering you are a experimented EE.
I think that only applies for people that really wants to earn a life from this, but other people just likes this as a hobby and they really dont need to know the, lets say, "heavy" things, because its just that, fun.
No offense, I say that because I saw your comments on Arduino videos. Valid points for sure, but even if Arduino claims other things, their boards are just toys. No sense on commenting claims about stuff.
I do a lot of Raspberry and arduino, and I watched a couple of can bus tutorials the past couple of years. I have plenty of use for such a communication system, but am always turned down by the way it is explained. Who cares how the signal looks like? Think arduino would have showed us the signal of whats coming out of the USBto TTL converter and tried to explain us on this level how arduino works, never ever anyone would have used it. So to do Can bus, we need a board that can receive and send. A library that can be imported to the project. Pin definitions , and a void function to send something to a board. That would make can bus popular.
I just don't think can is what you're looking for, it wasn't developed to be a plug'n'play solution for entry level hobbyists, nor was it intended to be used directly by consumers, it's meant to be a robust medium distance communication protocol for automotive and industrial applications (i.e. designed for use by professional engineers). It takes a modicum of technical understanding and effort to setup properly. You aren't the intended user, so it won't be easy for you to use.
Uh, and my comment is somehow gone.
That's what you get for mentioning vaccines! Seriously, we know many comments are deleted when we see a comment count that is vastly higher than the number of listed comments.
35:36
I don't like the way Robert conducts interview. He change the current subject without listening to the end. His questions are superficial, it's worth at least a little preparation for the conversation. I'm sure Ken could tell a lot of interesting things. but here w have to listen for more than an hour to what could be learn in 5 minutes from Wikipedia
Saele are way over priced and not worth it. dreamsourcelab has just as good, in some cases better, for much cheaper -- if you get the high end version, it has much nicer leeds than saele.
The interviewer is very annoying. Let the guest speak. Stop cutting him off
yeah I agree a bit
split it into shorter parts