If you’ve spent any time on a factory or plant floor, it is a good bet you’ve run into PLCs (Programmable Logic Controllers). These are rugged computers that do simple control and monitoring functions, usually using ladder logic to set their programs. [plc4u] wanted to connect a smart card reader to an Allen Bradley PLC, so he turned to an Arduino to act as a go-between.

The Arduino talks to a USB card reader using a USB host shield. Then it communicates with the PLC using an RS232 link and the DF1 protocol that most Allen Bradley PLCs understand. You may not need a smart card, but once you know how to communicate between an Arduino and the PLC, you could do many different projects that leverage other I/O devices and code available on the Arduino and connects to existing PLC installations. Just remember that you’ll probably need to ruggedize the Arduino a bit to survive and be safe to the same level as a PLC (which might include a NEMA enclosure or even an explosion-proof box).

We’ve covered more than one open source PLC project before. If you want to learn more about the ladder logic PLCs use, there’s a good video on the subject. The video below, however, shows the smart card reader in action.

PLC Photo: By Cmarcante (Own work) [CC BY-SA 3.0], via Wikimedia Commons

The language C++ is big. There is no doubting that. One reason C++ is big is to allow flexibility in the technique used to solve a problem. If you have a really small system you can stick to procedural code encapsulated by classes. A project with a number of similar but slightly different entities might be best addressed through inheritance and polymorphism.

A third technique is using generics, which are implemented in C++ using templates. Templates have some similarities with #define macros but they are a great deal safer. The compiler does not see the code inserted by a macro until after it has been inserted into the source. If the code is bad the error messages can be very confusing since all the developer sees is the macro name. A template is checked for basic syntax errors by the compiler when it is first seen, and again later when the code is instantiated. That first step eliminates a lot of confusion since error messages appear at the location of the problem.

Templates are also a lot more powerful. They actually are a Turing complete language. Entire non-trivial programs have been written using templates. All the resulting executable does is report the results with all the computation done by the compiler. Don’t worry, we aren’t going there in this article.

Template Basics

You can use templates to create both functions and classes. The way this is done is quite similar for both so let’s start with a template function example:

template<typename T, int EXP = 2>
T power(const T value, int exp = EXP) {
	T res { value };
	for (; exp > 1; --exp) {
		res *= value;
	}
	return res;
}

This is a template function for raising value by the integer exponent, exp. The keyword template is followed in angle brackets by parameters. A parameter is specified using either typename or class followed by a name, or by an integer data type followed by a name. You can also use a function or class as a template parameter but we won’t look at that usage.

The name of a parameter is used within the body of the class or function just as you would use any other type, or value. Here we use T as the type name for the input and return values of the function. The integer EXP is used to set a default value of 2 for the exponent, i.e. making power calculate the square.

When the compiler instantiates a template function or class, it creates code that is the same as a handwritten version. The data types and values are inserted as text substitutions. This creates a new version typed by the actual arguments to the parameters. Each different set of arguments creates a new function or type. For example, an instance of power() for integers is not the same as power() for floats. Similarly, as we’ll see in a moment, a class Triple for integers is not the same as one for float. Each are distinct types with separate code.

Since power() is a template function it will work directly for any numeric data type, integer or floating point. But what if you want to use it with a more complex type like the Triple class from the last article? Let’s see.

Using Templates

Here’s the declaration of Triple reduced to only what is needed for this article:

class Triple {
public:
	Triple(const int x, const int y, const int z);
	Triple& operator *=(const Triple& rhs);

	int x() const;
	int y() const;
	int z() const;

private:
	int mX { 0 };	// c++11 member initialization
	int mY { 0 };
	int mZ { 0 };
};

I switched the plus equal operator to the multiple equal operator since it is needed by the power() function.

Here is how the power() function is used for integer, float, and our Triple data types:

int p = power(2, 3);
float f = power(4.1, 2);

Triple t(2, 3, 4);
Triple res = power(t, 3);

The only requirement for using a user defined data type (UDT) like Triple with power() is the UDT must define an operator=*() member function.

Template Classes

Assume you’ve been using Triple in a project for awhile with integer values. Now a project requirement needs it for floating point values. The Triple class code is all debugged and working, and more complex than what we’ve seen here. It’s not a pleasant thought to create a new class for float. There are also hints that a long or double version might be needed.

