It's been a while since my last update. In that time, I've been working on a few projects here in there. As for MEGA_MATRIX, I've added support for the Arduino MEGA and have been able to do a few proof of concept stuff for the Raspberry Pi. The Pi version right now can get a whopping 20K FPS in the native C version! The Pi version isn't too functional right now, but expect soon enough. Link to source on GitHub.

Since the end of the summer, I've been working on my own Animation tool. It's not much right now, but you can find Linux and OS X binaries right over here. Here's the first thing I was able to make with it, a bouncing ball:

After tinkering with Arduinos for more two and a half years, I still find it a lot of fun just to turn LEDs on and off. What's more fun than that? Turning on and off a bunch of LEDs. When I first got my starter kit I ordered an 8x8 LED matrix along with it. I have whatsoever no formal training in electronics, so it took me a while to figure out how to use that thing. Using the magic of Charlieplexing I was able to get a small, very tiny image lit. Not satisfied with having an extra 64 LEDs at my disposal, I wanted to go bigger; I needed a 3x3 of 8x8's, a 24x24, I wanted 576 LEDs to blink on and off at my whim. There were a few challenges along the way.

The Arduino UNO R3 doesn't have enough I/O pins for this by itself (I'd need a good 48). The simple solution to this was use use some 74HC595 shift registers. By daisy-chaining two sets of three (one to act as the row controller and the other for the column), I could get away with only using six pins. Though it's possible that I could have used less. The final product uses ten pins on the Arduino (to have better control of the MR and OE pins on the shift register).

I originally planned to lay this all out on a protoboard, but as you can see from the below picture, it started to get really frustrating and confusing. I always wanted to learn how to make PCBs, so I though this would be a good opportunity to do so. I got myself a copy of KiCad, read a few tutorials, then went to work. I was actually surprised how easy it was to use this software. I did have some frustrations. Like that it's kind of half broken on Linux/GNU. It's only really usable under Windows or Wine (though there are still some quirks).

After receiving the print of the schematic, I found out that the footprints for the 788BS matrix were off, and the through holes where not wide enough. This wasn't a fun discovery. The next day, I spent a good two hours re-routing everything. I also added a CSH logo to the edge cuts. While I was waiting for the fixed boards to arrive I started to write the software to control the monstrous matrix. To my surprise, the circuit actually worked (this is on the bad board), and all I had to do was put globs of solder onto the pads and bend the pins on the 8x8 matrix. I also found out that it was a bit better to use a 200 Ohm resistor instead of 1K.

 

When using Arduino functions “digitalWrite(),” and “digitalRead(),” they may work okay for an 8x8 matrix, but I found out that on a 24x24, it doesn't work that well. I was getting around 75-ish frames per second. While I could have gotten away with showing a still image, it wasn't the easiest thing on the eyes. After doing some reading it seemed like writing some AVR C might be the remedy. One of the great things about the Arduino platform is that you can mix in AVR C code. After using C code to drive the matrix, I was getting around 625 frames per second. All of these measurements were made using timers and mathematics.

Now since I could display one image, the next logical step was to display a moving image. It only took another few hours of work to make this a possibility. The Arduino is always listening for data on its serial line. Once it has read in a full 72 bytes, it will display up a new picture. I also drafted a small pseudo scripting language where you can specify files to act as frames, assign them a delay, put them in a certain sequence, then have it loop.

If you want to check out the code for the project, you can find the repo right here: https://github.com/define-private-public/MEGA_MATRIX

And if you want a board, just send me a message. I've got a few to spare.

I've been a little bit busy lately for the past week. I've had to move down to Cincinnati for my current Co-Op and it took much longer to prepare, move, and get settled in than I though it would. I've been a little bit delayed on making this post, but better late than never.

Early in my summer vacation I went down to D.C. on a small trip. While visiting the Smithsonian Institute and picked up one of those crystal growing kits. I remember playing with one when I was much younger (around ten or so) and thought it would be fun to grow another one. They didn't have the blue color anymore, so I opted to get a pack labeled “Emerald.” I thought it would be extra fun to do a timelapse of the crystal growing.

It took a few days to write a decent application to do this. My tools were C++, OpenCV, ffmpeg, and a very low resolution webcam. The app comes in two parts:

1. Capture softare
2. A script to compile images

Once everything was setup, I set the software to run for just five days, taking one picture per minute. The package said that it would only take that long for the crystal to grow, but that was a lie. I had to run the setup for two weeks and half a day. This resulted in 21,000+ images (totaling 1.5 GB of disk space).

I wanted to run the film at 30 fps, but 21,000+ images would result in something around fifteen minutes long, so I only used every fifth image for the final movie. You can it below:

I'm sorry that I don't have any other photographs of the crystal, or the “Magical Crystal Fun-Box,” that I grew it in. You'll just have to use your imagination for that last one. Source code for the application can be found here on my github.

