Micro with CAN + drivers.

As is often the case, it depends on the definition of "easier." CAN gets you a built-in multiple "master" priority scheme with collision detection and retransmission. It also, at least in every microcontroller-based implementation I've used, gets you some level of hardware message filtering, so nodes are only informed of a new message arrival if it is one they want to see. Application software or ISRs never have to see messages they aren't interested in.

The down side of message filtering is that every $#%!#$ manufacturer and pretty much every separate processor line implements the initialization of the message filter differently. It's good in that one may, if needed, pick a processor with a simple or complex filter as the task requires. But they can be a PITA to get setup sometimes.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb
Loading thread data ...

Agree with Rich - CAN offers out of the box:

  • a packet/message format spec,
  • an addressing or target object selection mechanism, (what is a "message type" and what is an "address" depends on how you define things.)
  • message filtering (although how useful this is depends on the [mis]match between the filter capabilities and what you encode in the packet headers.)
  • error detection (CRC and bit-by-bit- compare)
  • automatic retries.
  • automatic cut-off of faulty nodes.

Using RS-485 + UARTs these features are not too difficult to duplicate (for simple protocols), but CAN still offers a distinct advantage.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

We evaluated using RS-485 with serial where I ended up selecting CAN.

CAN won because of the priority-based collision avoidance, and because it has a lot more of the network brains in hardware -- which loaded the software a lot less. Given that we were using it at 1Mbps, with distinctly layered message priorities (we closed a motion control loop on the same bus as human-speed status commands and even text-based menuing), that was a huge plus.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Reply to
Tim Wescott

it may be too expensive, but the Dearborn CAN products seem to include libraries for manipulation. SFAIK, you can use the .dlls to build your own apps using MingW.

-- Les Cargill

Reply to
Les Cargill

In the early days, before actual CAN transceivers were available, ordinary RS-485 chips were used to drive the CAN bus. The driver data input was constantly connected to the dominant state and the data to be sent was connected to the driver enable pin.

When the dominant state was to be transmitted, the driver was enabled, driving the bus actively to the dominant state. When the recessive state was to be transmitted, the driver was disabled into high impedance state and passive pull-ups put the bus in recessive state.

Reply to
upsidedown

You mean RS485 vs. ISO 11898-2?

I disagree then, please explain what's simpler with RS485.

Oliver

--
Oliver Betz, Munich (oliverbetz.de)
Reply to
Oliver Betz

Hi Roberto - What are you building ? I used RS-485 in an avionics system I designed a while ago, and more recently components using CAN. What sensors are you using, and what avionics are you building ? Enquiring minds want to know... Best Regards, Dave

Reply to
Dave Nadler

A butter-knife is easier to use than a chain-saw; we're comparing apples and oranges. CAN includes a lot of protocol you'll need to implement for RS485. Been there, done that...

Reply to
Dave Nadler

Building: (More planning than building) A poor man's EFIS for "Parrot":

formatting link

To go from this, (mine):

formatting link

to something like this, (somebody else's)

formatting link

Sensors/Avionics: The general idea is to use one of the several low-cost IMU/AHRS's available for RC planes, quad-copters, drones, etc. (openPilot, Px4, ArduIMU, etc.) and a generic Android tablet as the display and control device.

CAN bus between them for the obvious reasons.

The processor I was trying to choose will provide a CANUSB interface on the Android side and CANSPI/I2C/GPIO on the sensor side. It will also convert the raw data from the sensors into a common message format so that different IMUs can be exchanged freely.

The intention is, at first, to provide only a replacement for the standard VFR instrument "six-pack". Once the basic structure is in place, more things can added. Multiple/redundant displays, (or buses), GPS tracking, synthetic vision maps, etc. Moving forward, but very slowly.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

Just a tip - you can avoid the wrapping issue by putting angle brackets around a link:

Reply to
David Brown

Thanks for that, is a nice tip to add to the bag of tricks.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

It's not really a good idea to use an RS-485 chip instead of a CAN chip, as there are other factors involved (such as slope control). But I find it quite a good model to help understand how CAN drivers work.

Reply to
David Brown

This is also the last resort in ordinary RS-485 communication, if you do not have _reliable_ data direction control (e.g. using RTS).

I have used this driver enable trick on several Modbus systems, in which the RTS incorrectly dropped as soon as the last character was moved from the FIFO to UART Tx shift register, while the correct functionality would have been dropping RTS (and hence disabling the driver), when the last stop bit of the last character had actually been transmitted.

Reply to
upsidedown

Looks nice !

Here's my front office view:

formatting link
Top center instrument (I designed) uses RS485 Bottom center (systems management) uses CAN

Maybe a dumb question, but given your intentions here regarding the display device, why not BlueTooth ?

Keep us posted ! Best Regards, Dave

Reply to
Dave Nadler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.