Are you designing for the latest automotive embedded system?

---

Eventually, self-driving cars will arrive. But until then, here’s a look at what will drive that progression.

---

The next arrow of development is set for automotive

We all have seen it. We all have read about it in your front-center technology news outlets. The next forefront for technology will take place in the vehicle. The growing market fitted with the feature deviation trend does not appeal to the vision of customizing more traditional un-connected, oiled and commonly leveraged chassis vehicles of today. Instead, ubiquity in smartphones have curved a design trend, now mature while making way for the connected car platform. The awaiting junction is here for more integration of the automotive software stack.  Opportunities for the connected car market are huge, but multiple challenges still exist. Life-cycles in the development of automotive and the mobile industry are a serious barrier for the future of connected cars. Simply, vehicles take much longer to develop than smartphones other portable gadgetry. More integration from vendors and suppliers are involved with the expertise to seamlessly fit the intended blueprint of the design. In fact, new features such as the operating system are becoming more prevalent, while the demand for sophisticated and centrally operated embedded systems are taking the height of the evolution. This means more dependence on integration of data from various channels, actuators, and sensors — the faculty to operate all the new uses cases such as automatic emergency response systems are functionality requiring more SoC embedded system requirements.

What is happening now?

People. Process. Governance. Adoption. Let’s look at the similarities stemmed from change. We are going to witness new safety laws and revised regulations coming through the industry. These new laws will dictate the demand for connectivity. Indeed, drawing importance this 2015 year with the requirement set by 2018, European Parliament voted in favor of eCall regulation. Cars in Europe must be equipped with eCall, a system that automatically contacts emergency services directing them to the vehicle location in the event of an emergency. The automotive and mobile industries have different regional and market objectives. Together, all the participants in both market segments will need to find ways to collaborate in order to satisfy consumer connectivity needs. Case in point, Chrysler has partnered with Nextel to successfully connect cars like their Dodge Viper, while General Motors uses AT&T as its mobile development partner.

What is resonating from the sales floor and customer perspective?

The demand is increasing for more sophistication and integration of software in the cabin of cars. This is happening from the manufacturer to the supplier network then to the integration partners — all are becoming more engaged to achieve the single outcome, pacing toward the movement to the connected car. Stretched as far as the actual retail outlets, auto dealers are shifting their practice to be more tech savvy, too. The advent of the smart  vehicle has already dramatically changed the dealership model, while more transformation awaits the consumer.

On the sales floor as well as the on-boarding experience, sales reps must plan to spend an hour or more teaching customers how to use their car’s advanced technology. But still, these are only a few mentioned scenarios where things have changed in relation to cars and how they are sold and even to the point of how they are distributed, owned, and serviced. One thing for certain, though, is that the design and user trend are intersecting to help shape the demand and experience a driver wants in the connected car. This is further bolstered by the fast paced evolution of smartphones and the marketing experiences now brought forth by the rapid adoption and prolific expansion of the mobile industry tethered by their very seamless and highly evolved experiences drawn from their preferred apps.

Today, customer experiences are becoming more tailored while users, albeit on the screen or engaged with their mobile devices are getting highly acquainted with the expectation of “picking up from where I left off” regardless of what channel, medium, device, or platform.  Seamless experiences are breaking through the market.  We witness Uber, where users initialize their click on their smartphone then follows by telemetry promoted from Uber drivers and back to the users smart phone.  In fact, this happens vis versa, Uber driver’s have information on their console showing customer location and order of priority.  Real life interactions are being further enhanced by real-time data, connecting one device to draw forth another platform to continue the journey.  Transportation is one of the areas where we can see real-time solutions changing our day-to-day engagement.  Some of these are being brought forth by Atmel’s IoT cloud partners such as PubNub where they leverage their stack in devices to offer dispatch, vehicle state, and geo fencing for many vehicle platforms.  Companies like Lixar, LoadSmart, GetTaxi, Sidecar, Uber, Lyft are using real-time technologies as integral workings to their integrated vehicle platforms.

Cars are becoming more of a software platform where value chain add-ons tied to an ecosystem are enabled within the software tethered by the cloud where data will continue to enhance the experience. The design trajectory for connected cars follow this software integration arrow.  Today, the demand emphasizes mobility along with required connectivity to customer services and advanced functions like power management for electric vehicles, where firmware/software updates further produce refined outcomes in the driver experience (range of car, battery management, other driver assisted functionalities).

Carmakers and mobile operators are debating the best way to connect the car to the web. Built-in options could provide stronger connections, but some consumers prefer tethering their existing smartphone to the car via Bluetooth or USB cable so they can have full access to their personal contacts and playlists. Connected car services will eventually make its way to the broader car market where embedded connections and embedded systems supporting these connections will begin to leverage various needs to integrate traditional desperate signals into a more centrally managed console.

Proliferation of the stack

The arrow of design for connected cars will demand more development, bolstering the concept that software and embedded systems factored with newly-introduced actuators and sensors will become more prevalent. We’re talking about “software on wheels,” “SoC on wheels,” and “secured mobility.”

Design wise, the cost-effective trend will still remain with performance embedded systems. Many new cars may have extremely broad range of sensor and actuator‑based IoT designs which can be implemented on a single compact certified wireless module.

