The smart router is ready for IoT play

---

The evolution of router has reached the IoT’s doorsteps, and it raises some interesting prospects for industrial and smart home markets.

---

The router used to be largely a dumb device. Not anymore in the Internet of Things arena where node intelligence is imperative to make a play of the sheer amount of data acquired from sensors, machines and other ‘things.’ The IoT router marks a new era of network intelligence — but what makes a router smart?

For starters, it employs embedded hardware platforms with DIY capabilities while balancing the performance and power consumption requirements. Next, an IoT router provides the operational status on an LCD screen while manipulating the data from different interfaces. In human machine interface (HMI) applications, for example, a smart router offers LCD and touch screen interfaces on expansion I/Os.

Take the case of the DAB-OWRT-53 smart router, which is developed by the Belgian design house DAB-Embedded. The sub-100 euro device — based on Atmel’s SAMA5D36 processor and OpenWRT router hardware platform — is mainly targeted at smart home and industrial IoT applications.

The IoT router supports popular wireless interfaces such as Wi-Fi, ZigBee and Z-Wave, as well as a diverse number of wired interfaces including Ethernet, USB, CAN 2.0A/B, KNX and RS-232. And all the data from these interfaces can be stored in either microSD card or NAND flash.

Anatomy of Smart Router

The Atmel | SMART SAMA5D36 is at the heart of the smart router design. First and foremost, it optimizes power consumption in the battery-operated router that features 3.7V lithium polymer battery support with charging capability over a microUSB connector. The router boasts eight hours of battery lifetime while being in full ON mode with Wi-Fi communications.

Second, the ARM Cortex-A5 processor shows a robust performance in the communications domain. For instance, the SAMA5D36 implements routing functionality to transfer data from one Ethernet port to another in a way that router designers don’t require an external hardware hub or switch. Moreover, Atmel’s MPU offers greater flexibility to run a lot of embedded software packages such as OpenZWave and LinuxMCE.

Third, the SAMA5D36-based IoT router offers users the ability to manipulate firewall settings, Disable PING, Telnet, SSH and UPnP features. Furthermore, the hardware security block in SAMA5D3 processor allows the use of CryptoDev Linux drivers to speed up the OpenSSL implementation. The Wi-Fi module — powered by Atmel’s WILC3000 single-chip solution — also supports the IEEE 802.11 WEP, WPA and WPA2 security mechanisms.

The smart router of DAB-Embedded employs Active-Semi’s ACT8945AQJ305-T power management IC, but the real surprise is Altera’s MAX 10 FPGA with an integrated analog-to-digital converter (ADC). That brings the additional flexibility for the main CPU: Atmel’s SAMA5D36.

The FPGA is connected to the 16-bit external bus interface (EBI) so that IoT developers can put any IP core in FPGA for communication with external sensors. All data is converted inside the FPGA to a specific format by using NIOS II’s soft CPU in FPGA. Next, the SAMA5D36 processor reads this data by employing DMA channel over the high-speed mezzanine card (HSMC) bus.

An FPGA has enough cells to start even two soft cores for data preprocessing. Case in point: A weather station with 8-channel external ADC managing light sensors, temperature sensors, pressure sensors and more. It’s connected to the FPGA together with PPS signal from GPS for correct time synchronization of each measurement.

OpenWRT Framework

The SAMA5D36 embedded processor enables DAB’s smart router design to customize free OpenWRT Linux firmware according to the specific IoT application needs. The OpenWRT framework facilitates an easy way to set up router-like devices equipped with communications interfaces such as dual-port Ethernet and Wi-Fi connection.

What’s more, by using the OpenWRT framework, an IoT developer can add now his or her own application (C/C++) to exchange data with a KNX or Z-Wave transceiver. OpenWRT even supports the Lua embedded interpreter.

Next, while DAB-Embedded has built its smart router using the embedded Linux with OpenWRT framework, Belgium’s design house also offers a board support package (BSP) based on the Windows Embedded Compact 2013 software. That’s for IoT developers who have invested in Windows applications and want to use them on the new hardware: the DAB-OWRT-53 smart router.

Later, the embedded design firm plans to release smart router hardware based on the Windows 10 IoT software and Atmel’s SAMA5D family of embedded processors. The Belgian developer of IoT products has vowed to release the second version of its router board based on Atmel’s SAMA5D4 embedded processor and WILC3000 chipset that comes integrated with power amplifier, LNA, switch and power management. Atmel’s WILC3000 single-chip solution boasts IEEE 802.11 b/g/n RF/baseband/MAC link controller and Bluetooth 4.0 connection.

---

