Category Archives: Application Highlights

IR reflow oven for your prototype PCBs

When you use solder paste to assemble your prototype PCB (printed circuit board) you need a stencil or hypodermic needle to apply the paste to the pads on the board. Then you use an IR (infra-red) reflow oven to melt the solder. Scott Fritz, an Atmel IC designer on the third floor, found this neat home-made controller that turns a cheap toaster oven into an IR reflow oven. I assume the name Reflowster is a combination of the words “reflow” and “toaster.”

The Reflowster will do closed-loop control of a cheap toaster over so you can do IR reflow soldering on your prototype circuit boards.

The Reflowster is an Arduino-based controller that that gives you predicable and repeatable heating and cooling profiles to melt the solder paste and connect up all the components on your board. They got their start on Kickstarter, and have actually shipped, so all the Kickstarter people are rewarded. Now the Reflowster folks are starting to offer the product to the general public.

The Reflow controller V3 PRO from PCB POOL in Europe is another product meant to work with a toaster oven.

I have mentioned a similar reflow controller made by the fine people at PCB-POOL in Europe. That article also described how my buddy Wayne Yamaguchi was using a toaster oven a decade ago to make his PCBs. Wayne did not use a controller. He just did a whole bunch of tests until he was satisfied he was getting good whetting and solder fillets on his circuit boards.

The great thing about the Reflowster is that it is a closed-loop controller. It is actually measures the temperature of the oven, and then controls the power to it so that the heating and cooling match the profiles recommended by component makers like Atmel (pdf).

Precise temperature control is needed to do quality lead-free soldering.

While I love, admire, and respect my buddy Wayne Yamaguch’s “theory of experiments” approach, you might really need the Reflowster. If you want to use different ovens, or have changing wall voltage, or the boards you are soldering are different sizes or have a different set of components on them, you want a closed-loop controller. If the chips have a big pad on the bottom, the die-attach-paddle, you need reflow. The other big factor is lead-free solder. Many of the crazy analog engineers I hang out with still use tin-lead solder for prototypes. It looks better, it feels better, and lead solder is more reliable. We also pull the solder off the reel by biting it gently and tugging, so we don’t have to set the soldering iron down. Lead poisoning might explain why we are all crazy. But if you are sane and insist on using lead-free solder, the preciseness of reflow control is important.

Solder-stencil-squeegee-Wintech-Electronics

Solder paste application is like silkscreening T-shirts. Instead of silk the stencil is stainless steel. Instead of ink you use solder paste. Instead of T-shirts you do printed circuit boards.

Solder paste has its own hassles. You should refrigerate open containers so the little solder balls do not oxidize and change the reflow parameters. I am not sure the same caveat applies to when you use a big hypodermic to apply the solder paste. There the hassle is you have to do it one pad a time. A solder stencil is a thin stainless steel sheet where the PCB fab house has etched through all the areas where there is supposed to be solder. Sometimes called the “cream layer” Its not exactly the solder mask art, but it is pretty close, depending on your particular design. I know you can set up OrCAD 9.2 to do it, and I am sure other CAD packages can make it, or the PCB fab house can create one from your solder mask layer art.

Here is a typical solder stencil from Stencils Unlimited. With one swipe of a squeegee you apply solder paste to the pads for your chips and passive components.

The fine folks at Sunstone used to offer a free stencil, now it looks like they charge a little. Most fab houses can supply one. Assembly houses like Screaming Circuits or Advanced Assembly have the relationships with board houses to they can make your stencil when they assemble your boards. If you are really masochistic, and have a high-powered CO2 laser cutter handy, you can make your own stencils. You can also live in a cave and use flint tools, but I prefer to operate a little higher on the food chain. The LPKF laser mill can make your stencils as well.

This solder stencil from Proto-Advantage lets you apply solder paste for a QFN-32 chip.

There are also hybrid approaches. You can buy cheap solder stencils just for high-pin-count chips on your board. You squeegee the solder paste onto the board for each of those parts, Then you can use a hypodermic for the passive components or hand-solder them after you reflow the big chips.

If you are a big-time engineer on a big-budget project then just contact Screaming Circuits or Advanced Assembly or you local board assembly house (not PCB fab, but board assembly). I know Screaming Circuits can do it all since they have teamed up with Sunstone and Digi-Key. Just send Screaming Circuits the fab Gerber and fab files which they send to Sunstone, the assembly drawing and insert file which they use themselves, and the BOM (bill of material) they order the parts with from Digi-Key. They can do quick-turn and they can ship anywhere in the world.