With not much work Triple can be converted to a generic version as a template class. It’s actually fairly straightforward. Begin with the template declaration just as with the function power() and replace all the declarations of int with T. Also check member function arguments for passing parameters by value. They may need to be changed to references to more efficiently handle larger data types or UDTs. I changed the constructor parameters to references for this reason.

Here is Triple as a template class:

template<typename T>
class Triple {
public:
	Triple(const T& x, const T& y, const T& z);
	Triple& operator *=(const Triple& rhs);

	T x() const;
	T y() const;
	T z() const;

private:
	T mX { 0 };	// c++11 member initialization
	T mY { 0 };
	T mZ { 0 };
};

Not a lot of difference. Here’s how it could be used:

Triple<int> ires = power(Triple { 2, 3, 4 }, 3);
Triple fres = power(Triple(1.2F, 2.2, 3.3)); // calc square
Triple dres = power(Triple(1.2, 2.2, 3.3));// calc square
Triple lres = power(Triple(1, 2, 3.3), 2);

Unfortunately, the new flexibility comes at the cost of telling the template the data type to use for Triple. That is done by putting the data type inside brackets following the class name. If that is a hassle you can always use typedef or the new using to create an alias:

using TripleInt = Triple;
TripleInt ires = power(Triple { 2, 3, 4 }, 3);

Creating a template class like this saves debugging and maintenance costs overall. Once the code is working, it works for all related data types. If a bug is found and fixed, it’s fixed for all versions.

Template Timing and Code Size

The code generated by a template is exactly the same code as a handwritten version of the same function or class. All that changes between versions is the data type used in the instantiation. Since the code is the same as the handwritten version, the timing is going to be the same. Therefore there is no need to actually test timing. Phew!

Templates are Inline Code

Templates are inherently inline code. That means every time you use a template function or a template class member function the code is duplicated inline. Each instance with a different data type creates its own set of code, but that will be no more than if you’d written a class for each data type. There can be savings using template classes since member functions are not instantiated if they are not used. For example, if the Triple class getter functions – x(), y(), z() – are never used, their code is not instantiated. They would be for a regular class, although a smart linker might drop them from the executable.

Consider the following use of power() and Triple:

int i1 = power(2, 3);
int i2 = power(3, 3);
Triple t1 = power(Triple(1, 2, 3), 2);

This creates two inline integer versions of power even though both are instantiated for the same data type. Another instance is created for the Triple version. A single copy of the Triple class is created because the data type is always int.

Here we’re relying on implicit instantiation. That means we’re letting the compiler determine when and where the code is generated. There is also explicit instantiation that allows the developer to specify where the code is produced. This takes a little effort and knowledge of which data types are used for the templates.

Generally, implicit instantiation means inline function code with the possibility of duplication of code. Whether that matters depends on the function. When a function, not an inline function, is called there is overhead in invocation. The parameters to the function are pushed onto the stack along with the housekeeping information. When the function returns those operations are reversed. For a small function the invocation may take more code than the function’s body. In that case, inlining the function is most effective.

The power() function used here is interesting because the function’s code and the code to invoke it on an Uno are similar in size. Of course, both vary depending on the data type since large data types require more stack manipulation. On a Arduino Uno, calling power() with an int takes more code than the function. For float, the call is slightly larger. For Triple, the code to invoke is a good piece larger. On other processors the calling power() could be different. Keep in mind that power() is a really small function. Larger functions, especially member functions, are typically going to outweigh the cost to call them.

Specifying where the compiler generates the code is an explicit instantiation. This will force an out-of-line call with the associated overhead. In a source file you tell the compiler which specializations you need. For the test scenario we want them for int and Triple:

template int power(int, int);
template Triple<int> power(Triple<int>, int);

The compiler will create these in the source file. Then, as with any other function, you need to create an extern declaration. This tells the compiler to not instantiate them as inline. These declarations are just the same as above, only with extern added:

extern template int power(int, int);
extern template Triple power(Triple, int);

Scenario for Testing Code Size

It took me a bit to create a test scenario for demonstrating the code size differences between these two instantiations. The problem is the result from the power() function must be used later in the code or the compiler optimizes the call away. Adding code to use the function changes the overall code size in ways that are not relevant to the type of instantiation. That makes comparisons difficult to understand.

I finally settled on creating a class, Application, with data members initialized using the power() function. Adding data members of the same or different types causes minimal overall size changes so the total application code size closely reflects the changes only due to the type of instantiation.