Majeed Ahmad is the author of books Smartphone: Mobile Revolution at the Crossroads of Communications, Computing and Consumer Electronics and The Next Web of 50 Billion Devices: Mobile Internet’s Past, Present and Future.

The power of the platform in IoT and wearable designs

---

What IoT developers want? A candid look at the wearable designs shows how platform approach is helping design engineers confront daunting challenges in the IoT arena.

---

“Providers become platforms” is the second most prominent finding of the Forbes story entitled “The Five Most Disruptive Innovations at CES 2016.” Interestingly, all the five disrupting forces outlined in the story relate to the Internet of Things blaze one way or the other. A coincidence? Not really.

CES 2016 was mostly about demonstrating how the advent of a connected world is possible with the creation of an array of smart and interconnected devices. However, the IoT juggernaut, while exploring the true value of connectivity, also requires new business models, which in turn, makes time-to-market even more critical.

Take smart wearable devices, for instance, which were arguably the biggest story on the CES floor this year. A wearable design comprises of one or more sensors, connectivity solution like a radio controller, a processor to carry out system-level functions, storage to log information, display and battery. And what IoT and wearable developers want?

A platform that allows them to facilitate the finished products quickly and efficiently. The design engineers simply can’t afford experimentation with the basic blocks as they need a precedence of basic hardware and software functions working efficiently and smoothly.

Anatomy of Wearable Design

First and foremost, wearable designs confront power constraints even greater than mobile devices. Not surprisingly, ultra-low-power MCUs lie at the heart of wearable designs because they combine flash, on-chip RAM and multiple interface options while intelligently turning power on and off during activity and idle periods, respectively.

The next design conundrum relates to the form factor because these devices are being worn, so they have to be small and light. That, in turn, demands even smaller circuit boards with a greater level of integration. Enter the IoT platforms.

Amid power, performance and form factor considerations, the choice of a right IoT platform means that designers will most likely get the basic building blocks right. And that will allow IoT developers to focus on the application, differentiation and customer needs.

That’s what Atmel is aiming for with the launch of a reference platform for cost-optimized IoT and wearable applications. Atmel’s ultra-low-power platform, which was announced over the week of CES, is aimed at battery-operated wearable devices requiring activity and environment monitoring.

IoT Developer Platform

Below are the key highlights of Atmel’s platform offering for the IoT and wearable designs.

Processor: Microcontroller’s low-power requirements make it a likely choice in wearable designs; MCUs that communicate and process sensor inputs draw very little power from the battery while asleep. Remember the L21 microcontroller that made headlines back in 2015 after leading the low-power benchmarks conducted by EEMBC ULPBench.

Atmel’s SMART SAM L21 MCU — based on ARM’s lowest power Cortex-M0+ processing core — scored 185 in the benchmark and was able to bring the power consumption down to 35µA/MHz in active mode and 200nA in sleep mode.

Communications: The BTLC1000 is an ultra-low power Bluetooth Smart (BLE 4.1) system-on-chip (SoC) that comes integrated with ARM Cortex-M0 core, transceiver, modem, MAC, power amplifier, TR switch, and power management unit (PMU). It can be used as a BLE link controller or data pump with external host MCU or as a standalone applications processor with embedded BLE connectivity and external memory.

Atmel claims that its BTLC1000 Bluetooth solution — a 2.2mm x 2.1mm wafer level chip scale package — is 25 percent smaller than the nearest competitor solution. And Electronic Products magazine has corroborated that premise by calling it the lowest power BLE chipset that consumes less than 4mA in RX and less than 3mA in TX at 0dbm.

Security: Atmel is among the first chipmakers to offer specialized security hardware for the IoT market. Its microcontrollers come integrated with anti-cloning, authentication and encryption features.

Display: Wearable devices often show data such as time, measurements, maps and notifications on a display, and here, capacitive touch provides a very intuitive form of interfacing with the information. Atmel’s MCUs can directly manage capacitive buttons through software libraries that the firm provides.

Furthermore, Atmel offers standalone display controllers that support capacitive button, slider and wheel (BSW) implementations. These touch solutions can be tuned to moisture environments, a key requirement for many wearable applications. Atmel’s maXTouch capacitive touchscreen controller technology is a leading interface solution for its low-power consumption, precision and sensitivity.

Sensors: The development framework for the wearable designs features BHI160 6-axis SmartHub motion sensor and BME280 environment sensor from Bosch. It’s worth noting that Bosch is one of Atmel’s sensor partners. However, wearable product designers are free to pick sensors of their choice from Atmel’s other sensor partners.

Software support: The software package includes RTOS, Atmel’s Studio 7 IDE and Atmel START, which Atmel claims is the world’s first intuitive web-based tool for software configuration and code generation. Moreover, Atmel Software Framework (ASF) offers communication libraries for Bluetooth radios.