So the prototyping ecosystem is like this:

If you are a hobbyist use DIP (dual-inline plastic) chips with 0.1 inch lead spacing and through-hole passive components. You might use surface mount chips on DIP breakout boards.
If you are a pro-hobbyist or low-budget engineer buy a temperature-controlled Weller soldering iron or a Metcal and a good stereo microscope. Now you can hand-solder surface mount boards. For chips with bottom pads you have to either heat the whole chip with a big soldering iron, use a heat gun, or try to wick the solder in from vias you design in on the backside of the board.
If you are a hobbyist doing low-volume manufacturing or a medium-budget engineer, go to solder stencils and reflow ovens.
If you are a hobbyist that hit it big or a big-budget engineer, use the board house to order the parts, get the PCB fab, and assemble and maybe even test your board.

TQM Solutions knows that total quailty managemnt means you not only have a mountain of documentation, but that you organize that mountain.

TQM Solutions knows that total quality management means you not only have a mountain of documentation, but that you organize that mountain.

Note that last item. See, as an engineer, your real job is to make a set of documentation so the design can get manufactured by non-engineers and non-technicians and non-hobbyists. Its nice you are a hands-on person. Heck, its critical you are a hands-on person to be a good engineer. But your real responsibility is making sure the CAD files are correct. it might speed things up if you make a first-spin board yourself, and its neat if you make the board on an LPKF mill and you can get parts from the factory floor or Radio Shack or a salvage yard.

Salvage-yard-electronics-Weird-Stuff-Warehouse

I used to design products with parts I found cheap at places like Weird Stuff Warehouse in Silicon Valley. Then one of my designs went to production but Weird Stuff had sold off all the parts I had used. Now I select parts from distributors.

The great thing about using Screaming Circuits and Sunstone and a distributor like Mouser or Arrow or Newark or DigiKey is that you are proving out your documentation. You make it clear to Screaming Circuits that if your pick-and-place insert file has mistakes they tell you, you fix them and they use that file. This way, when they see that the part origin for a DPAK is at the pad and not the part center, they know the vacuum picker cannot pick it up, so you catch that AND FIX IT. If your Gerbers have problems you make sure Sunstone tells you, or you use the free DFM (Design for manufacturing) check offered by Advanced Circuits. Then you FIX THE FILES. Same deal for any BOM mistakes. Make sure somebody tells you so you can FIX THE FILE, and not the text file, you fix the CAD file in OrCAD or Altium or whatever, so it spits out a perfect BOM.

Now when you send the CAD files to China to get assembled on the cheap, you know the files are correct. Anything less and you are not an engineer, you are an amateur. Proto Express even works with a Chinese partner to ensure you can get cheap-high volume boards that work as well at the Proto-Express boards made right here in Silicon Valley.

The oqo Model 2 used a Via processor. The third model with an Intel Atom never got built since they ran out of money (courtesy Engadget).

This level of diligence and exactness is critical. I worked at oqo, a San Francisco start-up that made the first palm-top computer that ran real Windows OS. The first model was based on the Transmeta “emulated” x86 processor. The second model used a Via chip. Lesson there is never base a business plan on being smarter than Intel. The third prototype never went into production. I had left the company for National Semiconductor, but pals there told me they used an Intel Atom processor and it was a real product that could really work good. But they were running out of money. So I assume in a big rush, they sent the design to the Chinese contract manufacturer. A pal familiar with the company told me oqo had to fly out an engineer to China and there were 1000 ECOs (engineering change orders) to get the design ready for high-volume manufacturing. One thousand mistakes. Now it probably didn’t matter, but its nice to think that if they had scrubbed the CAD files, the fab, the assembly, and the rework documentation through a US quick-turn prototype manufacturer, and fixed most of those mistakes, then maybe they could have gotten that product to market and saved the company.

This is a perfect example of the asymmetric respect problem in engineering. The Chinese manufacturing engineers respected those high-tone former Apple designers at oqo. But the oqo engineers may have thought manufacturing was some triviality and beneath them. Perhaps they thought any idiot should be able to do it. Sorry. Wrong. Dead wrong. Dead just like oqo is today. You need to be every bit as smart, clever, and creative to do manufacturing and test as to do design work. When you take a product all the way to production, you will learn to respect everybody involved. Respect the planners, the clerks, the assemblers, and ALL the engineers. So be a good and respectful design engineer and make sure your CAD files are a good as they can be before you send them out for production. That is your responsibility, not a Flextronics responsibility.

