ATtiny102/104 are self-programmable, 8- and 14-pin tinyAVR MCUs

---

New tinyAVRs deliver industry’s smallest and lowest power 8-bit MCU on the market today with 1KB Flash.

---

Making its debut at Embedded World 2016, Atmel has returned to its old-school ways with the world’s highest-performance, low-power, 8-bit microcontrollers boasting 1KB Flash memory. The all-new ATtiny102/104 run up to 12MIPS and integrate features previously only available in larger more expensive MCUs, making them ideal for smaller applications including logic replacement and the latest cost-optimized applications in the consumer, industrial and home automation markets.

The majority of today’s 8-bit market growth is coming from applications that previously only required discrete components. With many of these requiring simple intelligent functions such as timing, motor control or on/off functionality, 8-bit MCUs are becoming an essential feature for the personal healthcare, small kitchen appliance and consumer markets.

The ATtiny102/104 provide all the necessary features to help spur the growth in these applications with its small, cost-optimized low-pincount package with just 1KB of Flash memory. These features include self-programming for firmware upgrades, non-volatile data storage, accurate internal oscillator to provide more reliable motor control, high-speed serial communication with USART, operating voltages ranging from 1.8V to 5.5V 10-bit ADC with internal voltage references, and sleep currents at less than 100nA in power down mode with SRAM retention.

“Atmel has already sold more units of its 8-bit AVR core-based MCUs than the 7.4 billion people on Earth,” says Oyvind Strom, Atmel’s Senior Director of MCUs. “We continue to expand our AVR portfolio with the new ATtiny102/104 8-bit MCUs. These are the first two devices in our new tinyAVR portfolio that are packed with features optimized for tiny, compact MCU systems such as LED lighting, fan control and other small applications.”

Key specs of these tinyAVRs include:

• 1KB Flash / 32bytes SRAM
• 8- and 14-pin packages down to 2mm x 3mm in size
• Up to 12 MIPS at 12MHz
• Self-programmable Flash
• Accurate (±3%) Internal oscillator
• Multiple calibrated internal voltage references (1.1V, 2.2V, 4.3V)
• 10-bytes Unique ID (serial number)
• USART
• 10 bit ADC and analog comparator
• 1.8V to 5.5V voltage range
• -40°C to +105°C and -40°C to +125°C temperature ranges

The ATtiny102/104 engineering samples are now available with mass production samples slated for May 2016. The latest tinyAVRs are fully supported by Atmel Studio 7. Additionally, designers have access to the company’s embedded software, including the Atmel Software Framework and application notes, as well as the Atmel Gallery ‘app’ store.

StoryHome is a connected storytelling device

---

This device is like Hallmark’s recordable storybooks for the Internet of Things era.

---

Everyone can agree that one of the most exciting things about being a kid is having a vivid imagination. Back in the day, one of the ways to stimulate those creative ideas was through bedtime stories. Aside from strengthening the bond between parents and their children, these tales were an excellent way to gradually ease a young one into their nightly slumbers. Though recent advancements like Skype and FaceTime on mobile devices are helping keep loved ones together like never before, the magical aura around listening to a narrative as you hit the hay has been lost.

This is what led to the development of StoryHome. The white, eggplant-shaped device, which resembles a Russian nesting doll, was designed as a simple way for families to connect and share stories with one another. This enchanted audio system enables users to tell and record, listen and play, as well as store some of their fondest memories.

How it works is pretty straightforward. A grandparent or another loved one plugs in the unit to their Internet router or connects to their Wi-Fi network, and presses a button to begin recording. This is uploaded to the company’s cloud service, and transmitted to a child’s companion device. Before bed, the gadget begins to glow, prompting a young one to pick it up and listen. What’s more, unlike those Hallmark recordable storybooks, everything remains stored in the cloud where those recordings can be managed, edited and organized using a web-based portal via smartphone or PC. Users can even invite extended family members to link their StoryHomes together.

