There are plenty of techniques and components that we use in our everyday hardware work, for which their connection and coding is almost a done deal. We are familiar with them and have used them before, so we drop them in without a second thought. But what about the first time we used them, we had to learn somewhere, right? [TheMagicSmoke] has produced just what we’d have needed then for one component that’s ubiquitous, the I2C EEPROM.
These chips provide relatively small quantities of non-volatile memory storage, and though they are not the fastest of memory technologies they have a ready application in holding configuration or other often-read and rarely written data.
Since the ST24C04 512-byte device in question has an I2C bus it’s a straightforward add-on for an Arduino Mega, so we’re shown the wiring for which only a couple of pull-down resistors are required, and some sample code. It’s not the most complex of projects, but it succinctly shows what you need to do so that you too can incorporate an EEPROM in your work.
[David Johnson-Davies] always wanted an illuminated button matrix for projects, but cost was never very friendly. That all changed when he discovered a cheap source of illuminated pushbuttons on Aliexpress, leading to this DIY 4×4 illuminated button matrix design which communicates over I2C. The button states can be read independently of setting the light pattern, and an optional interrupt signal gets pulled low whenever there is a change detected. Not bad for one PCB plus about $10-worth in components!
The device uses every single pin on an ATtiny88, and because each button gets its own pin the keypresses can be detected with pin-change interrupts. The state reporting of buttons over I2C is unambiguous, even when multiple buttons are pressed simultaneously. A simple protocol provides all the needed functionality, and all connections are brought to the board’s edge to allow for easily tiling multiple panels.
The GitHub repository contains the code and PCB files and [David] helpfully shared the board files to OSH Park and PCBWay for easy ordering. In addition, he provides two demos (Tacoyaki and Tacoyaki+) which are games related to the classic Lights Out to show off the matrix.
The Wii controller will likely go down in history as the hacker’s favorite repurposed input device, and there’s no question that the Raspberry Pi is the community’s top pick in terms of Linux single board computers. So it should come as little surprise that somebody has finally given us the cross-over episode that the hacking community deserves: the PiChuk, a Pi Zero inside of Nintendo’s motion-sensing “nunchuk”.
Veterans of Wii Sports might be wondering how the hero of our story, a hacker by the name of [keycaps], managed to pull off such a feat. The Pi Zero is small, but it’s not that small. The trick is that the case of the nunchuk has been extended by way of a new 3D printed bottom half.
There’s more than just a Pi Zero along for the ride, as well. [keycaps] has manged to sneak in a 750 mAh LiPo and an Adafruit Powerboost, making the device a completely self-contained system. Interestingly, the original nunchuk PCB remains more or less untouched, with just a couple of wires connected to the Pi’s GPIO ports so it can read the button and stick states over I2C.
We know you’re wondering why [keycaps] went through the trouble of breaking out the HDMI port on the bottom. It turns out, the PiChuk is being used to drive a Vufine wearable display; think Google Glass, but without the built-in computing power. The analog stick and motion sensing capabilities of the controller should make for a very natural input scheme, as far as wearable computers go.
By now most of us have used a Raspberry Pi at some level or another. As a headless server it’s a great tool because of its price point, and as an interface to the outside world the GPIO pins are incredibly easy to access with a simple Python script. For anyone looking for guidance on using this device at a higher level, though, [Arun] recently created a how-to for using some of the Pi’s available communications protocols.
Intended to be a do-everything “poor man’s hardware hacking tool” as [Arun] claims, his instruction manual details all the ways that a Raspberry Pi can communicate with other devices using SPI and I2C, two of the most common methods of interacting with other hardware beyond simple relays. If you need to go deeper, the Pi can also be used as a full JTAG interface or SWD programmer for ARM chips. Naturally, UART serial is baked in. What more do you need?
As either a tool to keep in your toolbox for all the times you need to communicate with various pieces of hardware, or as a primer for understanding more intricate ways of using a Raspberry Pi to communicate with things like sensors or other computers, this is a great write-up. We also have more information about SPI if you’re curious as to how the protocol works.
We often talk about the advantages of modular hardware here at Hackaday; the ability to just order a few parts online, hook them up with some jumper wires, and move onto the software side of things is a monumental time saver when it comes to prototyping. So anytime we see a new module that’s going to save us time and aggravation down the road, we get a bit excited.
Today we present the very slick I2CNavKey developed by [Saimon], a turn-key interface solution for your builds that can’t quite get away with a couple toggle switches. It not only gives you a four-way directional pad with center button, but a rotary “wheel” like on the old iPods. All of which you can access easily and with a minimum of wiring thanks to the wonders of I2C.
But even that might be selling the module short. This isn’t just a couple of buttons on a breakout board, the I2CNavKey is powered by its own PIC16F18345 microcontroller and features three configurable GPIOs with PWM support (perfect for an RGB LED) plus 256 bytes of onboard EEPROM storage.
[Saimon] has released the entire project as open source hardware for your hacking pleasure, but you can also get them as ready-to-use modules on Tindie for $18 USD [Editor’s Note: Because of a typo we originally we left the 1 out of the price]. Whether you’re a paying customer or not, you get access to the project’s absolutely phenomenal documentation, including a nearly 30 page manual that contains everything you’d ever want to know about the I2CNavKey and how to integrate it into your project. If all hardware was documented with this level of dedication, the world would be a much nicer place for folks like us.
Listen, it hurts to hear, but somebody needs to say it. It’s over, OK? You’ve got to admit it and move on. Sure, you could get away with it for a week or two in January, but now it’s just getting weird. No matter how hard you fight it, the facts are the facts: the holidays are over. It’s time to pack up all those lights and decorations before the neighbors really start talking.
But don’t worry, because there’s an upside. Retailers are now gearing up for their next big selling season, which means right now clearance racks the world over are likely to be playing home to holiday lights and decor. That wouldn’t have been very interesting to the average hacker or maker a few years ago, after all, there’s only so much you can do with a string of twinkle lights. But today, holiday decorations are dripping with the sort of high-tech features you’d expect from gadgets that are actively aiming to be obsolete within the next ten months or so.
Case in point, the “AppLights Personalized Projection” which I found sulking around the clearance section of the Home Depot a couple weeks back. This device advertises the ability to project multi-color custom messages and animations on your wall, and is configured over Bluetooth with a companion application on your Android or iOS device. At a minimum we can assume the device must contain a fairly powerful RGB LED, an LCD to shine the light through, and some sort of Bluetooth-compatible microcontroller. For $20 USD, I thought it was worth taking a shot on.
Around this time last year, the regular Hackaday reader may recall I did a teardown for a Christmas laser projector. Inside we found red, green, and blue lasers of considerable power, as well as all the optics and support hardware to get them running. It was a veritable laser playground for $14. Let’s see if the AppLights projector turns out to be a similar electronic cornucopia, and whether or not we’ve got a new Hackaday Holiday tradition on our hands.
Inexpensive OLED displays with I2C interfaces abound, but there is a catch: they tend to be stuck on I2C address 0x3C. Some have a jumper or solder pads to select an alternate (usually 0x3D), but they lack any other method. Since an I2C bus expects every device to have a unique address, this limits the number of displays per bus to one (or two, at best.) That is all still true, but what [Larry Bank] discovered is a way to get multiple OLED displays working with considerably fewer microcontroller pins than usually needed.
While bit-banging I2C to host one display per bus on the same microcontroller, an idea occurred to him. The I2C start signal requires both clock (SCL) and data (SDA) to be brought low together, but what would happen if the displays shared a single clock line? To be clear, each OLED would — logically speaking — still be on its own I2C bus with its own data line, but they would share a clock signal. Would a shared clock cause attached devices to activate unintentionally?
A quick test consisting of four OLED displays (all with address 0x3C) showed that it was indeed possible to address each display with no interference if they shared a clock. Those four individually controlled displays needed only five I/O lines (four SDA, one shared SCL) instead of eight. The Multi_OLED library is available on GitHub, and in case it is useful for devices other than OLED displays, bit-banged I2C with support for shared clock lines is available separately.
There’s more to do with OLEDs than get clever with signals: check out these slick number-change animations, and that even looks to be a project that could benefit from a few saved GPIO pins, since it uses one small display per digit.