The truth is that the design game has moved from hardware and software functional blocks to complete developer ecosystems since the iPhone days. Now the ecosystem play is taking platforms to a whole new level in the design diversity that comes with the IoT products.

The choice of a right IoT platform means that designers will most likely get the basic building blocks right, and then, they can focus on the application and customer needs. It also provides design engineers space for differentiation, a critical factor in making wearable devices a consumer success.

 

 

Why connect to the cloud with the Atmel | SMART SAM W25?

---

The “thing” of IoT does not have to necessarily be tiny. 

---

The Atmel | SMART SAM W25 is, in fact, a module — a “SmartConnect Module.” As far as I am concerned, I like SmartConnect designation and I think it could be used to describe any IoT edge device. The device is “smart” as it includes a processing unit, which in this case is an ARM Cortex-M0-based SAMD21G, and “connect” reminds the Internet part of the IoT definition. Meanwhile, the ATWINC1500 SoC supports Wi-Fi 802.11 b/g/n allowing seamless connection to the cloud.

What should we expect from an IoT edge device? It should be characterized by both low cost and power! This IoT system is probably implemented multiple times, either in a factory (industrial) or in a house (home automation), and the cost should be as low as possible to enable large dissemination. I don’t know the SAMD21G ASP, but I notice that it’s based on the smallest MCU core of the ARM Cortex-M family, so the cost should be minimal (my guess). Atmel claims the W25 module to be “fully-integrated single-source MCU + IEEE 802.11 b/g/n Wi-Fi solution providing battery powered endpoints lasting years”… sounds like ultra low-power, doesn’t it?

The “thing” of IoT does not necessarily have to be tiny. We can see in the above example that interconnected things within the industrial world can be as large as these wind turbines (courtesy of GE). To maximize efficiency in power generation and distribution, the company has connected these edge devices to the cloud where the software analytics allow wind farm operators to optimize the performance of the turbines, based on environmental conditions. According with GE, “Raising the turbines’ efficiency can increase the wind farm’s annual energy output by up to 5%, which translates in a 20% increase in profitability.” Wind turbines are good for the planet as they allow avoiding burning fossil energy. IoT devices implementation allows wind farm operators to increase their profitability and to build sustainable business. In the end, thanks to Industrial Internet of Thing (IIoT), we all benefit from less air pollution and more affordable power!

The ATWINC1500 is a low-power Systems-on-Chip (SoC) that brings Wi-Fi connectivity to any embedded design. In the example above, this SoC is part of a certified module, the ATSAMW25, for embedded designers seeking to integrate Wi-Fi into their system. If we look at the key features list:

• IEEE 802.11 b/g/n (1×1) for up to 72 Mbps
• Integrated PA and T/R switch
• Superior sensitivity and range via advanced PHY signal processing
• Wi-Fi Direct, station mode and Soft-AP support
• Supports IEEE 802.11 WEP, WPA
• On-chip memory management engine to reduce host load
• 4MB internal Flash memory with OTA firmware upgrade
• SPI, UART and I2C as host interfaces
• TCP/IP protocol stack (client/server) sockets applications
• Network protocols (DHCP/DNS), including secure TLS stack
• WSC (wireless simple configuration WPS)
• Can operate completely host-less in most applications

We can notice that host interfaces allow direct connection to device I/Os and sensors through SPI, UART, I2C and ADC interfaces and can also operate completely host-less. A costly device is then removed from the BOM which can enable economic feasibility for an IoT, or IIoT edge device.

The low-power Wi-Fi certified module is currently employed in industrial systems supporting applications, such as transportation, aviation, healthcare, energy or lighting, as well as in IoT areas like home appliances and consumer electronics. For all these use cases, certification is a must-have feature, but low-cost and ultra-low power are the economic and technical enablers.

---

This post has been republished with permission from SemiWiki.com, where Eric Esteve is a principle blogger and one of the four founding members of the site. This blog first appeared on SemiWiki on November 15, 2015.

mbed eval boards showcase focus on IoT software and connectivity

---

Chipmakers like Atmel are joining hands with ARM to bring the entire ecosystem under one roof and thus facilitate the creation of standards-based IoT products.

---

ARM’s mbed operating system is winning attention in the highly fragmented embedded software space by promising a solid software foundation for interoperable hardware and thus scale the Internet of Things designs by narrowing the development time.

Atmel has put its weight behind ARM’s mbed OS by launching the single-chip evaluation board for the IoT ecosystem in a bid to ensure low software dependence for the embedded developers. The leading microcontroller supplier unveiled the mbed evaluation platform at the recent ARM TechCon held in Santa Clara, California.