While it may not beat having a parent tuck a child into bed, this product certainly makes for a great alternative for when mom or dad is away on business, vacation, or simply steps out of the house at night.

Based on an ARM-based processor, each StoryHome features a microphone, a speaker and a 3.5mm audio jack for easy listening, a micro-USB connector, Flash memory for more than four hours worth of stories and messages, a built-in battery that can last up to several days on standby, as well as a magical RGB LED interface for visual notifications.

Think this gadget would be put to good use in your home? Head over to its official Kickstarter page, where the Campfire UG team is currently seeking $153,804. Should their funding goal have a happy ending, delivery is expected to get underway in February 2016.

Going back to the beginning of AVR with Vegard Wollan

The first episode of this series talked about the very beginning history of the AVR microcontroller chip co-invented by Vegard Wollan. In this clip, we delve into the beauty of Flash memory.

As mentioned in the previous post, engineers used to have to develop their firmware using special ceramic chips with quartz windows.

This early microcontroller has a quartz window in its expensive ceramic package so you can erase the program in an ultraviolet eraser.

Bad enough the chips themselves cost a lot, the real headache was when you had to debug or change your program. You had to pry it out of its socket, and stick it in a ultraviolet eraser for 20 minutes. This really slowed down your code development. It was like playing tennis in molasses.

This UV eraser was used to erase the microcontroller program memory so you could reprogram it with something that you hoped would fix the bugs.

That is what Vegard realized back in the early 1990s: You could make a microcontroller using Flash memory and reprogram in seconds, not hours. Atmel already had a Flash 8051-style micro, so we were a natural to develop the AVR chips.

The aforementioned video touches on the low-power heritage of AVR, which as you already know, Atmel memory products are famous for extremely low power. This advantage was “baked into” the AVR products, since they knew that many applications would run on battery power.

Vegard was also nice enough to bring some early AVR prototypes from his lab in Norway.

Vegard Wollan holds one of the first 10 AVR prototype chips, the S1200.

When Vegard holds up the various prototype chips, you can see the pride of an innovator on his face. I think every engineer gets a real charge out of that first prototype, as even I have a collection of my own at home.

In case you missed our earlier segment on the history of AVR, you can check that out here. Feeling inspired to create and share your own 8-bit ideas? Enter them in our Simply AVR Design Contest today for your chance at $1,500!

Vegard Wollan talks about the history of AVR

We were lucky enough to drag Vegard Wollan into the Atmel Studio while he was visiting headquarters from Norway a few weeks ago. For those of you who may not know, Vegard is commonly believed to be the “V” in AVR. After having spent hours in the Studio, we decided to break the film into separate segments — this one is about the history of the AVR. And, what better day to recount the earliest days of the revolutionary microcontroller than Throwback Thursday?

You young whippersnappers might not realize it, but Atmel started life as a memory company. We made EEPROM memory, and soon branched into Flash memory. Vegard and his pal Alf Bogen (the “A” in AVR) met on computer forums while students at Norges teknisk-naturvitenskapelige universitet, also called NTNU, or the Norwegian University of Science and Technology. They saw the need for a microcontroller based on Flash memory, which you could reprogram as many times as needed, even when it was in-circuit.

AVR inventor Vegard Wollan holds his Master’s thesis from college that began the AVR MCU architecture.

This was at the time where development engineers had to buy expensive ceramic package microcontrollers with a quartz window. You would program the part with your Data IO programmer, and when you had to make any change, you took the part out of its socket and put it in an ultraviolet eraser for 20 minutes. Savagery.

So Vegard and Alf pitched their MCU design to Atmel, who immediately saw the great potential in it. Atmel had already started to make 8051-style MCUs in the Colorado fab facility, which we had just purchased from Honeywell. One great thing about those parts was most instructions executed in one cycle instead of the 4 to 12 that the original 8051 needed.

So when Vegard explained the AVR was a RISC (reduced instruction set) machine designed to execute instruction in one cycle, it was music to Atmel’s ears. You could say that AVR was RISC before RISC was cool. And, it explains why AVR has passionate followers just like ARM-core RISC chips also have passionate followers… I guess that explains why Atmel makes 8- and 32-bit AVR chips, as well as a whole line of Atmel | SMART ARM-based chips.

