ECDH key exchange is practical magic

What if you and I want to exchange encrypted messages? It seems like something that will increasingly be desired given all the NSA/Snowden revelations and all the other snooping shenanigans. The joke going around is that the motto of the NSA is really “Yes We Scan,” which sort of sums it up.

Encryption is essentially scrambling a message so only the intended reader can see it after they unscramble it. By definition, scrambling and unscrambling are inverse (i.e. reversible) processes. Doing and undoing mathematical operations in a secret way that outside parties cannot understand or see is the basis of encryption/decryption.

Julius Caesar used encryption to communicate privately. The act of shifting the alphabet by a specific number of places is still called the Caesar cipher. Note that the number of places is kept secret and acts as the key. Before Caesar, the Spartans used a rod of a certain thickness that was wrapped with leather and written upon with the spaces not part of the message being filled with decoy letters so only someone with the right diameter rod could read the message. This was called a skytale. The rod thickness acts as the key.

A modern-day encryption key is a number that is used by an encryption algorithm, such as AES (Advanced Encryption Standard) and others, to encode a message so no one other than the intended reader can see it. Only the intended parties are supposed to have the secret key. The interaction between a key and the algorithm is of fundamental importance in cryptography of all types. That interaction is where the magic happens. An algorithm is simply the formula that tells the processor the exact, step-by-step mathematical functions to perform and the order of those functions. The algorithm is where the magical mathematical spells are kept, but those are not kept secret in modern practice. The key is used with the algorithm to create secrecy.

For example, the magic formula of the AES algorithm is a substitution-permutation network process, meaning that AES uses a series of mathematical operations done upon the message to be encrypted and the cryptographic key (crypto people call the unencrypted message “plaintext“). How that works is that the output of one round of calculations done on the plaintext is substituted by another block of bits and then the output of that is changed (i.e. permutated) by another block of bits and then it happens over and over, again and again. This round-after-round of operations changes the coded text in a very confused manor, which is the whole idea. Decryption is exactly as it sounds, simply reversing the entire process.

That description, although in actual fact very cursory, is probably TMI here, but the point is that highly sophisticated mathematical cryptographic algorithms that have been tested and proven to be difficult to attack are available to everyone. If a secret key is kept secret, the message processed with that algorithm will be secret from unintended parties. This is called Kerckhoffs’ principle and is worth remembering since it is the heart of modern cryptography. What it says is that you need both the mathematical magic and secret keys for strong cryptography.

Another way to look at is that the enemy can know the formula, but it does him or her no good unless they know the secret key. That is, by the way, why it is so darn important to keep the secret key secret. Getting the key is what many attackers try to do by using a wide variety of innovative attacks that typically take advantage of software bugs. So, the best way to keep the secret is to store the key in secure hardware that can protect if from attacks. Software storage of keys is just not as strong as hardware storage. Bugs are endemic, no matter how hard the coders try to eliminate them. Hardware key storage trumping software is another fundamental point worth remembering.

Alright, so now that we have a good algorithm (e.g. AES) and a secret key we can start encrypting and feel confident that we will obtain confidentiality.

Key Agreement

In order for encryption on the sender’s side and decryption on the receiver’s side, both sides must agree to have the same key. That agreement can happen in advance, but that is not practical in many situations. As a result, there needs to be a way to exchange the key during the session where the encrypted message is to be sent. Another powerful cryptographic algorithm will be used to do just that.

There is a process called ECDH key agreement, which is a way to send the secret key without either of the sides actually having to meet each other. ECDH uses a different type of algorithm from AES that is called “EC” to send the secret key from one side to the other. EC stands for elliptic curve, which literally refers to a curve described by an elliptic equation.   A certain set of elliptic curves (defined by the constants in the equation) have the property that given two points on the curve (P and Q) there is a third point, P+Q, on the curve that displays the properties of commutivity, associativity, identity, and inverses when applying elliptic curve point multiplication. Point-multiplication is the operation of successively adding a point along an elliptic curve to itself repeatedly. Just for fun the shape of such an elliptic curve is shown in the diagram.