The mbed OS platform is focused on rapid development of connected devices with an aim to create a serious professional platform to prototype IoT applications. So IoT developers don’t have to look to software guys for help. The mbed stack features a strong focus on enhancing the IoT’s connectivity and software components.

ARM is the lead maintainer for the mbed OS modules while it adds silicon partners, like Atmel, as platform-specific dependencies for the relevant mbed OS modules. Silicon partners are responsible for their platform-specific drivers.

Atmel’s mbed-enabled evaluation board is based on the low-power 2.4GHz wireless Cortex-M0+ SAM R21 MCU. Moreover, Atmel is expanding mbed OS support for its Wi-Fi modules and Bluetooth Low Energy products.

The fact that Atmel is adding mbed OS to its IoT ecosystem is an important nod for ARM’s mbed technology in its journey from merely a hardware abstraction layer to a full-fledged IoT platform. Atmel managers acknowledge that mbed technology adds diversity to embedded hardware devices and makes MCUs more capable.

Solid Software Foundation

There is a lot of code involved in the IoT applications and software is getting more complex. It encompasses, for instance, sensor library to acquire data, authentication at IoT gateways and SSL security. Here, the automatic software integration engine like mbed lets developers focus on their applications instead of worrying about integrating off-the-shelf software.

The mbed reference designs like the one showcased by Atmel during ARM TechCon are aimed at narrowing the development time with the availability of building blocks and design resources—components, code and infrastructure—needed to bootstrap a working IoT system. Atmel managers are confident that a quality software foundation like mbed could help bring IoT products to market faster.

Atmel’s mbed-enabled IoT evaluation board promises harmony between hardware and software. Apparently, chipmakers like Atmel are joining hands with ARM to bring the entire ecosystem — OS software, cloud services and developer tools — under one roof, and thus facilitate the creation of standards-based IoT products. Atmel’s mbed evaluation board clearly mirrors that effort to deliver a complete hardware, software and developer tools ecosystem in order to bring IoT designs quicker to market.

The platform comprises of mbed OS software for IoT client devices like gateways and mbed Device Server for the cloud services. ARM launched the mbed software platform in 2014 and Atmel has been part of this initiative since then.

mbed in Communications Stack

Additionally, Atmel has tied the mbed association to its SmartConnect wireless solutions to make the best of mbed’s networking stack in the Internet of connected things. The IoT technology is built on layers, and here, interoperability of communications protocols is a key challenge.

For a start, Atmel’s SAM R21-Xpro evaluation board is embed-enabled and is built around the R21 microcontroller, which has been designed for industrial and consumer wireless applications running proprietary communication stacks or IEEE 802.15.4-compliant solutions.

Next up, the evaluation board includes SAM W25 Wi-Fi module that integrates IEEE 802.11 b/g/n IoT network controller with the existing MCU solution, SAM D21, which is also based on the Cortex-M0+ processor core.

Furthermore, Atmel is offering an mbed-enabled Bluetooth starter kit that includes SAM L21 microcontroller-based evaluation board and ultra-low-power Bluetooth chip BTLC1000, which is compliant with Bluetooth Low Energy 4.1. Atmel demonstrated a home lighting system at the ARM TechCon show floor, which employed SAM R21-based Thread routers that passed light sensor information to an mbed-enabled home gateway. Subsequently, this information was processed and sent to the mbed Device Server using a web interface.

---

Majeed Ahmad is the author of books Smartphone: Mobile Revolution at the Crossroads of Communications, Computing and Consumer Electronics and The Next Web of 50 Billion Devices: Mobile Internet’s Past, Present and Future.

IAR Embedded Workbench vastly improves performance for 8-bit AVR MCUs

---

Version 6.70 of the popular toolchain includes improved compiler optimizations. 

---

IAR Systems has released a new version of its complete C/C++ development toolchain IAR Embedded Workbench for AVR. Version 6.70 of the popular toolchain includes improved compiler optimizations as well as new device support and updates to the add-on tool C-STAT for static code analysis.

“Embedded systems are growing in complexity and many applications are being migrated to 32-bit microcontrollers. Despite this, the 8-bit AVR microcontrollers are continuously being used in many applications for example within automotive, battery management and wireless solutions,” says Thomas Sporrong, IAR Systems Global FAE Manager. “IAR Systems has a large customer base of developers working with AVR and the company remains committed to supplying world-class tools for embedded developers across the entire range from 8-bit to 32-bit microcontrollers.”

IAR Embedded Workbench for AVR features world-leading code optimizations that create compact, fast-performing code. The optimization technology has been further improved in this version, particularly involving speed optimizations of floating-point data types. These improvements enable developers to gain even better performance in applications where optimal execution speed is critical. To achieve the best possible configuration for the application at hand, developers are able to tune the optimizations. With the possibility to set different optimizations for different parts of the code, the right balance between code size and code speed can be achieved.