Here is the declaration of Application:

struct Application {
public:
	Application(const int value, const int exp);

	static void loop() {
	}

	int i1;
	int i2;
	int i3;
	Triple t1;
	Triple t2;
	Triple t3;
};

and the implementation of the constructor:

Application::Application(int value, const int exp) :
		i1 { power(value++, exp) }, //
				i2 { power<int, 3="">(value++) }, // calcs cube
				i3 { power(value++, exp) }, //

				t1 { power(Triple(value++, 2, 3)) }, // calcs square
				t2 { power(Triple(value++, 4, 5), exp) }, //
				t3 { power(TripleInt(value++, 2, 3), exp) } //
{
}

The minimum application for an Arduino has just an empty setup and loop() functions which takes 450 bytes on a Uno. The loop() used for this test is a little more than minimum but it only creates an instance of Application and calls its loop() member function:

void loop() {
	rm::Application app(2, 3);
	rm::Application::loop();	// does nothing
}

Code Size Results

Here are the results for various combinations of implicit and explicit instantiation with different numbers of class member variables:

The first columns specify how many variables were included in the Application class. The columns under Uno and Due are the code size for those processors. They show the size for implicit instantiation, explicit instantiation of power() for just the Triple class, and explicit instantiation for both int and Triple data types.

The code sizes are dependent on a number of factors so can only provide a general idea of the changes when switching from implicit to explicit template instantiation. Actual results depend on the tool chains compiler and linker. Some of that occurs here using the Arduino’s GCC tool chain.

In all the cases with the Uno where one variable is used, the code size increases with explicit instantiation. In this case the function’s code plus the code for calling the function is, as expected, greater than the inline function’s code.

Now look at the Uno side of the table where there are 2 integers and 2 Triples, i.e. the fourth line. The first two code sizes remain the same at 928 bytes. The compiler optimized the code for the two Triples() by creating power() out-of-line without being told to do it explicitly. In the third column there is a decrease in code size when the integer version of power() is explicitly instantiated. It did the same a couple of lines below that when there are only the 2 Triples. These were verified by examing the assembly code running objdump on the ELF file.

In general, the Due’s code size did not improve with explicit instantiation. The larger word size of the Due requires less code to call a function. It would take a function larger than power() to make explicit instantiation effective in this scenario.

As I mentioned, don’t draw too many conclusions for these code sizes. I repeatedly needed to check the content of the ELF file using objdump to verify my conclusions. As a case in point, look at the Due side, with 2 integers and a Triple, with the two code sizes of 10092. They’re just coincidence. In one the integer version of power() is inlined and in the other, explicitly out-of-lined. The same occurs on the first line under Uno where there are just two integers and no Triples.

You can find other factors influencing code size. When three Triples are involved the compiler lifts the multiplication code from power(), but not the entire function. This isn’t because power() is a template function but just a general optimization, i.e. lifting code from inside a loop.

Wrap Up

Templates are a fascinating part of C++ with extremely powerful capabilities. As mentioned above, you can write an entire program in templates so the compiler actually does the computation. The reality is you probably are not going to be creating templates in every day programming. They are better suited for developing libraries and general utilities. Both power() and Triple fall into, or are close to, that category. This is why the C++ libraries consist of so many template classes. Creating a library requires attention to details beyond regular coding.

It’s important to understand templates even if you don’t write them. We’ve discussed some of the implications of usage and techniques for making optimal use of templates because they are an inherent part of the language. With them being such a huge part of C++ we’ll come back to them again to address places where they can be used.

The Embedding C++ Project

Over at Hackaday.io, I’ve created an Embedding C++project. The project will maintain a list of these articles in the project description as a form of Table of Contents. Each article will have a project log entry for additional discussion. Those interested can delve deeper into the topics, raise questions, and share additional findings.

The project also will serve as a place for supplementary material from myself or collaborators. For instance, someone might want to take the code and report the results for other Arduino boards or even other embedded systems. Stop by and see what’s happening.

If you have a good sense of balance, you can ride a unicycle or get on TV doing tricks with ladders. We don’t know if [Hanna Yatco] has a good sense of balance or not, but we do know her Arduino does. Her build uses the ubiquitous HC-SR04 SONAR sensor and a servo.

