Tag Archives: Atmel AVR microcontrollers

Building an Arduino-powered smart home model

PubNub Evangelist Ian Jennings walks through the process of building a smart home from scratch using Arduino.

Down the road we may build a full-sized smart home, but for now we figured a model home laser cut out of Eucaboard would do just fine for now.

We wanted to showcase how home automation, [Atmel AVR microcontroller based] Arduino, and PubNub go hand-in-hand-(in-hand). More importantly, we wanted to show how important reliable, realtime connectivity is for building a fully-featured home automation solution.

As a result, our Arduino connected home was born. In the story below, the home’s architect/PubNub Evangelist Ian Jennings walks through the process of building the home from scratch (with .gifs!). In the future, we’ll roll out a technical tutorial so you can build one yourself.

Back in September, our founder Stephen and I were talking about ways to make it easier to demonstrate where PubNub sits with the Internet of Things. Attendees at conferences often ask if we’re a “hub,” a bluetooth device, etc.

In reality, we’re a data stream network; a service similar to a CDN that provides a simple and reliable way for IoT devices to talk to each other.

I decided instead of telling people people what PubNub is, we should show them. If I handed you a mobile phone and told you to press a button and then a garage door opened, you would understand that the phone sent a message to the garage door (via Arduino remote configuration).

How did it send the message? That’s PubNub.

So I built the garage door, and a front door, and some lights, and a house, and a mobile app, and I recorded every minute of it. You can check out that video below:

The PubNub IoT Model House from PubNub on Vimeo.

Why a house?

When I think IoT, my mind goes to home automation. It’s a great use case of a number of different connected devices where reliability and security are paramount. In this case, the house is a single IoT device that represents any number of devices.

I started by looking for a suitable “house.” Originally the idea was the have the house fold down so it could be packed and shipped around to conferences. This lead me to believe laser cutting was the best option, because the “snap fit” ability is not only sturdy, but portable.

I eventually stumbled upon this CAD file of a house from “The Simpsons.” It was extremely well designed and only $15. I took a 2 hour lesson here at ATX Hackerspace and learned how to use the laser cutter. A couple days later my roommate came home with some extra Eucaboard.

I wasted half of the board because Corel Draw determines scaling settings when each file is opened. Apparently I cut all 4 laser files at different scales, so none of the pieces fit together! Once I figured this out I had a clean cut.

From there I needed to glue the smaller parts like the windows and chimney. No need to set these up on the road.

It turns out gorilla glue is extremely messy because it expands over time. This created a bunch of huge solid glue globs that completely ruined the aesthetics of the house. I used a dremel to cut away at the excess glue. It took me a while but I definitely leveled up my dremel skills.

Then I started prototyping. I used an Arduino Uno Rev 3 and an ethernet shield to get up and running fast. I started with a breadboard, LEDs, and used electrical tape to test mounting the servos.

Hooking Up PubNub

Everything checked out so I started to hook it up to PubNub. We have drivers for Arduino which made it really easy.

I used a Seed Studio Ethernet Shield v2 to provide an internet connection to the IoT house. I didn’t have an Ethernet port around, so I was using my Macbook’s Internet Sharing setting to share the WiFi network connection to the Arduino. There were some slight modifications I needed to make for the SS v2 drivers to work with our v1 library (a full post about this fix coming later).

I opted to use a key value syntax to process messages. As you can see in the video, it was as simple as “garage:0” or “lightLeft:1” to close the garage and turn the left light on.

When I verified that this worked correctly, I soldered everything into a separate board that could be mounted inside the house.

Looking back now, this board should have been a “prototype shield” for Arduino but at the time I thought it would be so simple that it wouldn’t require an entire shield. This was a mistake, and there are now 7 extra wires that would have been unnecessary with a shield.

I built a simple UI in a CodePen to publish PubNub messages on the same channel the house was listening to. I then mounted the LEDs in the house, drilled mounts for the servos and connected them to doors, and mounted the circuit board and the Arduino + Ethernet shield to the house.

It worked!…

About half of the time.

There was something really strange about the behavior. I would have a great connection to PubNub and everything would work… then suddenly it was completely broken. I noticed that something was amuck, and I suspected it was the internet connection.

I dug down into the network, spending many hours looking at WireShark for hints and configuring the WiFi network.