The previous version 6.60 of IAR Embedded Workbench for AVR introduced support for IAR Systems’ static analysis add-on product C-STAT. Completely integrated in the IAR Embedded Workbench IDE, C-STAT can perform numerous checks for compliance with rules as defined by the coding standards MISRA C:2004, MISRA C++:2008 and MISRA C:2012, as well as rules based on for example CWE (the Common Weakness Enumeration) and CERT C/C++. By using static analysis, developers can identify errors such as memory leaks, access violations, arithmetic errors, and array and string overruns at an early stage to ensure code quality and minimize the impact of errors on the finished product and on the project timeline. With the latest release come further updates to the C-STAT tool, including an added report generator and added pragmas for temporary disabling checks.

IAR Embedded Workbench for AVR is a complete set of powerful C/C++ development tools with extensive support for devices in all AVR families. IAR Systems’ high-performance development tools and world-class technical support are available across Atmel’s entire range of 8-bit and 32-bit microcontroller architectures.

Interested? Get started here.

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. 

IAR Systems provides tools for new Atmel | SMART SAMA5D2 series

---

IAR Embedded Workbench supports latest series of Atmel | SMART ARM Cortex-A5-based microprocessors with low power consumption and advanced security features.

---

Our friends over at IAR Systems have shared that the IAR Embedded Workbench for ARM now supports the Atmel | SMART SAMA5D2 series. With its highly optimizing build tools and comprehensive debugging capabilities, their popular development toolchain enables developers to fully leverage the high performance of the recently revealed MPU family.

The Atmel | SMART SAMA5D2 is based on the high-end ARM Cortex-A5 core and features an ARM NEON engine. ARM NEON is a Single Instruction Multiple Data (SIMD) architecture extension providing the top performance that is crucial to developers working for example with multimedia and signal processing applications. With the IAR Embedded Workbench for ARM, users will be able to benefit from this technology thanks to the automatic NEON vectorization available in the tools. By vectorizing their code, they can achieve faster application response time, improve application battery lifetime and further meet the market demands for low cost and low power.

What’s more, the SAMA5D2 boasts a robust security system including ARM TrustZone technology, along with secure boot, hardware cryptography, RSA/ECC, on-the-fly encryption/decryption on DDR and QSPI memories, tamper resistance, memory scrambling, independent watchdog, temperature, voltage and frequency monitoring and a unique ID in each device.

The complete development toolchain IAR Embedded Workbench for ARM features the powerful IAR C/C++ Compiler and the comprehensive C-SPY Debugger in a user-friendly integrated development environment. The toolchain offers extensive debugging and profiling possibilities such as complex code and data breakpoints, runtime stack analysis, call stack visualization, code coverage analysis and integrated monitoring of power consumption. For complete code control, IAR Systems provides integrated add-on tools for static and runtime analysis.

“We are excited to see early support for our latest low-power MPUs in IAR Systems’ leading development toolchain,” explains Jacko Wilbrink, Atmel Senior Director of MPUs. “In order to be able to develop next-generation industrial IoT and wearables applications, developers require more performance, lower power and additional security. The Atmel | SMART SAMA5D2 series and IAR Embedded Workbench deliver excellent performance and a wide range of features to fulfill these requirements and deliver truly differentiating products to help bring products faster to market.”

Interested? You can head over to the IAR Embedded Workbench for ARM, as well as read up on the industry’s lowest power Cortex-A5-based MPU here.

How to prevent execution surprises for Cortex-M7 MCU

---

We know the heavy weight linked with software development, in the 60% to 70% of the overall project cost.

---

The ARM Cortex-A series processor core (A57, A53) is well known in the high performance market segments, like application processing for smartphone, set-top-box and networking. If you look at the electronic market, you realize that multiple applications are cost sensitive and don’t need such high performance processor core. We may call it the embedded market, even if this definition is vague. The ARM Cortex-M family has been developed to address these numerous market segments, starting with the Cortex-M0 for lowest cost, the Cortex-M3 for best power/performance balance, and the Cortex-M4 for applications requiring digital signal processing (DSP) capabilities.

For the audio, voice control, object recognition, and complex sensor fusion of automotive and higher-end Internet of Things sensing, where complex algorithms for audio and video are needed for rich audio and visual capabilities, Cortex-M7 is required. ARM offers the processor core as well as the Tightly Coupled Memory (TCM) architecture, but ARM licensees like Atmel have to implement memories in such a way that the user can take full benefit from the M7 core to meet system performance and latency goals.