Similarly, having fastest startup times by performing the task with a high-performance MCU vs MPU, is economic for a designer. It can not only reduce significant bill of materials cost, development resources, sculpted form factor, custom wireless design capabilities, but also minimize the board footprint. Aside from that, ARM has various IoT device development options, offering partner ecosystems with modules that have open standards. This ensures ease of IoT or connected car connectivity by having type approval certification through restrictive access to the communications stacks.

Drivers will be prompted with new end user applications — demand more deterministic code and processing with chips that support the secure memory capacity to build and house the software stack in these connected car applications.

Feature upon feature, layer upon layer of software combined with characteristics drawn from the events committed by drivers, tires, wheels, steering, location, telemetry, etc. Adapted speed and braking technologies are emerging now into various connected car makes, taking the traditional ABS concept to even higher levels combined with intelligence, along with controlled steering and better GPS systems, which will soon enable interim or cruise hands-free driving and parking.

Longer term, the technological advances behind the connected car will eventually lead to self-driving vehicles, but that very disruptive concept is still far out.

Where lies innovation and change is disruption

Like every eventual market disruption, there will be the in-between development of this connected car evolution. Innovative apps are everywhere, especially the paradigm where consumers have adopted to the seamless transitional experiences offered by apps and smartphones. Our need for ubiquitous connectivity and mobility, no matter where we are physically, is changing our vehicles into mobile platforms that want us users to seamlessly be connected to the world. This said demand for connectivity increases with the cost and devices involved will become more available. Cars as well as other mobility platforms are increasingly becoming connected packages with intelligent embedded systems. Cars are offering more than just entertainment — beyond providing richer multimedia features and in-car Internet access.  Further integration of secure and trusted vital data and connectivity points (hardware security/processing, crypto memory, and crypto authentication) can enable innovative navigation, safety and predictive maintenance capabilities.

Carmakers are worried about recent hacks,  especially with issues of security and reliability, making it unlikely that they will be open to every kind of app.  They’ll want to maintain some manufactured control framework and secure intrusion thwarting with developers, while also limiting the number of apps available in the car managing what goes or conflicts with the experience and safety measures.  Importantly, we are taking notice even now. Disruption comes fast, and Apple and others have been mentioned to enter this connected car market. This is the new frontier for technological equity scaling and technology brand appeal. Much like what we seen in the earlier models of Blackberry to smartphones, those late in the developmental evolution of their platforms may be forced adrift or implode by the market.

No one is arguing it will happen. Eventually, self-driving cars will arrive.  But for now, it remains a futuristic concept.

What can we do now in the invention, design and development process?

The broader output of manufactured cars will need to continue in leveraging new designs that take in more integration of traditional siloed integration vendors so that the emergence of more unified and centrally managed embedded controls can make its way. Hence, the importance now exists in the DNA of a holistically designed platform fitted with portfolio of processors and security to take on new service models and applications.

This year, we have compiled an interesting mixture of technical articles to support the development and engineering of car access systems, CAN and LIN networks, Ethernet in the car, capacitive interfaces and capacitive proximity measurement.

In parallel to the support of helping map toward the progress and evolution of the connected car, a new era of design exists. One in which the  platform demands embedded controls to evenly match their design characteristics and application use cases. We want to also highlight the highest performing ARM Cortex-M7 based MCU in the market, combining exceptional memory and connectivity options for leading design flexibility. The Atmel | SMART ARM Cortex-M7 family is ideal for automotive, IoT and industrial connectivity markets. These SAM V/E/S family of microcontrollers are the industry’s highest performing Cortex-M microcontrollers enhancing performance, while keeping cost and power consumption in check.

So are you designing for the latest automotive, IoT, or industrial product? Here’s a few things to keep in mind:

• Optimized for real-time deterministic code execution and low latency peripheral data access
• Six-stage dual-issue pipeline delivering 1500 CoreMarks at 300MHz
• Automotive-qualified ARM Cortex-M7 MCUs with Audio Video Bridging (AVB) over Ethernet and Media LB peripheral support (only device in the market today)
• M7 provides 32-bit floating point DSP capability as well as faster execution times with greater clock speed, floating point and twice the DSP power of the M4

We are taking the connected car design to the next performance level — having high-speed connectivity, high-density on-chip memory, and a solid ecosystem of design engineering tools. Recently, Atmel’s Timothy Grai added a unveiling point to the DSP story in Cortex-M7 processor fabric. True DSPs don’t do control and logical functions well; they generally lack the breadth of peripherals available on MCUs. “The attraction of the M7 is that it does both — DSP functions and control functions — hence it can be classified as a digital signal controller (DSC).” Grai quoted the example of Atmel’s SAM V70 and SAM V71 microcontrollers are used to connect end-nodes like infotainment audio amplifiers to the emerging Ethernet AVB network. In an audio amplifier, you receive a specific audio format that has to be converted, filtered, and modulated to match the requirement for each specific speaker in the car. Ethernet and DSP capabilities are required at the same time.

“The the audio amplifier in infotainment applications is a good example of DSC; a mix of MCU capabilities and peripherals plus DSP capability for audio processing. Most of the time, the main processor does not integrate Ethernet AVB, as the infotainment connectivity is based on Ethernet standard,” Grai said. “Large SoCs, which usually don’t have Ethernet interface, have slow start-up time and high power requirements. Atmel’s SAM V7x MCUs allow fast network start-up and facilitate power moding.”

Atmel has innovative memory technology in its DNA — critical to help fuel connected car and IoT product designers. It allows them to run the multiple communication stacks for applications using the same MCU without adding external memory. Avoiding external memories reduces the PCB footprint, lowers the BOM cost and eliminates the complexity of high-speed PCB design when pushing the performance to a maximum.

