Tag Archives: engineers

RIOTing with the Internet of Things

RIOT is an open-source operating system (OS) designed to power the rapidly evolving Internet of Things (IoT).

Licensed as LGPL, RIOT was initially developed by FU Berlin, INRIA and the HAW Hamburg. 

Indeed, the origins of RIOT can actually be traced back to FeuerWare, an operating system for fire crews and their wireless sensor networks.

The operating system — which is based on a microkernel architecture — supports both C and C++, as well as full multi-threading and real-time capabilities. RIOT provides utilities like cryptographic libraries, data structures, or a shell, different network stacks, and support for various microcontrollers, radio drivers, sensors, and configurations for entire platforms.


The RIOT runs on both 16-bit and 32-bit hardware, with a native port allowing RIOT to run as a Linux or MacOS process. This helps facilitate the use of standard development and debugging tools such as the GNU Compiler Collection (GCC), GNU Debugger, Valgrind and Wireshark. RIOT runs on several platforms including embedded devices as well as common PCs, and supports multiple drivers, which offers out-of-the-box usage. The hardware dependent code is reduced to a minimum and abstracted from the kernel itself.

Among the architectures RIOT supports are ARM Cortex-M0, -M3 and -M4, as well as the ARM7. Subsequently, the IoT operating system is compatible with a number of boards like the Arduino Due (SAM3X8E), the Atmel ATmega2560 and the Nordic nRF51822 (ATSAM3U2C). RIOT also provides multiple network stacks, including IPv6, 6LoWPAN and standard protocols such as RPL, UDP, TCP and CoAP.


Simply put, RIOT is free software, meaning Makers and engineers can redistribute and modify the OS. Software developed by the RIOT community is available under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, version 2 (LGPLv2).

Interested in learning more? As a community project, you can find RIOT’s source code on GitHub as well as download its latest release here.

8- or 32-bit, that is the question…

Writing for Electronic DesignAtmel’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 upswing in 8-bit devices, like the incredibly popular Atmel AVR lineup, clearly highlights that there must be some compelling reasons to use an 8-bit device in place of a 32-bit MCU. The recently-published Electronic Design article looks to shed some insight as to why 8-bit devices are retaining market share.

Essential Differences

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.


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



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.

Interested in reading more? Be sure to check out the original article from Electronic Design here.

When it comes to firmware, when in doubt don’t leave it out!

Product design teams endeavor to plan the safe launch of electronics products to prevent re-discovering issues that should have been learned from the previous project. Many Serial Electrically Erasable Programmable Read-Only Memory (SEEPROM) users have never utilized such components and therefore may not have knowledge of potential issues. Here is a personal story from several years ago when I was asked to support a customer working on an issue on a weekend. (You may have already guessed that the call came to me that weekend was from my boss’s boss’s boss.)


Here’s the issue that was described to me over the phone by the customer engineers (hardware and firmware) while they were in their laboratory troubleshooting:

We exchanged emails with DSO (digital storage oscilloscope) captures of the serial protocol after which I would request another DSO capture or two. Once we were drilling down to the issue, a customer firmware engineer held the phone line while the customer hardware engineers made more measurements. The customer firmware engineer asked me, “Why would someone drive the SEEPROM /CS signal low (true) and then back high (false) with no clocks or data in?”  I quickly whipped out, “That is a chip select toggle that is utilized to recover from power interruption of the host microcontroller or from a protocol violation, and we have a Juraasic period FAQ about that buried deep in our website.”  The customer firmware engineer said, “Uh oh, I didn’t know why anyone would do that, so I took it out.” Soon, the hardware engineers emailed me a DSO capture showing a protocol violation and then no communication from the SEEPROM. I announced that the firmware engineer has the solution to this issue and should be able to produce a new firmware build to mitigate this situation in the future.

Several product lines were brought to a standstill because the task to reduce firmware lines of code took precedence over why the code was there to begin with. Numerous engineers (including myself) have worked weekends unnecessarily. The moral to the story is that if you have product firmware that communicates properly with an Atmel SEEPROM and you do not know why a few lines of code exist, then you may want to ask yourself about the expected benefit of modifying that code before you throw the baby out with the bath water. Sometimes things are there for a reason that may not be all that obvious.

Stick to the adage: “When in doubt, don’t leave it out.”

Oh, and one more thing… Please comment your firmware source files adequately to help the next firmware developer. Remember that person may just end up being a future version of you!

This blog was written by Clay Tomlinson, Atmel Staff Applications Engineer 

Production is underway for the Makesmith CNC router

Over the summer, the Makesmith CNC desktop router successfully raised over $82,000 on Kickstarter, well exceeding its initial $10,000 goal.

 Designed by Bar Smith and Tom Beckett, Makesmith uses off-the-shelf parts to put viable CNC technology into the hands of engineers, DIY hobbyists and Makers.

“Our CNC router employs a two or three dimensional computer model of an object and very precisely mills, cuts, or shapes the object out of any soft material. This low-priced high-quality desktop CNC router cuts intricate and accurate pieces,” Smith explained.