The cover of my mentor Bob Pease’s book Troubleshooting Analog Circuits has one of his “airball” prototypes on the cover. Application engineers like Bob can do proof-of-concept, but don’t try sending this out for high-volume manufacturing.

So like all things, prototyping has an analog continuum to it, There is a place for quick-and dirty hacks. There is place for super-diligence. And there is a whole spectrum of tradeoffs for an appropriate design effort in between those poles. Just don’t do some rush-job today that you just know will bite you a few months later.

[Update] I showed this post to Wayne Yamaguchi and he had this great comment:

“One of the major drawbacks to solder paste is the shelf life. No matter how you buy it, the container and contents will go bad in about 6 months time, even in the refrigerator. It’s the flux that ages and slowly solidifies making the reflow consistency different over time. It’s just a real pain to dispense the paste with a tiny-tip syringe when it it’s fresh, and even worse when it has aged a bit. If I recall correctly, the smallest syringe runs about $50.00. You can solder a lot with that but if you only make one proto this is an expensive proposition.

“Mine tends to absorb water over time and this makes it pop when reflowing, blowing off chunks of solderpaste in all directions. I can hand-solder 0402 and DFN parts with the soldering iron. I only need the hot-air station for pads that are not exposed, like power pads and some SMT inductors. I would recommend a really good soldering iron or two, and a general-purpose hot air station if you want to hand-solder small runs of boards. You will need one with a 0.2mm tip or smaller for the leadless and 0402 parts.

“I prefer to still use leaded solder. It solders at a lower temp and the chemicals are less caustic, unlike the solder flux used for leadless solder. Unless I have to, I try to use “no clean” flux and occasionally will use Kester 331 (IIRC) for gold-plated pads.

“Good stencils are cut non-vertical. The edges are beveled so the bottomside is slightly larger than the top, making the solderpaste less resistant to sticking to the stencil. Hopefully, when you lift the stencil the solderpaste adheres to the PCB and not the stencil. I’ve never actually seen the process, but, I always imagined that the paste would not all tranfer. I guess it works. Just doesn’t work in my mind. The bevel is only 5-10 degrees. Hardly noticeable by the eye, but, I guess it makes a difference.

“Another gotcha will come when you doing rework. You remove the part in question and/or use solderwick to clean the pads. If you try and apply solderpaste right away the residual heat will outflow the flux from the syringe tip which is most frustrating as now the tip is full of paste with no flux. When this occurs it is like concrete and won’t flow. It is possible to drain more than the tip into the larger part of the syringe tube rendering the whole syringe load bad. You can unscrew the tip and plunge out the bad material, but, who knows if you now have the right ratio of flux to solder anymore? If this is the tube from the vendor you can kiss $50.00 down the drain. If you transferred solderpaste to a smaller syringe the loss is less than $50.00.”

I guess all those years at HP and Agilent, and then being in business for himself gave Wayne a valuable perspective on prototyping. Many thanks to him, and add you own comments below.

Zymbit wants to get your IoT ideas to market in days, not months

Tutorial: Building cool projects with MCUs (Part 5)

3 Replies

I finally received the circuit boards! And, in this fifth and final part of the microcontroller tutorial, we are going to solder the components to the circuit board and program the MCU using the USB port of a computer.

Just to refresh our memories, so far we have learned:

I recently ordered the PCBs from Seeed Studio. In order to expedite their delivery, I used a more expensive shipping option from UPS. I did get the boards pretty fast – but I also got an unexpected bill from them because they had to take it through customs.

So, even though the boards were only $10, I ended up with paying about $60 in shipping and customs… But luckily, there exists a much cheaper shipping option (about $3-4) – you just have to wait a little bit longer for the boards to arrive.

Let’s solder the board!

I wanted to make this circuit in such a way that it was possible to make it at home. To solder the circuit, I’m going to use my old Ersa soldering iron and some standard solder wire. The tip of the iron is a bit thick, so it’s really not ideal for this job. However, I know many people only have a simple soldering iron like this lying around the house – so it’s the perfect test to see if this is something that anyone can build from the comfort of your home.