The thing that makes this all work is that EC point-multiplication is doable, but the inverse operation is not doable. Cryptographers call this a one-way or trap door function. (Trap doors go only one way, see?)  In regular math, with simple algebra if you know the values of A and A times B you can find the value of B very easily.  With Elliptic curve point-multiply if you know A and A point-multiplied by B you cannot figure out what B is. That is the magic. That irreversibility and the fact that A point-multiplied by B is equal to B point-multiplied by A (i.e. commutative) are what makes this a superb encryption algorithm, especially for use in key exchange.

To best explain key agreement with ECDH, let’s say that everyone agrees in advance on a number called G. Now we will do some point-multiply math. Let’s call the sender’s private key PrivKeySend.  (Note that each party can be a sender or receiver, but for this purpose we will name one the sender and the other the receiver just to be different from using the typical Alice and Bob nomenclature used by most crpyto books.) Each private key has a mathematically related and unique public key that is calculated using the elliptic curve equation.  Uniqueness is another reason why elliptic curves are used. If we point-multiply the number G by PrivKeySend we get PubKeySend. Let’s do the same thing for the receiver who has a different private key called PrivKeyReceive and point-multiply that private key by the same number G to get the receiver’s public key called PubKeyReceive.   The sender and receiver can then exchange their public keys with each other on any network since the public keys do not need to be kept secret. Even an unsecured email is fine.

Now, the sender and receiver can make computations using their respective private keys (which they are securely hiding and will never share) and the public key from the other side. Here is where the commutative law of point-multiply will work its magic. The sender point-multiplies the public key from the other side by his or her stored private key.  This is equates to:

PubKeyReceive point-multiplied by PrivKeySend which = G point-multiplied by PrivKeyReceive point-multiplied by PrivKeySend

The receiver does the same thing using his or her private key and the public key just received. This equates to:

PubKeySend point-multiplied by PrivKeyReceive  = G point-multiplied by PrivKeySend point-multiplied by PrivKeyReceive.

Because point-multiply is commutative these equations have the same value!

And, the rabbit comes out of the hat: The sender and receiver now have the exact same value, which can now be used as the new encryption key for AES, in their possession. No one besides them can get it because they would need to have one of the private keys and they cannot get them. This calculated value can now be used by the AES algorithm to encrypt and decrypt messages. Pretty cool, isn’t it?

Below is a wonderful video explaining the modular mathematics and discrete logarithm problem that creates the one-way, trapdoor function used in Diffie-Hellman key exhange. (Oh yeah, the “DH” in ECDH stands for Diffie-Hellman who were two of the inventors of this process.)

Are you building out for secure devices?  Protect your design investments and prevent compromise of your products? Receive a FREE Atmel CryptoAuthentication™ development tool.

5 IoT challenges for connected car dev

Growth in adoption of connected cars has exploded as of late, and is showing no signs of slowing down, especially the vehicle-to-infrastructure and vehicle-to-retail segments. As adoption grows exponentially, the challenges in how we develop these apps emerge as well.

One of the biggest challenges to consider will be connectivity, and how we connect and network the millions of connected cars on the road. How can we ensure that data gets from Point A to Point B reliably? How can we ensure that data transfer is secure? And how do we deal with power, battery, and bandwidth constraints?

1. Signaling

At the core of a connected car solution is bidirectional data streaming between connected cars, servers, and client applications. Connected car revolves around keeping low-powered, low-cost sockets open to send and receive data. This data can include navigation, traffic, tracking, vehicle health and state (Presence); pretty much anything you want to do with connected car.

Signaling is easy in the lab, but challenging in the wild. There are an infinite amount of speed bumps (pun intended) for connected cars, from tunnels to bad network connectivity, so reliable connectivity is paramount. Data needs to be cached, replicated, and most importantly sent in realtime between connected cars, servers, and clients.

2. Security

Then there’s security, and we all know the importance of that when it comes to connected car (and the Internet of Things in general). Data encryption (AES and SSL), authentication, and data channel access control are the major IoT data security components.

In looking at data channel access control, having fine-grain publish and subscribe permissions down to individual channel or user is a powerful tool for IoT security. It enables developers to create, restrict, and close open channels between client apps, connected car, and servers. With connected car, IoT developers can build point-to-point applications, where data streams bidirectionally between devices. Having the ability to grant and revoke access to user connection is just another security layer on top of AES and SSL encryption.

3. Power and Battery Consumption

How will we balance the maintaining of open sockets and ensuring high performance while minimizing power and battery consumption? As with other mobile applications, for the connected car, power and battery consumption considerations are essential.

