Making a clock with a common microcontroller like an Arduino isn’t very difficult. However, if you’ve tried it, you probably discovered that keeping track of wall time is difficult without some external hardware. [Barzok] has a very minimal clock build. It takes a handful of LED arrays with an integrated driver, an Arduino Nano, a real-time clock module, and a voltage regulator.

The software uses a custom 6×9 font and handles addressing the LEDs as one single display. Because the real time clock module is so accurate, there’s no provision for setting the time. [Barzok] says that twice a year he just hooks the Arduino up and reflashes the program with a new start time and that seems to be sufficient.

It wouldn’t be too hard, though, to add a few buttons to allow for setting the time or accepting other user input. Then again, this is a minimal build. It would be a good starter project for someone looking to get into building microcontroller projects.

If you want really minimal, you could go with a 4 LED clock (but you better know the resistor color code). Of course, an ESP8266 can serve as a simple clock and it gets set via NTP which is even better.

The 1970s called and they want their rotary dial cell phone back.

Looking for all the world like something assembled from the Radio Shack parts department – remember when Radio Shack sold parts? – [Mr_Volt]’s build is a celebration of the look and feel of a hobbyist build from way back when. Looking a little like a homebrew DynaTAC 8000X, the brushed aluminum and 3D-printed ABS case sports an unusual front panel feature – a working rotary dial. Smaller than even the Trimline phone’s rotating finger stop dial and best operated with a stylus, the dial translates rotary action to DTMF tones for the Feather FONA board inside. Far from a one-trick pony, the phone sports memory dialing, SMS messaging, and even an FM receiver. But most impressive and mysterious is the dial mechanism, visible through a window in the wood-grain back. Did [Mr_Volt] fabricate those gears and the governor? We’d love to hear the backstory on that.

This isn’t the first rotary cell phone hybrid we’ve featured, of course. There was this GSM addition to an old rotary phone and this cell phone that lets you slam the receiver down. But for our money a rotary dial cell phone built from the ground up wins the retro cool prize of the bunch.

[via r/Arduino]

In case you missed it, the big news is that a minimal Arduino core is up and working on the ESP32. There’s still lots left to do, but the core functionality — GPIO, UART, SPI, I2C, and WiFi — are all up and ready to be tested out. Installing the library is as easy as checking out the code from GitHub into your Arduino install, so that’s exactly what I did.

I then spent a couple days playing around with it. It’s a work in progress, but it’s getting to the point of being useful, and the codebase itself contains some hidden gems. Come on along and take a sneak peek.

The Core

An Arduino isn’t worth very much unless it can talk to the outside world, and making the familiar Arduino commands work with the ESP32’s peripheral hardware is the job of the core firmware. As of this writing, GPIO, WiFi, SPI and I2C were ready to test out. GPIO means basically digitalWrite() and digitalRead() and there’s not much to say — they work. WiFi is very similar to the ESP8266 version, and aside from getting the ESP32 onto our home WiFi network, I didn’t push it hard yet. When other libraries come online that use WiFi, I’ll give it a second look.

SPI

The SPI routines in the ESP32 Arduino port both work just fine. I tested it out by connecting a 25LC256 SPI EEPROM to the chip. The ESP’s extremely flexible hardware peripheral routing matrix allows it to assign the SPI functions to any pins, but the Arduino implementation is preset to a default pinout, so you just need to look it up, and hook up MOSI to MOSI and so on. As of now, it only uses one of the ESP32’s two free SPI units.

With SPI, some of the weirdness of using Arduino on a powerful chip like the ESP32 start to poke through. To set the speed of the SPI peripheral, you can use the familiar SPI_CLOCK_DIV_XX macros, only they’re scaled up to match the ESP32’s faster CPU clock speed. The end result is that SPI_CLOCK_DIV_16 gives you a 1 MHz SPI bus on either the 16 MHz Uno or the 240 MHz ESP32, which is probably what you want for compatibility with old code. But 240 divided by 16 is not 1. In retrospect, the macros would be better defined in terms of the desired frequency rather than the division factor, but you can’t go back in time.

There were also two extra definitions that I had to add to the program to make it run, but they’ve both been streamlined into the mainline in the last eighteen hours. That’s the deal with quickly evolving, openly developed software. One day you write that the macro MSBFIRST isn’t defined, and before you can go to press, it’s defined right there in Arduino.h. Great stuff!

I2C: The Wire

The I2C (“Wire”) library has also gotten the ESP32 treatment, and worked just as it should with an LM75 temperature sensor. This is my standard I2C test device, because it lets you read a few registers by default, but you can also send the sensor a few configuration options and read them back out. It’s not a particularly demanding device, but when it works you know the basics are working. And it did.