The first thing we’re going to solder is the MCU chip. This is also the hardest part to solder. I have to admit – when I looked at my soldering iron, then looked at the chip – I was a bit worried that it was going to be hard. But the main trick here was to be patient!

To solder the surface mount components, we can use the techniques described in this smd soldering article.

First, we solder one corner pin of the chip. When we have managed to solder this one pin correctly – and all the pins are aligned over their pads – we move on to the corner on the other side. With two corners soldered properly, all we need to do is to add a tiny bit of solder to all the other pins and pads.

Don’t rush it. Take your time. Inspect the pins closely to see if they are soldered and that they don’t have a “solder bridges” to their neighbors. And, don’t worry if it looks a bit like a war-zone with solder all over – just look at mine above – it still works!

Now, safe to say that the worst part is over. The other components are pretty straightforward to solder. Just make sure the LED and the polarized capacitor is placed in the correct direction.

Programming the circuit

Once we are confident that the components are soldered properly, it’s time to test it! First, we need to check if the USB interface works. Otherwise, we won’t be able to program the circuit. To test the USB interface, all we need to do is to connect a USB cable and connect the circuit to our computer. From there, we can just check if it pops up as a USB device on the computer.

And… it does!

So, let’s program the MCU. A simple way of testing it is to make an LED-blink program. This is a simple program that, well, makes our LED blink. It looks like this:

#define F_CPU 1000000 // The chip runs at 1 MHz as default (even if you are using a 8MHz crystal)

#include
#include

int main(void)
{
DDRC = (1<<PC7); //Sets the direction of the PC7 to output
PORTC = (1<<PC7); //Sets PC7 high

while(1)
{
_delay_ms(500); //Wait 500 milliseconds
PORTC &= ~(1<<PC7); //Turn LED off

_delay_ms(500); //Wait 500 milliseconds
PORTC |= (1<<PC7); //Turn LED on
}

return 0;
}

We save this code in a file called led-blink.c

Compiling our code

The first thing we need to do is to compile our code into machine code that the MCU can read. One way of doing this is through Atmel Studio. But, since I am a big fan of using the Linux terminal, I’ll show you how to compile and upload a program using Ubuntu.

First, install avr-gcc with the command:

sudo apt-get install avr-gcc

Then, compile the code and make it into the right format with the following commands:

avr-gcc -mmcu=atmega32u2 -Os blink-led.c -o blink-led.out
avr-objcopy -j .text -j .data -O ihex blink-led.out blink-led.hex

The resulting file – blink-led.hex – can now be uploaded to the microcontroller. You can find more information on the commands here.

Uploading the code to the MCU

Time to upload the program and see if it works. One way to do this is by using Atmel’s FLIP software. But, once again, let’s see how we can do it with the Linux terminal.

Install dfu-programmer with the command:

sudo apt-get install dfu-programmer

Then, erase the old flash memory on the MCU and upload the compiled .hex file:

sudo dfu-programmer atmega32u2 erase
sudo dfu-programmer atmega32u2 flash blink-led.hex

Unplug the circuit from your computer, then plug it in again. And what do you know, the LED starts to blink!

Making something cool

Now that we’ve got it working, we’re ready to make something cool. There are so many cool things you can make with a microcontroller. For example, you can connect it to this Wi-Fi module and make the LED blink every time @AtmelMakes posts a new tweet.

Or, how about connecting it to this sound module and this motion sensor, and make it play a Christmas song every time someone goes near your Christmas tree? As Atmel always says, the possibilities are truly endless.

If you missed any of the previous parts of this tutorial – you can find them here:

Good electronics videos and articles

Fun facts: 30 years, 1 company, unlimited possibilities

2 Replies

Boy, where has the time gone? Today, December 5, 2014, marks an extremely special day for us here at Atmel — it is the day we turn 30 as a semiconductor company. Founded in 1984, Atmel began as a company focusing on non-volatile memories. At this time, Atmel’s founder George Perlegos made a breakthrough with the invention of electrically erasable programable read-only memory, or EEPROM.

After 30 years of innovation, Atmel has emerged as a leading solutions-based company delivering secure, connected devices in the era of the Internet of Things. Guess you can say we’ve gotten ‘smarter’ with age! While the company’s influence can’t be underestimated when it comes to enabling Makers, designers and engineers alike, how much of its history do you actually know?

Here are a few interesting facts to get you up to speed on Atmel’s backstory!