M2M publish/subscribe messaging protocols like MQTT are built for just this, to ensure delivery in bandwidth, high latency, and unreliable environments. MQTT specializes in messaging for always-on, low-powered devices, a perfect fit for connected car developers.

4. Presence

Connected devices are expensive, so we need a way to keep tabs on our connected cars, whether it be for fleet and freight management, taxi dispatch, or geolocation. ‘Presence’ functionality is a way to monitor individual or groups of IoT devices in realtime, and has found adoption across the connected car space. Developers can build custom vehicle states, and monitor those in realtime as they go online/offline, change state, etc.

Take fleet management for example. When delivery trucks are out on route, their capacity status is reflected in realtime with a presence system. For taxi and dispatch, the dispatch system knows when a taxi is available or when its currently full. And with geolocation, location data is updated by the millisecond, which can also be applied to taxi dispatch and freight management.

5. Bandwidth Consumption

Just like power and battery, bandwidth consumption is the fifth connected car challenge we face today. For bidirectional communication, we need open socket connections, but we can’t have them using massive loads of bandwidth. Leveraging M2M messaging protocols like the aforementioned MQTT lets us do just that.

Building the connected car on a data messaging system with low overhead, we can keep socket connections open with limited bandwidth consumption. Rather than hitting the servers once multiple times per second, keeping an open socket allows data to stream bidirectionally without requiring requests to the server.

Solution Kit for Connected Cars

The PubNub Connected Car Solution Kit makes it easy to reliably send and receive data streams from your connected car, facilitating dispatch, fleet management applications and personalized auto management apps. PubNub provides the realtime data stream infrastructure that can bring connected car projects from prototype to production without scalability issues.

Video: Atmel talks Makers, Arduino and IoT at ESC Brazil

This past August, Atmel had the opportunity to be an exhibiting sponsor at the Embedded System Conference in São Paulo, Brazil. Aside from showcasing our latest IoT solutions, Atmel | SMART product line and AVR microcontrollers, we were fortunate to also have time to interact with the vibrant Latin American embedded community.

Sander Arts, Atmel VP of Corporate Marketing, shared detailed insight into DIY culture, as well as the integral role Atmel plays in fueling the emerging embedded community. Additionally, Arts addressed the growth of the worldwide Maker Movement, showcasing a variety of startups (e.g. Pebble and MakerBot) who each got their start using versatile a range of Atmel 8- and 32-bit MCUs.

“There are over 217, in this particular moment, based and built around an Arduino (and AVR),” Arts revealed. “Specifically, there are over 160 AVR based projects on Kickstarter, of which 103 successful, collecting $7 million in funding.”

Arts went on to explore the newest addition to the Arduino family, the Arduino Zero — a simple, elegant and powerful 32-bit extension of the platform originally established by the popular ATmega328 based Uno.

Arts added that there are now over 1,000 Makerspaces and communities around the world, including a number of nearby Brazilian hackerspaces.

Shortly thereafter, the Atmel VP of Marketing had the chance to sit down with Garoa Hacker Clube’s Luciano Ramalho to further discuss the Maker Movement throughout the region, the company’s role in the DIY movement, embedded solutions and development environments, and of course, the budding popularity of Arduino.

During his Makers Club interview, Arts hinted at a couple of “additional developments around the Internet of Things for Makers,” which we now know was the Arduino Wi-Fi Shield 101 — a shield which enables rapid prototyping of IoT applications using the highly-popular open-source platform.

Throughout the week, there was a tremendous amount of real buzz and excitement amongst the embedded engineers, developers and hobbyists in attendance. Caminhos de Sucesso Editor Jose Antonio Purcino caught up with Atmel Senior Product Marketing Andreas Eieland and EE Times’ Max Maxfield to explore the latest hot trends and topics in embedded design, IoT and wireless.

“The Internet of Things is nothing new, as we have been connecting MCUs to sensors and analyzing the data for a long time,” Andreas Eieland, Atmel Senior Product Marketing Manager, told EE Times. “But what is new is the technology options available for engineers to develop connected systems without the high degree of complexity of the past.”

Next, the Atmel team will be heading to Electronica 2014. Here’s a quick look at the tech you can expect to see next month in Munich.

Finger on the IoT Pulse: ‘Presence’ Functionality