This is a great use for a servo since a standard servo motor without modifications only moves through part of a circle, and that’s all that’s needed for this project. A PID algorithm measures the distance to the ball and raises or lowers a beam to try to get the ball to the center.

Servos like this usually operate in radio control vehicles and they are very easy to drive. A pot coupled to the shaft generates a pulse that the servo internally compares to a pulse from the microcontroller. If the pulse is wider than the reference pulse, the motor drives in one direction. If the pulse is narrower than the reference, the motor operates in the other direction. Just how much it drives depends on how much difference there is between the two pulses. When the pulses match, the servo motor stops moving. This pulse arrangement is very simple to drive from a logic output on an Arduino or other microcontrollers.

The build details are a bit sparse, but you can see in the video the general layout, and she links to a similar project that inspired this one if you are looking for more details.

You can do the same trick in two dimensions if you prefer. Or perhaps you’d like to try using a time of flight sensor, instead.

Hackaday.io user [Abderraouf] has written an implementation of the new(ish) Spritz cipher and hash for Arduino. While we’re not big enough crypto-nerds to assess the security of the code, it looks like it’s going to be pretty handy.

Spritz itself is a neat cipher. Instead of taking in fixed blocks of data and operating on them, it allows you to process it in (almost) whatever chunks it comes in naturally, and then extract out the encrypted results piecewise. It works both as a two-way cipher and as a one-way hash function. It looks like Spritz is a one-stop-shop for all of your encryption needs, and now you can run it on your Arduino.

In case you are afraid of new implementations of new ciphers (and you should be), Spritz’s pedigree should help to put you at ease: it was developed by [Ron Rivest] to be a successor to his RC4 algorithm, and it incorporates a lot of the lessons learned about that algorithm over the past. This doesn’t exclude subtle flaws in the implementation of the library (no offence, [Abderraouf]!) or your work downstream, but at least the underlying algorithm seems to be the real deal.

[Abderraouf] links it in his writeup, but just for completeness, here’s the Spritz paper (PDF). What crypto libraries do you currently use for Arduino or microcontroller projects? We’ve been fans of XXTEA for ages, but more because it’s simple and small than because it’s secure. Spritz may be simple enough to implement easily, and still more secure. Sweet.

Where you might see a can, [Adam Kumpf] sees a robot. [Adam’s] robot (named [Canny]) doesn’t move around, but it does have expressive eyebrows, multicolored eyes, and a speaker for a mouth. What makes it interesting, though, is the fact that it receives audio commands via the headphones it wears. You can see [Canny] in action in the video below.

The headphones couple audio tones to [Canny’s] microphone using AFSK (audio frequency shift keying). [Canny] uses an opamp to bring the microphone level up and then uses a 567 PLL IC to decode the audio tones. [Adam] selected two clever frequencies for the mark and space (12345 Hz and 9876 Hz). In addition to being numerically entertaining, the frequencies are far enough apart to be easy to detect, pass through the headphones with no problem, and are not harmonically related.

The 567 IC detects only one of the tones. Ignoring one tone is not always great for noise rejection, but for this use should be more than adequate and cuts the parts count down. To avoid false commands, the data contains markers, lengths, and checksums. The 567 feeds the Arduino, which handles all the robot control.

How do you create the sounds that go to the headphones? You use a Web page. Of course, you could generate the low baud rate tones in other ways, too. AFSK modems are common in Ham radio circles, and there are certainly plenty of modem designs. Then again, there is something pleasing about the simplicity of this circuit. The appeal of [Canny] doesn’t hurt any, either.

If you watch much science fiction, you know that in the future, there’re plenty of 3D holographic displays. From Princess Leah’s distress call to the Star Trek holodeck, there’s no shortage of computers that can make realistic images. It might not be up to holodeck standards, but [freedscript] created a 3D display for an Arduino using a chopstick, a motor, some paper, and a LASER. Of course, it isn’t actually a hologram, but neither is half the stuff you see on TV (Star Trek’s holographic characters were disturbingly solid for standing waves). The display is a type of volumetric display.

The idea is deceptively simple. A paper corkscrew spins and a laser spot perpendicular to the axis of rotation can create a point that appears to be anywhere in a slice of the volume enclosed by the outer perimeter of the corkscrew. You can see in the video below that the device is simple to build, although the results are not overwhelming. If the corkscrew is too big, the edges will have to move too fast. Also, you need a lot of LASERS, including one to sense the index point of the corkscrew.

