Path: EDN Asia >> News Centre >> Communications/Network >> Utilising MOST, Ethernet for car electronic systems
Communications/Network Share print

Utilising MOST, Ethernet for car electronic systems

03 Oct 2014  | Henry Muyshondt

Share this page with your friends

The trade-off is that you need additional hardware and buffering. Determinism is only a statistic, not a hard real-time feature. Switches are added to the basic network interfaces located in each device that uses the network. These switches can be centralised, or a three-port switch can be added to each device so they can all be daisy chained.

However, all network interfaces need to connect to a switch if they are to avoid colliding with other devices, adding hardware and cost beyond the actual Ethernet transceiver in each device. If devices share the physical medium without a switch, they go back to the CSMA/CD mechanisms.

Switches used in the automobile also need to be more specialised than the typical switch in an office, because they need to include hardware features for bridging audio and video and to provide time sensitive networking (TSN), previously referred to as AVB. Ethernet TSN includes extra hardware to distribute clocks, provide timestamps for each packet that is transmitted, and provide mechanisms for bandwidth reservation and packet prioritisation.

The bottom line, though, is that Ethernet is widely used, and just about all data entering and leaving a vehicle is likely to make its way ultimately to an Ethernet network of some kind. Ethernet refers to particular packet formats, as well as to a specific physical layer.

The case for MOST technology: Stream transmission

The addressing information used in IP packets is needed when packets are travelling long distances and over uncertain and varying paths.

However, it results in significant amounts of overhead when the main purpose is to get large amounts of data between a well-determined source and a well-determined sink that are in relatively close proximity and in a relatively fixed configuration, such as within the vehicle.

Sending an A/V stream between its source and its renderer means that a significant amount of data will be flowing for a prolonged period of time. The data flows from a fixed source to one or more fixed renderers. Adding addressing information and breaking up the data into packets that need to be examined every time they go through a device along the route results in a lot of wasted bandwidth. In addition, it complicates the processing of information, as packets may not always move through the system with exact latency and determinism.

Packets also need to be unpacked, and the data joined into a continuous stream, for the various audio and video decoders to process it.

This can cause high processing overhead at the microcontrollers that receive and reassemble the media streams before playback. This is typically done in software, on a host processor, since the network interfaces typically can only process standard Ethernet packets, without regard for the data contained in them.

An Ethernet channel is a pipe for Ethernet packets, and it is unaware of anything other than the priority of the packet, the source and the destination. Higher-level software protocols, which use processing power, have to be implemented to ensure transmissions are properly acknowledged, and to decode what the data received means and what to do with it.

For continuously flowing audio and video transmissions, the streaming and isochronous MOST network channels have a distinct advantage. A control channel is used to set up where the data is going to be placed within a frame, and where a renderer can pick up the data it needs. Once this setup is completed, only actual audio or video data is transmitted, without any overhead for addressing or timing information.

 Ethernet Frame

Figure 1: Ethernet Frame, as defined by IEEE 802.3. (Source: Microchip)

Figure 1 illustrates the structure of a typical Ethernet frame. It contains a total of 210bits of miscellaneous information (preamble, start-of-frame delimiter, destination and source addresses, etc.), which is required for every single packet of information.

This doesn't include any bits needed by protocols such as audio/video dridging (AVB) and TCP/IP, which add their own data to the header of each Ethernet packet.

When you consider that a CD-quality stereo audio sample is only 32bits, this is a huge amount of overhead. You could combine several audio samples into a larger data payload, but the larger you make this packet, the worse the audio drops are if a packet is lost, and the larger the buffers need to be to allow for software-based error detection, correction and retransmission.

Latency becomes an issue when you have to buffer information. This is critical for ADAS applications.

 First Page Previous Page 1 • 2 • 3 • 4 • 5 • 6 Next Page Last Page

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact