Tag Archives: 32-bit ARM Microcontroller

1:1 interview with TinyArcade creator Ken Burns


TinyArcade is the most adorable video game console you’ve ever seen.


Recently, we had the chance to sit down with TinyCircuits founder Ken Burns, who just wrapped up a successful Kickstarter campaign for the TinyArcade. Here’s what he had to say…

Ken Burns of Tiny Circuits

Josh Marinacci: Hi Ken. I’m one of the original Kickstarter backers of TinyCircuits and I love it. Could you tell us a little bit about TinyCircuits, why you created it, where it’s based?

Ken Burns: Thanks! TinyCircuits started as a side project while I was working at a contract engineering company. We would help other companies (from one person startups to Fortune 500 companies), develop electronic products, and prototyping was always a huge part of what we did. However, to create working prototypes usually involved creating a custom PCB (somewhat expensive and time consuming), or hobbling together a number of different development boards to create the proto, which was always ugly and usually too big.

So that’s what started the idea of a small modular system with a number of different sensors and options, and around the same time Arduino was becoming very popular so I decided to base it around that, which was the birth of the TinyDuino system. At the time it was just me in a spare bedroom of my house in Akron, Ohio, working on this and prototyping it up, but I showed it to a number of people and got a lot of great feedback, and decided to launch it on Kickstarter in the fall of 2012. The initial TinyDuino Kickstarter campaign did great, enough to convince me there was potential to create a business around it, so I left my job and committed to TinyCircuits full-time.

Three years later we’re still going strong, with a staff of 8 people and our own electronics design and manufacturing operation here in Akron, Ohio.

JM: One of our talented engineers recently built a Bluetooth wearable smartwatch using TinyCircuits. Have you seen a lot of adoption in wearables? What things do people build with it?

KB: That’s definitely a great project! Wearables is definitely something people use our stuff for a lot, it’s very small, compact, and easy to use, which makes it perfect for wearable applications. We launched the TinyScreen last year, which is a small OLED display that fits onto the TinyDuino and allows users to create add a very cool compact display to their projects.

Jewelry is one that a number of people have done, and some friends of ours are actually building out a 3D printed jewelry product based around our TinyScreen that should be launching early next year. Others are using our circuitry for wearable sensors, like for athletic and healthcare monitoring. And an eight-year old launched his own smart watch, the O Watchon Kickstarter to teach kids 3D printing and programing earlier this fall that is built around our stuff!

O-Watch-Smartwatch1

JM:Has anyone used your boards for a shipping product?

KB: A few small companies have used our products for very low volume items, but a few are designing products that integrate in the TinyScreen which will be higher volume. For low to mid volume items (one to a few hundred) it makes a lot of sense to buy products like ours to integrate with, since it saves the need to design a custom PCB and do the upfront engineering. After a certain volume it’s more cost effective to design a custom board, and we actually have helped a number of companies do that with our in-house design partner.

Josh: TinyArcade is absolutely the coolest thing ever. It’s a shame it won’t be ready in time for Christmas. Why did you decide to build this product, and why run it as a KickStarter instead of just selling it like your other boards?

Ken: Thanks! We would have loved to have it out by Christmas this year, but we needed to take our time over the summer to get the design right. The TinyArcade is really an outgrowth of the TinyScreen project we did last year, one of the things people really liked about it was that you could play games on it, and a number of our users started creating games for it, like Space Invaders, Outrun, Asteroids, etc.

In the spring we saw a really little arcade cabinet candy dispenser, and thought it would be cool to put a TinyScreen in it and play games, but the size wasn’t quite right. But the idea stuck with us, and we have a designer friend (Jason Bannister from mechanimal.com) design a 3D printed cabinet which came out looking incredible. We started showing this off at different shows, like Maker Faire Bay Area, and it was a huge hit, and people kept asking to buy it. So we decided to turn it into a product.

photo-original-1

We redesigned the TinyScreen to bring the cost down and way crank up the performance, and add things like audio, joysticks, and an SD expansion slot. The 3D printed cabinet is also fairly complex and something that needs a commercial printer to make (it can’t be printed on a Makerbot), so the prints are expensive. So we came up with a laser cut enclosure that could be made for much less but still look like a cabinet, so we could offer this at a low price.

We’ve had great luck on Kickstarter in the past, and one of the big reasons we did this again is so we can buy the components in bulk. We’re still a small startup and cash flow is always an issue, so using Kickstarter lets us buy some of the major components (like the OLED, joysticks, etc) in volume to keep the cost down. If we did it without Kickstarter, the price per unit would have to be a lot more.

JM: Where did you find those tiny joysticks?

KB: Those are super cute, aren’t they?! We used some PSP type joysticks in the past for our joystick board, but these were too big for this. These joysticks are made by CTS and actually available at places like DigiKey, and work amazingly well. They’re great for very precise analog movements. They are one of the more expensive components in the TinyArcade, but definitely worth it.

The top of the joystick is actually a knob that we designed ourselves and is a high-res 3D print, using a resin printer, so we can make it just like an old style arcade joystick.

JM: Does the TinyArcade have room for expansion? I’d love to make one connected to the internet through Bluetooth or Wi-Fi. Will you support those options?

KB: It certainly does! This is still a TinyDuino type product and maintains expansion capability, and there is room to add another board in the cabinet. Bluetooth and Wi-Wi are the two that we definitely consider the most likely, and since the platform is completely open source, it’s really up to the user’s imagination as to what they want to add. Based on how well the Kickstarter goes, and if there is community support, we’d love to see the ability for some multiplayer games over Bluetooth or Wi-Fi.

photo-main13

JM: With a Wi-Fi board, is it possible to do OTA updates?

KB: Right now we don’t have that capability, it really comes down to support in the bootloader. However we do support loading games and videos off a microSD card if it’s present, so it would definitely be possible to create a program to download files over Wi-i and save them to the SD card to use.

JM: What’s next for TinyCircuits? Any new products in the pipeline?

KB: We have a huge list of things in the pipeline that we would like to do, we actually have about 15 new expansion boards designed that should be hitting production early in 2016. One of the big push is into micro-robotics, so tiny servo drivers and motor drivers, new radio options, an ESP-based Wi-Fi board, many more sensors, and of course rolling out the TinyScreen+ board and the TinyZero processor board (basically the Arduino Zero, 32-bit ARM platform) which brings a new level of horsepower to the platform.

JM: Tell us a little more about the Kickstarter campaign and when do you expect it to ship?

KB The TinyArcade Kickstarter (successfully) ended on December 17th and we plan to start shipping in March 2016. The big reason for the delay is due to getting some of the key components in, like the raw OLEDs, this takes 8 – 12 weeks from our supplier, we plan to have the other items ready to go (the PCBs built, and the cases made), before then, so we can get shipping the moment they come in.

This interview originally appeared on PubNub’s blog

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.

Atmel mbed Xpro board

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.

thingsquare2

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.

XPLAIN
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.

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.

A step toward the connected car - ecall and how it works

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.

General Motors selected AT&T as its mobile 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.

The design trajectory for connected cars continues to follow this arrow forward

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.

The arrow for connected cars will demand more development bolstering the concept that software and embedded systems factored with newly introduced actuators & sensors will become more prevalent; “software on wheels”, “SoC on wheels” and “secured mobility”.

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.

Connected Car Evolution

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).

IMG_3659

[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.

fig1_popup

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.

fig.2

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.

box

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. 

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.

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

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:

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

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.

Pic

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.

6 memory considerations for Cortex-M7-based IoT designs


Taking a closer look at the configurable memory aspects of Cortex-M7 microcontrollers.


Tightly coupled memory (TCM) is a salient feature in the Cortex-M7 lineup as it boosts the MCU’s performance by offering single cycle access for the CPU and by securing the high-priority latency-critical requests from the peripherals.

Cortex-M7-chip-diagramLG

The early MCU implementations based on the ARM’s M7 embedded processor core — like Atmel’s SAM E70 and S70 chips — have arrived in the market. So it’d be worthwhile to have a closer look at the configurable memory aspects of M7 microcontrollers and see how the TCMs enable the execution of deterministic code and fast transfer of real-time data at the full processor speed.

Here are some of the key findings regarding the advanced memory architecture of Cortex-M7 microcontrollers:

1. TCM is Configurable

First and foremost, the size of TCM is configurable. TCM, which is part of the physical memory map of the MCU, supports up to 16MB of tightly coupled memory. The configurability of the ARM Cortex-M7 core allows SoC architects to integrate a range of cache sizes. So that industrial and Internet of Things product developers can determine the amount of critical code and real-time data in TCM to meet the needs of the target application.

The Atmel | SMART Cortex-M7 architecture doesn’t specify what type of memory or how much memory should be provided; instead, it leaves these decisions to designers implementing M7 in a microcontroller as a venue for differentiation. Consequently, a flexible memory system can be optimized for performance, determinism and low latency, and thus can be tuned to specific application requirements.

2. Instruction TCM

Instruction TCM or ITCM implements critical code with deterministic execution for real-time processing applications such as audio encoding/decoding, audio processing and motor control. The use of standard memory will lead to delays due to cache misses and interrupts, and therefore will hamper the deterministic timing required for real-time response and seamless audio and video performance.

The deterministic critical software routines should be loaded in a 64-bit instruction memory port (ITCM) that supports dual-issue processor architecture and provide single-cycle access for the CPU to boost MCU performance. However, developers need to carefully calibrate the amount of code that need zero-wait execution performance to determine the amount of ITCM required in an MCU device.

The anatomy of TCM inside the M7 architecture

The anatomy of TCM inside the M7 architecture.

3. Data TCM

Data TCM or DTCM is used in fast data processing tasks like 2D bar decoding and fingerprint and voice recognition. There are two data ports (DTCMs) that provide simultaneous and parallel 32-bit data accesses to real-time data. Both instruction TCM and data TCM — used for efficient access to on-chip Flash and external resources — must have the same size.

4. System RAM and TCM

System RAM, also known as general RAM, is employed for communications stacks related to networking, field buss, high-bandwidth bridging, USB, etc. It implements peripheral data buffers generally through direct memory access (DMA) engines and can be accessed by masters without CPU intervention.

Here, product developers must remember the memory access conflicts that arise from the concurrent data transfer to both CPU and DMA. So developers must set clear priorities for latency-critical requests from the peripherals and carefully plan latency-critical data transfers like the transfer of a USB descriptor or a slow data rate peripheral with a small local buffer. Access from the DMA and the caches are generally burst to consecutive addresses to optimize system performance.

It’s worth noting that while system memory is logically separate from the TCM, microcontroller suppliers like Atmel are incorporating TCM and system RAM in a single SRAM block. That lets IoT developers share general-purpose tasks while splitting TCM and system RAM functions for specific use cases.

A single SRAM block for TCM and system memory allows higher flexibility and utilization

A single SRAM block for TCM and system memory allows higher flexibility and utilization.

5. TCM Loading

The Cortex-M7 uses a scattered RAM architecture to allow the MCU to maximize performance by having a dedicated RAM part for critical tasks and data transfer. The TCM might be loaded from a number of sources, and these sources aren’t specified in the M7 architecture. It’s left to the MCU designers whether there is a single DMA or several data loading points from various streams like USB and video.

It’s imperative that, during the software build, IoT product developers identify which code segments and data blocks are allocated to the TCM. This is done by embedding programs into the software and by applying linker settings so that software build appropriately places the code in memory allocation.

6. Why SRAM?

Flash memory can be attached to a TCM interface, but the Flash cannot run at the processor clock speed and will require caching. As a result, this will cause delays when cache misses occur, threatening the deterministic value proposition of the TCM technology.

DRAM technology is a theoretical choice but it’s cost prohibitive. That leaves SRAM as a viable candidate for fast, direct and uncached TCM access. SRAM can be easily embedded on a chip and permits random accesses at the speed of the processor. However, cost-per-bit of SRAM is higher than Flash and DRAM, which means it’s critical to keep the size of the TCM limited.

Atmel | SMART Cortex-M7 MCUs

Take the case of Atmel’s SMART SAM E70, S70 and V70/71 microcontrollers that organize SRAM into four memory banks for TCM and System SRAM parts. The company has recently started shipping volume units of its SAM E70 and S70 families for the IoT and industrial markets, and claims that these MCUs provide 50 percent better performance than the closest competitor.

SAM-E70_S70_BlockDiagram_Lg_929x516

Atmel’s M7-based microcontrollers offer up to 384KB of embedded SRAM that is configurable as TCM or system memory for providing IoT designs with higher flexibility and utilization. For instance, E70 and S70 microcontrollers organize 384KB of embedded SRAM into four ports to limit memory access conflicts. These MCUs allocate 256KB of SRAM for TCM functions — 128 KB for ITCM and DTCM each — to deliver zero wait access at 300MHz processor speed, while the remaining 128KB of SRAM can be configured as system memory running at 150MHz.

However, the availability of an SRAM block organized in the form of a memory bank of 384KB means that both system SRAM and TCM can be used at the same time.The large on-chip SRAM of 384KB is also critical for many IoT devices, since it enables them to run multiple communication stacks and applications on the same MCU without adding external memory. That’s a significant value proposition in the IoT realm because avoiding external memories lowers the BOM cost, reduces the PCB footprint and eliminates the complexity in the high-speed PCB design.

This Wi-Fi-enabled touch light lets you stay connected with loved ones


This smart lamp gives users a decorative yet unobtrusive way to stay connected with the people they care for the most.


Picture this: A grandparent touches a lamp. Immediately, their grandchild who happens to be hundreds of miles away sees their light change. Not only does this enable the kid to know grandpa is thinking of him, the child can also respond back by placing their hand on the device as well. Or perhaps, you have a partner in the military and want a quick reassurance that they are okay.   The possibilities are endless.

fd26a37e25aa9223351141f126b4ca89_original

With the rise of the Internet of Things (not to mention more grandparents moving to Boca Raton or Scottsdale), a new decorative light will be able to connect loved ones without ever having to pick up the phone. Dubbed Filimin, the gadget connects with other Filimins via Wi-Fi and changes colors when touched. Once this occurs, other lamps within its network will also match the color anywhere in the world at the speed of the Internet.

Filimins provide a simple, beautiful alternative to the noise of communication we all experience every day in our pile of emails, messages and seemingly never-ending social notifications. The smart lamps have one job and one job only: to reach out to those we care about without texting, reading or dialing. This is ideal for when you’ve got nothing to say and a simple gesture lets someone know you’re thinking of them.

How it works is pretty straightforward. Touch the Filimin once and it will glow one of hundreds of possible hues. Touch it again and the color will vary slightly. Continue tapping to find a color that best suits your expression.

6a51295d7578f5cc3f354254fde31564_original

Each Filimin is powered 32-bit ARM Cortex-M3 based MCU along with a wireless module. This convergence of technology allows the device to easily be configured and operate independently from smartphones and laptop computers. Meanwhile, the series of RGB LEDs embedded within each Filimin are capable of emitting millions of colors and are designed to last the life of the product.

“Since Filimin communicates with no words, you and the people you care about get to choose the meaning of your interaction. Maybe you want to tell your friend that you’re ready to meet at your favorite hangout. Maybe you want to tell your cousin overseas that it’s an ok time for a video chat. Perhaps somebody you care about is in the hospital and you want to let them know you are thinking of them,” creator John Harrison explains.

In today’s always-on-the-go world, it’s often difficult to keep in touch with those you care about most. What’s nice about tho smart device is that it could be a continuous presence, even in times that you don’t have time or anything to share. Sound like a decorative yet functional piece you’d love to have at home? Head over to Filimin’s Kickstarter page, where the team is currently seeking $50,000. Shipment is expected to kick off in December 2015 — just in time to wish your loved ones happy holidays with some festive red and green lights.