CAN bus - what is the today's prefered method?
prof_braino
Posts: 4,313
in Propeller 1
A question just came in about CAN bus. What is the current preferred method for talking to CAN Bus(es) using the Prop?
I see previous discussion of MCP2515 and the MPC2550, also more recent discussion of XMC1xx
Which is most reliable, cheapest, etc.?
Are there speed constraints for the prop? (I.E. will the transceiver buffer the messages on the 1MB bus so we can slowly fetch them as 230400 or do we only use the slow bus?)
Thanks!
I see previous discussion of MCP2515 and the MPC2550, also more recent discussion of XMC1xx
Which is most reliable, cheapest, etc.?
Are there speed constraints for the prop? (I.E. will the transceiver buffer the messages on the 1MB bus so we can slowly fetch them as 230400 or do we only use the slow bus?)
Thanks!
Comments
I also tried my hand at writing a MCP2515 driver here http://obex.parallax.com/object/758. IIRC, the MCP2515 only has two receive buffers.
In any case, you'll need a MCP2551 or similar to convert the Prop logic levels into CAN bus high and low signals.
The XMC1xx series is maybe a little new for CAN use today, but there is a summary page here on XMC14xx
https://rutronik-tec.com/more-connectivity-with-the-new-arm-cortex-xmc1400-microcontrollers/
The XMC14xx looks well suited to CAN node development. 5.5V and plenty of peripherals.
I also see ST have a STM32F042 series that does CAN in quite small packages.
I see the spin code calls for a MCP2551 or similar line driver. So its directly aside from the line driver? This might be what I'm looking for.
I see the CANbus reader object requires two cogs, I guess this is due spin execution speed? Would there be anything from stopping one from doing it in one cog with assembler and timers, or was this already tried with no success?
I'm just getting started with CAN, I THINK I want to start with just a bus monitor to see how far this gets me.
So this looks do-able, but I have a bit of reading to do on the protocol and messages, and the list of items that changes per auto manufacturer.
Would CAN-bus monitor sound like a project for a high school auto-shop class?
A high school auto-shop class could certainly use a CAN-bus monitor, but it may be a bit ambitious to expect them to create a CAN-bus monitor.
A prop should also be able to time-stamp messages, or even parts of messages.
IIRC, typically CAN samples at least 8x per bit, and also has a CRC & bit-stuff to do in real time, all of which sounds tough for 1 COG at 1Mbps
I'm impressed someone has this working at 500k in one COG.
See also :
https://en.wikipedia.org/wiki/CAN_bus
There is also a recent CAN FD, which can go even faster than 1M bps, but that use is upward compatible with CAN.
A. While the Propeller may do CANbus independently, it is not licensed to do so. So the MCP2551 and MCP2151 chip set complies with the license requirement. The MCP2551 and MCP2151 merely require an SPI interface to the Propeller, perhaps one cog. (The MCP2550 is retired.) Bosch has previously put a stop to the PIC and the SX chips being used to create unlicensed CANbus, so I have doubts that a stand-alone Propeller solution is going to be escape a license requirement.
B. Historically there have been a lot of microcontrollers that have included a licensed CANbus interface starting with Microchip's PICs. Prices vary according to resources.
C. Speed is limited by a combination of factors: traffic, number of nodes, distances. In an automotive setting, a CANbus supposedly will have up to 70 nodes on one pair of wires with multiple masters broadcasting to various slaves. Collisions require retransmission, so even high speed bogs down.
+++++++++++
What is obvious here is that CANbus is all about taking advantage of lots of nodes.
Each node can be very different and even may be a different brand of microcontroller that best fits that node's tasks. The Propeller with the MCP2551 and MCP2151 is handy when you want a VGA interface or a somewhat sophisticated process at one node. It is also a good learning platform. Other nodes may be much simpler and merely monitor one or two ADC values; or toggle on and off one or two items. It is all about distribution of a system's tasks that decide these things.
So don't get blinded by one manufacturer's promotion of a new CANbus device. The MCP2551 and MCP2151 is still a good place to get started and I have even used them with the BasicStamp2. If one can use the MCP2551 and MCP2151, one can easily learn to use just about any CANbus microcontroller out there... sometimes the small 8 pin devices are the most useful.
One of the cogs in the reader simply runs a counter, resetting every time a transition is detected, and outputs triggers to the other cog that does actual reading.
That reduces the workload of the main cog, but it’s still quite busy as it has to determine if a sampled bit is stuffed or should be stuffed, parsing the data bits and branching differently depending on certain bits (extended IDs and RTRs), updating the CRC, and updating a counter that keeps track of the number of consecutive bits.
The writer is a little easier as it does all of its work beforehand, assembling a complete message with all of the expected stuffed bits into several cog registers and transmitting when the bus is available. It’s still required to monitor the bus for arbitration errors—the CAN bus uses dominant and recessive states, if two nodes begin writing simultaneously, the first node to send a recessive bit loses control of the bus and is required to stop and resend later.
While my 500Kbps controller is able to do all of that in a single cog, it has difficulty on a busy bus like OBD-II. There’s so much traffic that the writer often loses arbitration, requiring it to completely rebuild the message only to try and fail again that the handler often times out. To counter this, I created an OBD-II specific object that only listens to the bus after the writer sends a query, and only listens for certain messages; eight-byte standard-frame messages from ID $7E8.
It works brilliantly in the garage, though I’d be hesitant about having it connected while driving, one glitch on the OBD-II connector can disrupt the entire bus, which can cause all of the dashboard instruments to go haywire. I discovered that with a much earlier version of the code, long since fixed, but the possibility still exists. No doubt this is the reason for the license agreement. I wasn't aware that vehicles were using 1Mbps busses! While manufacturers each have their own proprietary PIDs (parameter IDs), getting them is either difficult or expensive. Fortunately, all OBD systems also share some common PIDs, check it out on Wikipedia: https://en.wikipedia.org/wiki/OBD-II_PIDs.
Also my OBD specific object, while only capable of operating at 500Kbps, has a higher-level object that decodes messages, even messages from a MCP2515 after some modification. http://obex.parallax.com/object/690