Mark, I really expect the almost latest technology to be used for two reasons possibly 1 step behind. First it is usually the highest yield, lowest die size, in dies per wafer (wafer costs rule). Secondly TSMC and others are geared for this process. Small microcontroller are in the 10-20K gate size which is really quite small. Asking for a 20V output is difficult. Internal voltages on these parts will be < 1V with onboard regulators. I would expect most of these devices to be below 50nm and headed lower for speed, power, size, yield reasons. 7nm is very well within the life expectancy of UPAMD for core logic. I/O bigger. Bob From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Mark Anderson
Sent: Wednesday, March 02, 2011 12:29 PM
To: Bob Davis
Cc: arjan strijker; Edgar Brown; upamd-comms@xxxxxxxx; upamd@xxxxxxxx
Subject: Re: Request for proposals: Communications physical layer When it comes to expense, Cars Manufacturers make CE OEMs look like spendthrifts. I think in the domains that we are looking at we're not planning to use 0.5um tech or anything like that. Mark 2011/3/2 Bob Davis <bobd@xxxxxxxx> Arjan,
Thanks!
A couple of issues that we will need to address with respect to the LIN
protocol.
1. How much more expensive is CAN single wire than LIN? The least expensive
NXP devices include CAN.
2. Bus speed. With CAN at 500KHz, a complete message (longest) with ACK is
~250us which allows for two faults and still kill the power before pin
separation in 1.87 to 3.2ms. It may be difficult to get the bus power shut
down in time if the detection of the communications pins takes more than
1ms. With 40Khz LIN the equivalent detection time would be longer than the
required shut down time.
3. 1 byte checksum vs 15bit CAN checksum
4. We will be connecting together devices that each thinks it is a master.
Probably need multi-master version of LIN for successful operation. CAN can
handle this.
5. I looks like there are up to 4 different message formats from LIN while
32 are available in CAN with arbitration.
This is good input.
Bob Subject: RE: Request for proposals: Communications physical layer
Dear Edgar, all,
Sorry for the late reply, it cost some time for me to find the person within
NXP that has experience with the CAN and LIN system (and also FlexRay)
I talked to one of my automotive colleagues.
Here is his comment:
----------------------------------------------------------------------------
----------------------------------------------------------------------------
-----
- A main difference between CAN and LIN is the communication speed. CAN is
1Mb/s, LIN is 20kb/s.
- 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.
- 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.
- The CAN protocol handler much more complicated than the LIN handler.
Silicon area is easy a factor 5 times bigger for CAN.
- CAN cannot be implemented in low cost (bigger feature size) IC processes.
(The silicon would be too big to fit in a package.)
- CAN requires strict timing. Every device needs a crystal (expensive). In
LIN only the master needs a crystal. The slaves synchronize on the master.
- LIN supply voltage is much more flexible (7-18V, but typically 5.5V will
work). CAN needs 5V.
- LIN communication is simple. A slave can activate the bus and the master
will than start the communication.
- CAN requires a rather complex arbitration protocol.(critical timing, event
driven)
Bottom line: if high speed communication is not required: use LIN. CAN would
be much too expensive.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
------
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
########################################################################
To unsubscribe from the UPAMD-COMMS list, click the following link:
http://listserv.ieee.org/cgi-bin/wa?SUBED1=UPAMD-COMMS&A=1
|