I tried things like assigning an IP address to the Arduino, making sure the MAC address was correct, and even ordering a second Ethernet shield from a different manufacturer and switching from driver-supported USB to native Thunderbolt sharing. Eventually I was able to isolate the problem.

Whenever I opened the garage door, the ethernet shield would reset. I laughed, in what other situation could opening your garage door possibly destroy your internet connection?

Arduino Board Limiters

Arduino board has limiters in place that prevent you from drawing too much power through the board (and frying it). Every time the garage door opened, the servos were drawing all the current, not leaving enough for the Arduino and Ethernet shield to properly function.

I tested my theory with a few external power supplies. When I verified it fixed the problem, I wired in the battery pack you can see in the video.

That was it! I had the working prototype.

Assembling the IoT House

I showed it to my team at PubNub over video chat. They loved it, but seemed a little concerned about how to assemble it. After all, there were about 20 wooden pieces that fit like a puzzle, and then another 20 wires.

There was also a new plan. Now we had a deadline; an upcoming IoT conference in San Francisco. In addition, I wouldn’t be going with the house. It was going right to our CEO Todd who was attending the show.

I started to second guess my original plan of shipping the house to be assembled on spot.

My co-worker at ATX Hackerspace picked up an awesome Pelican case to carry his function generator and other crazy electronic gizmos safely to his clients this same day. He gave me quick demo and ensured that this was the way to go. I plopped the assembled house on top of the case and verified it would fit inside. Later that day I drove over to Fry’s and got one myself.

I glued the house together and decided I was going to ship it in as few pieces as possible. I glued the house walls together, cut out the styrofoam, and fit the house snugly inside the Pelican case.

Then I threw it off a table, kicked it, and tossed it down stairs.

I figured that I would subject the house to the worse torture possible while I could still fix it. Who knows what kind of abuse it will need to endure in shipping?

The house survived with minor injury.

I decided it was time to show this thing off. Test it in a live environment.

Showcasing the IoT House

I took it to HackTX, a hackathon hosted at the University of Texas here in Austin and run by my new pal Taylor. My other good pals Swift and Jon happened to be in town too.

I found a seat next to the students and set up the house. I repeatability assured the other contestants that I wasn’t going to be competing for any of the prizes.

There was a problem. I was connected to the UT campus internet, but their security settings prevented the network from being rebroadcast. I couldn’t share the WiFi from my Macbook to the Arduino. I learned after the fact that there is some way around this, but didn’t look to far into it.

Instead, I decided it was time to make this thing wireless. I did 30 minutes of research and decided I was going to replace the Arduino Uno and the WiFi chip with the newer Arduino Yún board. In addition to the WiFi chip, Yún has a second processor that runs Linux.

What better time to get this thing set up then at a hackathon? My roommate Nick showed up to the hackathon, so we both jumped in my hatchback, rolled down the windows, and cruised to a Radio Shack in South Austin. I called to confirm they had the chip, it wasn’t available at every Radioshack.

We didn’t support Yún at the time so I used our REST API documentation to write my own client. I really wanted JSON support and getting it to work with Arduino was difficult.  It took me the entire hackathon, but by the end…

It was complete.

I bought an external battery pack and a WiFi hotspot. I chiseled little spots out of the Pelican case to fit them in, and configured the Arduino to automatically connect to the hotspot.

The I went to Harbor Freight and bought a toolkit, extra tools, a soldering iron, etc. I rounded up extra servos, LEDs, wires, and wrote a debugging guide in case something went wrong with the house. I also recorded a video about how to take the house out of the case and set it up.

Then I dropped it off at FedEx. Overnight shipping to California.

The worst wasn’t over. Now it was time to wait for the call from our CEO Todd so I could walk him through setting it up.

I didn’t get a call, but instead a couple emails.  One at 6:43am said:


I wasn’t.

“If so, call me. Starting set up now.”

Another arrive at 8:20am. I was awake for this one. It read:

“All works!”

I fell back asleep.

Wrapping Up

Working on this project was incredibly difficult yet also very fulfilling. I don’t have any formal electrical engineering experience, I’m a web developer by trade. I haven’t learned this much this fast since graduating college.

I was working extremely long days to meet the deadline. I would spend the entire morning just shopping for the right components, screws, glue, or paper. Then I would work, sometimes until 3 or 4am, getting everything together.