The ESP’s dedicated I2C pins are on GPIO 21 and 22 for data and clock respectively. Some I2C implementations will use the microcontroller’s pullup resistors to pull the I2C bus lines high, so I tested that out by pulling the 10 KOhm resistors out. The ESP stopped getting data back instantly, so that answers that. Don’t forget your pullup resistors on the I2C lines and all is well. Otherwise, it’s just connecting up two wires, double-checking the I2C device address, and reading in the data. That was easy.

External Libraries

More than half of the reason to use Arduino is the wide range of external, add-on libraries that make interfacing with all sorts of hardware easy and painless. Many of these libraries are built strictly on top of the Arduino core, and should “just work”. Of course, when you’re actually coding this close to the hardware, nothing is going to be as portable as it is a few layers of abstraction higher up on your desktop computer. Let’s go test this hypothesis out.

El Cheapo IL9341 TFT Display

Since the SPI library works out of the box, the other various libraries that depend on it should as well, right? Well, kinda. I wasted an afternoon, and still failed. Why? I have a cheapo ILI9341 screen that only works with an old TFTLCD library, rather than with the nice Adafruit_ILI9341 libs. The former is so full of AVR-specific voodoo that it completely fails to compile, and is probably easier to re-write from scratch for the ESP32 than make work in its present form. The Adafruit library compiles fine, because it only depends on the SPI library, but it doesn’t work with my lousy screen.

Going repeatedly back and forth between these two libraries, my LCD experiment ended in tears and frustration: I couldn’t make either of them work. I scoped out the SPI data on a logic analyser, and it looked good, but it wasn’t drawing on the screen. At this point, a full line-by-line protocol analysis would have been needed, and that’s a few days worth of work. If I just wanted a running ILI9341 driver, I would go grab [Sprite_tm]’s NES emulator demo and use the one there, but it’s not Arduinified yet, so it’s out of bounds for the scope of this article.

DHT22 Humidity and Temperature Sensor

Seeking a quick-and-dirty success, and beaten down by hours of hacking away for naught, I pulled a DHT22 sensor out of the eBay bin, and cloned Adafruit’s DHT library. Of course it didn’t compile straight out of the box, but there were only a couple of things that were wrong, and both turned out to be easily fixable.

ESP32’s Arduino didn’t have a microsecondsToClockCycles() function yet so I commented it out, multiplied by 240 MHz, and left a hard-coded constant in my code. This value was just used for a timeout anyway, so I wasn’t too worried. There are also some timing-critical code sections during which the Adafruit code uses an InterruptLock() function to globally enable and disable interrupts, but these functions weren’t yet implemented, so I just commented it all out and crossed my fingers.

After reassigning the data pin to one of the ESP32’s free ones (GPIO 27, FWIW), it compiled, uploaded, and ran just fine. I now know exactly how hot and humid it is up here in my office, but moreover have had a quick success with an Arduino external library, and my faith is restored.

Lessons from the Libraries

I suspect that these two examples are going to be representative of the ESP32-Arduino experience for a little while. Oddball hardware is going to take some time to get supported. Highly optimized libraries with cycle-correct timings or other microcontroller-architecture specific code in them will need to be ported over as well, despite being “Arduino” code. If you’re a code consumer, you’ll just have to wait while the wizards work their behind-the-scenes magic.

But there will also be a broad group of libraries that are written in a more-or-less device-independent way, and these should be easy enough to get working within fifteen minutes or so, as with the DHT sensor library. If you’re willing to compile, read the errors, and comment out or fix whatever shows up, some codebases will work in short order.

What’s Next? Turning Servos

Given that the Arduino-ESP32 port is brand new, indeed it’s still in progress, there is a lot of work for the community to do in getting it up to speed. Suppose that you need to drive a lot of servos, but the “Servo” library isn’t implemented yet. You’re an impatient coder. What to do? Get hacking!

The good news is that the Arduino-ESP32 libraries themselves are full of hints and examples for getting started. Open up the ESP32-specific directory that you cloned from GitHub. The usual *.cpp files provide the standard Arduino core functionality. The esp32-hal-xxx.h and esp32-hal-xxx.c files are chip-specific, and a tremendous help in taking advantage of the chip’s stranger options. For instance, esp32-hal-matrix.* gives you nice and easy access to the pin-routing matrix, which is a daunting task if you’re starting just from the datasheet.

But let’s get back to servos. The ESP32 chip has an intriguing hardware LED PWM peripheral that lets you assign up to sixteen channels to individual LEDS, specify the PWM frequency and bit-depth, and then control them by appropriately setting bits in hardware registers. If you think this would be hard to do by hand, you’d be right. The esp32-hal-ledc.* files provide helper functions to set up the hardware PWM generator, and with these libraries, getting a 16-bit LED fade in straight C or “Arduino” is easy. But our sights are set on servos.

