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.
Most modern computers are able to dynamically adjust their operating frequency in order to save power when they’re not heavily used and provide instantaneous-seeming response when load increases. You might be surprised to hear that the lowly 8-bit AVR microcontrollers can also switch CPU-speed gears on the fly. In this edition of Embed with Elliot, we’ll dig into the AVR’s underappreciated CPU clock prescaler.
The Hackaday Prize isn’t exclusively about building things that will help the planet; you can also build things that will enable others to build things to save the planet. [Eric] isn’t saving the world with his commonCode library, but it will make it vastly easier for other people to build the next great Thing.
The idea behind commonCode is the same as shared libraries you’ll find in any desktop application of reasonable size; it provides a common library for AVR microcontrollers to build just about anything. Bit manipulation, an interface for timers, math functions, graphics, I/O, and peripheral drivers are all available in the commonCode library. This makes it easy for the developmentally challenged among us to create whatever project they want.
The commonCode library wasn’t created just for The Hackaday Prize. [Eric] has been tinkering around with AVRs since well before the Arduino existed, and he has dozens of projects in permanent installations. It’s a great way to give back to the community, and the perfect way to allow people to develop their own things to solve whatever problem they have in mind.
A while ago, [Paul Stoffregen], the creator of the Teensy family of microcontrollers dug into the most popular Arduino library for driving TFT LCDs. The Teensy isn’t an Arduino – it’s much faster – but [Paul]’s library does everything more efficiently.
Even when using a standard Arduino, there are still speed and efficiency gains to be made when driving a TFT. [Xark] recently released his re-mix of the Adafruit GFX library and LCD drivers. It’s several times faster than the Adafruit library, so just in case you haven’t moved on the Teensy platform yet, this is the way to use one of these repurposed cell phone displays.
After reading about [Paul]’s experience with improving the TFT library for the Teensy, [Xark] grabbed an Arduino, an LCD, and an Open Workbench Logic Sniffer to see where the inefficiencies in the Adafruit library were. These displays are driven via SPI, where the clock signal goes low for every byte shifted out over the data line. With the Adafruit library, there was a lot of wasted time in between each clock signal, and with the right code the performance could be improved dramatically.
The writeup on how [Xark] improved the code for these displays is fantastic, and the results are impressive; he can fill a screen with pixels at about 13FPS, making games that don’t redraw too much of the screen at any one time a real possibility.