Thankfully Arduino makes things simple and I had a great network of people who helped me each step along the way. Alex, in particular was extremely helpful with electronics and another member of the space, Riley, spent on late Friday supplying me with every tool and component I needed during assembly like a surgeon’s assistant.

The IoT house is on display at the ground level office at 725 Folsom in San Francisco. It will also be displayed at upcoming IoT conferences which will be announced on our blog. If you would like me to give a talk about building IoT house at your conference, you can reach me at ian@pubnub.com.

Now to convince PubNub to get me a drone…

Vegard Wollan talks AVR chips and tools

While some of my earlier segments with Vegard explored the history of AVR, this video with its co-inventor addresses its product line and the tools one would use to write the firmware for the 8-bit chips.

Vegard touches on the availability of AVR chips in DIP (dual in-line) packages. These larger packages are loved by Makers and hobbyists since they are easy to prototype with. You can solder to the pins without a microscope and it is easy to make changes. They are also well-suited to installing in sockets, so you can replace them, or yank them out and program them in a separate programmer board.


Atmel still makes parts in the older DIP package, loved by hobbyists and Makers alike.

In the interview, Vegard refers to the ball grid array, commonly referred to as BGA by us acronym-loving tech people. BGAs are extremely small, just a little bigger than the silicon die itself. They also tend to transfer heat out of the die effectively, but that is rarely a factor in AVR chips since they are so low power. The headache with BGA chips is that you need an IR reflow oven to solder them on a board. Now, my buddy Wayne Yamaguchi has figured out a toaster oven will get the job done, just don’t toast any bread in it after you put a lead-soldered board into it.


Atmel parts in BGA packages are very small, but take special inspection and rework equipment.

The real headaches with BGA packages are rework and inspection. To replace the chip, you would need a camera mounted hot-air rework station from Metal/OKI; in order to make sure it is soldered correctly would require an X-ray machine (no, I am not kidding) to see that all the balls have sweated onto the pads under the chip. It helps to use gold-immersion finished circuit boards since they tend to be flatter than HASL (hot air solder-leveled) boards. However, if you are making some leading-edge tiny consumer product, all these prototyping and QC hassles are well worth it to get the smallest size possible.


To remove and resolder a BGA on your circuit board, you need to use a high-dollar camera equipped hot-air station like the Metcal Scorpion from Oki.

Vegard confirmed that Atmel uses the AVR 32-bit UC3 core in our touch controllers and mouse controller products. As you will see in the video above, we then went on to discuss Atmel’s legacy of providing really inexpensive demo boards and development tools.


Vegard Wollan smiles with pride as I show him an old demo board I used in 1999.

I also dragged out the actual AVR ICE 200 in-circuit emulator (ICE) I used in 1998, to design a point-of-sale terminal (note I misspeak in the video, calling it an STK200). The remarkable thing was this system would emulate an AVR chip in-circuit, and it only cost 200 dollars, back in an era when Intel Blue-Box 8051 systems were 50 grand.


Vegard Wollan really beams as I describe the 200-dollar Atmel AVR ICE 200, that got my startup off to a fast start in 2001.

To conclude the segment, Vegard Wollan shares how the Atmel Studio 6 integrated development environment is a high-quality software tool to develop your application, and works with AVR 8- and 32-bit parts as well as Atmel ARM-core microcontroller chips. When you add Atmel Gallery, Atmel Spaces, and the Atmel Software Framework (ASF), Atmel Studio becomes an integrated development platform (IDP). And, don’t forget you can get Atmel demo hardware through our distributors or the Atmel Store.


Baskin-Robbins only has 31 flavors, Atmel has 505

Actually these days even Baskin-Robbins has more, but not 505 like Atmel. That’s a lot. While some are AVR, both 8-bit and 32-bit, others are various flavors of ARM (all 32-bit) ranging from older parts like the ARM9 to various flavors of Cortex ranging from the M0 (tiny microcontroller with no pipeline or cache) up to A5. Of course, the ARM product line goes all the way up to 64-bit Cortex-A57 and so on — but they are not in any sense of the word microcontrollers and are really only used in SoCs and not standalone products.

But with 505 choices, how do you pick one? Fortunately, Atmel has made it easy for you to navigate the various flavors. With the help of the company’s MCU product finder, you now have the ability to input your hard constraints, while the tool will narrow down the choices. For example, if you want your microcontroller to have at least 64 Kbytes of flash, then there are only 257 out of the 505 that will suit your needs. For each parameter, users can set minimums and maximums — except for the yes/no choices.