To drive a hobby servo, one needs pulses between 1,000 and 2,000 microseconds each, repeated every twenty milliseconds or so. Setting the repetition rate to 50 Hz takes care of the first part, and each count is 20 ms / 65,635 ticks long, or roughly 0.3 microseconds. Setting the PWM width value to something between 3,300 and 6,500 generates pulses in the right ballpark, and my servo ran jitter-free (and a clean signal was confirmed on the oscilloscope). Here’s all it took:

#include "esp32-hal-ledc.h"
void setup() {
   ledcSetup(1, 50, 16); // channel 1, 50 Hz, 16-bit depth
   ledcAttachPin(22, 1);   // GPIO 22 on channel 1
}

void loop() {
   for (int i=3300 ; i < 6500 ; i=i+100){
    ledcWrite(1, i);       // sweep the servo
    delay(100);
   }
}

That wasn’t so hard, was it? It’s not “Arduino”-style — there’s no objects or classes or methods anywhere in sight — but thanks to a straightforward and well-written hardware abstraction layer, using the very complicated peripherals is made pretty simple. Kudos to [me-no-dev] for his work on the back-end here. The HAL inside the Arduino libraries is currently the best source of code examples on many of the chip’s more esoteric and interesting peripherals.

Conclusion?

The short version of my dive into Arduino-esp32 is that there’s a lot here, even though it’s not done yet. Blinking LEDs and other simple GPIO is a given, and the core communication libraries that are already implemented worked for me: GPIO, WiFi, SPI, and I2C are up and running.

Non-core libraries are hit and miss. I suspect that a lot of them will work with just a little bit of tweaking. Others, especially those that are architecture-dependent, may not be worth the effort to port and will need to be re-written. The ESP32 has a bunch of interesting and innovative hardware peripherals onboard and there’s certainly no Arduino libraries written for them yet, but there’s some great HAL code hidden away in the Arduino-ESP32 codebase that’ll give you a head start. We could get lost in there for hours. Time to get hacking!

The ESP32 is still a new chip, but orders should be coming in soon. Have one? Want to see us put other libraries or languages through their paces? Let us know in the comments.

Sometimes the technology part of a project isn’t the hard part. It is having an idea for something both useful and doable. Sure, a robot butler that would do your cleaning and laundry would be useful, but might be out of reach for most of us. On the other hand, there’s only so many use cases for another blinking LED.

[Martinhui] knows how to use an ultrasonic sensor with an Arduino. Driving a motor isn’t that hard, either. The question is: what do you do with that? [Martin’s] answer: Automate a trash can. You can see a video of the result, below.

You can find commercial versions of this, of course, but what fun is that? The can is a bit small, but a larger motor or a different mechanical design could scale it up easily.

As robotic trash cans go, this isn’t that ambitious, but it is highly doable. If only it connected to the Internet.

There was a time, not so long ago, when all the cool kids were dual-booting their computers: one side running Linux for hacking and another running Windows for gaming. We know, we were there. But why the heck would you ever want to dual-boot an Arduino? We’re still scratching our heads about the application, but we know a cool hack when we see one; [Vinod] soldered the tiny surface-mount EEPROM on top of the already small AVR chip! (Check the video below.)

Aside from tiny-soldering skills, [Vinod] wrote his own custom bootloader for the AVR-based Arduino. With just enough memory to back up the AVR’s flash, the bootloader can shuffle the existing program out to the EEPROM while flashing the new program in. For more details, read the source.

While you might think that writing a bootloader is deep juju (it can be), [Vinod]’s simple bootloader application is written in C, using a style that should be familiar to anyone who has done work with an Arduino. It could certainly be optimized for size, but probably not for readability (and tweakability).

Why would you ever want to dual boot an Arduino? Maybe to be able to run testing and stable code on the same device? You could do the same thing over WiFi with an ESP8266. But maybe you don’t have WiFi available? Whatever, we like the hack and ‘because you can’ is a good enough excuse for us. If you do have a use in mind, post up in the comments!

With All Hallow’s Eve looming close, makers have the potential to create some amazing costumes we’ll remember for the rest of the year. If you’re a fan of the hugely addict-*cough* popular game Minecraft, perhaps you’ve considered cosplaying as your favorite character skin, but lacked the appropriate props. [Graham Kitteridge] and his friends have decided to pay homage to the game by making their own light-up Minecraft swords.

These swords use 3D-printed and laser-cut parts, designed so as to hide the electronics for the lights and range finder in the hilt. Range finder? Oh, yes, the sword uses an Arduino Uno-based board to support NewPixels LEDs and a 433Mhz radio transmitter and receiver for ranged detection of other nearby swords that — when they are detected — will trigger the sword to glow. Kind of like the sword Sting, but for friendlies.