The TCM interface provides a single 64-bit instruction port and two 32-bit data ports.

In a 65nm embedded Flash process device, the Cortex-M7 can achieve a 1500 CoreMark score while running at 300 MHz, offering top class DSP performance: double-precision floating-point unit and a double-issue instruction pipeline. But algorithms like FIR, FFT or Biquad need to run as deterministically as possible for real-time response or seamless audio and video performance. How do you best select and implement the memories needed to support such performance? If you choose Flash, this will require caching (as Flash is too slow) leading to cache miss risk. Whereas SRAM technology is a better choice since it can be easily embedded on-chip and permits random access at the speed of processor.

Peripheral data buffers implemented in general-purpose system SRAM are typically loaded by DMA transfers from system peripherals. The ability to load from a number of possible sources, however, raises the possibility of unnecessary delays and conflicts by multiple DMAs trying to access the memory at the same time. In a typical example, we might have three different entities vying for DMA access to the SRAM: the processor (64-bit access, requesting 128 bits for this example) and two separate peripheral DMA requests (DMA0 and DMA1, 32-bit access each). Atmel has get round this issue by organizing the SRAM into several banks as described in this picture:

By organizing the SRAM into banks, multiple DMA bursts can occur simultaneously with minimal latency.

For a chip maker designing microcontrollers, licensing ARM Cortex-M processor core provides numerous advantages. The very first is the ubiquity of the ARM core architecture, being adopted in multiple market segments to support variety of applications. If this chip maker wants to design-in a new customer, the probability that such OEM has already used ARM-based MCU is very high, and it’s very important for this OEM to be able to reuse existing code (we know the heavy weight linked with software development, in the 60% to 70% of the overall project cost). But this ubiquity generates a challenge: how do you differentiate from the competition when competitors can license exactly the same processor core?

Selecting a more aggressive technology node and providing better performance at lower cost are an option, but we understand that this advantage can disappear as soon as the competition also move to this node. Integrating larger amount of Flash is another option, which is very efficient if the product is designed on a technology that enables it to keep the pricing low enough.

If the chip maker has designed on an aggressive technology node for higher performance and offers a larger amount of Flash than the competition, it may be enough differentiation. Completing with the design of a smarter memory architecture unencumbered by cache misses, interrupts, context swaps, and other execution surprises that work against deterministic timing allow bringing strong differentiation.

If you want to more completely understand how Atmel has designed this SMART memory architecture for the Cortex-M7, I encourage you to read this white paper from Jacko Wilbrink and Lionel Perdigon entitled “Run Blazingly Fast Algorithms with Cortex-M7 Tightly Coupled Memories.” (You will have to register.) This paper describes MCUs integrating SRAM organized into four banks that can be used as general SRAM and for TCM, showing one example of a Cortex-M7 MCU being implemented in the Atmel | SMART SAM S70, SAM E70 and SAM V70/V71 families.

---

This post has been republished with permission from SemiWiki.com, where Eric Esteve is a principle blogger, as well as one of the four founding members of the site. This blog was originally shared on August 6, 2015.

“It’s not a feature, it’s a bug”

---

Embedded systems no longer need to be a ‘black box’ that leaves engineers guessing what may be happening, Percepio AB CEO Dr. Johan Kraft explains his latest guest blog post.

---

Anyone involved with software development will have most likely heard (and perhaps even said) the phrase “it’s not a bug, it’s a feature” at some point, and while its origins remain a mystery, its sentiment is clear — it’s a bug that we haven’t seen before.

Intermittent ‘features’ in an embedded system can originate in either the software or hardware domain, often only evident when certain conditions collide in both. In the hardware domains, the timings involved may be parts of a nano second and where the logic is accessible, such as an address line or data bus — there exist instruments that can operate at high sample rates, allowing engineers to visualize and verify such ‘glitches.’ In the software domain, this becomes much more challenging.

Sequential Processing

While parallel processing is being rapidly adopted across all applications, single-processor systems remain common in embedded systems, thanks partly to the continued increases in the performance of microcontroller cores. Embedded MCUs are now capable of executing a range of increasingly sophisticated Real-Time Operating Systems (RTOS), often including the ability to run various communication protocols for both wired and wireless interfaces.

Whether in a single- or multi-processing system, combining these tasks with the embedded system’s main application, written by the engineering team, can make embedded software builds large, complex and difficult to fault-find, particularly when visibility into the code’s execution is limited. It can also lead to the dreaded intermittent fault which, if part of the system’s operation is ‘hidden’, can make solving them even more challenging.