We talk a lot about connecting, networking, and securing the Internet of Things, and the billions of devices spread across the globe. Another essential piece of the IoT puzzle is monitoring those devices, specifically with what we call presence. 

Presence functionality gives IoT developers a way to monitor individual or groups of IoT devices in realtime. Whenever the state of the device changes, the change is reflected in realtime to a dashboard, with an alert, or any other way you want to display your tracking.

What Can Presence Monitor?

As soon as you start streaming large volumes of data, or signaling and trigger actions to devices, you need to know what devices are connected. So what kinds of device states can you monitor with presence functionality? Pretty much anything you want! With Presence functionality, you can build out custom device states including:

• Online/offline status
• Device health
• Capacity for fleet management
• Total device count in field
• Battery/location status
• Machine status (eg. currently working on X task, driver driving/offline)
• Temperature and weather data from IoT sensors

With presence data, you can also log a history of device connectivity for audits and analytics. It’s not just about having realtime insight into your devices, but also tracking and logging performance, health, and other key metrics.

Why Is It Important?

Devices may get expensive: IoT devices can be expensive, so keeping tabs on your investment is essential. Device health presence monitoring gives you up to the millisecond health reports for device temperature, connectivity, battery life, etc, ensuring you that your device is 100% operational, all the time. And if any issues arise, you’ll know immediately that maintenance is required.

Devices may be imperative to operations/business: If IoT devices are at the core of business and operations, monitoring their health and status is paramount. Whether it’s agriculture readings, security sensors, or delivery fleet management, up to the millisecond device status can make or break a business.

Device Analytics: Accurate and up to date statistics and analytics is important to any IoT application or business. Presence functionality can store, retrieve, and playback collected analytics, for example, to give a history of device connectivity or health for audits.

Machine-to-Machine and IoT Use Cases for Presence

As we know, connected devices come in all shapes and sizes. And as IoT devices get smarter, more connected, more secure, and faster, they’re use in the field is skyrocketing across the globe. And as we add more devices into the field, realtime presence functionality is just as important as our device networks and IoT security.

Agriculture: As with other connected technologies, the Internet of Things has found heavy adoption in the agricultural industry. Sensors and monitoring devices for temperature, irrigation, weather patterns, and harvest management give farmers a realtime, accurate data stream, giving them full control over their agriculture system. As a result, keeping tabs on their vast system of IoT devices with presence functionality is key.

Connected Car/Shipping & Freight: Smart cars are shifting IoT boundaries and constitutes a disruptive and transformative environment. Connected car represents a large number of IoT use cases for automobiles including taxi, fleet management, shipping and freight, and delivery service. Connected cars require a secure and reliable connection to counter the various roadblocks that arise in the wild, such as constantly changing cell and network towers and dropped connections.

For taxi, shipping, freight, and delivery management, custom presence functionality is a vital component of the business, providing realtime custom vehicle and device states, such as vehicle and cargo capacity, location data, and device health.

Home Automation: We’re well aware that our homes are getting smart. It seems today, every appliance has an IP address. It’s safe to say that the smart home market is prepared to take the world by storm. Especially for applications that enable users to control their homes remotely, presence functionality is essential. In the smart home, presence gives users a realtime view of their devices status (lights on, doors locked, water leak, thermostat, fridge temperature, etc). And that’s the basis of a solid home automation solution.

Presence on the PubNub Data Stream Network

PubNub Channel Presence is one of the core features of the PubNub Data Stream Network. It enables developers to add user and device detection to their web, mobile, and IoT applications, giving realtime instant detection and notification of user/device status. Built on the global PubNub Data Stream Network, no matter where the devices are located, you can get an accurate and reliable reading on any custom device state you want.

For a quick tutorial on using Presence for IoT devices, whether it’s a network of 1000 connected devices or a single Arduino, check out our blog post: Realtime IoT Monitoring for Devices with PubNub Presence.

Atmel and IHR driving innovation in automotive electronics

Atmel has just announced a collaboration with IHR, a worldwide partner in the automotive industry, to further support the innovation of Local Interconnect Network (LIN) systems. This collaboration leverages IHR’s LIN configuration tools with Atmel’s industry-leading embedded solutions to improve application integration, time-to-market and to minimize licensing costs.

Atmel’s collaboration with IHR enables Atmel to provide manufacturers with a LIN-compliant evaluation environment to further streamline development, bringing the best of automotive engineering faster to market. IHR’s solutions support several Atmel technologies including the megaAVR, tinyAVR and XMega AVR families.

