Embed with Elliot: Practical State Machines

Raindrops on roses, and whiskers on kittens. They’re ok, but state machines are absolutely on our short list of favorite things.

There are probably as many ways to implement a state machine as there are programmers. These range from the terribly complex, one-size-fits-all frameworks down to simply writing a single switch...case block. The frameworks end up being a little bit of a black box, especially if you’re just starting out, while the switch...case versions are very easy to grok, but they don’t really help you write clear, structured code.

In this extra-long edition of Embed with Elliot, we’ll try to bridge the middle ground, demonstrating a couple of state machines with an emphasis on practical coding. We’ll work through a couple of examples of the different ways that they can be implemented in code. Along the way, we’ll Goldilocks solution for a particular application I had, controlling a popcorn popper that had been hacked into a coffee roaster. Hope you enjoy.

Continue reading “Embed with Elliot: Practical State Machines”

Embed with Elliot: The Volatile Keyword

Last time on Embed with Elliot we covered the static keyword, which you can use while declaring a variable or function to increase the duration of the variable without enlarging the scope as you would with a global variable. This piqued the curiosity of a couple of our readers, and we thought we’d run over another (sometimes misunderstood) variable declaration option, namely the volatile keyword.

On its face, volatile is very simple. You use it to tell the compiler that the declared variable can change without notice, and this changes the way that the compiler optimizes with respect to this variable. In big-computer programming, you almost never end up using volatile in C. But in the embedded world, we end up using volatile in one trivial and two very important circumstances, so it’s worth taking a look.

Continue reading “Embed with Elliot: The Volatile Keyword”

Embed with Elliot: the Static Keyword You Don’t Fully Understand

One of our favorite nuances of the C programming language (and its descendants) is the static keyword. It’s a little bit tricky to get your head around at first, because it can have two (or three) subtly different applications in different situations, but it’s so useful that it’s worth taking the time to get to know.

And before you Arduino users out there click away, static variables solve a couple of common problems that occur in Arduino programming. Take this test to see if it matters to you: will the following Arduino snippet ever print out “Hello World”?