The other cool thing that this video touches upon is how AVR chips were designed to run C programs well. You might remember the early days, when Intel would make whatever hardware people thought was cool and Microsoft would program in ways that software people thought was cool. Things didn’t always line up. I remember how you had to do a software reboot to take a 80286 out of protected mode, or that “thunking” in Win 95 to switch between 16- and 32-bit.

Vegard is a Renaissance Man that understood the hardware implications of good software design. So he made sure that C code would compile superbly into AVR assembly language. My buddy Wayne Yamaguchi routinely writes C programs for AVR that compile down into a few hundred bytes. AVR is one of those magnificent examples of computer science, not computer “slap this together and push this out so we can sell it”.

Like all Norwegians, Vegard is incredibly modest about his contribution. He credits his co-founder, and the team at Atmel that developed the AVR. But you just have to look at the billions of AVR chips that Atmel has sold to see what a remarkable thing Vegard created. Check out the video and stay tuned for the next installment.

 

 

Securing offline passwords with Atmel MCUs

Over the past few months, Bits & Pieces has featured a number of DIY offline password keepers built around Atmel microcontrollers (MCUs).

First up is the official HackADay Mooltipass. Powered by Atmel’s ATmega32U4, the device is equipped with an easily readable screen, a read-protected smart-card (AT88SC102) and flash memory to store encrypted passwords.

Next up is the USBPass. Designed by a Maker named Josh, the platform comprises an ATmega32U2 MCU, USB connector, three buttons and a few passives chips. Like the Mooltipass, the USBPass is connected to a computer via USB and read as an HID keyboard.

The latest Atmel-powered offline password keeper to surface in the Maker community and on the HackADay website? Cyberstalker’s ATMega32U4-packing Final Key, which includes a single button and LED, all neatly enclosed in a 3D printed case.

According to HackADay’s Mathieu Stephan, the Final Key is linked to the host computer via USB and recognized as a composite comm device/HID keyboard, requiring Windows-based devices to install drivers.

“AES-256 encrypted passwords are stored on the device and can only be accessed once the button has been pressed and the correct 256 bit password has been presented through the command line interface,” Stephan explained. “Credentials management and access are also [executed by] the latter.”

Interested in learning more about the ATMega32U4-powered Final Key? You can check out the project’s official page here.

32-bit AVR MCUs for automotive applications (Part 3)

In the first part of this series, we took a closer look at how Atmel’s AVR low-power 32-bit microcontrollers (MCUs) help enable the implementation of various product-differentiating features, including advanced control algorithms, voice control and capacitive touch sensing. In part two, we discussed powering Atmel’s AVR UC3C 32-bit automotive-grade microcontrollers with either a 3.3V or a 5V supply  (generally supporting 5V I/O) and focused on Atmel’s Peripheral Event System.

And today we will exploring how Atmel’s low-power 32-bit microcontrollers (MCUs) are used to help protect IP and bolster system safety. Firstly, it is important to note that code protection has become a critical design consideration, as software contains an increasing amount of intellectual property (IP). As such, internal Flash memory should be locked to protect code from being read or copied – with system development significantly accelerated by making application code available from third-party devs in a locked section of the Flash memory.

“Microcontrollers must either be programmed before they are assembled on boards or programmed in-device. Yet, preprogramming creates a challenge in logistics, as devices must be programmed in a trusted facility and transported to the manufacturing site,” an Atmel engineering rep told Bits & Pieces.

“In contrast, programming in-system allows the most recent code to be added during the manufacturing stage or in the field. The AVR UC3C arrives with USB drivers that support the Device Firmware Upgrade (DFU) class to allow devices to be programmed over the system’s USB port. As an alternative, a boot loader can be used to allow in-system programming using the CAN interface.”

