Ever wonder who is forking your code? [Jack] did, so he built a real time GitHub activity display for his company’s repositories. The display is based a Wyolum The Intelligent Matrix (TiM) board. The TiM is an 8 x 16 matrix of the ubiquitous WS2811/Smart Pixel/NeoPixel RGB LEDs with built-in controller. We’re seeing more and more of these serial LEDs as they drop in price. Solder jumpers allow the TiM to be used as 8 parallel rows of LEDs (for higher refresh rates), or connected into one long serial chain.
[Jack] wasn’t worried about speed, so he configured his board into a single serial string of LEDs. An Arduino drives the entire matrix with a single pin. Rather than reinvent the wheel, [Jack] used Adafruit’s NeoMatrix library to drive his display. Since the TiM uses the same LEDs as the Adafruit NeoPixel Matrix, the library will work. Chalk up another victory for open source hardware and software!
An Electric Imp retrieves Github data via WiFi and passes it on to the Arduino. This is a good use of a microcontroller such as the AVR on the Arduino. [Jack’s] display has a scrolling username. Every step in the scroll animation requires all the pixel data be clocked out to the TiM board. The Arduino can handle this while the IMP takes care of higher level duties.
Continue reading “Monitor GitHub Activity with an RGB LED Matrix”
We love Git. We know everyone has their favorite version tracking tools. But even those that don’t care for Git should see the value of getting meaningful Diff data from tracking Eagle layout files.
Was that last sentence just gibberish to you? Let’s take a step back. A few years ago it was impossible to use version control with Eagle at all because the schematic and PCB layout software used to save its files as binaries. But then Cadsoft transitioned to saving Eagle files as XML. This opened the door for things like scripting to rename parts en masse and to track the files under version control. One problem with the latter has been that performing a Diff on two different versions of a file results in XML changes that are probably not human readable. [Patrick Franken] wrote this script to add at least a glimmer of meaning.
We’d love to see some kind of side-by-side highlighting on the schematic or board renderings themselves. But that’s quite a ways off if we ever actually see it. For now his script will take the Diff and print out the tables seen above denoting which types of changes were made from one version to the next. It’s a start, and we hope it inspires even more work in this area.
We love using Git for its superior version control. We often host our more advanced projects in a public Github repository. But the bulk of our little experiments are simply local repos. This is fine if you’re always at home, but if we are away from home we find ourselves having to SSH into our server to copy over the Git files. [Andrew] found a way around this slightly awkward process. He used an old Android phone as a Git server.
This actually makes a lot of sense when you start to think about it. Most Android phone have a microSD card slot to provide a huge storage bin (the lack of this on the Nexus 4 is baffling) so you don’t need to worry about running out of space. All of these devices have WiFi, making it easy to use them as an AP when there isn’t any other WiFi around. And the web-connected nature of the device will make syncing your repo over the Internet a snap.
Most of the behind the scenes work is done using Debian packages. This provides a few issues which [Andrew] walks through one by one. We also like his pointers like using ‘noatime’ on your EXTx file systems to avoid wear on the SD card.
What happens if you’re a prolific developer and decide to release all of the source code from your work? Well, you should get a huge pat on the back from all interested parties. And so we say thank you to [Hunter Davis] for releasing the source code for his 70+ Android apps. But just making the decision isn’t the end of things, you’ve got actually get the code out there. And herein lies the hack. Instead of archiving and posting all of those projects he wrote a script to crawl, init, and push his projects to Github automatically.
This process is made pretty easy because of the Github API. Looks like he used version 2 for his script but you’ll want to check out version 3 if you’re looking to write your own script. His script takes the API key and username as command line arguments, then traverses his local source tree. Along the way it uses some text manipulation to sanitize the directories for use as the name of the repository. Once that’s established it steps into the directory, creates a repository, adds and commits all the files, then pushes them to Github.
Following [Hunter’s] example makes it really easy to share your code. We hope more will follow suit, putting their work out there for others to learn from and build upon.
We’ve seen some hardware hacks from [Hunter] as well. He did a bunch involving the ZipIt, as well as some work with playing games with a Dockstar.
There’s a fine line between solving problems that don’t exist and solving problems that no one recognizes until a solution is found. The former shows up with housewares peddled on late-night infomercials, while the latter is summed up by [Henry Ford], “If I asked people what they wanted, they would have said faster horses.” [Dave]’s method of storing microcontroller code in the cloud definitely falls into the ‘useful’ category.
[Dave] first realized the problem when he was digging around the IDEO Toy Lab and came across an orphan project, a Barbie credit card swiper. [Dave] had no idea if the firmware for this project was saved on the server, or even if the current version was available. One solution to this problem could be burning a copy of the source onto the Flash or EEPROM on the board.
There’s a problem with this idea, though: storing the source in an Arduino’s memory takes space. Thinking laterally, [Dave] realized that editing source happens on a computer, computers are connected to the Internet, so why not keep the source “in the cloud?”
[Dave]’s solution is to host the source on GitHub, and tie every piece of code to a board’s unique USB serial number. This gives every Arduno a unique ID, allows for version control, and libraries of multiple files.
This very clever addition to the Arduino IDE is up on GitHub
, ready to be added to any Arduino installation. Why the Arduino IDE doesn’t already have this feature is beyond us, but that’s what you get when you want a faster horse.