According to its creators, the machine allows an individual to shape objects that would otherwise be too tedious, difficult, or impossible to complete by hand. The router is well-equipped to cut through wood, plastic, foam and a number of other soft materials.

Although the Makesmith does not cut metals, the machine is capable of easily carving basic red bricks.

Aside from Atmel’s ATmega328 MCU, key specs include:

  • Custom closed loop controller
  • 9.2in x 8.7in x 1.9in workspace (234mm x 221mm x 48mm) (cutting/working area)
  • 12in x 14in x 14in machine size (dimensions of the entire machine)
  • 0.00005in (.001mm) minimum step size (the minimum amount the machine can be instructed to move)
  • 0.1mm – .5mm repeatability depending on feed rate and material (the ability to return to the same spot after a process; accuracy)
  • 5in/min (127mm/min) maximum feed rate (the rate it can move in any one direction)

“The kit contains EVERYTHING you need to put together your own desktop CNC router except the dremel,” Smith added.

Those who pledged their support of the router “will receive a complete set of laser-cut parts to construct the frame and moving parts of the router, all the necessary metal hardware, an Arduino-compatible microcontroller, three continuous rotation servos and three magnetic encoder boards, and all of the requisite bolts and wires. To assemble your kit you will need a soldering iron (previous soldering experience is not necessary) and some glue. You should be able to put your kit together in just a few hours,” the Makers write.

Good news backers, production is well underway! Those wishing to follow along with the team’s latest updates can head here.


TinkerForge launches Atmel-powered IoT starter kit

Designed by TinkerForge, the Atmel-powered Starter Kit: Internet of Things allows Makers and engineers to easily control multiple home automation devices across a wide range of devices, both locally or over the Internet.

More specifically, the Starter Kit can be used to control 433MHz mains switches, dimmers and home automation components.

“With the API Bindings it is possible to control the wireless actuators with any (embedded) PC, smartphone or tablet over the Internet,” a TinkerForge rep explained in a recent product post.

“With the kit, nothing stands in the way of turning your coffee maker on while you are heading home or to dim your living room illumination with your own cloud. [Plus], the IoT Starter Kit website gives you direct access to wireless actuators from any web-enabled device.”

The IoT kit comprises a USB-equipped Master Brick powered by Atmel’s ARM-based ATSAM3S4C MCU and a Remote Switch Bricklet (+ antennae), the latter of which features a 433MHz transceiver.

Additional kit items include:


1x Bricklet cable 6cm
  • 1x Remote switch Bricklet case
  • 1x USB cable 180cm
  • 1x Mounting kit 12mm
  • 1x Mounting kit 9mm

“Over the USB connection of the Master Brick you can control remote control mains switches or similar. An (embedded) PC either does the switching itself or it can serve as a gateway,” the rep added.

“With an additional Ethernet Master Extension it is possible to go without a gateway.”

It should also be noted that TinkerForge is offering a number of shields or bricklets for its IoT starter kit, including a motion detector, temperature IR/PTC, ambient light, GPS and hall-effect.

Interested in learning more about the Atmel-powered Starter Kit: IoT? You can check out the product’s official page here.

ATmega328 external serial monitoring – sans PC

Serial monitors are typically used to help Makers and engineers more easily debug their projects.

However, as HackADay’s Will Sweatman notes, traditional serial monitors require a PC or laptop loaded with a terminal program.

“Most of the time this is not an issue, because the PC is used to compile the code and program the project at hand,” Sweatman explained.

“But what if you’re in the field, with a mission of fixing a headless system and in need a serial monitor? Why lug around your PC when you can make your own external serial monitor?”

And that is precisely why ARPix designed a barebones, albeit fully functional serial monitor around Atmel’s versatile ATmega328 microcontroller (MCU) and a 102 x 64 LCD display.

Although the minimalistic platform lacks a keyboard port like some other external monitors, tact switches facilitate access to the user interface (UI) for start and stop commands. As expected, the tact switches can also be used to set the baud rate.

Interested in learning more? You can check out the project’s official Instructables page here, which offers the relevant sketches and parts list.

Atmel kicks off Simply AVR Design Contest (stage 2)

Back in September 2013, Atmel launched the first stage of its AVR Hero Maker Faire Contest, which challenged Makers, designers and engineers to develop new AVR-powered devices and platforms with commercial potential. 

Winners for the first stage of the contest included Sumit Grover and Rahul Kar (two runner up prizes) from India and Juan Luis Gonzalez from Mexico.


The grand prize winner? Pamungkas Sumasta from Indonesia, who designed a slick Inertial Mobile Phone Unit.

Earlier this week, Atmel launched stage two of its Simply AVR Design Contest. Targeted at engineers, Makers and DIY hobbyists, the contest invites participants to create ground-breaking microcontroller-based designs using Atmel’s wildly popular AVR MCU lineup.

The Simply AVR winner (first prize) will receive $1,500 in cash as well as coverage on Atmel’s social media channels: Twitter, Facebook and Bits & Pieces. Each of the four runner ups will claim a $500 cash prize, along with coverage on Atmel’s various social media channels.

Interested in submitting your design or voting for others? Click here to sign up and vote.