For those interested, a free demo version of the LIN drivers is now available for download via the IHR website and can be used for evaluation purposes. Upcoming new product series will be supported by IHR solutions as well.

“With nearly 30 years of experience working with the automotive industry, Atmel has spurred the pervasive growth of electronic features in cars,” explained Giovanni Fontana, Atmel Automotive Applications Director. “Our collaboration with IHR will help our customers continue to build innovative electronic products in a cost-effective manner with improved integration and intuitive configuration capabilities.”

Atmel combines a unique blend of IVN products and embedded MCUs. AVR MCUs deliver the power, performance and flexibility to support a wide range of automotive applications. These small, yet powerful, advanced 8- and 32-bit AVR MCUs deliver the technical features, advanced architecture and dependable design ideal for an array of applications.

In what has become the industry’s largest, the Atmel LIN product portfolio includes stand-alone transceivers, system basis chips (SBC) which integrate a transceiver, a voltage regulator and often other functions as well as AVR MCU-based system-in-package (SiP) and application-specific (ASSP) devices.

“IHR is recognized for our proven LIN tools used by designers to create applications that automotive manufactures rely on as competitive differentiators,” said Rüdiger Kewitz, COO at IHR GmbH. “Together with Atmel, we offer a very compelling proposition for manufacturers to not only design next-generation embedded systems, but also to bring high-end applications to market through an amplitude of makes and models.”

Interested in learning more about Atmel’s LIN solutions? Additional information is available here. You can also browse through the Bits & Pieces archive on the topic.

There’s good news about BadUSB

The good news about the recently-revealed BadUSB is that there actually is a cure: Atmel CryptoAuthentication. Hardware crypto engines were invented to protect software, firmware and hardware from exactly these types of attacks, among many others. These uber-tiny, ultra secure hardware devices can be easily and cost-effectively added to USB sticks (and other peripherals) by manufacturers, who are seeking to protect their customers by ensuring that only the proper and intended code is downloaded and used. Once installed into the peripherals, CryptoAuthentication devices will block the bad code. Period.

Let’s look at what Bad USB has uncovered: It is that everything with a processor is vulnerable to attack. Most people don’t really think of a USB stick, modern thermostat, home router, fax machine, PC mouse or trackpad, a camera, iPod, microwave, and other “things” as being computers; however, they are. In fact, they all have at least one processor, memory, ways to get stuff in and out, and code (firmware) that tells the processor what to do. That last piece is where the danger lies.

As any PC or smartphone user knows, code gets updated all the time to get rid of bugs and add features. Updating code opens up a processor that was previously running good code, to code altered by people with mal-intent, i.e. malware. This is how good embedded systems go bad. We recently saw malware that allowed an ATM to spit out 40 bank notes at a time if a certain code was entered. Real nice for those who know the code!

BadUSB is Bad for More Than Just USB

All systems with processors are vulnerable to bad code, which can do bad things to good systems. All it takes is a way to transfer bad code from one processor to another… and, that happens all the time. USB sticks, USB accessories, the Internet, wireless links like Wi-Fi or Bluetooth — you name it — can be vectors for diseased code. What BadUSB has revealed to us is that all embedded systems, unless equipped with robust protection mechanisms, are now vulnerable to catching diseased code. (Embola?)

Embola

One contracted, a machine infected with Embola can send private and sensitive information to bad guys, or let them take over your system for ransom or other mal-purposes. They can turn on cameras and microphones to spy, grab your photos and bank account information, or even mess with your car. Whatever they want they can have, and you most likely will never know it.

By now you should see the point, which is that every embedded system and PC needs protection. Everything that runs software is vulnerable such as wearables, phones, USB accessories, USB sticks, cameras, cars, printers, thermostats, ATMs, meters, microwaves, appliances, and whatever the IoT will become. Simply put: If it has a processor and connects to something else, it is hackable.

So, what can you do to protect against Embola? The answer is twofold:

1. Don’t let the bad code in, and
2. If it does get in, don’t let it run.

While this sounds pedantically simplistic, these steps are NOT being taken. These two functions have the self-explanatory names of secure download and secure boot.

Secure Download

