Re: Request for proposals: Communications physical layer
Arjan,
I don't think we (as a group) have given much thought to LIN. Although LIN seems to be less expensive to implement (as nearly every microcontroller has an UART), it requires/specifies the same physical interfaces as CAN.
The basic differences I see:
- LIN is strictly master-slave and requires the presence of a bus master in a polling round-robin. CAN is peer-to-peer broadcast only.
- LIN is address-based. CAN is event-based.
- LIN tops at ~20kb/s. CAN tops at ~1mb/s (similar speed to LIN for low-precision clocking).
- LIN uses 8-bit checksum for error detection. CAN uses 15-bit CRC and ACK frames for error detection.
- LIN requires code implementation to handle the interface (an UART is only the starting point). CAN peripherals handle most of the protocol heavy lifting.
The main differences I see are the master-slave vs. peer-to-peer design, the maximum speed, and the overall safety margin improvement. For this application it seems that CAN provides more flexibility and a simpler overall design.
My perception is that LIN may require as much or more code to support than CAN does nowadays, however there should be several support libraries already for both. So the cost differential should be minor to inexistent; but I could be wrong.
As the working documents evolve, please feel free to show how/where would LIN simplify the requirements.
Edgar
On Feb 13, 2011, at 4:32 AM, arjan strijker wrote:
> Edgar, all,
>
> I was going through my upamd mail and the mail below made me rethink the communication options:
>
> CAN is indeed a good protocol but is LIN assessed enough?
> I don't know all the pros and cons, but reading about LIN this seems a cheaper alternative to CAN.
> I understand that LIN also has a dc LIN transceiver option. Maybe not useful for 130W but interesting.
> LIN is a single master system. Could that be an issue here or would LIN already be good enough,
> making the communication not more complicated than really needed?
>
>
> With regards,
> 阿勇 Arjan Strijker
>
>
> -----Original Message-----
> From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Edgar Brown
> Sent: Tuesday, November 30, 2010 10:48 PM
> To: upamd-comms@xxxxxxxx
> Cc: upamd@xxxxxxxx
> Subject: Request for proposals: Communications physical layer
>
> Request for proposals on physical layer definitions
>
>
> So far, the only viable physical layer definition proposal has been the CAN bus family (ISO 11898, ISO 11992, ISO 17356, EN 50325-xx, etc.)
>
> Other protocols that have been mentioned are:
>
> - PMB, which is used for batteries and power systems. It relies on I2C which is not reliable over cables, and requires at least three separate wires (full implementation requires 4).
> - LIN, an intermediate between RS232 and CAN. Similar to I2C, but designed for reliability, requires only one wire (supports the same hardware interfaces as CAN), and is a pure master-slave architecture.
>
> However CAN (in both the single-ended or differential variant) seems preferable in terms of industry penetration and existing infrastructure and overall reliability.
>
> Please, if you have any additional proposals submit it to the communication subcommittee reflector or to me. The choice of physical interface would enable other aspects of the protocol, so the upper protocol layers will be based on what this allows.
>
> Also, even within the CAN family, there are several upper-level protocols in use (e.g., OpenCAN). If you, or your team, have any opinion regarding these, please make your opinion heard in the main group and subcommittees.
>
>
> ------
> Edgar Brown
> Subcommittee chair
> UPAMD Communications
########################################################################
To unsubscribe from the UPAMD-COMMS list, click the following link:
http://listserv.ieee.org/cgi-bin/wa?SUBED1=UPAMD-COMMS&A=1