All of the files for the parts are available on the project’s Thingverse page and the board setup can be purchased here. If you want to have some fun controlling the real world from inside Minecraft, check out how this fan uses it to turn on lamps in their home.

Nobody’s perfect. Sometimes you’re up late at night writing a blog post and you stumble upon an incredible story. You write it up, and it ends up being, well, incredible. IEEE Spectrum took the bait on this video (embedded below) where [Keran McKenzie] claims to have built a self-driving car for under $1,000 AUS with Arduinos.

The video is actually pretty funny, and we don’t think it’s intended to be a mass-media hoax as much as a YouTube joke. After letting the car “take over” for a few seconds, it swerves and [Keran] pretends to have hit something. (He’s using his knees people!) There are lots of takes with him under the car, and pointing at a single wire that supposedly makes the whole thing work. Yeah, right.

We were a bit bummed, though. We don’t think you can even reliably interface a sensor system with the steering wheel, accelerator, and brakes for as little as one grand, but we would have been entirely happy to see it done. We’re not saying that the software to run an autonomous car is the easy part, but we’d love to have a hack at it if the hardware were affordable.

Anyway, if you’re looking for a real autonomous driving experience, we recommend starting by hacking RC cars and giving them substantially bigger brains than an Arduino. Once you’ve got that working, making progress to a real car is doable, but expensive. And it helps to be [geohot].

And lest you think we’re all holier-than-thou, check out our most embarrassing post ever. We could just curl up and die. Feel better soon, IEEE Spectrum!

Thanks [jpiat] for the tip!

[Tim] was tired of compromising his portrait-oriented digital photos by shoehorning them into landscape-only frames. Unable to find a commercial solution, he built his own rotating digital photo frame from a 27″ LCD TV.

It uses a Raspi 3 to find [Tim]’s pictures on a giant SD card. He originally wanted to have the Pi pull pictures from Google Photos and display them randomly, but the API doesn’t work in that direction. Instead, a Python script looks at the pictures on the SD card and determines whether each is landscape or portrait-oriented. If a picture was taken in portrait-mode, the display will rotate 90 degrees. Rotation is handled with an Arduino, a stepper motor, and some 3D-printed herringbone gears. The first version was a bit noisy, so [Tim] re-printed the motor mount and the pinion gear out of flexible filament.

[Tim] designed the mount and frame himself and laser-cut the pieces out of birch plywood. We like that he accounted for the front-heaviness and that he covered the high voltage circuitry with acrylic to mitigate the risk of shock. All the code and design files are available on his project page. Make the jump to see a brief demonstration followed by a walk-through and stay for the six-minute slide show.

In our eyes, there isn’t a much higher calling for Arduinos than using them to make musical instruments. [victorh88] has elevated them to rock star status with his homemade electronic drum kit.

The kit uses an Arduino Mega because of the number of inputs [victorh88] included. It’s not quite Neil Peart-level, but it does have a kick drum, a pair of rack toms, a floor tom, a snare, a crash, a ride, and a hi-hat. With the exception of the hi-hat, all the pieces in the kit use a piezo element to detect the hit and play the appropriate sample based on [Evan Kale]’s code, which was built to turn a Rock Band controller into a MIDI drum kit. The hi-hat uses an LDR embedded in a flip-flop to properly mimic the range of an actual acoustic hi-hat. This is a good idea that we have seen before.

[victorh88] made all the drums and pads out of MDF with four layers of pet screen sandwiched in between. In theory, this kit should be able to take anything he can throw at it, including YYZ. The crash and ride cymbals are MDF with a layer of EVA foam on top. This serves two purposes: it absorbs the shock from the sticks and mutes the sound of wood against wood. After that, it was just a matter of attaching everything to a standard e-drum frame using the existing interfaces. Watch [victorh88] beat a tattoo after the break.

If you hate Arduinos but are still reading for some reason, here’s a kit made with a Pi.

Building an arcade cabinet seems to be a rite of passage for many hackers and woodworkers. Not that there is anything wrong with that: as this series of posts from [Alessandro] at boxedcnc shows, there is an art to doing it well.

His final build is impressive, with quality buttons, a genuine-looking banner, and even a coin slot so he can charge people to play. His build log covers both the carpentry and electronic aspects of the build, from cutting the panels to his own code for running the coin acceptor that takes your quarter (or, as he is in Italy, Euro coins) and triggers the game to play.

To extract money from his family, he used the Sparkfun COM-1719 coin acceptor, which can be programmed to send different pulses for different coins, connected to an Arduino which is also connected to the joystick and buttons. The Arduino emulates a USB keyboard and is connected to an old PC running MAME with the Attract Mode front end. It’s a quality build, down to the Bubble Bobble banner, and the coin slot means that it might even make some money back eventually.