Quote:
Originally Posted by duane
I'm quite baffled by all of the caution around CAN. Why is there so much concern? We run the entire robot on CAN now.
I find the project interesting so far.
|
CAN does have some quarks (as well as some nice parts). You should make sure that you understand the tradeoffs before you settle on an interface.
I prefer ethernet/TCP (or UPD), because it's more common, easier to debug (some CAN issues can be difficult to debug without some hardware designed for it), and has more throughput.
I'm not saying don't use CAN - just make sure that you have solid reasoning as to why you're doing it.
Quote:
Originally Posted by duane
|
CAN is a very well defined format (Well, pretty well defined. There are actually a few different versions of CAN out there, but you mostly will never see the less-standard ones), but the way to interface with a microprocessor that implements CAN can vary depending on the microprocessor.
I was under the impression that you were asking about writing the Pi-side code. If that's not the case, then the chip that you're using is not very important. Sorry if you're asking about the roborio side of the interface - if that's the case then I've misunderstood your question.
The one that you linked to uses some GPIO pins on the Pi to control the CAN controller and transceiver. It looks like it does this over
SPI, but I'm not entirely sure about that. They provide example C code which should be fairly easy to adapt to C++. The links that I provide below should actually apply for both the Pi-side and Rio side as well.
Regarding the RoboRIO side of the interface, there's been some good advice about looking at WPILib. I would recommend looking at the linux kernel docs for
SocketCAN (The
Wikipedia page is also good, and has some example code). Looking at the
can-utils source could also be helpful. This is lower-level than most of what's in WPILib. I find that that makes it easier to understand, but YMMV.