Importantly, the Atmel | SMART ARM Cortex-M7 family achieves a 1500 CoreMark Score, delivering superior connectivity options and unique memory architecture that can accommodate the said evolve of the eventual “SoC on wheels” design path for the connected car.

How to get started

1. Download this white paper detailing how to run more complex algorithms at higher speeds.
2. Check out the Atmel Automotive Compilation.
3. Attend hands-on training onboard the Atmel Tech on Tour trailer. Following these sessions, you will walk away with the Atmel | SMART SAM V71 Xplained Ultra Evaluation Kit.
4. Design the newest wave of embedded systems using SAM E70, SAM S70, or SAM V70 (ideal for automotive, IoT, smart gateways, industrial automation and drone applications, while the auto-grade SAM V70 and SAM V71 are ideal for telematics, audio amplifiers and advanced media connectivity).

[Images: European Commission, GSMA]

How Ethernet AVB is playing a central role in automotive streaming applications

---

Ethernet is emerging as the network of choice for infotainment and advanced driver assistance systems, Atmel’s Tim Grai explains.

---

Imagine you’re driving down the highway with the music blaring, enjoying the open road. Now imagine that the sound from your rear speaker system is delayed by a split second from the front; your enjoyment of the fancy in-car infotainment system comes to a screeching halt.

Ethernet is emerging as the network of choice for infotainment and advanced driver assistance systems that include cameras, telematics, rear-seat entertainment systems and mobile phones. But standard Ethernet protocols can’t assure timely and continuous audio/video (A/V) content delivery for bandwidth intensive and latency sensitive applications without buffering, jitter, lags or other performance hits.

Audio-Video Bridging (AVB) over Ethernet is a collection of extensions to the IEEE802.1 specifications that enables local Ethernet networks to stream time synchronised, loss sensitive A/V data. Within an Ethernet network, the AVB extensions help differentiate AVB traffic from the non-AVB traffic that can also flow through the network. This is done using an industry standard approach that allows for plug-and-play communication between systems from multiple vendors.

The extensions that define the AVB standard achieve this by:

• reserving bandwidth for AVB data transfers to avoid packet loss due to network congestion from ‘talker’ to ‘listener(s)’
• establishing queuing and forwarding rules for AVB packets that keep packets from bunching and guarantee delivery of packets with a bounded latency from talker to listener(s) via intermediate switches, if needed
• synchronizing time to a global clock so the time bases of all network nodes are aligned precisely to a common network master clock, and
• creating time aware packets which include a ‘presentation time’ that specifies when A/V data inside a packet has to be played.

Designers of automotive A/V systems need to understand the AVB extensions and requirements, as well as how their chosen microcontroller will support that functionality.

AVB: A basket of standards

AVB requires that three extensions be met in order to comply with IEEE802.1:

• IEEE802.1AS – timing and synchronisation for time-sensitive applications (gPTP)
• IEEE802.1Qat – stream reservation protocol (SRP)
• IEEE802.1Qav – forwarding and queuing for time-sensitive streams (FQTSS).

In order to play music or video from one source, such as a car’s head unit, to multiple destinations, like backseat monitors, amplifiers and speakers, the system needs a common understanding of time in order to avoid lags or mismatch in sound or video. IEEE802.1AS-2011 specifies how to establish and maintain a single time reference – a synchronised ‘wall clock’ – for all nodes in a local network. The generalized precision time protocol (gPTP), based on IEEE1588, is used to synchronize and syntonize all network nodes to sub-microsecond accuracy. Nodes are synchronized if their clocks show the same time and are syntonised if their clocks increase at the same rate.

This protocol selects a Grand Master Clock from which the current time is propagated to all network end-stations. In addition, the protocol specifies how to correct for clock offset and clock drifts by measuring path delays and frequency offsets. New MCUs, such as the Atmel | SMART SAMV7x (shown above), detect and capture time stamps automatically when gPTP event messages cross MII layers. They can also transport gPTP messages over raw Ethernet, IPv4 or IPv6. This hardware recognition feature helps to calculate clock offset and link delay with greater accuracy and minimal software load.

Meanwhile, SRP guarantees end-to-end bandwidth reservation for all streams to ensure packets aren’t delayed or dropped at any switch due to network congestion, which can occur with standard Ethernet. For the in-vehicle environment, SRP is typically configured in advance by the car maker, who defines data streams and bandwidth allocations.

Talkers (the source of A/V data) ‘advertise’ data streams and their characteristics. Switches process these announcements from talker and listeners to:

• register and prune streams’ path through the network
• reserve bandwidth and prevent over subscription of available bandwidth
• establish forwarding rules for incoming packets
• establish the SRP domain, and
• merge multiple listener declarations for the same stream

The standard stipulates that AVB data can reserve only 75% of total available bandwidth, so for a 100Mbit/s link, the maximum AVB data is 75Mbit/s. The remaining bandwidth can be used for all other Ethernet protocols.

In automotive systems, the streams may be preconfigured and bandwidth can be reserved statically at system startup to reduce the time needed to bring the network into a fully operational state. This supports safety functions, such as driver alerts and the reversing camera, that must be displayed within seconds.

SRP uses other signalling protocols, such as Multiple MAC Registration Protocol, Multiple VLAN Registration Protocol and Multiple Stream Registration Protocol to establish bandwidth reservations for A/V streams dynamically.