Atmel = “Advanced Technology for Memory and Logic.”

Atmel changed headquarters and its logo in 2012. (Previous logo shown below.)

Atmel’s leadership in EEPROM and Flash was put to good use when it developed the first-ever Flash-based MCU in 1993, the AT89LP.

Atmel complemented the ARM7TDMI CPU with a unique set of system peripherals to create the world’s first ARM-based MCU.

Atmel’s SAM9 became the world’s first ARM9-based controllers.

The mXT768E was the industry’s first 32-bit single-chip controller for touchscreens up to 12-inches.

Atmel is also credited for creating the automotive industry’s first touchscreen controller supporting shieldless sensors and gloved operation.

The incredibly-popular AVR 8-bit architecture was introduced in 1997. By 2003, Atmel had already shipped over 500 million of the MCUs.

Atmel can be found at the heart of the the first Arduino prototype.

… And in the earliest MakerBot 3D printers.

… Oh, and some of the first DIY drones, too.

Atmel remains at the forefront of the Maker Movement, having been an avid participant in Maker Faires since their onset.

… Including an appearance at this year’s inaugural White House Maker Faire.

At the moment, there are over 160 Kickstarter projects built around Atmel AVR, not to mention its versatile Atmel | SMART ARM-based MCUs. Specifically, more than 60% have been successfully funded, garnering well over $7 million in pledges.

Atmel brought flexy back with the debut of its XSense touch sensors.

Atmel unveiled the first futuristic touch-centric curved automotive console back at CES 2014.

Oh. My. God. Becky, look… Atmel has even rap-battled with Sir Mix-A-Lot.

Atmel’s ATmega32U4 has transformed a number of ordinary objects into touch interfaces.

The ATtiny20 is so small that it can almost fit inside the ball of a ballpoint pen, or balance precariously on the tip of a matchstick.

Talk about driving the IoT! Earlier this year, Atmel packed its latest solutions onto a 40′ x 85′ mobile trailer and hit the open road. To date, the big rig has traveled over 55,000 miles with 10,000 visitors hopping onboard.

So, as we reminisce about our past, we can’t help but look ahead to the next 30 years! In celebration of this joyous occasion, we’re asking our fans, friends and loyal customers to share their favorite memories and show off their Atmel pride! Learn how to get started here!

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

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

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.

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

Getting up close and personal with symmetric session key exchange

1 Reply

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.

Atmel launches industry’s first wide-Vcc low-power temperature sensor family

1 Reply

We’re excited to announce the launch of the industry’s first family of high-precision digital temperature sensors with the widest Vcc range from 1.7V to 5.5V. The new family delivers higher temperature accuracy and faster I2C bus communication speeds, and are available with integrated nonvolatile registers and serial EEPROM memory making them ideal for consumer, industrial, computer, and medical applications.

With the widest Vcc range in the industry, the new temperature sensor family allows customers to purchase one device to cover all their Vcc requirements in a variety of applications. Currently, digital temperature sensors on the market are available with a very limited Vcc range requiring customers to purchase multiple temperature sensors in their overall bill of materials (BOM) and utilizing multiple devices to cover the different voltage ranges across various applications.

Atmel’s new family of digital temperature sensors lets customers select just one device to cover all Vcc requirements in various applications, reducing their overall BOM. The new family also delivers a higher accuracy rate at ±0.5°C accuracy (typical) across the 0°C to +85°C temperature range across the entire wide voltage range (1.7V to 5.5V). The low voltage operation of the devices also reduce the overall power consumption in applications such as portable handheld consumer devices, enabling longer battery life.

“Developers for consumer, industrial, computer, medical applications are constantly looking for ways to reduce their overall bill of materials while increasing their system reliability and lowering their power consumption,” said Bryce Morgan, Atmel Strategic Marketing Manager. “With Atmel’s new family of temperature sensors, developers are guaranteed a wide Vcc range along with higher temperature accuracy to satisfy a variety of applications across all market segments. Even more, the new family enables these developers to lower their overall system BOM, while increasing system reliability and lowering the overall power by selecting just one device in this new temp sensor family.”

The new family also delivers a faster I2C bus communication with speeds of up to 1MHz, increasing the data throughput for both temperature sensor operations and for devices with integrated Serial EEPROM. Additionally, the new lineup includes six high-precision, digital temperature sensors based on the industry-standard LM75 functionality offered by a number of vendors. All the devices accurately measure and monitor temperature to address the thermal monitoring requirements for a wide variety of applications and are highly configurable..

