RE: Request for proposals: Communications physical layer
Hello Arjan,
I will be at APEC next week in Fort Worth.
I look forward to the opportunity to meet you the opportunity to meet you there.
Liang Downey (Ms.)
Director, Nextek Power Systems
461 Burroughs St
Detroit, MI 48202
Office: 313. 887.1321 ext.121
Mobile: 313.310.5775
Toll-Free: 877.24VOLTS
Fax: 313.887.9433
www.nextekpower.com
liang.downey@xxxxxxxxxxxxxxx
CONFIDENTIALITY NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----Original Message-----
From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Edgar Brown
Sent: Thursday, March 03, 2011 12:51 AM
To: arjan strijker
Cc: upamd-comms@xxxxxxxx; upamd@xxxxxxxx
Subject: Re: Request for proposals: Communications physical layer
Arjan,
Just for clarification, as language sometimes does not 'travel well' between experts...
> - A main difference between CAN and LIN is the communication speed. CAN is 1Mb/s, LIN is 20kb/s.
This is max rates specified in the standards. CAN is specified down to 10kb/s, at which point all of its clocking and interfacing requirements are relaxed.
> - FlexRay is introduced for even higher speeds.
> - LIN can be driven at 40kb/s, (K-line) The low speed is only chosen for low emission.
> - LIN is single wire. CAN is dual wire. Single wire CAN is possible, but not standardized.
Not strictly true, The SAE J2411 CAN 1-wire standard physical 30kb/s layer is less common than the 2-wire one but it exists and is standard in some older vehicles.
http://engineers.ihs.com/document/abstract/HZEYNAAAAAAAAAAA
http://www.nxp.com/documents/data_sheet/AU5790.pdf
I _believe_ that LIN was born by using the CAN 1-wire interface with a standard UART, which then was improved upon in what became the LIN SAE standard.
> - LIN was developed because CAN is too expensive for many applications. High speeds ABS etc need CAN, but for low speed like window regulators LIN is good enough.
True, but this was more than 12 years ago. Implementation costs have dropped to the point of making CAN viable for lower speed applications (while FlexRay moves into the time-critical ones)
> - The CAN protocol handler much more complicated than the LIN handler. Silicon area is easy a factor 5 times bigger for CAN.
True, but this does not include all the code required to achieve what the CAN standard does in hardware. The only hardware support for LIN is a standard UART perhaps with some address-recognition or similar logic. The CAN hardware implements among other things symbol coding, bit-stuffing, CRC, clock adjustment, acknowledge bits, and error counts.
> - CAN cannot be implemented in low cost (bigger feature size) IC
> processes. (The silicon would be too big to fit in a package.)
Due to supply/demand dynamics, larger feature size processes are slowly becoming more expensive (or at most equivalent in cost) than smaller feature size ones. (Even without considering reduction in die size and yields.) Larger feature size processes are being mostly used for power or other applications that specifically require higher voltages and devices.
NXP itself has had low-cost CAN microcontrollers since 2000 http://www.nxp.com/#/pip/pip=[pip=P8XC591]|pp=[t=pip,i=P8XC591] and even full differential high-end microcontrollers with integrated CAN drivers: http://www.ceasiamag.com/article-6970-nxpannouncesintegratedcantransceivermicrocontrollersolution-Asia.html
> - CAN requires strict timing. Every device needs a crystal (expensive). In LIN only the master needs a crystal. The slaves synchronize on the master.
Not strictly true, low speed CAN (~10kb/s) only requires ceramic resonators or internal oscillators in _all_ nodes. Nodes synchronize against each other (the protocol guarantees at least one transition every 5 bits). In LIN at least one device (the master) requires a crystal.
> - LIN supply voltage is much more flexible (7-18V, but typically 5.5V will work). CAN needs 5V.
Can does not _need_ 5V, differential 3.3V CAN drivers are rather common. Line voltages do not exceed 3V.
http://focus.ti.com/docs/prod/folders/print/sn65hvd232.html
> - LIN communication is simple. A slave can activate the bus and the master will than start the communication.
Can you elaborate on this one. What exactly is meant by "a slave can activate the bus"?
> - CAN requires a rather complex arbitration protocol.(critical timing,
> event driven)
Although true, the most complex sections of the protocol are commonly implemented in hardware. NXP goes further, and some of their ICS incorporates many of the higher-level layers in internal roms.
> Bottom line: if high speed communication is not required: use LIN. CAN would be much too expensive.
I am not sure this conclusion is fully warranted. For some applications it is definitively true, but not in general. Even if directly compared to 10kb/s CAN.
An application that requires a higher degree of error protection, event-based communications, or multiple communicating peers might be better served by CAN. If the application is strictly master-slave, then LIN might be a better option.
Edgar
>
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ------------------
>
> So I think the thing to ask ourselves is how much communication speed do we need?
> If, for example, 100 bytes (incl. overhead) need to be send over LIN,
> this will take 40msec (or 20msec at 40kb/s) CAN will do this in 800usec.
>
> Btw: I will be at the APEC next week. I hope I can meet UPAMD people.
>
>
> With regards,
> 阿勇 Arjan Strijker
>
> IC architect, Business Line Power & Lighting Solutions (PLS) BU High
> Performance Mixed Signal (HPMS) NXP Semiconductors
>
> Gerstweg 2, Room BZ0.103, 6534AE Nijmegen, The Netherlands
> Tel: +31 24 353 4661
> E-mail: arjan.strijker@xxxxxxx, www.nxp.com
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Edgar Brown [mailto:ebrown@xxxxxxxxxxxxxxxxxxxx] On Behalf Of
> Edgar Brown
> Sent: Tuesday, February 22, 2011 4:33 AM
> To: arjan strijker
> Cc: upamd-comms@xxxxxxxx; upamd@xxxxxxxx
> Subject: 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
>