Secure download uses encryption to ensure that the code that is received by the embedded system is kept away from hackers. The code is encrypted using an algorithm such as Advanced Encryption Standard (AES) by using an encryption key. That encryption key is created using a secret that is only shared with the target system. The encrypted code is sent to the target embedded system to be decrypted and loaded for its use. Along with the encrypted code, a seed is also sent to the target system.

The seed is a number (typically unique with each session) that is hashed during the encryption session with a secure secret key. The result of that hashing is called the digest or Message Authentication Code (MAC) and it is used to encrypt the code (i.e. the MAC is the actual encryption key). The seed is sent to the target system to enable decryption, and not useful to anyone unless it is hashed with the secret key, which is what the target system will do. The target system runs the same hashing algorithm with the identical shared secret key stored there and the seed, which results in the same digest (MAC) that was used to encrypt the code. That MAC can now be used as the decryption key to decrypt the code. At this point, the decrypted code can be ran in the target embedded system.

However, there is another step that can be taken that adds even more security, which is authentication using a digital signature. To use authentication, the unencrypted original code is hashed and signed by the code originator at the same time as the original encryption process. The originator uses a signing key on that hash of the code to make a signature. That signature is sent with the encrypted code and seed to the target system. Once the encrypted code is decrypted using the process noted above, the newly decrypted code will be hashed by the target system, just like was done by the originator, and then signed with the signing key stored in the target system. That signing key is the same as on the originator’s signing module, so if the decrypted code has not been altered, the signature made on the digest of that decrypted code and the signing key will be exactly the same as the signature that was sent over. These two signatures are compared and if they match then the code has been authenticated and can be safely run on the target system. What does this mean? No risk of Embola!

The two levels or security provided by secure down load with authentication is obviously very robust. It will ensure that code that was received has been kept secret during transmission and has not been tampered.

Secure Boot

Secure boot also uses digital signatures to ensure that the code to be booted when the target system starts up matches the code that the manufacturer intended and has not been tampered with. It sort of works in a similar way as secure download. If the code to be booted has been altered, then the signature made by hashing the digest of that code with a secret signing key will not match the signature from the manufacturer. If they don’t match, the code will not load.

These methods are easy and inexpensive to implement and already exist. You should be able to see by now how Atmel has you covered. Ready, set, get secure!

 

Video: Atmel showcases the WINC1500 wireless module at ARM TechCon

Back in September, Atmel expanded its leading SmartConnect wireless portfolio with four new turnkey system-on-chips (SoCs), including the WINC1500. The recently-unveiled WINC1500 is an IEEE 802.11b/g/n network controller optimized for battery-powered Internet of Things (IoT) applications.

The WINC1500 is an ideal add-on to existing MCU solutions bringing Wi-Fi and network capabilities through UART or SPI-to-WiFi interface, and connects to any Atmel AVR or Atmel  | SMART MCU with minimal resource requirements. As a result, the SoC enables Makers and engineers to bring connectivity to any embedded design, ranging from consumer to industrial apps.

As Hackaday’s Adam Fabio recently noted, “The WINC1500 is a nifty little Wi-Fi module in its own right… 72Mbps may not sound like much by today’s standards, but it’s plenty fast for most embedded applications. WINC handles all the heavy lifting of the wireless connection.”

The WINC1500’s most advanced mode is a single stream 1×1 802.11n mode providing up to 72 Mbps PHY throughput, and features a fully-integrated power amplifier, LNA, switch and power management. The solution provides internal Flash memory as well as multiple peripheral interfaces including UART, SPI, and I2C. The only external clock source required for the SoC is a high-speed crystal or oscillator with a wide variety of reference clock frequencies supported (between 12 – 32 MHz). The WINC1500 is also available in a QFN package.

During ARM TechCon 2014, our friends at ARM had the chance to catch up with Henrik Flodell, Atmel Senior Product Marketing Manager, who highlighted a few demos that combined ARM-based Cortex-M0+ MCUs with the Atmel WINC1500 module.

First, Flodell showed off the SAM D21 Xplained Pro Kit, combined with a WINC1500 and motion sensor. As the video below demonstrates, the board was capable of wirelessly transmitting its coordinates to the application running on the screen.

“For the professional that wants to use the Atmel development tools or those from third party vendors, we have the Xplained Pro Solution.” However, Flodell went on to address the DIY crowd seeking to use 32-bit ARM Cortex-M0+ based MCUs stating, “We’ve also realized there’s a huge interest in the Maker community for creating connected devices based on ARM technology.”