The third extension is FQTSS, which guarantees that time sensitive A/V streams arrive at their listeners within a bounded latency. It also defines procedures for priority regenerations and credit based traffic shaper algorithms to meet stream reservations for all available devices.

The AVB standard can support up to eight traffic classes, which are used to determine quality of service. Typically, nodes support at least two traffic classes – Class A, the highest priority, and Class B. Microcontroller features help manage receive and transmit data with multiple priority queues to support AVB and ‘best effort class’ non AVB data.

Automotive tailored requirements

Automotive use cases typically fix many parameters at the system definition phase, which means that AVB implementation can be optimised and simplified to some extent.

• Best Master Clock algorithm (BMCA): the best clock master is fixed at the network definition phase so dynamic selection using BCMA isn’t needed.
• SRP: all streams, their contents and their characteristics are known at system definition and no new streams are dynamically created or destroyed; the proper reservation of data is known at the system definition phase; switches, talkers and listeners can have their configurations loaded at system startup from pre-configured tables, rather than from dynamic negotiations
• Latency; while this is not critical, delivery is. Automotive networks are very small with only a few nodes between a talker and listener. It is more important not to drop packets due to congestion.

Conclusion

The requirement to transfer high volumes of time sensitive audio and video content inside vehicles necessitates developers to understand and apply the Ethernet AVB extensions. AVB standardization results in interoperable end-devices from multiple vendors that can deliver audio and video streams to distributed equipment on the network with micro-second accuracy or better. While the standard brings complexities, new MCUs with advanced features are simplifying automotive A/V design.

---

This article was originally published on New Electronics on October 13, 2015 and authored by Tim Grai, Atmel’s Director of Automotive MCU Application Engineering. 

Atmel launches new CAN transceiver family

We are excited to announce the launch of a new family of control area network (CAN) transceivers to meet the growing demands of the automotive and industrial markets. Supporting the new CAN FD (flexible data rate) standard with data rates up to 5Mbits/s, our new ATA6560 and ATA6561 provide an interface between a CAN protocol controller and the physical two-wire CAN bus.

Compliant with ISO11898-2, ISO11898-5 and SAEJ2284, the new CAN transceiver family offers high electromagnetic compatibility (EMC) and electrostatic discharge (ESD) performance. Both the ATA6560 and ATA6561 devices deliver ideal passive behavior to the CAN bus when the supply voltage is off, while the ATA6561 offers a direct interface to MCUs with 3V to 5V supply voltages.

Various operating modes together with the dedicated fail-safe features make the ATA6560/ATA6561 an excellent choice for all types of high-speed CAN networks, especially in CAN nodes requiring a low-power mode with wake-up capability via the CAN bus. Atmel’s new low-power CAN transceivers are developed on an advanced process technology that allows further integration of analog and complex digital functionality. The devices are available in SO8 and DFN8 packages with wet-able flanks for automated optical solder inspection.

“Our new family of CAN transceivers enables our OEMs to bring improved connectivity with higher speed in their automobile with overall lower power,” explained Claus Mochel, Atmel Marketing Director for Automotive High Voltage Products. “We are continuing to expand our automotive product portfolio to give our customers the right mix of products to help shorten their design cycle and bring next-generation designs faster to market.”

Among the many key features of Atmel’s ATA6560/61 are:

• Data rate up to 5Mbits/s
• Fully ISO 11898-2,-5, SAE J2284 compliant
• Low EME and high EMI
• Remote wake-up capability via CAN bus
• Transmit data (TXD) dominant time-out function
• Undervoltage detection on VCC and VIO pins
• CANH/CANL short-circuit and over temperature protected
• ATA6560: Silent Mode (Receive only)
• ATA6561: Compatible to 3.3V and 5V control signals

Both the ATA6560 and ATA6561 CAN transceivers are now available in mass production in SO8 and DFN8 packaging with wet-able flanks for automated optical solder inspection. Interested? Pricing starts at $0.48 USD each in 10,000-piece quantities. You can find more detailed information — including datasheets — here.

Heading to Munich next week for Electronica 2014? Stop by Atmel booth — located in Hall A5, #542 — to discover how we’re bringing the Internet of Things to the connected car though simple, touch-enabled human machine interfaces. There, you will find both the ATA6560 and ATA6561 CAN transceivers among a number of other demos including passive entry and start, a next-generation center console and futuristic door handle.

The CANBus Triple is like an Arduino for your car

According to Maker Derek Kuschel, there is a massive pool of hidden data flowing around within a car’s computer units. In an effort to display this data, Derek recently launched a successful Kickstarter campaign for a device that taps into these binary riches. If you’re someone who enjoys tinkering with their vehicle, you’ll certainly be interested in his new car hacking platform, the CANBus Triple.

CANBus Triple has been developed in hopes of providing an Arduino-style device for cars that can be used to bus data and add awesome functionality to your vehicle.

The Controller Area Network (CAN) is a message-based protocol found in modern automobiles, which carries significant amounts of data all around your vehicle while you drive, with much of it being unavailable to the average driver. In fcat, . Atmel offers a wide range of solutions for CAN networking, including AVR 8-bit RISC microcontrollers and transceivers.

However, it didn’t sit well with Derek that this much data was going to waste; therefore, through a series of three prototypes, he finally developed a system to display this sought after automobile information.