And that is precisely why Atmel’s AVR UC3C 32-bit microcontroller architecture includes the Atmel FlashVault code protection technology, which allows the on-chip Flash to be partially programmed and locked, creating secure on-chip storage for software IP and boot loader operation.

On the system safety side, systems must be able to recover quickly from clock failure. Indeed, motor control systems must be able to shut systems down upon detection of clock failure to prevent severe damage to the motor or operator. To achieve this, the UC3C devices incorporate a main clock failure detection functionality that immediately switches over to the internal 115kHz RC oscillator in case of malfunction. The system may either continue operation using the backup clock (while triggering an alarm that the primary clock has failed) or perform any necessary shut-down operation to place the system in a fail-safe condition.

Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part four of this series which details how Atmel MCUs can be used to streamline automotive development. Part one can be read here and part two is available here.

Interested in learning more about 32-bit AVR MCUs for automotive applications? Be sure to check out part one, two, three and four of this series.

This ATmega1284 is an 8-voice 32 kHz synthesizer

Atmel’s ATmega1284 is certainly a versatile microcontroller, but how many of us have thought of using the MCU to power an 8-voice 32 kHz synthesizer like Mike of Epromfoundry?

As the Hack A Day crew notes, we should particularly admire the cleanliness of the prototype shown in the video above, with each part given ample room on its own board – and interconnected by 10-pin IDC ribbon connectors.

So, how does it work? Well, to generate audio from the digital microcontroller, Mike built his own R2R digital to analog converter. A resistor ladder – created from 16 resistors – feeds a rail-to-rail amplifier. And although the sound is mono, playback is actually polyphonic due to Atmel’s stalwart ATmega1284.

“It is reading MIDI commands coming in from an external controller (we assume it’s the computer on which the hardware is sitting),” Hack A Day’s Mike Szczys explained.

“The chip’s 128 KB of Flash memory leave plenty of room to store samples, which are selected from a lookup table based on the MIDI data. If more than one sample is to be played the chip averages the data and sets the 8-bit output port accordingly.”

Additional information about the 8-voice 32 kHz synthesizer can be found here.

The value of microcontrollers (MCUs) with dual-bank flash

Written by Brian Hammill

Atmel, along with a number of other industry heavyweights, recently introduced a slew of Cortex-M microcontrollers (MCUs) equipped with a dual-bank flash feature.  While single bank flash is sufficient for numerous applications, the dual-bank feature offers significant value in specific scenarios. So let’s discuss the added benefit of dual-bank flash.

Dual bank flash provides a fail safe method of implementing remote firmware upgrades

First, we need to understand the role of flash in a MCU.  Just under 100% of the time, the flash memory in your MCU is in read mode.  The processor core is almost always fetching instructions to execute out of the flash. Exceptions? When code is being run from RAM, internal or external, or ROM.  Meaning, with typical flash memory, you cannot read while you are writing to it.  As such, during firmware upgrades and data storage operations, the processor core cannot execute code from the flash.  Either the processor has to wait for the write operation to complete, or the core can continue to execute from other physical memory such as RAM or ROM.

In Atmel’s single bank SAM3 and SAM4 family flash MCUs, this problem has been solved in a somewhat novel manner by providing flash programming code in the factory programmed ROM.  This means that whenever the firmware engineer wants to write the flash, it will buffer the data to be written and make a call to a routine in ROM.  The processor core will then be executing from ROM while the flash is being written.  Since flash erase and programming operations can take milliseconds (a very long time for a MCU core running at up to 150 MHz), the ROM routine may have to sit in a do nothing loop while the flash operation completes.

Admittedly there are limitations, but this method generally works just fine for systems with external storage such as serial flash – retaining downloaded firmware images until they can be written to the internal flash.  It also works well in systems which infrequently write a few bytes of data to the flash.

Firmware upgrades can be risky, especially in applications where firmware images are downloaded across slow unreliable wireless links – or where systems are prone to power failures. In a single bank flash system, ensuring a reliable firmware upgrade means there is a part of the flash that you never erase or write over. The code contained in that part of the flash knows how to detect corrupted code in the rest of the flash.