During my spring break (sometime in March), I decided to revisit my old CHIP-8 emulator that I made in the beginning of the school year.

I consider both to be separate projects. There are quite a few differences between the new one and the older one.

 

Done in C++ instead of C

C is a lot of fun and this could have been done without the help of classes, but I felt using an object orient approach to this made a bit more sense and made components of the CHIP-8 machine a bit more reusable.

 

Uses the newer SDL2 library

This is not too much of an advancement, except that the emulator is a bit more future proof. I've been looking for an excuse to learn the differences between the newer and older SDL libraries and I think this gave a pretty good foundation. So far I really like the changes that have been made to the API.

 

Much better modularized and cleaned up

The older emulator was essentially a one source file behemoth. In this one, I looked at the CHIP-8 machine as a hole and split it up into smaller parts that would be interconnected. For instance, there are separate Display, CPU, Stack, Memory and Buzzer objects. One of the original ideas was to have a version that ran on SDL2 and another on Qt (but I decided not to do a Qt version), so I tried to make sure that most of these objects were not dependent upon a specific platform. Certain components, like the Buzzer, are. Most of the platform specific code is supposed to be put into the main program loop or separate source files

 

There are also variations of CHIP-8 out there and these objects are able to accommodate “non-standard,” CHIP-8 systems in case you wanted an emulator for their ROMs. It also wouldn't be as hard to add in Super CHIP-8 support, but I'm not doing that for a while.

 

Better interpretation of CHIP-8 and more ROMS working

While I don't have all of the ROMs complete working order I have much more than I did with the last emulator. I grabbed a copy Frédéric Devernay's SVision-8 emulator and used it as a reference since I don't have a real piece of CHIP-8 hardware with me. With the last emulator I just read the CHIP-8 manuals and online resources on how the op-codes are interpreted. For a few of them, there is some non-consensus for what they do. This of course was quite frustrating. I would say now though that I have a good 80-90% of ROMS working perfectly versus the older one that was more around 60-70%.

 

More features

Nothing too significant other than the addition of saves states. They seem a little complex at first, but they were actually quite easy to implement. Essentially it's either dump/load all of the registers, stack, and memory into/from a file. My emulator supports one thousand save states (though you could change the number if you wanted), but I doubt anyone will use that many for a measly CHIP-8 program.

I also added in step-by-step execution. This was mainly done for my purposes of debugging, but the code is still in there in case someone wants to run through a ROM step-by-step. They would need to edit a boolean value in the source to turn it on.

 

Final Thoughts

With all that, I'm fairly happy with how it turned out. The only things that frustate me are the ROMs that still don't work. I haven't touched most of the source code since, just the README file to document it a bit better. If you want to checkout the source, the repo is right here.

While I'm at home for a month, I figured I was going to be pretty bored unless I find something to do.   So I decided to start a new project that I hope to get done before I get back from break.  So I would like to announce:

I am going to take a coffee machine, modify it, and then link it up with the Internet so I can order coffee remotely.  Whether or not I actually end up using this in the future is a question left to time, but for now I think it will be pretty something fun to do.  Below is my work area.

Currently there are three main components of this project that I'm looking at:

1. Augmenting the coffee machineAdding a servo motor to control the flow of coffee
   • Adding water level sensors
   • Hacking in extra controls to the existing electronics
   • Some method to detect there is a cup underneath the coffee nozzle
2. Developing “barista software,” to manage all of the above, as well as process orders
3. Drafting the “Buzz Protocol,” an XML interface for ordering coffee

For modifying the machine, the most difficult parts will be figuring out how to control the built in circuitry and figuring out if there is an empty cup below the dispenser.  I'm thinking that I might be able to do that with via acoustic distance sensing.  I bought one of those ultrasonic ping sensors/transmitters over the summer, but never did anything with it.  I've also never worked with servos before, so that might be another spot of difficulty.

The barista software shouldn't bee too much of a challenge.  I plan on making a Django application that will be the web interface for the system.  I was originally going to write this software targeting an Arduino with an Ethernet shield, but using a BeagleBoard is much cheaper and gives me some extra power/functionality that an Atmel chip wouldn't.

The last thing might be a bit more of a postmortem component, and I'm not entirely sure if the barista software will implement the protocol.  In case though I ever want to network another machine, having a common interface for controlling machines would be useful, and I could move the barista software over to the client.  The original idea of this project was to draft the protocol, create a client program to send XML payloads, and have the barista software interpret those messages.  Though thinking it over a bit I'm not sure if that is best for the small project that this is.  I still want to have the protocol ready on the side if I ever get any other machines up and running.

 

 

Cheers!I hope this project goes well, and I'll be sure to document it as I go along.  I am going to post everything related in the github repo.