void loop()
	int count=0;
	count = count + 1;
	if (count > 10) {
		Serial.println("Hello World");

Continue reading “Embed with Elliot: the Static Keyword You Don’t Fully Understand”

Embed with Elliot: There is no Arduino “Language”

This installment of Embed with Elliot begins with a crazy rant. If you want to read the next couple of paragraphs out loud to yourself with something like an American-accented Dave-Jones-of-EEVBlog whine, it probably won’t hurt. Because, for all the good Arduino has done for the Hackaday audience, there’s two aspects that really get our goat.

(Rant-mode on!)

First off is the “sketch” thing. Listen up, Arduino people, you’re not writing “sketches”! It’s code. You’re not sketching, you’re coding, even if you’re an artist. If you continue to call C++ code a “sketch”, we get to refer to our next watercolor sloppings as “writing buggy COBOL”.

And you’re not writing “in Arduino”. You’re writing in C/C++, using a library of functions with a fairly consistent API. There is no “Arduino language” and your “.ino” files are three lines away from being standard C++. And this obfuscation hurts you as an Arduino user and artificially blocks your progress into a “real” programmer.

(End of rant.)

Let’s take that second rant a little bit seriously and dig into the Arduino libraries to see if it’s Arduinos all the way down, or if there’s terra firma just beneath. If you started out with Arduino and you’re looking for the next steps to take to push your programming chops forward, this is a gentle way to break out of the Arduino confines. Or maybe just to peek inside the black box.

Continue reading “Embed with Elliot: There is no Arduino “Language””

Making Mario Kart Real

If you’ve ever had a casual go-kart experience, you might be able to relate to [HowToLou]. He noticed that whenever he tried to race, the same situation inevitably always happened. One racer would end up in front of the pack, and no one else would be able to pass them. The result was more of a caravan of go-karts than an actual race. That’s when he realized that video games like Mario Kart had already figured out how to fix this problem long ago. [Lou] took ideas from these games and implemented them onto a real life go-kart in order to improve the experience. The result is what he calls a Flash Kart.

The key to improving the experience was to add more features that you don’t normally get in a real word go-karting experience. The Flash Kart uses an electronic drive system that is controlled by computer. This setup allows the computer to limit the speed of the kart so they are all the same. The system includes a Logitech gaming steering wheel with built-in control buttons. There is also a color LCD screen mounted as a heads up display. The screen displays the racer’s speed in miles per hour, as well as multiple MP3 music tracks to choose from. The system provides the user with a limited number of speed boost tokens, listed on the heads up display. The user can also view their current ranking, their location on the track, or even get a view directly behind them.

The back of the kart includes a 23″ LCD screen that shows other players who you are and what team you are on. For added fun, the rider can display taunting messages to other racers using this screen. The front of the kart includes a laser cannon for shooting other karts as well as a “token scoop” sensor. This allows the riders to pick up virtual items such as laser cannon ammo, shields, or extra speed boost tokens.

To pack in all of this added functionality, [Lou] started with a typical go-kart chassis. From there, he built a custom fiber glass shell for the back-end. This houses most of the sensitive electronics. The system is powered by three 12V deep cycle batteries. A 15HP electric motor drives the rear wheels. The throttle is controlled with a gas pedal that simply feeds to a sensor that is hooked up to the control computer. The heart of the system is a computer that runs on a 2.6Ghz small footprint Zotac motherboard with Windows XP. The software is custom written in C#. The computer is plugged into a miniLAB 1008 interface board. This is how it communicates with all of the various sensors. The interface board is also used to control a number of relays which in turn control the speed of the kart.

Unfortunately [Lou] built this kart years ago and doesn’t include many details about what sensors he is using, or how the software works. Still, this was such a cool idea that we had to share it. Be sure to watch [Lou’s] video below to see the kart in action. Continue reading “Making Mario Kart Real”

Optimizing AVR LCD Libraries

A while ago, [Paul Stoffregen], the creator of the Teensy family of microcontrollers dug into the most popular Arduino library for driving TFT LCDs. The Teensy isn’t an Arduino – it’s much faster – but [Paul]’s library does everything more efficiently.

Even when using a standard Arduino, there are still speed and efficiency gains to be made when driving a TFT. [Xark] recently released his re-mix of the Adafruit GFX library and LCD drivers. It’s several times faster than the Adafruit library, so just in case you haven’t moved on the Teensy platform yet, this is the way to use one of these repurposed cell phone displays.

After reading about [Paul]’s experience with improving the TFT library for the Teensy, [Xark] grabbed an Arduino, an LCD, and an Open Workbench Logic Sniffer to see where the inefficiencies in the Adafruit library were. These displays are driven via SPI, where the clock signal goes low for every byte shifted out over the data line. With the Adafruit library, there was a lot of wasted time in between each clock signal, and with the right code the performance could be improved dramatically.

The writeup on how [Xark] improved the code for these displays is fantastic, and the results are impressive; he can fill a screen with pixels at about 13FPS, making games that don’t redraw too much of the screen at any one time a real possibility.

Use A Lamp To See Into The Future

We’ve heard of magic lamps before, but this one is actually real. [Alex] has created a wall-mounted lamp that can tell you what the future will be like; at least as far as the weather is concerned. It is appropriately named “Project Aladdin” and allows you to tell a great deal about the weather at a glance as you walk out of the door.

The lamp consists of twelve LED strips arranged vertically. The bottom strip represents the current hour, and each strip above represents another hour in the future. The color of each strip indicates the temperature, and various animations of the LEDs within each strip indicate wind speed and precipitation.

The system uses a weather forecasting backend built-in Java, which is available on the project’s page. The LEDs are controlled by an application that is written in C, and the entire set of LEDs are enclosed in a translucent housing which gives it a very professional appearance. Be sure to check out the demo video after the break. Be sure to check out some other takes on weather lamps which use regular desk lamps instead of intricate scratch-made LED lamps.

Continue reading “Use A Lamp To See Into The Future”