When it comes to the selection process, there are several things that you can constrain:

  • Flash memory (0 to 2Mbytes)
  • Pin count (6 to 324)
  • Operating frequency (1 to 536MHz)
  • CPU architecture (pick from 8-bit AVR, 32-bit AVR, ARM 926 and 920, ARM Cortex M0, M3, M4, A5)
  • SRAM (30 bytes to 256 Kbytes)
  • EEPROM (none to 8 Kbytes)
  • Max I/O pins (4 to 160)
  • picoPower (yes or no)
  • Operating voltage (various ranges from 0.7V to 6V)
  • Operating temperature (various from -20oC to 150oC)
  • Number of touch channels (none to 256)
  • Number of timers (1 to 10)
  • Watchdog (yes or no)
  • 32KHz real time clock (yes or no)
  • Analog comparators (0 to 8)
  • Temperature sensor (yes or no)
  • ADC resolution (8 to 16 bits)
  • ADC channels (2 to 28)
  • DAC channels (0 to 4)
  • UARTs (0 to 8)
  • SPI (1 to 12)
  • TWI (aka I2C) interface (none to 6)
  • USB interface (none, device only, host+OTG, host and device)
  • PWM channels (0 to 36)
  • Ethernet interfaces (none to 2)
  • CAN interfaces (none to 2)

Wow, that’s a lot of options! But after a couple of dozen selections, you can narrow down your choice to something manageable. Here’s how the interface will appear:

Say for instance, I wanted to pick a microcontroller, an ARM Cortex of some flavor. Already choices are down to 189. I want 32K to 128K of flash (now down to 73 choices). I want it to run at an operating frequency of at least 64 MHz (now down to 10). I want 4K of SRAM (turns out all 10 choices already have that much). I need 4 timers. I am now down to 2 choices:

These two choices are the ATSAM3S1C and the ATSAM3S2C — both ARM Cortex-M3s. The first has 64K of flash and the second 128K. I can click on the little PDF icon and access a full datasheet for these microprocessors. If I don’t like the choices and I have some flexibility on specs, then obviously I can go back and play with the parameters to get some new options.

I can click on the “S” to order samples. However, in order to do this, you must already have an Atmel account. Or, with just another click on the shopping cart icon, I can obtain a list of distributors throughout various geographic regions, where I can actually place an order. It even tells me how many each of them have in stock!

For those of you ready to start searching, you can find the Atmel Microcontrollers Selector here.

This post has been republished with permission from SemiWiki.com, where Paul McLellan is a featured blogger. It first appeared there on March 2, 2014.

Atmel and the Maker Revolution

I was part of the “original” Maker revolution. This was years ago, in the late 1980’s, and I was a latecomer. We used to make our own circuit boards, but slightly different from the ones today.

There was a 386 computer on my desk. My trusty 386 had ISA ports, extension card space, that most of us used as a basis for our designs. The ISA bus was easy to use, and the connector was large, meaning we could use simple, basic, cheap equipment to make our boards. What did we make? Everything! Digital IO, radio, remote control systems, everything. When I was a student, my flat was controlled entirely by one of these cards. Of course, the brain of my invention was the computer itself, it wasn’t easy to create a computer system.

A computer system requires several components. It requires a processor, and there were quite a few on the market at the time. It also requires memory, but two kinds; random access memory, RAM for short, is where variables are stored, and is the memory that a program uses to copy, calculate and modify data. A computer also requires read-only memory, ROM for short, and this is where the program is placed. Even that was tricky. You see, at the time, in order to “flash” a new program, we had to remove the EPROM device (short for Erasable Programmable Read Only Memory) and place it in ultraviolet light for up to 30 minutes. That was only the beginning. In order to flash a new program, you had to put it into a programmer, a device attached to the computer that wrote data into the device. Once that was done (it took a few minutes), then you could put the chip back onto the circuit board, and away you went. If you made a mistake, or if your program didn’t work, then you had to redo everything, which took over half an hour.

All of this was complicated, and required multiple components. The processor was one component. The RAM was another. So was the ROM. Interrupt controllers? Digital IO? PWM? They were all external components too. There was a reason why computers used to be that big. So we simplified things. The processor was the PC, and we just made extension boards. Of course, this made making things like robots difficult, but we had lots of fun.