Still, it is impressive to see an Arduino driving a 3D display, and the system is simple enough to hack if you’d like to experiment. We’ve looked at other optios for 3D displays before, both using lasers and using computer projectors. Maybe Princess Leah’s distress call will soon be a reality.

For those who haven’t addicted themselves to Super Hexagon yet, it’s pretty… addicting, to say the least. Normally this 80’s arcade-style game would run in a browser but some of the people at Club de Jaqueo in Buenos Aires decided to cram all of that into an Arduino. They didn’t stop there, though, and thought that it would work best with a POV display.

To navigate the intricate maze of blending a POV display with a fast-paced game like this, the group turned to the trusty Arduino Micro. After some frustration in the original idea, they realized that the game is perfectly suited for a POV display since it’s almost circular. The POV shouldn’t take up too much of the processing power of the Arduino, so most of the clock cycles can be used for playing the game. They couldn’t keep the original name anymore due to the lack of hexagon shape (and presumably copyrights and other legal hurdles), but the style of the original is well-preserved.

The group demonstrated their setup this past weekend, and the results are impressive judging by the video below. They’ve also released their source code and schematics as well, in case you have an old fan (or maybe even a bicycle?) lying around that is just begging to be turned into a mini-arcade game.

Writing articles for Hackaday, we see funny projects, and we see dangerous projects. It’s rare to find a project which combines the two. This one somehow manages to pull it off. [Outaspaceman] is familiar with LittleBits, but he’s just starting to learn Arduino programming. He completed the blink tutorial, but blinking an LED just wasn’t enough fanfare for the success of his first Arduino program. He connected the Arduino Mega’s LED output to a pair of LittleBits which then switch a servo between two positions. A bare servo wouldn’t be much fun, so [Outaspaceman] connected a tentacle and a small Swiss army knife. Yes, a knife.

The tentacle in question is designed to be a finger puppet. There’s something about a tentacle waving a knife around that is so hilarious and absurd that we couldn’t help but laugh. We’re not alone apparently, as this video has gone viral with over 1 million views. It’s almost like a violent revenge of the most useless machine. For the technically curious, the tentacle’s seemingly random motion is analogous to that of the double pendulum.

Our readers will be happy to know that [Outaspaceman] has made it to the Arduino servo tutorial, and is now controlling the servo directly, no LittleBits needed. We just hope he has a good way to turn his creation off – without the need for stitches.

What’s a hacker going to do with an oven? Reflow solder? Dry out 3D printing filament? If you are [Alicia Gibb] you’d be baking a cake. While complaining that projects aren’t a hack seems to be a favorite past time for Hackaday commentators, we think [Alicia] will be in the clear. Why? Because these cakes have Arduinos, LEDs, and motorized candles among other gizmos.

The Game Boy cake is undeniably cool, although we have to admit the cake that screams when cut got our attention (see video below), even if it would unnerve guests.

As you might expect, you can’t bake the electronics directly into the cake. [Alicia] uses Tupperware or parchment paper to create cavities for the electronics. Connections and other solder joints get professional grade Saran wrap to keep the lead and other awful chemicals out of the cake.

We’ve seen embedded electronics in cakes before, including some that tie into the Star Wars merchandising that seems unavoidable lately. If you aren’t much of a baker, you could always just forego the cake part.

Making your own booze involves a lot of sitting around waiting for things to happen, like waiting for the fermentation process to finish so you can get on with bottling and drinking it. That involves watching the bubbles in the airlock: once the frequency of the bubbles falls below a certain level, your hooch is ready for the next step.

[Waldy45] decided to automate this process by building a bubble catcher that measures the frequency of bubbles passing through the airlock. He did this using an optocoupler, a combination of LED and light sensor that changes resistance when something passes between them. You can’t see it in the image, but the horseshoe-shaped optocoupler is slotted around the thin neck in the bubble tube to sense when a bubble passes through.

The optocoupler is connected to an Arduino, running a bit of code that generates an interrupt when the optocoupler is triggered. At the moment, this just outputs an average time between bubbles to the serial port, but [Waldy45] is looking to add an ESP8266 to wirelessly connect the Arduino and contact him when the bubble frequency falls, indicating that the booze is ready for bottling.

We’ve seen a couple of over the top beer breweries before (here and here), but none of them have automated the actual fermentation stage, so something like this would definitely be an addition. Cheers!