Let’s skip the Gartner hype cycle discussion about the ever-evolving Internet of Things, shall we? It’s a given: IoT is huge, everyone’s hair is on fire — some will be disillusioned, some will win big, time will sort it out. But, if you’re waiting for the “one thing to rule them all,” you’ll surely be a bystander to a new wave of innovation and opportunities. You have to dive in before all the winners and losers are culled.
Because IoT is such a massive domain, this series is an attempt to boil it down into something practical, even desktop scope.
Roadmap
To start, we’ll introduce and discuss a relatively simple model and way to think about the IoT in order to help keep your technical bearings in a rapidly changing landscape.
In subsequent parts of this series, I’ll explore some of the leading IoT protocols, and in keeping with a “practical IoT” theme, we’ll do some desktop IoT with some easy-to-use development boards from Atmel along with a selection of open-source tools or libraries.
I’ll put heavy emphasis on IoT security as it is an often overlooked, yet critical, element of implementing a successful IoT stack. The goal is to create a basic IoT stack that works well together, but more importantly, provides a hands-on lab to try out various aspects of the connected world as it evolves.
Use Case
As a system architect, you need to get a sensor solution up and running which won’t fall on its face at the first inkling of success. You need to worry about such things as embedded size constraints, scaling strategies, third party integration, connectivity, economics, implementation skill sets, power, and even future-proofing.
You’ll want your system to grow and evolve while the IoT is trying to figure out what it wants to be when it grows up.
It sounds a lot like you are doing M2M, so how is IoT going to help?
What’s the difference between IoT and M2M?
“Always design a thing by considering it in the next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” – Eliel Saarinen
If you developed a sensor network before the IoT acronym came along, you’d be forgiven for thinking IoT is just lipstick on M2M. M2M is often associated with point solutions or a fleet of the same kind of thing — a system of Wi-Fi thermostats, a flow sensor network in an oil-refinery, a vehicle location system, home automation, all the heart monitoring telemetry in a hospital. For some in the industry, M2M means anything with a cellular modem on a particular carrier’s network.
Long story short, the key takeaway is that M2M is almost synonymous with isolated systems of sensors and islands of telemetry data. In contrast, the IoT is trying to marry disparate systems into an expansive system view to enable new applications — that’s not only the big idea, it’s the one key difference between M2M and IoT.
“If you consider M2M in the next larger context, you get the IoT.” – Landon Cox
I guess we can say that IoT really stands for “I want it all.” In order to achieve that, major new facets such as first class security, big data, cloud scale, ubiquitous presence, human interactions — all wrapped up in business objective parlance — come to bear.
IoT is a catch-all technology bucket and it’s probably always going to be that way, so let’s make the best of it and make headway amidst all the ambiguity and hype. Here’s how…
One practical way to think about it is: The Internet of Things is the arch connecting M2M vertical pillars (technology stacks). This view allows the IoT to leverage all of the good work that has gone into M2M, incorporate existing legacy M2M systems, yet leave it loosely coupled and abstract enough to describe various business problems (not one size fits all).
In the example above, IoT is marrying health sensor data from three very different sources and contexts, all of which are using different company’s products within siloed M2M ecosystems. Bringing this together provides a better overall picture of a client’s health than individual silos can. IoT technologies, such as cloud scale and security, gain tremendous importance in an application like this, beyond the significance within the silo’s scale.
This view also helps keep IoT from being tied to a specific M2M technology stack. The implication? For IoT to add value not already in M2M, it must provide a fabric that either bridges M2M systems, through analytics or data networking, or fulfill a business mission not addressed by an individual M2M stack.
IoT Caveats
IoT is dangerously close to the SOA vortex (Service Oriented Architecture) and is something we need to be mindful of avoiding. As SOA expert Anne Thomas Manes pointed out in SOA is Dead; Long Live Services, “Perhaps that’s the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., “what’s the best ESB?” or “WS-* vs. REST”), and they missed the important stuff: architecture and services.”
My summary? Despite some good technology and ideas that came out of SOA, technology that the IoT builds upon, SOA died of its own weight. We should keep the cause of death of SOA in mind when working on IoT so it doesn’t become a likewise casualty.
I would like to see IoT architecture evolve along the lines of the OSI network reference model and not SOA (except for the important stuff). That means that IoT should be a simple, common concept used by system architects to design, map, and compare different implementations.
Ethernet and Token Ring, for example, are two very different network technologies, but both map to the OSI reference model. OSI gives us a common way to talk about nearly any network technology. We need the same idea for IoT to make it practical.
From that perspective, we could talk about many different Internet of Things stacks in the same manner we talk about Ethernet, Wi-Fi, TCP/IP, or UDP. Various technologies fit into a common network model (OSI) and are combined in various ways to achieve something useful (i.e. the web). Same with the IoT: Think of it as a model, like OSI. Specific IoT implementations map to various parts of an IoT reference model like specific networks technologies map to OSI.
So, this is the basic philosophy behind what I would call “practical IoT:”
1. Don’t let the acronym get in the way.
2. Use the right tool for the right job (IoT stack flexibility, not one-size-fits-all, no IoT wars).
3) Ensure IoT is more technology-oriented, like the OSI reference model; less marketing oriented and less like SOA.
4) It has to be more than, and distinctly different from, M2M.
Now where?
I realize this was a really high level view of Practical IoT. Stay tuned for upcoming Desktop IoT tutorials and hands-on demonstrations as we’ll delve deep and get practical with the Internet of Things. In the meantime, imagine, expand and evolve your connected ideas with Atmel’s latest (free) white paper.
My buddy Rob Bowers over at Brocade told me about this video channel for home made (aka Maker) electronics projects. It’s produced by Alan “W2AEW” Wolke. You can see by his nickname and video channel name, he is a Ham radio enthusiast. I never got that bug, my projects were more like a wire wrapped around a nail to make an electromagnet.
The video above is what got my buddy Rob excited. He enthused, “Wow electronics for everybody! There may be hope for me. I watched the one on completing the noise source on the Ham It Up! convertor. He builds it, tests the basics, and the shows a simple use case. I feel .031% less stupid. I wanted to know if I should purchase the noise source parts. ‘Yes’ is the answer, after watching this.”
This is the cool thing about the Maker Movement. Rob is not an engineer. He did software QA in the past and now works at Brocade in the IT department. He is technical, but not formally trained. But the Maker movement is about the fun stuff, and the dreary classrooms and boring lectures are dispensed with in favor of learning with a specific objective in mind. It’s all the fun of engineering without the tedium. We invented computers. They can do the tedium, and the math, for that matter.
Electronics enthusiast Alan Wolke at his bench.
You can see from Alan’s bench the passion he has for radio and electronics in general. Any person with a Metcal soldering iron and a Simpson 260 analog voltmeter is OK by me. The extended CRT (cathode ray tube) housing on that scope makes me think it is the 400MHz Tek 2467B, the fast glitch capture version of the Tektronix 2465B. The CRT is longer to add the plates needed for persistence.
Another cool tip from Rob was about Brocade where he works. He told me the labs have vending machines with cables and mice and other day-to-day engineering essentials. The engineers can just swipe their badge into the vending machine, pick out the cable and be on their way, no requisition forms or hassle. What a class outfit.
Nuts and Volts magazine has a ton of good articles about electronics.
Knowing I worked at Atmel, my pal wanted to point out the above article about Arduino by Joe Pardue. Nuts and Volts is a subscription magazine, so you have pay 27 bucks a year for print and digital, or only 20 bucks a year if you don’t want the print magazine.
Even without subscribing, you can download the code samples for the Arduino 101 article, and if you upgrade to the mysterious un-priced “preferred subscriber network” you get access to all the old issues of Nuts and Volts. This is a great complement to Circuit Cellar magazine, which is also a subscription magazine, but for $250 they can also give you a memory stick with every single article they have ever done. I recommend both these magazines since they are aimed at system design. The trade press, where I have worked, is fine to learn about the latest chip or test method. But Circuit Cellar and Nuts and Volts both show you how to hook up the chips, and do the code and everything else to get a working product. They even touch on 3-D printing and the stuff to put your gizmo in an enclosure. No wonder they can charge for a subscription. All they lack is articles about FCC, CE, and UL approvals, and those might happen one day for all I know.
So keep watching those YouTube videos and reading articles, but more importantly, keep hacking on circuits and code. That is the fun stuff that gives real satisfaction and happiness.
Writing for Electronic Design, Atmel’s Ingar Fredriksen and Paal Kastnes recently explored the latest market trends for both 8- and 32-bit microcontrollers (MCUs). While the 32-bit MCU devices continue to rise in popularity throughout the embedded community, 8-bit MCUs are still experiencing a CAGR close to that of their bigger cousins.
These 32-bit, function-rich devices suit an array of different applications, which explains why many embedded developers select them for their next designs. Designers recognize that such complex devices offer everything they need in terms of raw compute power, a rich peripheral set, and easy access to a wide range of development tools and libraries.
Many of these 32-bit devices — which are members of the Atmel | SMART family — are based on the highly-successful ARM cores. Thus, developers feel confident in having access to second source devices and a comprehensive set of development, test and validation tools being available in the market.
However, taking a closer look at recent MCU market trends has revealed that 32-bit devices aren’t the only ones experiencing strong growth. The surging 8-bit MCU market boasts a CAGR (6.4%) close to that of 32-bit (6.9%). Meanwhile, a number of other industry analysts forecast identical growth rates for 8- and 32-bit microcontrollers.
The principle differences between 8- and 32-bit MCUs are cost and price structure, CPU performance, ease of use, efficiency in hardware near functions, and static power consumption. When embarking on a new design, developers need to carefully scope out the requirements for an MCU based on the amount of processing capability required, the degree of interfacing needed, and, for battery-powered designs, the all-important power consumption profiles. There’s no doubt that a 32-bit MCU delivers higher performance than an 8-bit device, but the engineer faces the traditional decision of choosing between the best available device in the market versus an application’s actual needs.
Of course, these decisions will greatly influence the likely bill of materials (BOM) cost. With a lower gate count, a less complex 8-bit device will certainly be cheaper than a 32-bit device. When comparing 8- and 32-bit MCUs from leading vendors, each with a similar amount of flash memory, pin-out etc., 8-bit devices typically cost about 20% less. But this is only the first of many considerations. Another aspect relates to the ease in setting up for a new development.
Ease of Development
MCU suppliers tend to add more features and functionality to their 32-bit devices as opposed to 8-bit products. Consequently, far more setup considerations emerge with a more complex device. While some 32-bit MCUs can run with a limited setup similar to that of an 8-bit device, you’re unable to take advantage of the more powerful device’s additional features.
For example, a typical 32-bit ARM device will have independent clock settings for the core itself, the AHB bus, the APBA bus, and the APBB bus. They all can be set to different frequencies. Typically, you will also have to switch to the clock you want to use because it’s set in software, not in hardware like most 8-bit parts. Furthermore, changing the clock means you must set up the wait states for flash, possibly predicated on measured VCCvoltage.
Such a setup can be much simpler with an 8-bit MCU, though. For example, Atmel’stinyAVR and megaAVR products only require initialization of the stack pointer, which typically takes four lines of code, prior to coding the application. The choice of clock, brownout detector, reset pin function, etc., is all pre-programmed into the device.
The architecture is also much more straightforward than a 32-bit device with internal registers, peripherals, and SRAM all mapped on the same data bus. The peripherals and CPU would normally run at the same frequency, so no peripheral bus configuration is necessary. Moreover, designers can avoid being concerned about latency in synchronizing between different clock domains.
Performance
When it comes to desired CPU performance, the engineer should consider all use cases. The reality is that many embedded designs don’t have high compute requirements. Often, very little manipulation of data is required, so balancing those needs against power-consumption and peripheral-interfacing requirements becomes crucial.
For instance, a simple thermostat application will spend most of its life in a sleep mode. Every so often, it will wake up and measure the temperature and then make a decision to turn a relay on/off or send an instruction to a host controller. Then it will resume sleep. The compute and interface requirements of this application are small, but many other applications such as fire detectors, power tools, flow meters, and appliance controls have a similar use profile, too.
Efficiency of Hardware Near Functions
Many modern microcontrollers incorporate some hardware functions that serve to help the CPU operate as efficiently as possible. In Atmel’s case, both the 8-bit AVR and 32-bit ARM-based MCU families feature the Peripheral Event System. An event system is a set of hardware-based features that allows peripherals to interact without intervention from the CPU. It allows peripherals to send signals directly to other peripherals, ensuring a short and 100% predictable response time.
When fully using the capabilities of the event system, the chip can be configured to do complex operations with very little intervention from the CPU, saving both valuable program memory and execution time. In the case of detecting a hardware event, it’s important to first detect the event and then switch control to the desired interrupt service routine (ISR).
In these situations, CPU speed isn’t the single determining factor. It’s a question of how long, in terms of cycles, does it take to respond to the interrupt, run the ISR, and return. As the following example will show, 8-bit devices can be more efficient in handling hardware near actions.
Consider receiving one byte on the SPI, using an interrupt to detect it, and then running a simple ISR routine to read the byte from the SPI peripheral and store it in SRAM. Using this scenario, table above draws comparisons between an Atmel 8-bit AVR device and an Atmel ARM Cortex M0+based 32-bit MCU. Calculated with information available, the results are based on minimum implementations. However, engineers should check with their own applications since the interrupt detection and return from interrupt could take more cycles than shown in the table. Requiring 12 cycles versus 33 cycles equates to having a theoretical maximum SPI bandwidth of 1.67 MB/s for the 8-bit CPU and a 606 kB/s bandwidth for a 32-bit CPU when running at 20 MHz.
The degree of numeric processing can also have an impact on the stack and required memory. Applying the Fibonacci algorithm is one particularly good method for testing memory requirements. Since it only uses a local variable, everything needs to be pushed to the stack.
When making a comparison between an 8-bit AVR and an ARM 32-bit CM0+-based device, and using a recursive 15-stage Fibonacci algorithm, the AVR uses a total of 70 bytes of stack, including 30 for return stack (15 calls deep). The ARM-based device uses 192 bytes (60 should be return stack). This means the CSTACK is more than three times the size of the 8-bit solution. In typical C code, more of the variables on the stack often come in a packed format, so this is an extreme corner. However, saying 1.5 to 3 times more SRAM is needed for the same 8-bit-centric application on a 32-bit (versus a native 8-bit) device is a fair estimation.
Power Consumption
No MCU article would be complete without investigating static power consumption. This alone may be a key factor in choosing between an 8- or 32-bit device, especially for battery-powered applications. The table below illustrates power-consumption differences between 8- and 32-bit devices in both active and static modes.
Aggressive manufacturing technologies increase transistor leakage current, which roughly doubles with each process generation, and is proportional to the number of gates. Leakage current increases exponentially at higher temperatures, which can be easily overlooked when designing a consumer design. Mobile phones and personal media players are transported everywhere, and as we have all found out, temperatures experienced during the summer inside a car can easily climb above 40°C.
The amount of time the microcontroller will spend in active mode versus static mode contributes significantly to the overall application power budget.
Naturally, the ratio between active and static modes will vary depending on the application requirements. Taking the previous SPI interrupt example (second table from above) and assuming a SPI data bandwidth of 80 kb/s, the 8-bit CPU will spend 1.2% of its time in active mode compared to that of the 32-bit, which will spend 3.3% in active mode (table below).
Conclusion
Contemplating whether to use an 8- or 32-bit microcontroller for a future design may involve an Internet of things (IoT) application. How IoT actually takes shape provokes lots of debate, but it will certainly challenge engineers to make a detailed appraisal of the MCU requirement. Wireless connectivity, especially ZigBee, will also be an essential component, but that doesn’t automatically mean that it will need a higher power device.
A number of available 8-bit microcontroller products satisfy the need for low levels of processing and wireless connectivity. One such example is the Atmel ATmegaRFR2 series, which provides an IEEE 802.15.4-compliant, single-chip, 2.4-GHz wireless microcontroller solution that suits battery-powered, low-cost IoT designs.
So, is the 8-bit MCU experiencing a renaissance? According to Electronics Weekly, it’s rather possible. A recent article notes that despite the rise of ARM architecture and widespread adoption of 32-bit microcontrollers (MCUs), a number of suppliers like Atmel are “more committed to their 8-bit chips than ever before.”
In fact, the publication points out that companies are now adding higher performance peripherals and extending development tools for their highly-popular 8-bit lineups.
“Atmel is another supplier which continues to invest in its range of megaAVR MCUs. Now in their third generation, the MCUs are attracting growing interest in hobbyist/professional crossover applications as a result of being designed into the Arduino low cost embedded computing platform.”
Since its initial launch in 2002, the megaAVR family has become the go-to choice of Makers and engineers alike. The MCUs, which include the stalwart ATmega328 to ATmega32U4, can be found at the heart of millions of gadgets and gizmos, including an entire lineup of Arduino boards, 3D printers such as RepRap and MakerBot, as well as a number of innovative DIY platforms.
“This family of 8-bit megaAVR MCUs has been highly recognized by a variety of communities from the professional designers using our Atmel Studio ecosystem to the hobbyist and Maker in the AVR Freaks and Arduino communities,” explained Oyvind Strom, Senior Director of Marketing for Atmel’s MCU Business Unit.
These MCUs run single-cycle instructions with performance of 1MIPS per MHz, while on-chip flash memory spans from 4KB to 16KB. These new devices provide next-gen enhancements including analog functionality and features for the latest low-power hungry consumer, industrial and IoT applications.
As Electronics Weekly notes, the burgeoning Maker Movement combined with the low-cost embedded board phenomenon has created a new playground for 8-bit devices. This “new relevance” has never been more apparent than with Arduino’s adoption of AVR MCUs, which can be found in its wildly-popular Uno (ATmega328), Leonardo (ATmega32U4) and Mega (ATmega2560) to name just a few.
The primary attraction of 8-bit MCUs is not only affordable performance, but with 8, 14 and 20-pin packages, they also are affordable and easier to use than their 32-bit counterparts.
Development tools are also matching the increasing range of higher performance applications for these MCUs as well. Take Atmel’s Xplained Mini 8-bit development platform for instance, which not only costs less than $9 but are also designed with an optional Arduino header for expandability.
The article goes on to reference IAR Systems, who recently updated its high-performance development tools for 8-bit MCUs. Just a few weeks back, IAR Systems and Atmel announced an extension of their ongoing partnership would include over 1,400 example projects in IAR Systems’ development tools to support Atmel’s entire portfolio. This allows designers using microcontrollers, like the 8-bit AVR, to leverage the Embedded Workbench C/C++ compiler and debugger toolchain with new example projects to bring their products to market faster.
In today’s world, the three pillars of security are confidentiality, integrity (of the data), and authentication (i.e. “C.I.A.”). Fortunately, Atmel CryptoAuthentication crypto engines with secure key storage can be used in systems to provide all three of these.
Focusing on the confidentiality pillar, in a symmetric system it is advantageous to have the encryption and decryption key shared on each side go through a change for every encryption/decryption session. This process, which is called symmetric session key exchange, helps to provide a higher level of security. Makes sense, right?
So, let’s look at how to use the capabilities of the ATSHA204A CryptoAuthentication device to create exactly such a changing cryptographic key. The way a key can be changed with each session is by the use of a new (and unique) random number for each session that gets hashed with a stored secret key (number 1 in the diagram below). While the stored key in the ATSHA204A devices never changes, the key used in each session (the session key) does. Meaning, no two sessions are alike by definition.
The video below will walk you through the steps, or you can simply look at the diagram which breaks down the process.
The session key created by the hashing of the stored key and random number gets sent to the MCU (number 2) and used as the AES encryption key by the MCU to encrypt the data (number 3) using the AES algorithm. The encrypted data and the random number are then sent (number 4) to the other side.
Let’s explore a few more details before going on. The session key is a 32 byte Message Authentication Code or “MAC.” (A MAC is defined as a hash of a key and message.) 16 bytes of that 32 byte (256 bit) MAC becomes the AES session key that gets sent to the MCU to run the AES encryption algorithm over the data that is to be encrypted.
It is obvious why the encrypted code is sent, but why is the random number as well? That is the magic of this process. The random number is used to recreate the session key by running the random number through the same SHA-256 hashing algorithm together with the key stored on the decryption side’s ATSHA204A (number 5). Because this is a symmetric operation, the secret keys stored on both of the ATSHA204A devices are identical, so when the same random number is hashed with the same secret key using the same algorithm, the 32 byte digest that results will be exactly the same on the decrypting side and on the encrypting side. Just like on the encrypting side, only 16 bytes of that hash value (i.e. the MAC) are needed to represent the AES encryption/decryption key (number 6). At this point these 16 bytes can be used on the receiving side’s MCU to decrypt the message(number 7).
And, that’s it!
Note how easy the ATSHA204A makes this process because it stores the key, generates the random number, and creates the digest. There’s a reason why we call it a crypto engine! It does the heavy cryptographic work, yet is simple to configure the SHA204A using Atmel’s wide range of tools.
Not to mention, the devices are tiny, low-power, cost-effective, work with any micro, and most of all, store the keys in ultra-secure hardware for robust security. By offering easy-to-use, highly-secure hardware key storage crypto engines, it’s simple to see how Atmel has you covered.
One of the companies that is best positioned to supply components into the Internet of Things (IoT) market is Atmel. For the time being most designs will be done using standard components, not doing massive integration on an SoC targeted at a specific market. The biggest issue in the early stage of market development will be working out what the customer wants and so the big premium will be on getting to market early and iterating fast, not premature cost optimization for a market that might not be big enough to support the design/NRE of a custom design.
Here is Atmel’s latest product in the SmartConnect family, the SAM W25 module
Atmel has microcontrollers, literally over 500 different flavors and in two families, the AVR family and a broad selection of ARM microcontrollers ad processors. They have wireless connectivity. They have strong solutions in security.
Indeed last week at Electronica in Germany they announced the latest product in the SmartConnect family, the SAM W25 module. It is the industry’s first fully-integrated FCC-certified Wi-Fi module with a standalone MCU and hardware security from a single source. The module is tiny, not much larger than a penny. The module includes Atmel’s recently-announced 2.4GHz IEEE 802.11 b/g/n Wi-Fi WINC1500, along with an Atmel | SMART SAM D21 ARM Cortex M0+-based MCU and Atmel’s ATECC108A optimized CryptoAuthentication engine with ultra-secure hardware-based key storage for secure connectivity.
Atmel at Electronica 2014
That last item is a key component for many IoT designs. Security is going to be a big thing and with so many well-publicized breaches of software security, the algorithms, and particularly the keys, are moving quickly into hardware. That component, the ATECC108A, provides state-of-the-art hardware security including a full turnkey Elliptic Curve Digital Signature Algorithm (ECDSA) engine using key sizes of 256 or 283 bits – appropriate for modern security environments without the long computation delay typical of software solutions. Access to the device is through a standard I²C Interface at speeds up to 1Mb/sec. It is compatible with standard Serial EEPROM I²C Interface specifications. Compared to software, the device is:
Edge nodes are becoming integrated into everyone’s life
As it says in the white paper:
On first inspection, the requirements of an IoT edge device appear to be much the same as any other microcontroller (MCU) based development project. You have one or more sensors that are read by an MCU, the data may then be processed locally prior to sending it off to another application or causing another event to occur such as turning on a motor. However, there are decisions to be made regarding how to communicate with these other applications. Wired, wireless, and power line communication (PLC) are the usual options. But, then you have to consider that many IoT devices are going to be battery powered, which means that their power consumption needs to be kept as low as possible to prolong battery life. The complexities deepen when you consider the security implications of a connected device as well. And that’s not just security of data being transferred, but also ensuring your device can’t be cloned and that it does not allow unauthorized applications to run on it.
IoT design requirements: Software / development tools ecosystem
For almost any application, the building blocks for an IoT edge node are the same:
Embedded processing
Sensors
Connectivity
Security
And while not really a “building block,” ultra-low power for always-on applications
My view is that the biggest of these issues will be security. After all, even though Atmel has hundreds of different microcontrollers and microprocessors, there are plenty of other suppliers. Same goes for connectivity solutions. But strong cryptographhic solutions implemented in hardware are much less common.
One protocol, and its descendants, drove the success of the World Wide Web. IP, or Internet Protocol, is the basis of every browser connection and the backbone of IT data centers. Some assumed that the Internet of Things would follow suit, with the thought that having an IP address would be a sufficient condition to connect.
The problem on the IoT isn’t IP – the problem is all the stuff layered on top of it. Running protocols such as HTTP, SSL, and XML requires significant compute power and memory space. The average PC, smartphone, or tablet has enough horsepower today to do that, but the average sensor running on a smaller microcontroller does not. (ARM Cortex-M7 notwithstanding.)
To combat that, the industry has spawned a huge list of alternative, mostly non-interoperable IoT protocols. A partial list: 6LoWPAN, AllJoyn, AMQP, ANT+, Bluetooth, CoAP, DASH7, DDS, INSTEON, KNX, MQTT, NFC, RFID, STOMP, Thread, Weightless, XMPP, ZigBee, and Z-Wave. New consortia are popping up weekly with more ideas.
Searching for an IoT “god protocol”, one unifying end-to-end protocol serving all things, is silly. At one end, sensors have different requirements such as range, RF spectrum, security, topology, and power consumption. At the other, any successful IoT strategy will ultimately need to integrate with an IP-based cloud in some form. Greenfields of any scale rarely exist. IoT applications need to connect and exchange data.
The answer is building a multi-protocol bridge between sensors and actuators, mobile devices, and the cloud. Ideally, code would be open source, and would provide scalability to span a wide range of devices in large numbers. Additionally, transport would be reliable, surviving brief intermittency in wireless connections.
More and more organizations are embracing MQTT as part of the bridge. MQTT offers a full-up version running over TCP/IP, and a slimmed down version MQTT-SN for non-IP devices. Its publish/subscribe model allows topologies to scale while retaining real-time characteristics and configurable quality of service.
IBM started the whole MQTT movement as a message broker for mainframes and servers, with integration into WebSphere for web services. They then opened it up for embedded use in a release to OASIS and the Eclipse Foundation.
A big piece of IBM Bluemix is the IoT Foundation, a cloud-based instance of MQTT with predefined topic structures and message formats. Mobile apps are already using MQTT, with applications such as Facebook Messenger and Salesforce.com. IBM also has an e-book on MQTT in mobile.
Other recent developments to consider:
ARM’s mbed device server seeks to replace a generic web server with one tailored for the IoT. Built from technology in the Sensinode acquisition, ARM has brought HTTP, CoAP, and MQTT together in one platform.
2lemetry has taken that a step further with ThingFabric, integrating protocol actors including MQTT, CoAP, and STOMP, along with extensibility.
PubNub has taken a websocket connections approach running over MQTT, focusing on low latency, reliable delivery from a cloud implementation. There is a good PubNub guest post on Atmel Bits & Pieces describing the approach.
Open source motivates many folks, and one of the more interesting individual projects out there is a bridge for AllJoyn to MQTT. If successful, the implications could be significant, such as controlling home entertainment devices directly from Facebook on a mobile device.
Again, I don’t think there is a “god protocol” that will take over the IoT once and for all, satisfying each and every use case. The winners are going to integrate multi-protocol bridges to serve as wide a range of use cases as possible. The ability of MQTT to connect sensors and mobile devices to big data systems in real time is drawing more participants in.
This post has been republished with permission from SemiWiki.com, where Don Dingee is a featured blogger. It first appeared there on November 5, 2014.
“My goal was to implement a subset of the little-wire functionality to control a WS2812 LED by USB. This takes 3 I/O lines, which is exactly the number of free pins on the ATtiny10.”
As Tim notes, little-wire supports a number of functions to control WS2812 LEDs on arbitrary I/O ports. However, he simplified this approach by only supporting a single LED on a specific pin, while still retaining protocol compatibility. Meaning, all the little-wire host programs were still functional, with the finished device fully capable of being used as an RGB indicator LED similar to the Blink1.
“The V-USB USB interface requires more than 1.5kb of flash in its smallest implementation and uses more than 50 bytes of RAM, including stack usage,” he explained. ”Additional code is required to implement the little-wire interface and to write to the WS2812. The ATtiny10 has 1kb of flash, 32 bytes of SRAM and 16 instead of 32 registers. So this ended up as a nice exercise in cutting down V-USB to its bare essentials – and further.”
One critical step towards reducing the memory footprint, Tim admits, was adopting an interrupt-free implementation of V-USB, as developed for micronucleus. This allowed him to lower the SRAM footprint by omitting register saving on the stack and avoiding double buffering — all while facilitating the reduction of program size.
Further measures to reduce code size include clocking the controller at 12 MHz (using the internal RC oscillator), manually remapping numerous registers in V-USB to avoid collisions with the GCC, removing all handling of the reset signal on the USB-Bus and altering the code to support replies from the SRAM.
Final stats?
Flash: 988 of 1024 bytes used (96.4%)
SRAM: 28 (variables)+2 (stack) of 32 bytes used (93.8%)
“This is most likely the most complex firmware ever loaded into an ATtiny10,” Tim added. “[Plus], it also works with the new 8mm WS2812 LEDs.”
While ARM TechCon 2014 may be a thing of the past, product releases, discussions and trends from the show floor continue to make their way forward. Case in point, Design World’s Aimee Kalnoskas recently sat down with our very own Kaivan Karimi to discuss the building blocks of the ever-growing Internet of Things in a candid post-TechCon interview. During the conversation, the Atmel VP and GM of Wireless Solutions shares his insights and adds flavor and some color to this ‘thing’ commonly referred to as IoT. You can read the entire interview — which was brought to our attention by our friends at ARM and whose original article can be found here — in its entirety below.
AK: What do you think the IoT infrastructure looks like? How does it compare to the current communications infrastructure?
KK: The first thing we must do is to define the IoT industry infrastructure properly – what kinds of devices are connected and how are they connected. We then define the infrastructure of IoT services to determine what the weak points within this infrastructure and how do we resolve them.
First, let us define the weak points. For a while, the cellular operators where the ones claiming that IoT was all about cellular “telemetry-like” services. In IoT, most “things” will be battery operated, requiring long battery lives. But if you assume a cellphone tower is making the connections through an LTE modem with less than two days of battery life, then you can see why edge nodes of IoT have practically nothing to do with cellular. Additionally, IoT is all about secure low data rate command- and control- type of communications, but cellular generally is not. The fact is that by the time IoT services role out, cellular pipes will only carry about five to 10 percent of the WAN traffic. There are many reasons why cellular is the wrong pipe.
IoT communications infrastructure would be based on a “smart” box inside of the home or premise –hierarchical gateways – but not the access points of today. Today’s access points only switch, route and collect information upstream or retrieve it from downstream. For IoT, there will be a new generation of smart gateways that will have intelligence on board to process the information, make decisions, and disperse that information. This “smart gateway” functionality could be an add-on to the existing access points or set-top boxes, or could be a standalone box, but the bottom line is that the “intelligence” will move to the customer premises versus only in the cloud today.
A smart gateway accesses the cloud using various WAN communication technologies, which would be different than BAN/PAN/LAN connectivity technologies used inside the home or on premise. Due to the variety of end segments IoT covers, the smart gateway can be installed anywhere, depending on the use case and application within a given IoT segment.
For example in a smart-highway use case, the gateway is inside a shiny cabinet on the side of a bridge, communicating with tiny seismic sensors (microphones) positioned on the bridge. In the Western world, we have an aging infrastructure, with multiple incidents of collapsing bridges in the past few years. Each of these inexpensive seismic sensors can generate a ping every 30 seconds measuring the integrity of the bridge every 30 minutes or so, and ensure against future bridge collapses.
In this case, communication from the sensor to the gateway or the box is short-range. That can be one of the many 802.15.4 (mesh) technologies such as ZigBee, 6LowPAN, Wireless Hart, etc. Communication through the gateway to the cloud, on the other hand, is WAN connectivity such as Fiber/Ethernet through local networks, cellular, satellite, PLM/PLC, or the next generation of IoT pipes in sub-GHz bands such as SigFox, Weightless, etc.
AK: What’s the role of the smart gateway with regards to provisioning a service?
KK: Think about how you create value as a service provider. It’s this idea of service provision. You need to be concerned not only about connecting the widget but the service delivery frameworks that sit on top of that connection and manage the overall system ensuring quality of service, as well as security of the service.
Smart gateways are key drivers for IoT communications. For instance, a smart gateway in a home could involve communication between thermostats to the gateway box but there is little value in simply connecting these widgets. You need to create a tangible value – the box needs to provision the IoT service. Also note that not everyone is technology savvy enough to program these connections….something we usually lose sight of in Silicon Valley. It needs to become foolproof so that a non-techy can use it just as easily. Again, service providers will play a key role in that.
There is a belief that the IoT edge nodes will generate massive amounts of data and this will all go to the cloud, so you need a lot of bandwidth, a lot of storage space, and data management in the cloud. This is a big fallacy advertised by the people who make money from big bandwidth or cloud storage.
Let’s illustrate what we mean here: For example, consider a thermostat in your home set between 73 and 75 degrees F. A sensor comes on every few seconds and notes what the temperature is. The gateway box gets that information and registers it but it doesn’t need to send it to the cloud because that’s not necessary (not a “cloud-worthy” event). The gateway captures the event from a certain time span and simply registers it – say from 1:25PM to 1:45PM it was 74 degrees F. Now, if the sensor communicates to the box that the temperature has gone to 76 degrees F, then the box activates the air conditioner (actuates). But it still doesn’t need to go to the cloud.
At some point, the thermostat might reach 90 degrees in a couple of readings and then, two intervals later, 110 degrees. The box determines that this is not a false reading but, perhaps, an event and alerts the smoke detector to the event. Smoke sensed by the device confirms the event.
The gateway then communicates this information to the cloud and an emergency call is triggered to the fire department. Test have shown that in a scenario like this, when the sensor device (i.e. thermostat) and gateway are involved, you shave about 15 to 18 minutes of police or EMT-response time off of an otherwise manual 911 call. This event is an exception that goes to the cloud right away. Think about how often someone’s house catches on fire, and you see that indeed this is an exception and not the rule.
In a mobile health (mHealth) application, you could monitor heart rate or check other biometrics with the gateway box perhaps every five minutes. The sensor simply delivers the information to the box as opposed to the scenario where a healthcare worker checks in with a patient every few hours and spends less than three seconds checking vitals. If you are monitoring a potential heart attack patient and the vitals are within range, then the box records the event as satisfactory. But if the patient is having a heart attack, that is an exception to the event and the box calls the hospital.
The bottom line is that it is not necessary to be continuously communicating to the cloud. Because you upload metadata and not all the data at scheduled intervals, you consume far less bandwidth and power.
AK: What are the real or perceived challenges with adding connectivity to devices for IoT?
KK: The reason the industry has challenges is that most wireless-device connectivity technologies (i.e. Wi-Fi, BT) traditionally have been designed for cellular, enterprise, and data communications. In these applications, the device is always on so the off state is not a consideration. These are also data-intensive applications that demand bandwidth to carry the data. However, IoT devices such as the tiny sensors in thermostats, smoke detectors, or entries to a house, or those sensors on the bridges, or moister sensors in a farm, for example, are almost all battery-operated devices and spend most of their time in sleep or off condition.
If you architect it the traditional way then, yes, you will have power-consumption issues. In IoT, the total cost of ownership is extremely important, due to the large number of devices that will be deployed. Hence, it is not cost effective to send technicians out into the field to change batteries on these devices every four to six months. In consumer applications, the batteries need to last between four and five years, and in industrial anywhere from eight-12 years. What we need for IoT communication devices is a new generation of wireless connectivity solutions, built from the ground up for IoT applications and battery operation. Implementing Wi-Fi in an IoT application cannot be about simply retrofitting from another market where power consumption is far less of a consideration and using it now for IoT, which most vendors are doing today.
Connectivity in IoT is a new way of doing things, hence you need to enable additional modes of operation (including deep-sleep modes) from a software and device-architecture perspective. You also need to enable very fast shut down and wake-up time, as well as partial memory retention to bring the device back to a known state of connection with the least leakage current possible.
One size does not fit all in IoT connectivity and a broad portfolio is required. If a vendor does not have multiple wireless technology capabilities, they cannot offer a complete solution. Simply because you don’t have expertise in a technology or IP, does not mean that the technology is not applicable. Even in 802.15.4, you use ZigBee for lighting and use 6lowPAN for home automation, but you may also need Bluetooth Smart and/or NFC for secure pairing in a multimode solution.
AK: What role do microcontrollers play in this market?
KK: From an architecture perspective, IoT devices are smart devices and what makes them smart is the tiny MCU. All IoT edge nodes include an MCU or MPU, connectivity, sensors and sensing platforms, and an energy source. About 85 percent of IoT devices use MCUs, and the rest will use MPUs. Design an MCU into a toaster oven with a user interface and you can control it in a more predictable and systematic manner. It now has become a “smart” toaster. Add the appropriate connectivity and you can now communicate and control that smart toaster remotely. And because these devices are sleeping most of the time, they benefit from the nonvolatile memory (FLASH) in many MCUs. When the power is off, the device’s memory retains the content.
That’s why thousands of application developers are turning to MCUs. Maker movements are the perfect example of how MCUs in the hand of smaller players are fueling the innovations on the edge node side of IoT. There were nearly 17 billion MCUs sold in 2013 alone and approximately 170 to 200 billion over the past 10 year. Most of these were never connected wirelessly or networked in the traditional sense of “networking”. Suddenly, MCUs are becoming even more popular because they are the intelligence behind IoT devices. They will go into the sensors which connect to gateways which connect to the cloud, yet a lot of MCU developers don’t necessarily have the expertise in connectivity, networking, and security.
AK: How will the industry address the learning curve of designers who must transform a previously non-IoT device into an IoT device?
KK:It’s true that many of the current MCU developers are not security and connectivity experts and that is a challenge. Remember that the majority of IoT – about 95 percent – is industrial IoT which is a wide application spread out among thousands of small- to medium-sized companies. These SMEs aren’t in a position to hire another couple of dozen people simply for connectivity and security expertise. As an MCU supplier, you need to understand MCU designers and the fact they are using products without the full expertise needed to optimally use connectivity and security.
At Atmel, we have over 40,000 MCU customers. With that many customers, we have had to learn how to sell in a no-touch fashion, leveraging our tools and development environment. I believe we will measure success in the IoT market by how well you can get to the point with mass market MCU developers where they can “consume” connectivity and security in a no-touch fashion without needing to become experts at it.
AK: What types of companies stand to benefit the most from IoT and why do you feel the Maker community is a key component to success?
KK: There are two sets of players in the IoT market: the traditional MCU companies who have the channels and reach into the mass market, and the traditional wireless connectivity companies whom I call “elephant hunters” since they have traditionally been focused on tens – not thousands – of customers. Most traditional MCU companies don’t have the level of connectivity expertise or the IP required, or their understanding of “things” is elementary. On the other hand, connectivity companies while they have rich connectivity know-how, don’t have the channels and mass market reach or expertise – an absolute must have for this market. Loyalty in channels takes years to develop, and is not an overnight situation into which you can buy your way.
Based on the dynamics of the edge nodes where billions of devices are to be developed, I believe it is the MCU guys who are at the center of IoT-device development. The MCU player that can provide a broad range of MCUs and MPUs, and simultaneously a full portfolio of connectivity solutions (including Wi-Fi which is the toughest nut to crack between all short-range connectivity technologies), will be the winner and capture this market.
Just as in nearly any other market, the majority of innovation in electronics came from small players. Because IoT is so wide and has so many different segments involved, there is the potential for thousands of starts ups to innovate.
Importantly for IoT, smaller players heavily equates to the Maker community. There are over 1.3 million Arduino users, and of course our partnership with them has made our MCUs prominent on Arduino platforms. You simply can’t establish these this kind of community, allegiances, customers, or critical channels overnight. It’s a 10- to 15-year investment. As an example we have 680,000+ AVR freaks in our community. How long do you think it will take for a newcomer to develop a technology community of that size?
Atmel is committed to becoming the number one fully-integrated edge node provider in the world through an expanded MCU and MPU portfolio, sensing platforms, full IoT communications technologies built from the grounds up for battery operations, integrated security, and a whole host of software offerings related to service delivery and provisioning. Along with this we are establishing a robust ecosystem of partners that can jointly provide full IoT system solutions from the tiniest edge nodes to the service providers in the cloud seamlessly.
At each step along the way, we are bringing innovation, ease-of-use, and integrated solutions to conserve power, extend battery life, ensure data security, and conform to wireless standards in the next big connected design. It’s our way of powering the possibilities of next-generation ideas. Get started today enabling a smarter world of tomorrow!
In the final segment of my interview with AVR microcontroller creator Vegard Wollan, I asked about his background and innovation at Atmel.
In response to my question of how he views his expertise, Vegard noted that he started out as a computer architect and digital designer. It’s simple to see the ease-of-use DNA in the AVR product line when Vegard then noted that he soon saw himself as someone that could make life easy for embedded designers. I think this focus on the customer pervades all of Atmel to this day.
Vegard Wollan reflects on his history of innovation at Atmel.
I went on to ask Vegard what he does in his spare time. His response? Exercising and boating off the beautiful, dramatic Norwegian coastline. I think physical activity is a key thing. In fact, I wish someone had warned me as a young man that engineering has an occupational hazard. You can make a good living sitting at a desk. This was less true when I was an automotive engineer, as I had to go the experimental garage and walk around Ford’s giant complex in Dearborn, Michigan. Nowadays, we all seem chained to a computer, and stuck in a chair all daylong. So, exercise and boating sounds like a great way to stay active and balance our lives a little bit!
As I pictured Vegard sailing around Norway looking at beautiful sunsets, I wondered if that was inspired him to be so innovative. He responded that the primary source of innovation at Atmel is working with a team of creative innovative people. I think this is true in most human endeavors. When I asked my dad why some restaurants had really good service, he noted that good people like to work with other good people. That is why Vegard is spot-on, and quite humble in noting that innovation comes from a team, not any single person.