“The CAN Bus Triple gives you an easy way to read and write raw CAN data packets, and perform operations with that data easily,” the Maker elaborates. Using an Atmel ATmega32u4 MCU, the device can read and analyze numerous data sets that are traditionally hidden within the vehicle’s inner workings.

You can use the CANBus Triple to simply watch all the data on your CAN Bus, or send your own packets out to the network. “Simply attaching the two CAN High and Low lines it’s all you need to send and receive raw CAN data packets,” its Kickstarter page explains. “The real fun comes in when you physically cut the CAN Bus and use the CANBus Triple to read and augment the packets. Each packet is read and processed, then optionally sent back out and your car doesn’t know the difference.”

As Derek points out, using this method, one can listen for all of the hidden data on the bus and send it over Bluteooth LE, or even send out your own packets to an in-dash OEM display as shown below on a Mazdaspeed3.

Given the open-source nature of his project, Derek has provided fellow Makers with the coding and schematics needed to produce their own software for the CAN Bus Triple platform as he envisions his project as “a toolkit for adding to and augmenting your vehicle.”

Both the ATmega program and Bluetooth firmware are flashable without any additional hardware, the Maker explains. “You can add functionality to the Bluetooth module and upload the firmware over USB!” Now, add in the fact that the Triple is compatible with the Arduino IDE and can run on multiple mobile platforms, and any mechanic Maker should be ready to rev their engines!

Derek is currently beta testing his machine in a variety of cars. He has used the device in his Mazdaspeed 3 for over two years without a single issue. Next up will be large-scale production, and shortly thereafter hopefully customer distribution by the end of the year.

The open-source car hacking platform garnered just shy of $68,000 in pledges, tripling its original goal of $18,000. For more information about Derek’s project or how you could obtain your own unit, head over to his Kickstarter page.

Nuvation talks Atmel and batteries at EELive! 2014

Nuvation CEO Mike Worry is at Atmel’s EELive! 2014 ToT booth presenting a series of Tech Talks about his company’s EV Battery Management System. His presentations have been covered by a number of prominent journalists, including Steve Taranovich of EDN.

“We’e seen enough instances of battery disasters occurring over the last few years in our industry. Batteries have a tremendous amount of energy within and if not properly handled and charged/monitored can be dangerous,” writes Taranovich.

“With chemistries such as Lithium, each cell must have its voltage monitored and balanced. This not only extends battery life, but prevents tragedies. [This is why] Nuvation has expertly developed their customizable battery Management System (BMS) that can handle 10s to 1,000s of cells. The system is easily made compatible with lithium, nickel, silver based and other battery chemistries.”

In terms of the Tank Controller, Nuvation selected Atmel’s ATSAM4E8C, a 32-bit ARM Cortex-M4 controller to power a wide range of features, including Ethernet, UART, CAN, current shunt and optically-isolated GPIO.

As Taranovich notes, the Tank Controller is also equipped with an optically-isolated interface to battery pack management (PackMan) strings.

“The system handles soft-start, main start and emergency disconnect and controls the charging system to protect the battery,” says Taranovich.

Meanwhile, the PackMan, or BMS slave utilizes Atmel’s ATA6870N, a Li-Ion, NiMH battery measuring, charge balancing and power-supply circuit.

This IC is tasked with measuring all cell voltages simultaneously – and balancing cells with higher voltage. 

Each IC is capable of monitoring 6 cells, with a daisy chain configuration supporting up to 16 PackMan board or 96 stacked cells.

“Nuvation’s BMS must deal with the balance/imbalance of a battery pack. It looks at the state-of-charge (SOC) between cells in the pack,” Taranovich adds. “The usable SOC of pack is determined by the lowest energy cell and then the BMS has the task of balancing these cells accurately and quickly without overcharging or overheating the cell.”

Interested in learning more? You can check out Nuvation’s official site here, while the full text of Steve Taranovich’s “Nuvation at EELive: The Fun in Electronics Design” can be read on EDN here.

Automotive circuit design headaches

I wrote an article for Electronic Design magazine about Bob Pease and his solenoid driver circuit. Former National Semiconductor employee Myles H. Kitchen was nice enough to drop me an encouraging note.

“Thanks for your great article on Bob Pease and the solenoid drivers. Having worked with Bob in the late 1970s and early 1980s at National Semiconductor, I came to appreciate his wisdom and simplicity for addressing issues that seemed simple, but were really quite involved. As someone who’s worked on automotive electronics my entire career, an issue such as a solenoid driver is critical. I recall when testing early automotive product designs at one company, we would put the module under test in a car, and then turn on the 4-way flashers to see if operation was affected, or if it stopped working completely. The combination of multiple inductive and high-current resistive loads operating on and off at several hertz would play havoc with the power supply, and immediately point out design deficiencies in module power supplies, regulation, protection, and noise immunity…. some of which could be traced to poor relay or solenoid driver circuits.  Surviving the 4-way flasher test was only a quick way to see how robust the new design might be, but it was a quick indicator if we had things right up to that point. I miss Bob and his ramblings in ED, but hope to see more of your work in the future.  Loved it.”

Well, having been an automotive engineer at both GM and Ford before moving out to Silicon Valley, Myles’s note sparked a flood of memories. His four-way flasher story was prophetic. When I was in college at GMI (General Motors Institute) one of my pals worked at Delco. They were just coming out with the integrated electronic voltage regulator in the back of the alternator, circa 1973. So all the executives were standing around at a demo and after they ohhhh and ahhhh, and congratulate themselves, my buddy gets in the car, and knowing what Myles knows, he cycles the air conditioning switch a few times. The “Charge” light promptly came on.