Those interested in the new digital temperature sensor family are in luck! AT30TS74, AT30TS75A, AT30TS750A, AT30TSE752A, AT30TSE754A, and the AT30TSE758A are now available.

MQTT not IoT “god protocol,” but getting closer

2 Replies

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.
Speaking of Atmel and Arduino, IBM has several recipes for leveraging Arduino with the IoT Foundation, such as an Arduino Uno connection example, and a series on implementing a cloud-ready temperature sensor.
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.

Don’t be an “ID-IoT”

5 Replies

Authentication may just be the “sine qua non” of the Internet of Things.

Let’s just come out and say it: Not using the most robust security to protect your digital ID, passwords, secret keys and other important items is a really, really bad idea. That is particularly true with the coming explosion of the Internet of Things (IoT).

The identity (i.e. “ID”) of an IoT node must be authenticated and trusted if the IoT is ever to become widely adopted. Simply stated, the IoT without authenticated ID is just not smart. This is what we mean when we say don’t be an ID-IoT.

It seems that every day new and increasingly dangerous viruses are infecting digital systems. Viruses — such as Heartbleed, Shellshock, Poodle, and Bad USB — have put innocent people at risk in 2014 and beyond. A perfect case in point is that Russian Cyber gangs (a.k.a. “CyberVor”) have exposed over a billion user passwords and IDs — so far. What’s scary is that the attacks are targeted at the very security mechanisms that are meant to provide protection.

If you think about it, that is somewhat analogous to how the HIV/AIDS virus attacks the very immune system that is supposed to protect the host organism. Because the digital protection mechanisms themselves have become targets, they must be hardened. This has become increasingly important now that the digital universe is going through its own Big Bang with the explosion of the IoT. This trend of constant connectivity will result in billions of little sensing and communicating processors being distributed over the earth, like dust. According to Gartner, processing, communicating and sensing semiconductors (which comprise the IoT) will grow at a rate of over 36% in 2015, dwarfing the overall semiconductor market growth of 5.7%. Big Bang. Big growth. Big opportunity.

The IoT will multiply the number of points for infection that hackers can attack by many orders of magnitude. It is not hard to see that trust in the data communicated via an ubiquitous (and nosey) IoT will be necessary for it to be widely adopted. Without trust, the IoT will fail to launch. It’s as simple as that. In fact, the recognized inventor of the Internet, Vint Cerf, completely agrees saying that the Internet of Things requires strong authentication. In other words, no security? No IoT for you!

There is much more to the story behind why the IoT needs strong security. Because the world has become hyper-connected, financial and other sensitive transactions have become almost exclusively electronic. For example, physical checks don’t need to be collected and cancelled any more — just a scanned electronic picture does the job. Indeed, the September 11th terror attacks on the U.S. that froze air travel and the delivery of paper checks accelerated the move to using images to clear checks to keep the economy moving.

Money now is simply electronic data, so everyone and every company are at risk of financial losses stemming directly from data breaches. See? Data banks are where the money is now kept, so data is what criminals attack. While breaches are, in fact, being publicized, there has not been much open talk about their leading to significant corporate financial liability. That liability, however, is real and growing. CEOs should not be the least bit surprised when they start to be challenged by significant shareholder and class action lawsuits stemming from security breaches.

Although inadvertent, companies are exposing identities and sensitive financial information of millions of customers, and unfortunately, may not be taking all the necessary measures to ensure the security and safety of their products, data, and systems. Both exposure of personal data and risk of product cloning can translate to financial damages. Damages translate to legal action.

The logic of tort and securities lawyers is that if proven methods to secure against hacking and cloning already exist, then it is the fiduciary duty of the leaders of corporations (i.e. the C-suite occupants) to embrace such protection mechanisms (like hardware-based key storage), and more importantly, not doing so could possibly be argued as being negligent. Agree or not, that line of argumentation is viable, logical, and likely.

A few CEOs have already started to equip their systems and products with strong hardware-based security devices… but they are doing it quietly and not telling their competitors. This also gives them a competitive edge, besides protecting against litigation.

Software, Hardware, and Hackers

Why is it that hackers are able to penetrate systems and steal passwords, digital IDs, intellectual property, financial data, and other secrets? It’s because until now, only software has been used to protect software from hackers. Hackers love software. It is where they live.

