Planning to make that carved a pumpkin last past Halloween night? Forget the tealight or LED candle—here’s an easy, no-solder project that will make it extra special. By default, this jack-o-lantern looks like it has a flickering flame, but get close enough to it and it goes crazy with color.
All you need is an LED matrix, a Rainbowduino to drive it, a PIR motion sensor to trigger the random colors, and a power source. [Alpha Charlie] kept the electronics from becoming pumpkin-flavored with some plastic bags. Since he used the PIR as the jack-o-lantern’s nose, there is a bit of plastic behind it to keep moisture from interfering.
[Alpha Charlie]’s build instructions are quite detailed, which makes this project even simpler if you’ve never used a PIR before. There are lots of ways you could build on this project to make it your own, like using trick-or-treater motion to trigger screams or spooky sounds, or add more sensors to make it more interactive. Watch it react after the break.
If you have nothing else at all to do between now and trick-or-treat time, you could bust out the soldering iron and recreate this 70-LED matrix jack-o-lantern. Blinkenlights too safe for your tastes? Fire-breather it is, then.
As we work on projects we’re frequently upgrading our tools. That basic soldering iron gives way to one with temperature control. The introductory 3D printer yields to one faster and more capable. One reason for this is we don’t really understand the restrictions of the introductory level tools. Sometimes we realize this directly when the tool fails in a task. Other times we see another hacker using a better tool and realize we must have one!.
The same occurs with software tools. The Arduino IDE is a nice tool for starting out. It is easy to use which is great if you have never previously written software. The libraries and the way it ties nicely into the hardware ecosystem is a boon.
When you start on larger projects, say you upgrade to a Due or Teensy for more code or memory space, the Arduino IDE can hamper your productivity. Moving beyond these limitations requires a new, better tool.
Where do we find a better tool? To begin, recognize, as [Elliot] points out that There is no Arduino “Language”, we’re actually programming in C or C++. We chose which language through the extension on the file, ‘c’ for C and ‘cpp’ for C++. An Arduino support library may be written in C or C++ depending on the developer’s preference. It’s all mix ‘n match.
Potentially any environment that supports C/C++ can replace the Arduino IDE. Unfortunately, this is not easy to do, at least for inexperienced developers, because it means setting up the language tool chain and tools for uploading to the board. A developer with that much experience might eschew an integrated development environment altogether, going directly to using makefiles as [Joshua] describes in Arduino Development; There’s a Makefile for That.
The reality is the Arduino IDE is not much more than a text editor with the ability to invoke the tools needed to compile and download the code to the Arduino. A professional IDE not only handles those details but provides additional capabilities that make the software development process easier.
The project took around 450 meters of RGB strips controlled by two Rainbowduinos and driven by sixty-four power Mosfets, sixty-four bipolar transistors, and a few other components. Producing white light from the LEDs draws 8 amps from the power supply.
The Rainbowduino is an ATmega328 Arduino compatible board with two MY9221 controllers. Each controller handles 12 channels of Adaptive Pulse Density Modulation. In other words, it makes the LEDs flash nicely. [Loren] used the Rainbowduino instead of some alternatives because multiple R’duinos can coordinate their activities over I2C.
The software part of the project did not work as well as the hardware. The light patterns were supposed to follow the music being played. A PC software package intended to drive the R’duinos produced just a muddy mess. Some kludges, including screen captures (!), driven by a batch file tamed the unruliness.
It’s been awhile, but a similar disco dance floor, built by [Chris Williamson] but not over a pool, previously caught our attention. [Chris] is a principle in Terror Tech that recently got a mention on Sparkfun.
The video after the break fortunately does not make a big splash, but is still electrifying.
The Leap Motion controller is a rather impressive little sensor bar that is capable of generating a massive 3D point cloud and recognizing hands and fingers to allow for gesture control based computing. It’s been out for a few years now but we haven’t seen many hackers playing with it. [Anwaarullah] has messed around with it before, but when it came time to submit something for India’s first Maker Faire, he decided to try doing an actual project with it.
Checking out the latest Leap Motion SDK, [Anwaarullah] realized many improvements had been made and he’d have to rewrite some of his original code to reflect the changes. This time around he’s opted to use the ESP8266 WiFi module instead of a Bluetooth one. He printed off a Raptor hand (from the wonderful folks at e-NABLE) and hooked it up with some RC servos to give him a nice robotic hand to control.
Maker Faire Rome is over, and that means it’s time for the Arduino media blitz. Arduino has already had a big announcement this week with the introduction of the Arduino / Genuino 101 board powered by the Intel Curie module. Team .cc hasn’t forgotten all their Atmel-powered boards though. The latest news is that Arduinos will be manufactured in Germany by Watterott Electronics (.de, Google Translate).
Right now, Arduino.cc boards are manufactured in China by Seeed, and in the US by Adafruit and Sparkfun. Watterott Electronics is one of the premier hobby electronics distributors in Germany.
Boards made by Watterott will carry the Genuino mark; Arduino.cc seems to anticipate a loss in the Arduino vs. Arduino trademark dispute outside the US. All boards produced under license from Arduino.cc sold outside the US will carry the Genuino trademark, whereas boards produced for the US market will carry the Arduino trademark. Interestingly, this Arduino vs. Arduino split began with a former manufacturer, with a maelstrom of pettiness stemming from that trademark dispute. In any case, the licensing for boards manufactured by Watterott is most assuredly worked out by now. The new manufacturing partner guarantees a greater supply of Arduinos for all.
Range finders are amazing tools for doing pretty much anything involving distance calculations. Want to blink some lights when people are nearby? There’s a rangefinder for that. Need to tell how far away the next peak of a mountain range is? There’s a rangefinder for that. But if you’re new to range finders and want one that’s hackable and configurable, look no further than the SF02/F rangefinder with the Arduino shield, and [Laser Developer]’s dive into what this pair can do.
Once the rangefinder and shield have been paired is when the magic really starts to happen. Using USB, the Arduino can instantly report a huge amount of raw data coming from the rangefinder. From there, [Laser Developer] shows us how to put the device into a “settings” mode which expands the capabilities of the rangefinder even more. The data can be dumped into a graph, for example, which can show trends between distance, laser strength, and many other data sets. [Laser Developer] goes one step further and demonstrates how to use this to calculate the speed of light, but from there pretty much anything else is possible as well.
And while you can just buy a rangefinder off the shelf, they are fairly limiting in their features and can cost exponentially more. This is a great start into using a tool like this, especially if you need specific data or have a unique application. But, if laser range finding isn’t for you or if this project is too expensive, maybe this $5 ultrasonic rangefinder will work better for your application.
For over ten years, Arduino has held onto its popularity as “that small dev-board aimed to get both artists and electronics enthusiasts excited about physical computing.” Along the way, it’s found a corner in college courses, one-off burning man rigs, and countless projects that have landed here. Without a doubt, the Arduino has a cushy home among hobbyists, but it also lives elsewhere. Arduino lives in engineering design labs as consumer products move from feature iterations into user testing. It’s in the chem labs when scientists need to get some sensor data into their pc in a pinch. Despite the frowns we’ll see when someone blinks an LED with an Arduino and puts it into a project box, Arduino is here to stay. I thought I’d dig a little bit deeper into why both artists and engineers keep revisiting this board so much.
Arduino, do we actually love to hate it?
It’s not unusual for the seasoned engineers to cast some glares towards the latest Arduino-based cat-feeding Kickstarter, shamelessly hiding the actual Arduino board inside that 3D-printed enclosure. Hasty? Sure. Crude, or unpolished? Certainly. Worth selling? Well, that depends on the standards of the consumer. Nevertheless, those exact same critical engineers might also be kicking around ideas for their next Burning Man Persistence-of-Vision LED display–and guess what? It’s got an Arduino for brains! What may seem like hypocrisy is actually perfectly reasonable. In both cases, each designer is using Arduino for what it does best: abstracting away the gritty details so that designs can happen quickly. How? The magic (or not) of hardware abstraction.
Meet HAL, the Hardware-Abstraction Layer
In a world where “we just want to get things blinking,” Arduino has a few nifty out-of-the-box features that get us up-and-running quickly. Sure, development tools are cross-platform. Sure, programming happens over a convenient usb interface. None of these features, however, can rival Arduino’s greatest strength, the Hardware Abstraction Layer (HAL).
A HAL is nothing new in the embedded world, but simply having one can make a world of difference, one that can enable both the artist and the embedded engineer to achieve the same end goal of both quickly and programmatically interacting with the physical world through a microcontroller. In Arduino, the HAL is nothing more than the collection of classes and function calls that overlay on top of the C++ programming language and, in a sense, “turn it into the Arduino programming language” (I know, there is no Arduino Language). If you’re curious as to how these functions are implemented, take a peek at the AVR directory in Arduino’s source code.
With a hardware abstraction layer, we don’t need to know the details about how our program’s function calls translate to various peripherals available on the Uno’s ATMEGA328p chip. We don’t need to know how data was received when Serial.available() is true. We don’t “need to know” if Wire.begin() is using 7-bit addressing or 10-bit addressing for slave devices. The copious amounts of setup needed to make these high-level calls possible is already taken care of for us through the HAL. The result? We save time reading the chip’s datasheet, writing helper functions to enable chip features, and learning about unique characteristics and quirks of our microcontroller if we’re just trying to perform some simple interaction with the physical world.
Cross-Platform Compatibility
Teensy 3.2 keeps form factor but adds on-chip hardware features compared to 3.1
There are some cases where the HAL starts to break down. Maybe the microcontroller doesn’t have the necessary hardware to simultaneously drive 16 servos while polling a serial port and decoding serial data. In some cases, we can solve this issue by switching Arduino platforms. Maybe we actually do need three serial ports instead of one (Teensy 3.2). Maybe we do need pulse-width-modulation (PWM) capability on every pin (Due). Because of the hardware abstraction layer, the rest of the source code can remain mostly unchanged although we may be switching chip architectures and even compilers in the process! Of course, in an environment where developing code for the target platform does matter, it doesn’t make sense to go to such efforts to write the general-purpose code that we see in Arduino, or even use Arduino in the first place if it doesn’t have the necessary features needed for the target end-goal. Nevertheless, for producing an end-to-end solution where “the outcome matters but the road to getting there does not,” writing Arduino code saves time if the target hardware needs to change before getting to that end goal.
HAL’s drawbacks
Of course, there’s also a price to pay for such nice things like speedy development-time using the HAL, and sometimes switching platforms won’t fix the problem. First off, reading the Arduino programming language documentation doesn’t tell us anything about the limitations of the hardware it’s running on. What happens, let’s say, if the Serial data keeps arriving but we don’t read it with Serial.read() until hundreds of bytes have been sent across? What happens if we do need to talk to an I2C device that mandates 10-bit addressing? Without reading the original source code, we don’t know the answers to these questions. Second, if we choose to use the functions given to us through the HAL, we’re limited by their implementation, that is, of course, unless we want to change the source code of the core libraries. It turns out that the Serial class implements a 64-byte ring buffer to hold onto the most recently received serial data. Is 64 bytes big enough for our application? Unless we change the core library source code, we’ll have to use their implementation.
Both of the limitations above involve understanding how the original HAL works and than changing it by changing the Arduino core library source code. Despite that freedom, most people don’t customize it! This odd fact is a testament to how well the core libraries were written to suit the needs of their target audience (artists) and, hence, Arduino garnered a large audience of users.
Pros of Bare-Metalspeak
digitalWrite takes a whopping 52-55 cycles to change pin direction! [image source]Are there benefits to invoking the hardware directly? Absolutely. A few curious inquirers before us have measured the max pin-toggling frequency with digitalWrite to be on the order of ~100 KHz while manipulating the hardware directly results in a pin-toggling frequency of about 2 MHz, about 20 times faster. That said, is invoking the hardware directly worth it? Depends, but in many cases where tight timing isn’t a big deal and where the goal of a functional end-to-end system matters more than “how we got there,” then probably not! Of course, there are cases when tight timing does matter and an Arduino won’t make the cut, but in that case, it’s a job for the embedded engineer.
Use the HAL, Luke!
To achieve an end-to-end solution where the process of “how we got there” matters not, Arduino shines for many simple scenarios. Keep in mind that while the HAL keeps us from knowing too many details about our microcontroller that we’d otherwise find in the datasheet, I don’t proclaim that everyone throw out their datasheets from here on out. I am, however, a proponent of “knowing no more than you need to know to get the job done well.” If I’m trying to log some sensor data to a PC, and I discover I’ll be saving a few days reading a datasheet and configuring an SPI port because someone already wrote SPI.begin(), I’ll take an Arduino, please.
If you’ve rolled up your sleeves and pulled out an Arduino as your first option at work, we’d love to hear what uses you’ve come up with beyond the occasional side-project. Let us know in the comments below.
The project took around 450 meters of RGB strips controlled by 
It’s not unusual for the seasoned engineers to cast some glares towards the latest Arduino-based cat-feeding Kickstarter, shamelessly hiding the actual Arduino board inside that 3D-printed enclosure. Hasty? Sure. Crude, or unpolished? Certainly. Worth selling? Well, that depends on the standards of the consumer. Nevertheless, those exact same critical engineers might also be kicking around ideas for their next Burning Man Persistence-of-Vision LED display–and guess what? It’s got an Arduino for brains! What may seem like hypocrisy is actually perfectly reasonable. In both cases, each designer is using Arduino for what it does best: abstracting away the gritty details so that designs can happen quickly. How? The magic (or not) of hardware abstraction.
Of course, there’s also a price to pay for such nice things like speedy development-time using the HAL, and sometimes switching platforms won’t fix the problem. First off, reading the Arduino programming language documentation doesn’t tell us anything about the limitations of the hardware it’s running on. What happens, let’s say, if the Serial data keeps arriving but we don’t read it with Serial.read() until hundreds of bytes have been sent across? What happens if we do need to talk to an I2C device that mandates 10-bit addressing? Without reading the original source code, we don’t know the answers to these questions. Second, if we choose to use the functions given to us through the HAL, we’re limited by their implementation, that is, of course, unless we want to change the source code of the core libraries. It turns out that the Serial class implements a 64-byte ring buffer to hold onto the most recently received serial data. Is 64 bytes big enough for our application? Unless we change the core library source code, we’ll have to use their implementation.![digitalWrite takes a whopping 52-55 cycles to change pin direction! [image source]](https://hackaday.com/wp-content/uploads/2015/10/arduino-digital-write-pin-toggle.jpg?w=400)