Flodell then went on to give a first-hand look at our recently-unveiled Arduino Shield 101, which was paired with the SAM D21-based Arduino Zero.

This cost-effective, secure shield is an easy-to-use extension that can seamlessly be connected to any Arduino board enabling high-performance Wi-Fi connectivity. The Arduino Wi-Fi Shield 101 is powered by Atmel’s wireless network controller, part of the Atmel SmartConnect family. It also includes the ATECC108 device, from the CryptoAuthentication family, which allows users to easily incorporate hardware authentication capability in their design.

 

Arduino and Adafruit unveil the Arduino Gemma

During his Maker Faire Rome presentation, Arduino Co-Founder Massimo Banzi offered attendees a preview of the company’s new collaboration with Adafruit — the Arduino Gemma, a tiny wearable MCU board packed in a 1-inch (27mm) diameter package.

Similar to the original Adafruit Gemma, the mini yet powerful wearable platform board is powered by the versatile ATtiny85. The board will be default-supported in the Arduino IDE, equipped with an on/off switch and a microUSB connector. Since it is programmable with the Arduino IDE over USB, all Makers will have the ability to easily create wearable projects with all the advantages of being part of the Arduino family.

“We wanted to design a microcontroller board that was small enough to fit into any project, and low cost enough to use without hesitation,” Adafruit’s Limor Fried (aka LadyAda) explained in a blog post last September. “Gemma is perfect for when you don’t want to give up your Flora and aren’t willing to take apart the project you worked so hard to design. It’s our lowest-cost sewable controller.”

Ideal for small and simple projects sewn with conductive thread, the [tinyAVR based] Arduino Gemma fits the needs of nearly every entry-level wearable creations — ranging from reading sensors to driving addressable LED pixels.

To better visualize just how small we are talking, look at this image from an earlier version of the Adafruit Gemma.

“The ATtiny85 is a great processor because despite being so small, it has 8K of flash and 5 I/O pins, including analog inputs and PWM ‘analog’ outputs. It was designed with a USB bootloader so you can plug it into any computer and reprogram it over a USB port (it uses 2 of the 5 I/O pins, leaving you with 3),” Arduino noted in its announcement.

In addition to ATtiny85 MCU, other key hardware specs include:

• Operating Voltage: 3.3V
• Input Voltage (recommended): 4-16V via battery port
• Input Voltage (limits): 3-18V
• Digital I/O Pins: 3
• PWM Channels: 2
• Analog Input Channels: 1
• DC Current per I/O Pin: 40 mA
• DC Current for 3.3V Pin: 150 mA
• Flash Memory: 8 KB (ATtiny85) of which 2.5 KB used by bootloader
• SRAM: 0.5 KB (ATtiny85)
• EEPROM: 0.5 KB (ATtiny85)
• Clock Speed: 8 MHz
• MicroUSB for USB Bootloader
• JST 2-PH for external battery

For those seeking to use an Arduino Gemma in their next DIY wearable project, the board will be available for purchase on the Arduino Store and Adafruit Industries beginning late Fall 2014.

Atmel samples new family of Atmel | SMART ARM Cortex-M7-based MCUs

As previously reported on Bits & Pieces, ARM recently unveiled a new 32-bit Cortex-M7 microcontroller (MCU) targeted at high-end, next generation embedded applications and has named Atmel as one of the early lead licensees of the processor, enabling the company to deliver exciting new products to the market in the forthcoming months.

Today, in the midst of ARM TechCon, Atmel has announced the development of a new family of Atmel | SMART ARM Cortex-M7-based MCUs that are sampling to select customers now. Broadening Atmel’s current MCU/MPU portfolio, the family is well positioned between Atmel’s ARM Cortex-M-based MCUs and Cortex-A-based MPUs enabling designers to select from a greater range of processing solutions. The new devices will address high-growth markets including the Internet of Things (IoT) and wearables, as well as automotive and industrial applications that require both high performance and power efficiency.

The Atmel | SMART Cortex-M-based MCUs allow customers to scale-up performance, SRAM and system functionality, while keeping the Cortex-M class ease-of-use and maximizing software reuse. The first devices will run up to 300MHz, with up to 384kByte SRAM configurable as Tightly Coupled Memory (TCM) or System Memory, and up to 2Mbyte on-chip Flash. They will be comprised of three series: general purpose, connectivity and automotive-qualified.