I asked my fellow student if he was in trouble or if they hated him for causing the failure, and to GM’s credit, he told me “No, they were actually glad I found it before it went into production.” It must have been some serious egg on some faces, though. After that, survival after repeated AC clutch cycling became part of the spec for the voltage regulator. I bet four-way flashers are included as well.

I later worked on anti-lock brakes for GMC heavy duty trucks. This was way before anti-lock brakes on cars, about 1975. We dutifully shielded all the wires to the sensors with expensive braided cable. When we pulled the truck out on the road, the brakes started modulating, with the truck just sitting there. We realized that the entire 24V power system was a pretty nice antenna and that noise can get into a module from the power side as easy as from the sensors. We begged the government to give us more time, and they did. Indeed, I don’t know if they ever put in antilock brakes on heavy trucks. Let me check, yeah, wow, it’s still called MVSS 121 (motor vehicle safely standard) and it finally went into effect in 1997. That was at least a 20-year delay in getting it working.

I told Bob Reay over at Linear Tech that automotive design was the toughest, because you had a military temperature and vibration, but consumer cost. He added another factor, the chips for automotive have to yield well, since you need to ship millions. What a crazy challenge.

When I thanked Myles Kitchen for his kind words and told him the above stories, he responded with a great story about load dump. The phenomena called load dump is usually caused by a mechanic who is troubleshooting the battery and charging system of a car. You get the car running, rev it up a bit, and yank off the battery cable. If the car keeps running, that means the alternator and regulator are OK, it is just a bad battery. Thing is, the alternator is often putting full output into this bad battery. And when you yank the cable off the battery, the voltage regulator controlling the alternator cannot react instantly. So there is this huge overvoltage spike as all the stored energy in the alternators magnetic field has to dissipate into whatever loads are still connected, like your radio. A load dump can put over 100 volts on electrical system. And it is not a fast spike; it can last for hundreds of milliseconds. Smart mechanics just leave the battery cable on and hook up a voltmeter to see if the alternator is putting 13.75 to 14.2 volts on the battery. So Myles recounts:

“Thanks for your email.  Yes, sounds like we’ve run up against many of the common automotive issues in our time.  I’ll add one brief anecdote here.  When I worked at Motorola’s automotive division, I certainly learned all about what a load dump is, but I’d never really heard of anyone experiencing one first-hand and what it could do.  One day, our admin complained that her 70’s vintage Plymouth Duster wasn’t running right, and that her headlamps and radio quit working.  She had been driving it the night before when something went wrong.  We brought it into the garage at Motorola, and found that she had a very discharged battery with very loose battery connections. You could just lift them off with your hand.  As a result, her battery was discharged, and when she hit a Chicago pothole it all went bad.  The resulting load dump had blown out every light bulb filament in the car, along with the radio.  Only the alternator/regulator had survived.  The ignition was still a points and condenser system, or that would have probably died as well.  A new battery, tight connections, and a bunch of replacement bulbs got her back on the road again.  And, I’ve never doubted the need for a load-dump-tolerant design since!”

Those are wise words from someone who has been there and seen it first-hand. And I wonder if the voltage regular in that old Duster was a mechanical points type. In the early days we automotive engineers would try to protect each individual component for load dump. The radio would have a Zener diode clamp, so would the cruise control module. Then manufactures put a big Zener clamp right in the voltage regulator that clamps the voltage on the whole car. Maybe that was too low an impedance to clamp, because now I see there are a lot of smaller distributed TVS (transient voltage suppressor) clamps that you use to protect the circuitry of your module.

There are two other approaches. One, you can just disconnect your circuit with a high-voltage FET when the load dump happens:

I used this circuit to keep automotive overvoltage from destroying an LT1513 chip I used as a battery charger. When the DC Bus voltage exceeds the 24V Zener plus the base-emitter drop of Q10, it turns Q10 on and that turns Q12 off and protects downstream circuitry from overvoltage.

Alternative two, you can put a high-voltage regulator in front of your circuit that will maintain power to your circuit through the load dump, at the risk that the pass transistor will overheat since it is dropping a lot of voltage while passing current during the load dump. Linear Tech makes such a part.

There is one more tip for every engineer regarding automotive electronics. Remember that there are laws that make auto manufacturers offer service parts for 10 or 15 years. So no matter what your application, you might consider using an automotive part like Atmel’s line of MCUs, memory, CAN/LIN bus, and RF remote controls. We state that we will be making many of these parts for over a decade. If you design them into your industrial, medical or scientific application (ISM) you can have some assurance you can still get the part for years, or at least a pin-for-pin compatible part. That means no board spins. On top of that assurance, most of the parts have extended temperature range, which might help in your application as well. Since we make the parts for high-volume automotive customers, they are usually priced very reasonably.

Two-Wire LIN networking with Atmel (Part 1)

Current-gen vehicles are packed with hundreds of sensors used to monitor and display parameters such as temperature and pressure. In most instances, these sensors are remotely located within a vehicle far away from the host microcontroller (MCU) responsible for monitoring and processing the sensor data.