Using a checksum, CRC, or even a digital signature are common ways to determine the validity of the flash image on boot or reset.  If the check comes out bad, the code in the part of flash that is never over-written knows to look for a backup image and attempt to reprogram the application.  The backup image can be located in an external memory such as a serial flash or if there is enough space, in an unused part of the internal flash.

Managing backup images in internal flash or external serial flash can be done reliably in a well planned system with single bank flash.  The key is well-planned, although the firmware engineer has to jump through some hoops because changing the interrupt table ordinarily means you have to change the very lowest flash addresses.  Plus, you cannot keep that part of flash unchanged over the life of the product in the field.  So it is necessary to have the fixed interrupt vectors point at defined locations where the actual interrupt service routines are located.  And finally, the actual ISRs can be changed when the application is changed by a firmware update, although this can lead to size restrictions or wasted flash space between the ISRs.

Atmel expands ARM Cortex-M4 Flash lineup with SAM4N series

Atmel has expanded its ARM Cortex-M4 Flash lineup with the entry-point SAM4N series. The new microcontrollers – which feature a 100MHz operating frequency – boast up to 1MB of Flash memory, multiple serial communication peripherals and analog capability.

“This combination of features, coupled with low power consumption, makes the SAM4N series ideal for a wide range of applications, including the industrial automation, consumer appliance and energy metering markets,” an Atmel engineer told Bits and Pieces.

“In addition, the SAM4N series offers pin-to-pin compatibility with the Atmel SAM4S, SAM3S, SAM3N and SAM7S devices – facilitating easy migration within the SAM lineup.”

As noted above, the SAM4N is built around a low power sipping design, achieving real-world consumption levels down to 170µA/MHz in active mode; down to 20µA in sleep mode with full RAM retention & wake-up time down to 10µs; and down to 1µA in backup mode with the RTC running.

Key hardware specs include fast serial communication with 7 UARTs, four SPIs and three I2Cs; 12-bit ADC, 10-bit DAC, integrated voltage reference, multiple timers and PWM.

On the software side, there is full IDE support for Atmel Studio 6, IAR and Keil, while a Modbus Demo (RTOS + Modbus RTU) will go live later this month. In addition, Atmel’s SAM4N Xplained Pro is available as a starter or evaluation kit – and is probably the most ideal platform for evaluating and prototyping with the SAM4N. Of course, extension boards can also be purchased individually. Additional information about Atmel’s new SAM4N lineup can be found here.

Why on-chip EEPROM is cool

EEPROM costs more to make than flash memory. But you don’t have to write to it in blocks. And you can write to it more times without wearing it out. Flash is good for about 10k to 100k writes. EEPROM can do more.

Better yet, you can arrange the EEROM as a circular buffer so it is unlikely to ever wear out. That is a benefit of EEPROM, you don’t have to program it in blocks. The reason EEROM costs more is not simply the size of the cells. It’s that you need to do extra process steps. You have to realize that those extra process steps penalize the whole die, since you are adding steps to making a finished wafer.

So integrating EEPROM onto an MCU does have a cost penalty. But when you do it, you have some solid reliable non-volatile memory that can be written to individually instead of an entire block a time.

Adding EEPROM to some large die like an ARM core carries too much of a cost penalty, so you won’t see then there. But many Atmel MCUs have embedded EEPROM and you should check them out for any critical non-volatile functions you need in your system. If you do need some big iron, like an ARM core, well then you can always use some Atmel serial EEPROMs and have the same benefits in you larger systems.

When you live here in Silicon Valley, you get to meet all kinds of engineers. Some are programmers, some are hardware folks. But some of the most interesting are semiconductor process engineers, and their kindred spirits, the product engineer.

When you hang around those folks, you really do see how difficult it is to make the high-performance silicon that is coming out in this day and age. You might not directly see the work of the process engineers, but they are just as important as the IC designers, apps and test engineers in bringing you the remarkable parts you can use in modern designs.