“As one of the first ARM licensees, we are excited to add the Cortex-M7 core to our already broad portfolio of MCUs and MPUs,” explained Jacko Wilbrink, Atmel Senior Marketing Director. “The new Cortex-M7-based MCUs leverage our advanced peripherals and flexible SRAM architecture for higher performance applications, while keeping the Cortex-M class ease-of-use. This new addition enables our customers to select from an even larger portfolio of Atmel | SMART ARM-based MCUs to optimize system designs from consumer IoT devices to automotive applications.”

“Atmel’s new family of microcontrollers helps to bridge the gap between existing microprocessors and highly-efficient microcontrollers on the market,” shared Noel Hurley, General Manager, CPU Group. “The ARM Cortex-M7 core drives innovation and pushes the performance envelope for embedded devices.”

All devices come standard with high-speed USB On-the-Go (OTG) and on-chip high-speed USB PHY, the connectivity series offers 10/100 TBase Ethernet MAC and Dual CAN-FD from Bosch. The automotive series offers Ethernet AVB support and Media LB, which when combined with the Cortex-M7 DSP extensions, make the series ideal for infotainment connectivity and audio applications.

Atmel is working closely with the ARM ecosystem partners on development tool support and RTOS BSPs for the new Atmel | SMART Cortex-M7-based MCUs. In addition, Atmel will offer complete support for this new MCU family on Atmel Studio and Atmel ICE. A comprehensive set of peripheral drivers and examples will be provided, as well as Xplained evaluation kits.

“The Cortex-M7 is well positioned between Atmel’s Cortex-M based MCUs and Cortex-A based MPUs enabling Atmel to offer an even greater range of processing solutions,” Reza Kazerounian, Atmel Senior Vice President and General Manager, recently revealed. “Customers using the Cortex-M-based MCU will be able to scale up performance and system functionality, while keeping the Cortex-M class ease- of-use and maximizing software reuse.”

While sampling to select customers is currently underway, general sampling and availability of the Xplained kit is expected in early 2015. Those interested in learning more can come visit us at ARM TechCon in Santa Clara, California October 1-3, 2014 at booth #205.

Vegard Wollan on the AVR and ARM cores and peripherals

In the fifth video of the series, I asked the co-inventor of the AVR microcontroller about the progression of the peripherals in the various microcontrollers Atmel offers. Vegard shares that when they invented the first AVR products, the team was concerned with ease-of-use, a clean instruction set that would run C, instructions that ran in a single cycle, and good quality tools.

However, he was just as proud of the peripherals that they then developed for the XMEGA line of AVR 8-bit chips. There, he said the stress was still on low power, but also a set of peripherals that were high performance, robust, strong, effective, and that included analog and digital advanced peripherals. Additionally, Vegard stressed how the XMEGA event system would allow programmers to handle complex events and take action, all without waking up the CPU core in the part.

Vegard Wollan becomes animated when talking about the peripherals in AVR and ARM chips offered by Atmel.

I knew this was cool for the low-power aspect, yet Vegard reminded me that it also allows you to service an interrupt faster and more deterministically — always a good thing in embedded systems. The great news for engineers is that all the cool things Atmel figured out for the XMEGA AVR also went into to the UC3, the 32-bit AVR product lines. Then, we made sure to put these same powerful and flexible peripheral systems into our ARM core-based MCUs. In addition we would add dedicated touch I/O pins and more accurate clocks and references. You can still see the AVR DNA from back in 1990 at the Norwegian University of Science and Technology where the AVR came to life.

What I really loved about Vegard was his humility. Every time I tried to give him credit for the AVR he was sure to remind me that there was a whole team that developed it. And, when I tried to point that the AVR was RISC (reduced instruction set computer) before ARM came out, he told me that he was more proud of the peripherals in all of Atmel’s chips, rather than just the core he invented for the AVR. That’s a good thing to keep in mind.

While using any ARM core will get you the instruction set and header files and open-source tools, Atmel’s ARM chips will also get these great peripherals and the event system to tie them all together, while the CPU sleeps peacefully. A recent article helped me understand Vegard’s Norwegian modesty, but I am sure glad he and his team worked on the AVR and ARM chips.