The ISA bus was slow, and users wanted PCs to become faster and faster. The ISA bus was soon replaced by VLB, short for VESA Local Bus. It added an extension to the ISA bus, allowing for faster memory transfers. We had faster computers, better graphics, and we could still use our boards. However, it also sent a clear message; we were soon to find a new way of doing things. VLB was replaced by PCI, which was replaced by PCI Express. This bus is lightning fast, but requires complex electronics, and very good equipment to make boards with connectors that fine. Our trusty ISA cards soon ended up in the dustbin. We could still use the serial port or the parallel port, but it wasn’t the same. Most of us stopped.

It was depressing. We tried making our own computers, but they were complicated. External components, long flash times, prohibitive prices… One company was listening.

Atmel's ATMEGA328P-PU an AVR 8-bit processor

Atmel’s ATMEGA328P-PU an AVR 8-bit processor

In 1996, Atmel shipped the AVR processor. It was an 8-bit processor, with a twist. It had internal RAM, and internal flash. No more external components. It could be flashed within seconds, and reflashed. You didn’t even need to take it off the breadboard to reflash it. Founded in 1984, Atmel had already made semiconductor devices for the professional market, but was also very close to Makers. They heard our cry for help, and they delivered. The AVR changed everything.


The AVR chip was an 8-bit device (32-bit devices also exist), but the computer we used to control our ISA cards was 32-bit. The thing is, we didn’t need 32-bits, and an 8-bit microcontroller was perfect for our needs. The AVR was small, cheap, reliable, and really, really easy to use. We flooded back, we redesigned our boards, and we made. We made everything. How good were the AVR chips? By 2003, Atmel had shipped 500 million devices.

Fast forward a few years, and here we are today. Makers are everywhere. We are back. We are making more than ever. And with awesome sponsors like Atmel, we are here to stay. 2013 was the year of 100 Maker Faires, and they were full of Arduinos.

New Breed of Maker Movement Engineers Blooming from Garages, Maker Faire, Hackerspaces, and Makerspaces

New Breed of Maker Movement Engineers Blooming from Garages, Maker Faire, Hackerspaces, and Makerspaces

What is on the Arduino? Well, most of them have an AVR. The Arduino Due isn’t an AVR-based device, it is an ARM device, but even that is made by Atmel too, and is just as easy to use. 2014 promises to be even more exciting!

New Breed of Engineers - Some Images from Maker Faire Bay Area, there were over 100 Maker Faires in 2013 budding in cities all across the globe

New Breed of Engineers – Some Images from Maker Faire Bay Area 2014. There were over 100 Maker Faires in 2013 budding in cities all across the globe

Arduino Due

Here’s the Arduino Due – with an Atmel ARM Based Processor

With Atmel as a sponsor, Makers are here to stay. If you haven’t tried to make your own device yet, try it! It doesn’t cost a lot, and you don’t need all the complicated hardware we used to have. You will be up and running in mere minutes, and believe me, it is fun! If you have any questions, go and see Atmel at one of the Maker Faires. If you come by the Maker Faire Rome, come say hello, I’ll be there with Atmel to show you just how much this technology has changed my life, and show you how to start.

Video: Electronic dice go random with AVR

A Maker named Walter recently created an entropy library for Atmel AVR microcontrollers (MCUs) to ensure a reliable source of truly arbitrary numbers.

As HackADay’s Brian Benchoff reports, the electronic dice generate random numbers by taking advantage of the watchdog timer’s natural jitter.

“[This isn’t] fast by any means but most sources of entropy aren’t that fast anyway,” Benchoff explains. “By sampling a whole lot of AVR chips and doing a few statistical tests, it turns out this library is actually a pretty good source of randomness, at least as good as a pair of dice.”

According to Benchoff, the circuit itself employs a pair of 8×8 LED matrices from Adafruit, an Atmel-based Arduino board and a pair of buttons.

Supported modes (11 total)?

  • 2d6
  • 2d4
  • 2d8
  • 2d10
  • 1d12
  • 1d20
  • Deck of cards
  • Single hex number
  • Single 8-bit binary number
  • 8 character alphanumeric password

Interested in learning more? You can watch the video above or check out the project’s official page here.