A typical example may be an unexplained delay in a scheduled task. Of course, an RTOS is intended to guarantee specific tasks happen at specific times but this can be dependent on the task’s priority and what else may be happening at any time. In one real-world example, where a sensor needed to be sampled every 5ms, it was found that occasionally the delay between samples reached 6.5ms, with no simple explanation as to the cause. In another example, a customer reported that their system exhibited random resets; the suspected cause was that the watchdog was expiring before it was serviced, but how could this be checked? In yet another example, a system running a TCP/IP stack showed slower response times to network requests after minor changes in the code, for no obvious reason.

These are typical examples of how embedded systems running complex software can behave in unforeseen ways, leaving engineering teams speculating on the causes and attempting to solve the problems with only empirical results from which to assess their efforts. In the case of intermittent faults or system performance fluctuations, this is clearly an inefficient and unreliable development method.

Trace Tools

The use of logging software embedded in a build in order to record certain actions isn’t new, of course, and it can offer a significantly improved level of visibility into a system. However, while the data generated by such trace software is undoubtedly valuable, exploiting that value isn’t always simple.

Analyzing trace data and visually rendering it in various ways is the key function of Percepio’s Tracealyzer tools. It offers visualization at many levels, ranging from an event list to high-level dependency graphs and advanced statistics.

Over 20 different graphical views are provided, showing different aspects of the software’s execution that are unavailable with debuggers alone, and as such it complements existing software debug tools in a way that is becoming essential in today’s complex embedded systems. It supports an increasing range of target operating systems.

Figure 1(a): It appears that the ControlTask may be disabling interrupts.

The main view in Tracealyzer, as shown in Figure 1(a) and 1(b), is a vertical timeline visualizing the execution of tasks/threads and interrupts. Other logged events, such as system calls, are displayed as annotations in this timeline, using horizontal colour-coded text labels. Several other timeline views are provided using horizontal orientation and all horizontal views can be combined on a common horizontal timeline. While much important data is created by the operating system’s kernel, developers can also extend the tracing with User Events, which allow any event or data in a user’s application to be logged. They are logged similar to calling the classic ‘printf’ C library function but are much faster as the actual formatting is handled in the host-side application, and can therefore also be used in time-critical code such as interrupt handlers. And, of course, they can also be correlated with other kernel-based events.

Figure 1(b): By changing the way ControlTask protects a critical section, SamplerTask is able to run as intended.

Tracealyzer understands the general meaning of many kernel calls, for instance locking a Mutex or writing to a message queue. This allows Tracealyzer to perform deep analysis to connect related events and visualize dependencies, e.g., which tasks communicate (see the communication flow graph, shown in Figure 3). This allows developers to quickly understand what’s really going on inside their system.

Insights

Returning to the first example, where a scheduled task was being inexplicably delayed intermittently, Tracealyzer was used to graphically show the task in question, time-correlated with other tasks. By invoking an exploded view of the task of interest, it was found that a lower priority task was incorrectly blocking the primary task from executing. It was discovered that the second task was disabling interrupts to protect a critical section unrelated to the primary task, which blocked the operating system scheduling. After changing the second task to using a Mutex instead, the primary task was able to meet its timing requirements. Figure 1(a) shows the SamplerTask being delayed by the (lower priority) ControlTask before the bug fix; Figure 1(b) confirms that SamplerTask is now occurring every 5ms as intended.

In the second example, User Events were used to not only record when the Watchdog was reset or when it expired, but also to log the remaining Watchdog timer value, thereby showing the time left in the Watchdog timer when it is reset. By inspecting the logged system calls it was found that the task in question did not only reset the Watchdog timer; it also posted a message to another task using a (fixed-size) message queue. The Watchdog resets seemed to occur while the Watchdog task was blocked by this message posting. Once realised, the question then became ‘why’. By visually exploring the operations on this message queue using the Kernel Object History view, it became clear that the message queue sometimes becomes full, as suspected. By correlating a view of the CPU load against how the Watchdog timer margin varied over time, as shown in Figure 2, it was found that Fixed Priority Scheduling was allowing a medium-priority task (ServerTask) to use so much CPU time that the message queue wasn’t always being read. Instead, it became full, leading to a Watchdog reset. The solution was in this case to modify the task priorities.

Figure 2: The CPU Load graph, correlated to the Watchdog Timer User Event, gives valuable insights.

In the last example, where a software modification caused increased response time to network requests, using the Communications Flow view (Figure 3) it was found that one particular task — Logger — was receiving frequent but single messages with diagnostics data to be written to a device file system, each causing a context switch. By modifying the task priorities, the messages were instead buffered until the network request had finished and thereafter handled in a batch. This way, the number of context-switches during the handling of network requests was drastically reduced, thereby improving overall system responsiveness.

Figure 3: The Communication Flow reveals 5 tasks sending messages to Logger.