As such, these sensors typically do not directly connect to a network (such as CAN or LIN) due to the vehicle wiring overhead associated with connecting to the network. One such method for overcoming this wiring limitation is to convert the standard three-wire LIN network to a two-wire implementation where the LIN slave nodes harvest power directly from the LIN bus master communication wire, thereby eliminating the need for an individual battery supply wire to each slave node.

As Atmel engineering rep Darius Rydahl notes, a standard LIN bus consists of a master node and up to 15 slave nodes connected to a single network. The physical LIN network is a three-wire configuration consisting of power (vehicle battery), ground and the LIN bus communication line. A pull-up resistor, RLIN, typically 1kΩ, is required on the master’s LIN bus line. Under normal LIN bus operation, this pull-up resistor provides a voltage bias on the LIN bus line to the slave nodes on the LIN network. It does not power the LIN slave nodes, rather slave node power is derived from the battery input to the device, as shown in Figure 1.

“It is possible to use a non-standard LIN network architecture that simplifies to two wires. This approach relies on the harvesting of power by a connected slave node directly from the LIN bus line, thus eliminating the need for an independent slave node battery supply line (see figure 2),” Rydahl told Bits & Pieces. “With the battery supply line removed, all that is required to power the slave node is a blocking diode, VDS and buffer capacitor, CVS_S, large enough to sustain the slave node supply voltage during the transmission of LIN data packets, which periodically pulls the LIN signal to ground.”

In this series, Bits & Pieces will outline the implementation of this two-wire approach and identify the inherent system-level tradeoffs that must be considered to fully realize a functional two-wire LIN network.

According to Rydahl, the key to successfully implementing a two-wire LIN network centers around the power requirements of the connected slave node. Simply put, the slave node must be supplied with sufficient power to maintain communication at the minimum system operating voltage: typically 9V. If this condition cannot be met, it is unlikely that the two-wire LIN implementation will be a viable solution. Key parameters that affect the slave node’s performance in a two-wire implementation include LIN bus power supply, slave node current consumption, slave node buffer capacitance and LIN Bus data protocol.

“In terms of the LIN Bus power supply, the two-wire LIN network is limited by the power supplied from the master to the slave node over the LIN bus line. Meaning, the supply to the LIN slave in this configuration will be dictated by the LIN bus master pull-up resistor, RLIN (see figure 2),” Rydahl continued. “The slave node has a fixed minimum input voltage operating requirement of 5.5V (reference: the Atmel ATA6624 LIN transceiver). In order to meet this minimum operating voltage requirement, the load current drawn by the slave node must not cause the voltage drop across the LIN master pull-up resistor to increase to the point at which the input voltage to the slave node drops below 5.5V.”

As Rydahl points out, this is the minimum operating voltage threshold for slave node voltage regulator operation. Indeed, figure 3 shows the maximum load current available to the slave node at the minimum supply voltage of 5.5V at different LIN master pull-up resistances.

“The 1kΩ master pull-up resistor specified in the LIN standard specification cannot be used in the two-wire configuration. The resistor is too large and, as a result, is unable to properly source the slave node load,” he said. “As such, the pull-up resistor must be reduced in size to the smallest value possible without exceeding the current limitation specification of the LIN driver. In the case of the typical Atmel LIN transceiver, the ATA6624, the recommended minimum pullup resistor value is 220Ω. Resistances lower than this could result in excessive current flow through the LIN transceiver when the LIN bus is asserted low.”

Interested in learning more about Two-Wire LIN networking with Atmel? Be sure to check out part two of this series here.

Designing next-gen LIN systems with Atmel (Part 1)

The LIN (Local Interconnect Network) bus is a vehicle standard used within the latest automotive network architectures. The low-cost, single-wire serial communication system for distributed electronics in vehicles is highly suited to body control applications, including power windows, mirrors, smart wipers, door locks, seat/roof/lighting control, lamps and indicators, dashboard instruments, steering wheels, climate and air-conditioning (HVAC) systems, motors, switch panels and sensors.

“It is primarily used as a cost-effective sub-network of a CAN bus to integrate intelligent sensor devices or actuators where the LIN master node also acts as a gateway to connect the LIN bus with the corresponding CAN bus,” an Atmel engineering rep told Bits & Pieces. “Going hand in hand with rapid LIN market growth, the requirements for greater system efficiency and lower costs exerted on LIN products have continued to increase as well.”

To be sure, in-vehicle electronic systems are rapidly evolving and increasing in number, as are the number of switches for controlling various applications. In addition, applications with switches located far away from the control electronics and wires integrated within the wiring harness require high-voltage switches.

“And that is precisely why Atmel offers a next-generation ATA6641/42 System Basis Chip (SBC) with an eight-channel high-voltage switch interface, a LIN2.1 and SAEJ2602-2-compliant LIN transceiver and lowdrop voltage regulator,” the Atmel engineering rep continued. “The ATA6641/42 also boasts an adjustable window watchdog, facilitating the development of inexpensive, low-end, but also powerful slave and master nodes for LIN bus systems meeting the latest OEM requirements.”

Due to its optimized architecture, the ATA6641/42 provides a high degree of flexibility for deployment in various applications such as switch connection through the wiring harness, port/contact monitoring, contact cleaning, switches (towards GND or VBAT) and LED/relay/power transistor control.

Two versions of the System Basis Chip are currently available: the ATA6641 with a 3.3V voltage regulator and the ATA6642 with a 5V voltage regulator. The voltage regulator delivers up to 80mA load current. Sleep mode and active low-power mode guarantee very low current consumption even in the case of a floating bus line or a short circuit on the LIN bus to GND. To maintain very low current consumption in sleep mode, a special technique ensures that the circuit switches back to sleep mode after approximately 10ms if the bus line is floating or in case of a short circuit.

