We never have enough peripherals on a microcontroller. Whether it’s hardware-driven PWM channels, ADCs, or serial communication peripherals, we always end up wanting just one more of these but don’t really need so many of those. Atmel’s new version of the popular ATmega328 series, the ATmega328PB, seems to have heard our pleas.
We don’t have a chip in hand, but the datasheet tantalizes. Here’s a quick rundown of the new features:
Two more 16-bit timer/counters. This is a big deal when you’re writing code that’s not backed up by an operating system and relies on the hardware for jitter-free timing.
Two of each USART, SPI, and I2C serial instead of one of each. Good when you use I2C devices that have limited address spaces, or when you need to push the bits out really fast over SPI.
Ten PWM channels instead of six. This (along with the extra 16-bit timers) is good news for anyone who uses PWM — from driving servos to making music.
Onboard capacitive sensing hardware: Peripheral Touch Controller. This is entirely new to the ATmega328PB chip, and looks like it’ll be interesting for running capacitive sense buttons without additional ICs. It relies on Atmel’s QTouch software library, though, so it looks like it’s not a free-standing peripheral as much as an internal multiplexer with maybe some hardware-level filtering. We’ll have to look into this in detail when we get our hands on one of the chips.
So what does this mean for you? A quick search of the usual suspects shows the chips in stock and shipping right now, and there’s an inexpensive dev kit available as well. If you write your own code in C, taking advantage of the new features should be a snap. Arduino folks will have to wait until the chips (and code support) work their way into the ecosystem.
Just last week, there was considerable speculation that Microchip would buy Atmel. The deal wasn’t done, and there was precedent that this deal wouldn’t happen – earlier this year, Dialog made an approach at Atmel. Now, though, the deal is done: Microchip will acquire Atmel for $3.56 Billion.
There are three main companies out there making microcontrollers that are neither ancient 8051 clones or ARM devices: TI’s MSP430 series, Microchip and Atmel. Microchip has the very, very popular PIC series microcontrollers, which can be found in everything. Atmel’s portfolio includes the AVR line of microcontrollers, which are also found in everything. From phones to computers to toasters, there’s a very high probablitiy you’re going to find something produced by either Atmel or Microchip somewhere within 15 feet of your person right now.
For the hobbyist electronic enthusiast, this has led to the closest thing we have to a holy war. Atmel chips were a little easier (and cheaper) to program, but were a little more expensive. Microchip’s chips have a very long history and proportionally more proper engineers who are advocates. PIC isn’t Arduino, though, a community that has built a large and widely used code base around the AVR family.
Microchip’s acquisition of Atmel follows several mergers and acquisitions in recent months: NXP and Freescale, Intel and Altera, Avago and Broadcom, and On Semiconductor and Fairchild. The semiconductor industry has cash and wants to spend it. What this means for the Atmel product line is left to be seen. The most popular micros probably won’t be discontinued, but if you’re using unpopular Atmel micros such as the ATtiny10 you might want to grab a reel or two before they’re EOL’d.
Take a leap the next time you use SPI and don’t poll for the busy flag. “What, are you crazy? That’s the whole point of the busy flag! It’s a quick check to make sure you don’t kill a byte waiting to be shifted out!” Sure, we thought the same thing, but the other side of the coin is that it takes time to check the busy flag, and that’s time he could be transmitting data. [bigjosh2] calculates that his technique saves 20% of those wasted cycles in this particular case. And he’s “using the force” only because he’s a Jedi master able to rely on the cycle count of a chunk of assembly code.
He’s working with an AVR processor, and pumping out bits to drive the vintage LED display pictured above. The ancient chips don’t have buffered SPI so he has to blank the display while shifting new data in to prevent it from glitching. Because the display blank during the SPI transmission, the slower it goes, the dimmer the lights.
He attacks the problem with synchronous code. It takes 2 cycles for the hardware SPI to send each bit, so he twiddles his thumbs (that’s exactly what he wrote in his code comments) for 16 cycles before reloading the SPI register with his next value. This leaves it up to faith in the silicon that the shifting will always take the same number of cycles, but the nice thing about hardware is that it’s deterministic. He ends up killing a few cycles in order to save time by not polling the busy flag.
The Internet is full of extremely clever people, and most of the time they don’t realize how stupid they actually are. Every time there’s a rocket launch, there’s usually a few cubesats tucked away under a fairing. These cubesats were designed and built by university students around the globe, so whenever a few of these cubesats go up, Internet armchair EEs inevitably cut these students down: “That microcontroller isn’t going to last in space. There’s too much radiation. It’ll be dead in a day,” they say. This argument disregards the fact that iPods work for months aboard the space station, Thinkpads work for years, and the fact that putting commercial-grade microcontrollers in low earth orbit has been done thousands of times before with mountains of data to back up the practice.
While microcontrollers that aren’t radiation tolerant have gone up in cubesats and larger commercial birds over the years, the commercial-grade stuff is usually reserved for low Earth orbit stuff. For venturing more than a few hundred miles above the Earth, into the range of GPS satellites and to geosynchronous orbit 25,000 miles above, radiation shielding is needed.
Will you ever need a space-grade, rad-hard Arduino? Probably not. This new announcement is rather cool, though, and we can’t wait for the first space grade Arduino clone to show up in the Hackaday tips line.
The deal between Dialog and Atmel is not very big; the combined revenue of both companies should be $2.7 Billion, not even in the top-20 semiconductor companies by revenue. However, Atmel is an extremely big player in the Internet of Things and the nebulous ‘maker’ market. Dialog’s portfolio is complementary to Atmel’s, focusing on mobile platforms such as smartphones, e-readers, and tablets. The future is in the Internet of Things, and Dialog wants to get in on the ground floor.
Dialog’s current portfolio is focused mainly on mobile devices, with Bluetooth wearables-on-a-chip, CODEC chips for smartphones, and power management ICs for every type of portable electronics. Atmel’s portfolio is well-established in automotive, smart energy metering, and the maker movement. While the Arduino may be Atmel’s most visible contribution to the industry, the Arduino itself is just a fraction of Atmel’s sales in this space. Atmel parts can already be found Internet of Things products like the LightBlue Bean (an 8-bit AVR), and the Tessel 2 Internet of Things board (a 32-bit Atmel ARM).
Curiously, neither Dialog nor Atmel have many sensor or MEMS products, and the future of wearables, portable electronics, and the Internet of Things will depend on these sensors. STMicroelectronic produces both the microcontrollers and sensors that are packed into phones. TI is nearly a full-stack hardware company, able to produce everything that will go into a wearable or Internet of Things device, all the way from the power regulator to the microcontroller. Although this may be seen as a shortcoming for Dialog and Atmel, both companies combined are still many times smaller than the likes of Avago/Broadcom or NXP/Freescale there’s plenty of room for more acquisitions to round out their future needs.
As for what changes will come to Dialog and Atmel’s portfolio, don’t expect much. Unlike the NXP and Freescale merger where both companies have a lot products that do pretty much the same thing, the portfolios of Dialog and Atmel build on each other’s strengths. You’ll have your 8-bit AVRs for a few more decades, and with Dialog’s focus on connectivity, we can expect even more tools for building the Internet of Things.
Speak with those who consider themselves hardcore engineers and you might hear “Arduinos are for noobs” or some other similar nonsense. These naysayers see the platform as a simplified, overpriced, and over-hyped tool that lets you blink a few LEDs or maybe even read a sensor or two. They might say that Arduino is great for high school projects and EE wannabes tinkering in their garage, but REAL engineering is done with ARM, x86 or PICs. Guess what? There are Arduino compatible boards built around all three of those architectures. Below you can see but three examples in the DUE, Galileo, and Fubarino SD boards.
Arduino DUE uses Atmel ARM
Arduino Galileo uses Intel x86
Fubarino SD uses PIC32
This attitude towards Arduino exists mainly out of ignorance. So let’s break down a few myths and preconceived biases that might still be lurking amongst some EEs and then talk about Arduino’s ability to move past the makers.
Arduino is NOT the Uno
When some hear “Arduino”, they think of that little blue board that you can plug a 9v battery into and start making stuff. While this is technically true, there’s a lot more to it than that.
An Arduino Uno is just an AVR development board. AVRs are similar to PICs. When someones says “I used a PIC as the main processor”, does that mean they stuck the entire PIC development board into their project? Of course not. It’s the same with Arduino (in most cases), and design is done the same way as with any other microcontroller –
Use the development board to make, create and debug.
When ready, move the processor to your dedicated board.
What makes an Arduino an “Arduino” and not just an AVR is the bootloader. Thus:
An Atmega328P is an AVR processor.
An Atmega328P with the Arduino bootloader is an Arduino.
The bootloader allows you to program the AVR with the Arduino IDE. If you remove the bootloader from the AVR, you now have an AVR development board that can be programmed with AVR Studio using your preferred language.
There Is No Special Arduino Language
Yes, I know they call them sketches, which is silly. But the fact is it’s just c++. The same c++ you’d use to program your PIC. The bootloader allows the IDE to call functions, making it easy to code and giving Arduino its reputation of being easy to work with. But don’t let the “easy” fool you. They’re real c/c++ functions that get passed to a real c/c++ compiler. In fact, any c/c++ construct will work in the Arduino IDE. With that said – if there is any negative attribute to Arduino, it is the IDE. It’s simple and there is no debugger.
The strength comes in the standardization of the platform. You can adapt the Arduino standard to a board you have made and that adaptation should allow the myriad of libraries for Arduino to work with your new piece of hardware. This is a powerful benefit of the ecosystem. At the same time, this easy of getting things up and running has resulted in a lot of the negative associations discussed previously.
So there you have it. Arduino is no different from any other microcontroller, and is fully capable of being used in consumer products along side PICs, ARMs etc. To say otherwise is foolish.
What is the Virtue of Arduino in Consumer Products?
This is Ask Hackaday so you know there’s a question in the works. What is the virtue of Arduino in consumer products? Most electronics these days have a Device Firmware Upgrade (DFU) mode that allows the end user to upgrade the code, so Arduino doesn’t have a leg up there. One might argue that using Arduino means the code is Open Source and therefore ripe for community improvements but closed-source binaries can still be distributed for the platform. Yet there are many products out there that have managed to unlock the “community multiplier” that comes from releasing the code and inviting improvements.
What do you think the benefits of building consumer goods around Arduino are, what will the future look like, and how will we get there? Leave your thoughts below!
[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.
Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.
The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.