Conclusion

The complexity of embedded software is increasing rapidly, creating demand for improved development tools. While runtime data can be recorded in various ways, understanding its meaning isn’t a simple process, but through the use of innovative data visualization tools such as Tracealyzer it can be.

Many companies have already benefited from the many ways of using the tool to really discover what’s going on in the runtime system. Some Tracealyzer users even include it in production code, allowing them to gather invaluable data about real systems running in the field.

Embedded systems need no longer be a ‘black box,’ leaving engineers to suppose what may be happening; powerful visualization tools now turn that black box into an open box.

Why do drones love the Atmel SAM E70?

---

Eric Esteve explains why the latest Cortex-M7 MCU series will open up countless capabilities for drones other than just flying. 

---

By nature, avionics is a mature market requiring the use of validated system solution: safety is an absolute requirement, while innovative systems require a stringent qualification phase. That’s why the very fast adoption of drones as an alternative solution for human piloted planes is impressive. It took 10 or so years for drones to become widely developed and employed for various applications, ranging from war to entertainment, with prices spanning a hundreds of dollars to several hundreds of thousands. But, even if we consider consumer-oriented, inexpensive drones, the required processing capabilities not only call for high performance but versatile MCU as well, capable of managing its built-in gyroscope, accelerator, geomagnetic sensor, GPS, rotational station, four to six-axis control, optical flow and so on.

When I was designing for avionics, namely the electronic CFM56 motor control (this reactor being jointly developed by GE in the U.S. and Snecma in France, equipping Boeing and Airbus planes), the CPU was a multi-hundred dollar Motorola 68020, leading to a $20 per MIPS cost! While I may not know the Atmel | SMART SAM E70 price precisely — I would guess that it cost a few dollars — what I do I know is that the MCU is offering an excess of 600 DMIPS. Aside from its high performance, this series boasts a rather large on-chip memory size of up to 384KB SRAM and 2MB Flash — just one of many pivotal reasons that this MCU has been selected to support the “drone with integrated navigation control to avoid obstacle and improve stability.”

In fact, the key design requirements for this application were: +600 DMIPS, camera sensor interface, dual ADC and PWM for motor control and dual CAN, all bundled up in a small package. Looking at the block diagram below helps link the MCU features with the various application capabilities: gyroscope (SPI), accelerator (SPI x2), geomagnetic sensor (I2C x2), GPS (UART), one or two-channel rotational station (UART x2), four or six-axis control communication (CAN x2), voltage/current (ADC), analog sensor (ADC), optical flow sensor (through image sensor Interface or ISI) and pulse width modulation (PWM x8) to support the rotational station and four or six-axis speed PWM control.

For those of you who may not know, the SAM E70 is based on the ARM-Cortex M7 — a principle and multi-verse handling MCU that combines superior performance with extensive peripheral sets supporting multi-threaded processes. It’s this multi-thread support that will surely open up countless capabilities for drones other than simply flying.

Today’s drones already possess the ability to soar through the air or stay stationary, snapping pictures or capturing HD footage. That’s already very impressive to see sub-kilogram devices offering such capabilities! However, the drone market is already looking ahead, preparing for the future, with the desire to get more application stacks into the UAVs so they can take in automation, routing, cloud connectivity (when available), 4G/5G, and other wireless functionalities to enhance data pulling and posting.

For instance, imagine a small town tallying a few thousand habitants, except a couple of days or weeks per year because of a special event or holiday, a hundred thousand people come storming into the area. These folks want to feed their smartphone with multimedia or share live experiences by sending movies or photos, most of them at the same time. The 4G/5G and cloud infrastructure is not tailored for such an amount of people, so the communication system may break. Yet, this problem could be fixed by simply calling in drone backup to reinforce the communication infrastructure for that period of time.

While this may be just one example of what could be achieved with the advanced usage of drones, each of the innovative applications will be characterized by a common set of requirements: high processing performance, large SRAM and flash memory capability, and extensive peripheral sets supporting multi-threaded processes. In this case, the Cortex M7 ARM-based SAM E70 MCU is an ideal choice with processing power in excess of 640 DMIPS, large on-chip SRAM (up to 384 KB) and Flash (up to 2MB) capabilities managing all sorts of sensors, navigation, automation, servos, motor, routing, adjustments, video/audio and more.

Intrigued? You’ll want to check out some of the products and design kits below:

• SAM V
• SAM S
• SAM E
• SAM V Xplained Ultra Kit

---

This post has been republished with permission from SemiWiki.com, where Eric Esteve is a principle blogger as well as one of the four founding members of SemiWiki.com. This blog first appeared on SemiWiki on July 18, 2015.