Improved slope control at the LIN driver ensures secure data communication of up to 20kBaud, while data rates of up to 250kBaud also enable high-speed data communication. Most features can be configured via the 16-bit SPI interface which streamlines and accelerates configuration of the slave/master LIN node for any given application.

Want to learn more about Atmel’s ATA6641/42? Be sure to check out part two and three of this series.

32-bit AVR MCUs for automotive applications (Part 4)

In the first part of this series, we took a closer look at how Atmel’s AVR low-power 32-bit microcontrollers (MCUs) help enable the implementation of various product-differentiating features, including advanced control algorithms, voice control and capacitive touch sensing.

We also discussed powering Atmel’s AVR UC3C 32-bit automotive-grade microcontrollers with either a 3.3V or a 5V supply  (generally supporting 5V I/O), talked about Atmel’s Peripheral Event System and explored how Atmel’s low-power 32-bit microcontrollers (MCUs) are used to help protect IP and bolster system safety.

Today we will take an in-depth look at how Atmel’s AVR low-power 32-bit microcontrollers (MCUs) help streamline automotive development. As previously discussed on Bits & Pieces, evaluating current-gen microcontroller architecture requires a complete development environment, including an evaluation kit, a software development environment with compiler and debugger, as well as a comprehensive set of application examples, drivers and services.

“[Simply put], Atmel simplifies system development with the AVR Software Framework, which supports a variety of optimized interface drivers peripheral firmware, and application code – including extensive motor control algorithms, capacitive touch drivers, advanced digital signal processing algorithms (i.e., FFTs and filters such as band-pass, high-pass, and low-pass), commonly used audio and image codecs such as MP3, speech recognition engines, display drivers, and FAT12/16/32 file systems, to name a few,” an Atmel engineering rep told Bits & Pieces.

“For automotive systems, the support with LIN and CAN software stacks, as well as with operating systems such as OSEK, and MCAL layers for the Autosar environment is mandatory. Model-based approaches for the development of automotive applications are becoming more and more popular, and these require additional support of design environments such as MATLAB/Simulink. Atmel AVR MCUs also support real-time trace, enabling full system operation visibility. Plus, updates with new features are available every quarter.”

In terms of software, the intuitive GUI-based Atmel AVR Studio is the industry’s most complete development environment for 8- and 32-bit applications, offering full compiler and debugger support for all AVR microcontrollers. Since peripherals are configured using the AVR Software Framework, migration between different AVR devices is truly seamless.

Atmel also supplies a wide range of hardware-based tools for in-system programming, debugging, and evaluation. The AT32UC3C-EK evaluation kit provides access to the extensive capabilities of the UC3C architecture with out-of-the-box simplicity, with the evaluation kit supporting Atmel QTouch capabilities.

“Specific examples of automotive applications with Atmel’s AVR UC3C include car audio, LED backlighting with a dimming function for the indicators, as well as interfaces for different types of sensors and switches to control the window lifter and the mirror positioning,” the Atmel engineering rep continued.

“Perhaps most importantly, a microcontroller such as the UC3C—with peripheral integration and extended processing capacity—allows an entire system architecture to be consolidated onto a single chip.”

Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part one, two and three of this series.

Atmel accelerates automotive design (Part 2)

Yesterday, Bits & Pieces took a closer look at how Atmel is helping accelerate automotive design by closely collaborating with Vector Informatik to fully support our  32-bit AUTOSAR compliant devices.

Essentially, AUTOSAR provides an abstraction layer between hardware and application – allowing hardware-independent development and testing of the application software. It also permits the reuse of a validated application from previous designs for a new one.

“And that is precisely why Atmel has developed a microcontroller (MCU) abstraction layer (MCAL) for its 32-bit AVR automotive family devices,” Atmel engineering rep Eric Tinlot told Bits & Pieces.

“These MCAL modules and Vector’s LIN/CAN communication layers are integrated into Vector’s complete MICROSAR environment (including OS, real-time environment, diagnostic, etc). Using Vector’s DaVinci, Atmel has also developed a complete set of graphical user interfaces (GUI) for each MCAL module to help users configure all features needed in the application.”

According to Tinlot, all MCAL modules have to be configured using their respective GUI screens. The user generates the required configuration files (.h and .c files) with a single click of the ‘generate’ toolbar icon (green triangle) at the top. These configuration files, the MCAL module, and the MICROSAR package can be compiled with any AUTOSAR application onto a 32-bit AVR automotive device to design an AUTOSAR-compliant ECU node.

The following list details the specific MCALs and GUIs developed by Atmel, with the CAN and LIN drivers provided by Vector Informatik.

• General-purpose timer driver
• Watchdog driver
• Microcontroller unit driver
• Flash drivers
• EEPROM drivers
• Serial protocol interface drivers
• ICU drivers
• Pulse width modulation (PWM) drivers
• Analog-digital (A/D) converter drivers
• Digital input output drivers
• Port drivers

“Simply put, the complete AUTOSAR solution, available via Vector Informatik, allows designers to develop their own ECU firmware using an Atmel 32-bit automotive device,” Tinlot added. “Networking communication via LIN or CAN buses is also available. Meaning, the included firmware fulfills AUTOSAR spec requirements.”