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.
Still need a crash course in what SPI actually does? [Bil Herd] has you covered with this SPI communication demo.
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.
For every problem, imagined or not, there’s a solution. Now, finally, Atmel has released a rad tolerant AVR for space applications. It’s the ATmegaS128, the space-grade version of the ‘mega128. This chip is in a 64-lead ceramic package, has all the features you would expect from the ATmega128 and is, like any ‘mega128, Arduino compatible.
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
Arduino “blink” sketch should run on any Arduino compatible board.
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!
In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!
[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.
The modified version of the Optiboot bootloader is available on [Majek]’s Github. If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.
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.