The problem is that rogue software can see into system memory, so it is not a great place to store important things such as passwords, digital IDs, security keys, and other valuable things. The bottom line is that all software is vulnerable because software has bugs despite the best efforts of developers to eliminate them. So, what about storing important things in hardware?

Hardware is better, but standard integrated circuits can be physically probed to read what is on the circuit. Also, power analysis can quickly extract secrets from hardware. Fortunately, there is something that can be done.

Several generations of hardware key storage devices have already been deployed to protect keys with physical barriers and cryptographic countermeasures that ward off even the most aggressive attacks. Once keys are securely locked away in protected hardware, attackers cannot see them and they cannot attack what they cannot see. Secure hardware key storage devices — most notably Atmel CryptoAuthentication — employ both cryptographic algorithms and a tamper-hardened hardware boundary to keep attackers from getting at the cryptographic keys and other sensitive data.

The basic idea behind such protection is that cryptographic security depends on how securely the cryptographic keys are stored. But, of course it is of no use if the keys are simply locked away. There needs to be a mechanism to use the keys without exposing them — that is the other part of the CryptoAuthentication equation, namely crypto engines that run cryptographic processes and algorithms. A simple way to access the secret key without exposing it is by using challenges (usually random numbers), secret keys, and cryptographic algorithms to create unique and irreversible signatures that provide security without anyone being able to see the protected secret key.

Crypto engines make running complex mathematical functions easy while at the same time keeping secret keys secret inside robust, protected hardware. The hardware key storage + crypto engine combination is the formula to keeping secrets, while being easy-to-use, available, ultra-secure, tiny, and inexpensive.

While the engineering that goes into hardware-based security is sophisticated, Atmel does all the crypto engineering so there is no need to become a crypto expert. Get started by entering for your chance to take home a free CryptoAuthentication development tool.

Share this:

Like this:

Share this:

Like this:

Let’s solder the board!

Programming the circuit

Compiling our code

Uploading the code to the MCU

Making something cool

Share this:

Like this:

Share this:

Like this:

Atmel = “Advanced Technology for Memory and Logic.”

Atmel changed headquarters and its logo in 2012. (Previous logo shown below.)

Atmel’s leadership in EEPROM and Flash was put to good use when it developed the first-ever Flash-based MCU in 1993, the AT89LP.

Atmel complemented the ARM7TDMI CPU with a unique set of system peripherals to create the world’s first ARM-based MCU.

Atmel’s SAM9 became the world’s first ARM9-based controllers.

The mXT768E was the industry’s first 32-bit single-chip controller for touchscreens up to 12-inches.

Atmel is also credited for creating the automotive industry’s first touchscreen controller supporting shieldless sensors and gloved operation.

The incredibly-popular AVR 8-bit architecture was introduced in 1997. By 2003, Atmel had already shipped over 500 million of the MCUs.

Atmel can be found at the heart of the the first Arduino prototype.

… And in the earliest MakerBot 3D printers.

… Oh, and some of the first DIY drones, too.

Atmel remains at the forefront of the Maker Movement, having been an avid participant in Maker Faires since their onset.

… Including an appearance at this year’s inaugural White House Maker Faire.

At the moment, there are over 160 Kickstarter projects built around Atmel AVR, not to mention its versatile Atmel | SMART ARM-based MCUs. Specifically, more than 60% have been successfully funded, garnering well over $7 million in pledges.

Atmel brought flexy back with the debut of its XSense touch sensors.

Atmel unveiled the first futuristic touch-centric curved automotive console back at CES 2014.

Oh. My. God. Becky, look… Atmel has even rap-battled with Sir Mix-A-Lot.

Atmel’s ATmega32U4 has transformed a number of ordinary objects into touch interfaces.

The ATtiny20 is so small that it can almost fit inside the ball of a ballpoint pen, or balance precariously on the tip of a matchstick.

Talk about driving the IoT! Earlier this year, Atmel packed its latest solutions onto a 40′ x 85′ mobile trailer and hit the open road. To date, the big rig has traveled over 55,000 miles with 10,000 visitors hopping onboard.

Share this:

Like this:

Essential Differences

Ease of Development

Performance

Efficiency of Hardware Near Functions

Power Consumption

Conclusion

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Software, Hardware, and Hackers

Share this:

Like this: