Posts | Comments

Planet Arduino

Archive for the ‘Software Development’ Category

A neat little hacker project that’s flying off the workbenches recently is the Arduboy. This tiny game console looks like a miniaturized version of the O.G. Game Boy, but it is explicitly designed to be hacked. It’s basically an Arduino board with a display and a few buttons, anyway.

[rv6502] got their hands on an Arduboy and realized that while there were some 3D games, there was nothing that had filled polygons, or really anything resembling a modern 3D engine. This had to be rectified, and the result is pretty close to Star Fox on a microcontroller.

This project began with a simple test on the Arduboy to see if it would be even possible to render 3D objects at any reasonable speed. This test was just a rotating cube, and everything looked good. Then began a long process of figuring out how fast the engine could go, what kind of display would suit the OLED best, and how to interact in a 3D world with limited controls.

Considering this is a fairly significant engineering project, the fastest way to produce code isn’t to debug code on a microcontroller. This project demanded a native PC port, so all the testing could happen on the PC without having to program the Flash every time. That allowed [rv] to throw out the Arduino IDE and USB library; if you’re writing everything on a PC and only uploading a hex file to a microcontroller at the end, you simply don’t need it.

One of the significant advances of the graphics capability of the Arduboy comes from exploring the addressing modes of the OLED. By default, the display is in a ‘horizontal mode’ which works for 2D blitting, but not for rasterizing polygons. The ‘vertical addressing mode’, on the other hand, allows for a block of memory, 8 x 128 bytes, that maps directly to the display. Shove those bytes over, and there’s no math necessary to display an image.

This is, simply, one of the best software development builds we’ve seen. It’s full of clever tricks (like simply not doing math if you’ll never need the result) and stuffing animations into far fewer bytes than you would expect. You can check out the demo video below.

It’s hard not to be impressed by the Arduboy. In just a few short years, [Kevin Bates] went from proof of concept to a successful commercial product without compromising on his original open source goals. Today, anyone can develop a game for the Arduboy and have it distributed to owners all over the world for free. If you’ve ever dreamt of being a game developer, the Arduboy community is for you.

Realizing the low-cost hardware and open source software of the Arduboy makes it an excellent way to learn programming, [Kevin] is now trying to turn his creation into a legitimate teaching tool. He’s kicking off this new chapter in the Arduboy’s life with a generous offer: giving out free hardware to educators all over the world. Anyone who wants to be considered for the program just needs to write-up a few paragraphs on how they’d plan on using the handheld game system to teach programming.

[Kevin] already knows the Arduboy has been used to teach programming, but those have all been one-off endeavours. They relied on a teacher that was passionate enough about the Arduboy to put in their own time and effort to create a lesson plan around it. So one of the main goals right now is getting an official curriculum put together so educators won’t have to start from scratch. The community has already developed 16 free lessons, but they’re looking for help in creating more and translating them into other languages.

While the details are still up in the air, [Kevin] also plans to travel to schools personally and help them get their Arduboy classes off the ground. He’s especially interested in developing countries and other areas that are disadvantaged educationally. Believing that the Arduboy is as much a way to teach effective leadership and teambuilding as it is programming, he thinks this program can truly make a difference.

Since [Kevin] first Rickrolled us with his prototype in 2014, we’ve seen the Arduboy project spread like wildfire through the hacker community. From figuring out how to play its games on other gadgets to developing an expansion cartridge for the real thing, the Arduboy has already done its fair share of inspiring. Here’s hoping it has just as much of an impact on the next generation of hackers once they get their hands on it.

It’s hard not to be impressed by the Arduboy. In just a few short years, [Kevin Bates] went from proof of concept to a successful commercial product without compromising on his original open source goals. Today, anyone can develop a game for the Arduboy and have it distributed to owners all over the world for free. If you’ve ever dreamt of being a game developer, the Arduboy community is for you.

Realizing the low-cost hardware and open source software of the Arduboy makes it an excellent way to learn programming, [Kevin] is now trying to turn his creation into a legitimate teaching tool. He’s kicking off this new chapter in the Arduboy’s life with a generous offer: giving out free hardware to educators all over the world. Anyone who wants to be considered for the program just needs to write-up a few paragraphs on how they’d plan on using the handheld game system to teach programming.

[Kevin] already knows the Arduboy has been used to teach programming, but those have all been one-off endeavours. They relied on a teacher that was passionate enough about the Arduboy to put in their own time and effort to create a lesson plan around it. So one of the main goals right now is getting an official curriculum put together so educators won’t have to start from scratch. The community has already developed 16 free lessons, but they’re looking for help in creating more and translating them into other languages.

While the details are still up in the air, [Kevin] also plans to travel to schools personally and help them get their Arduboy classes off the ground. He’s especially interested in developing countries and other areas that are disadvantaged educationally. Believing that the Arduboy is as much a way to teach effective leadership and teambuilding as it is programming, he thinks this program can truly make a difference.

Since [Kevin] first Rickrolled us with his prototype in 2014, we’ve seen the Arduboy project spread like wildfire through the hacker community. From figuring out how to play its games on other gadgets to developing an expansion cartridge for the real thing, the Arduboy has already done its fair share of inspiring. Here’s hoping it has just as much of an impact on the next generation of hackers once they get their hands on it.

What do you program the Arduino in? C? Actually, the Arduino’s byzantine build processes uses C++. All the features you get from the normal libraries are actually C++ classes. The problem is many people write C and ignore the C++ features other than using object already made for them. Just like traders often used pidgin English as a simplified language to talk to non-English speakers, many Arduino coders use pidgin C++ to effectively code C in a C++ environment. [Bert Hubert] has a two-part post that isn’t about the Arduino in particular, but is about moving from C to a more modern C++.

Even those of us who use C++ often use what we think of as “classic” C++. More or less the C++ that started life as a preprocessor in front of the C compiler. C++ has changed a lot since then, though. [Bert] looks mostly at useful features from the C++ 2014 standard which is widely available in compilers now. He only talks a little about some 2017 features. He doesn’t, however, talk about super new features or very specialized features that probably won’t be your first stop in a transition from C.

In particular, [Bert] doesn’t cover multiple inheritance, template metaprogramming, a big chunk of iostreams, C++ locales, user-defined literals, or exotics. Just to motivate you, he shows an example where calling the C library to sort a large array is slower than the code using C++ templates that take advantage of parallelism. While this is a special case, it does show that C++ isn’t just “another way to write the same thing.” You could write a faster sort in C, but you’d be writing a lot of code, not just pulling in a library.

What he does cover is strings, namespaces, classes, smart pointers, threads and error handling. Some of these will be more useful on the Arduino than others, but if you are writing for other platforms like a PC or a Raspberry Pi you could use all of them. He’s planning on adding more items in future installments of the series.

Meanwhile, we had our own story about modern C++ and the Arduino last year. If you want to know more about templates, we’ve talked about that, too.

As every Hackaday reader knows, and tells us at every opportunity in the comments, adding an Arduino to your project instantly makes it twice as cool. But what if, in the course of adding an Arduino to your project, you run into a problem and need to debug the code? What if you could use a second Arduino to debug the first? That would bring your project up to two Arduinos, instantly making it four times as awesome as before you started! Who could say no to such exponential gains?

Debugging an ATTiny85

Not [Wayne Holder], that’s for sure. He writes in to let us know about a project he’s been working on for a while that allows you to debug the execution of code on an Arduino with a second Arduino. In fact, the target chip could even be another AVR series microcontroller such as a the ATTiny85. With his software you can single-step through the code, view and modify values in memory, set breakpoints, and even disassemble the code. Not everything is working fully yet, but what he has so far is very impressive.

The trick is exploiting a feature known as “debugWIRE” that’s included in many AVR microcontrollers. Unfortunately documentation on this feature is hard to come by, but with some work [Wayne] has managed to figure out how most of it works and create an Arduino Sketch that lets the user interact with the target chip using a simple menu system over the serial monitor, similar to the Bus Pirate.

[Wayne] goes into plenty of detail on his site and in the video included after the break, showing many of the functions he’s got working so far in his software against an ATTiny85. If you spend a lot of time working on AVR projects, this looks like something you might want to keep installed on an Arduino in your tool bag for the future.

Debugging microcontroller projects can be a huge time saver when your code starts running on real hardware, but often takes some hacking to get working.

If you’ve ever been curious if there’s a way to program microcontrollers without actually writing software, you might be interested in FlowCode. It isn’t a free product, but there is a free demo available. [Web learning] did a demo of programming a Nucleo board using the system. You can check it out below.

The product looks slick and it supports a dizzying number of processors ranging from AVR (yes, it will do Arduino), PIC, and ARM targets. However, the pricing can add up if you actually want to target all of those processors as you wind up paying for the CPU as well as components. For example, the non-commercial starter pack costs about $75 and supports a few popular processors and components like LEDs, PWM, rotary encoders, and so on.

Price aside, we have serious concerns about building applications with GUIs. It sounds seductive and for simple projects, it is easy and intuitive. However, complex problems get messy quickly when you have flowcharts. This is the same reason complex logic designs moved away from schematics — another form of graphical representation — and went to Verilog and VHDL.

Still, looking at how this is done might give you some ideas and it might be just the ticket for the right application. It isn’t the only graphical game in town, of course. There’s ArduBlock, for example. Another one we’ve looked at is MiniBloq. You can even use Scratch on the Arduino or Raspberry Pi.


Filed under: Arduino Hacks, ARM, Software Development

Codebender.cc was a cloud based IDE for Arduino development. It was made for hackers by a few fellows in Greece. Unfortunately, while they saw some serious success, they were never able to convert it all the way into a viable business.

By November 31st Codebender.cc will be completely shut down. They assure users that the site will be in read-only mode for as long as the end of the year, but longer if the traffic justifies it. Codebender made it all the way to 10,000 monthly active users, but hosting and administration overshadowed this success to the tune of 25,000 dollars a month. Not so much as far as businesses go, but without revenue it’s more than enough to shut down a site. Their business plan aimed to tailor their services for specific chip manufacturers and other companies but those deals never came together.

It’s a pity, we were excited to see if Codebender could continue to grow. They were certainly doing some really interesting stuff like remote code upload. As the comments on the site show, many users, especially educators and Chromebook users, loved Codebender — your code isn’t stuck on one computer and where there was a browser there was an IDE.

Two paid services will remain (starting at $10/month) at addresses with different TLDs. But the post does mention that the Codebender project started as Open Source. Their GitHub repo isn’t a clear path for rolling your own, but if you do manage to hack together a working Codebender implementation we’d love to hear about it.


Filed under: Arduino Hacks, news, Software Development

Matthias Faust has created an Arduino controller for speeding up software development.

The “Maven Box” is based on an Uno and communicates with a Java program running on a desktop. The device is equipped with customizable buttons, switches and a dial, which act as physical inputs for expediting his daily routine. This enables Faust to select a branch from several GitHub projects, stash changes before pulling, pull the changes, trigger a maven build, as well as display the status of six tests on a set of notification LEDs.

Every job has it’s routine. I am a software developer who works with a Git/Maven based workspace everyday. So when I start working, my daily routine is to update and build my local workspace, pulling changes from GitHub, execute a maven build and execute the updated software. Usually I get my first coffee after that, but because I love coffee so much I thought there must be a faster way to get my system updated and running.

Whether a software developer yourself or simply a fan of awesome Arduino builds, check out the Maven Box’s Instructables page to see more!

The Arduino software environment, including the IDE, libraries, and general approach, are geared toward education. It’s meant as a way to introduce embedded development to newbies. This is a great concept but it falls short when more serious development or more advanced education is required. I keep wrestling with how to address this. One way is by using Eclipse with the Arduino Plug-in. That provides a professional development environment, at least.

The code base for the Arduino is another frustration. Bluntly, the use of setup() and loop() with main() being hidden really bugs me. The mixture of C and C++ in libraries and examples is another irritation. There is enough C++ being used that it makes sense it should be the standard. Plus a good portion of the library code could be a lot better. At this point fixing this would be a monumental task requiring many dedicated developers to do the rewrite. But there are a some things that can be done so let’s see a couple possibilities and how they would be used.

The Main Hack

As mentioned, hiding main() bugs me. It’s an inherent part of C++ which makes it an important to learning the language. Up until now I’d not considered how to address this. I knew that an Arduino main() existed from poking around in the code base – it had to be there because it is required by the C++ standard. The light dawned on me to try copying the code in the file main.cpp into my own code. It built, but how could I be sure that it was using my code and not the original from the Arduino libraries? I commented out setup() and it still built, so it had to be using my version otherwise there’d be an error about setup() being missing. You may wonder why it used my version.

When you build a program… Yes, it’s a “program” not a “sketch”, a “daughter board” not a “shield”, and a “linker” not a “combiner”! Why is everyone trying to change the language used for software development?

When you build a C++ program there are two main stages. You compile the code using the compiler. That generates a number of object files — one for each source file. The linker then combines the compiled objects to create an executable. The linker starts by looking for the C run time code (CRTC). This is the code that does some setup prior to main() being called. In the CRTC there will be external symbols, main() being one, whose code exists in other files.

The linker is going to look in two places for those missing symbols. First, it loads all the object files, sorts out the symbols from them, and builds a list of what is missing. Second, it looks through any included libraries of pre-compiled objects for the remaining symbols. If any symbols are still missing, it emits an error message.

If you look in the Arduino files you’ll find a main.cpp file that contains a main() function. That ends up in the library. When the linker starts, my version of main() is in a newly created object file. Since object files are processed first the linker uses my version of main(). The library version is ignored.

There is still something unusual about main(). Here’s the infinite for loop in main():

	for (;;) {
		loop();
		if (serialEventRun) serialEventRun();
	}

The call to loop() is as expected but why is there an if statement and serialEventRun? The function checks if serial input data is available. The if relies on a trick of the tool chain, not C++, which checks the existence of the symbol serialEventRun. When the symbol does not exist the if and its code are omitted.

Zapping setup() and loop()

Now that I have control over main() I can address my other pet peeve, the setup() and loop() functions. I can eliminate these two function by creating my own version of main(). I’m not saying the use of setup() and loop() were wrong, especially in light of the educational goal of Arduino. Using them makes it clear how to organize an embedded system. This is the same concept behind C++ constructors and member functions. Get the initialization done at the right time and place and a good chunk of software problems evaporate. But since C++ offers this automatically with classes, the next step is to utilize C++’s capabilities.

Global Instantiation

One issue with C++ is the cost of initialization of global, or file, scope class instances. There is some additional code executed before main() to handle this as we saw in the article that introduced classes. I think this overhead is small enough that it’s not a problem.

An issue that may be a problem is the order of initialization. The order is defined within a compilation unit (usually a file) from the first declaration to the last. But across compilation units the ordering is undefined. One time all the globals in file A may be initialized first and the next time those in file B might come first. The order is important when one class depends on another being initialized first. If they are in different compilation units this is impossible to ensure. One solution is to put all the globals in a single compilation unit. This may not work if a library contains global instances.

A related issue occurs on large embedded computer systems, such as a Raspberry Pi running Linux, when arguments from the command line are passed to main(). Environment variables are also a problem since they may not be available until main() executes. Global instance won’t have access to this information so cannot use it during their initialization. I ran into this problem with my robots whose control computer was a PC. I was using the robot’s network name to determine their initial behaviors. It wasn’t available until main() was entered, so it couldn’t be used to initialize global instances.

This is an issue with smaller embedded systems that don’t pass arguments or have environment values but I don’t want to focus only on them. I’m looking to address the general situation that would include larger systems so we’ll assume we don’t want global instances.

Program Class

The approach I’m taking and sharing with you is an experiment. I have done something similar in the past with a robotics project but the approach was not thoroughly analyzed. As often happens, I ran out of time so I implemented this as a quick solution. Whether this is useful in the long run we’ll have to see. If nothing else it will show you more about working with C++.

My approach is to create a Program class with a member run() function. The setup for the entire program occurs in the class constructor and the run() function handles all the processing. What would normally be global variables are data members.

Here is the declaration of a skeleton Program class and the implementation of run():

class Program {
public:
	void run();
	static Program& makeProgram() {
		static Program p;
		return p;
	}

private:
	Program() { }
	void checkSerialInput();
};

void Program::run() {
	for (;;) {
		// program code here
		checkSerialInput();
	}
}

We only want one instance of Program to exist so I’ve assured this by making the constructor private and providing the static makeProgram() function to return the static instance created the first time makeProgram() is called. The Program member function checkSerialInput() handles checking for the serial input as discussed above. In checkSerialInput() I introduced an #if block to eliminate the actual code if the program is not using serial input.

Here is how Program is used in main.cpp:


void arduino_init() {
	init();
	initVariant();
}

int main(void) {
	arduino_init();
	Program& p = Program::makeProgram();
	p.run();
	return 0;
}

The function initArduino() is inlined and handles the two initialization routines required to setup the Arduino environment.

One of the techniques for good software development is to hide complexity and provide a descriptive name for what it does. These functions hide not only the code but, in one case, the conditional compilation.

Redbot Line Follower Project

redbotThis code experiment uses a Sparkfun Redbot setup for line following. This is a two wheeled robot with 3 optical sensors to detect the line and an I2C accelerometer to sense bumping into objects. The computer is a Sparkfun Redbot Mainboard which is compatible with the Arduino Uno but provides a much different layout and includes a motor driver IC.

This robot is simple enough to make a manageable project but sufficiently complex to serve as a good test, especially when the project gets to the control system software. The basic code for handling these motors and sensors comes from Sparkfun and uses only the basic pin-level Arduino routines. I can’t possibly hack the entire Arduino code but using the Sparkfun code provides a manageable subset for experimenting.

For this article we’ll just look at the controlling the motors. Let’s start with the declaration of the Program class for testing the motor routines:

class Program {
public:
	void run();
	static Program& makeProgram() {
		static Program p;
		return p;
	}

private:
	Program() { }
	static constexpr int delay_time { 2000 };

	rm::Motor l_motor { l_motor_forward, l_motor_reverse, l_motor_pwm };
	rm::Motor r_motor { r_motor_forward, r_motor_reverse, r_motor_pwm };
	rm::Wheels wheels { l_motor, r_motor };

	void checkSerialInput();
};

There is a namespace rm enclosing the classes I’ve defined for the project, hence the rm:: prefacing the class names. On line 11 is something you may not have seen, a constexpr which is new in C++ 11 and expanded in C++14. It declares that delay_time is a true constant used during compilation and will not be allocated storage at run-time. There is a lot more to constexpr and we’ll see it more in the future. One other place I used it for this project is to define what pins to use. Here’s a sample:

constexpr int l_motor_forward = 2;
constexpr int l_motor_reverse = 4;
constexpr int l_motor_pwm = 5;
constexpr int r_motor_pwm = 6;
constexpr int r_motor_forward = 7;
constexpr int r_motor_reverse = 8;

The Motor class controls a motor. It requires two pins to control the direction and one pulse width modulation (PWM) pin to control the speed. The pins are passed via constructor and the names should be self-explanatory. The Wheels class provides coordinated movement of the robot using the Motor instances. The Motor instances are passed as references for the use of Wheels. Here are the two class declarations:

class Motor : public Device {
public:
	Motor(const int forward, const int reverse, const int pwm);

	void coast();
	void drive(const int speed);

	int speed() const {
		return mSpeed;
	}

private:
	void speed(const int speed);

	PinOut mForward;
	PinOut mReverse;
	PinOut mPwm;
	int mSpeed { };
};


class Wheels {
public:
	Wheels(Motor& left, Motor& right) :
			mLeft(left), mRight(right) {
	}

	void move(const int speed) {
		drive(speed, speed);
	}
	void pivot(const int speed) {
		drive(speed, -speed);
	}
	void stop() {
		mLeft.coast();
		mRight.coast();
	}

	void drive(const int left, const int right) {
		mLeft.drive(left);
		mRight.drive(right);
	}

private:
	Motor& mLeft;
	Motor& mRight;
};

The workhorse of Wheels is the function drive() which just calls the Motor drive() functions for each motor. Except for stop(), the other Wheels functions are utilities that use drive() and just make things easier for the developer. The compiler should convert those to a direct call to driver() since they are inline by being inside the class declaration. This is one of the interesting ways of using inline functions to enhance the utility of a class without incurring any cost in code or time.

The run() method in Program tests the motors by pivot()ing first in one direction and then the other at different speeds. A pivot() rotates the robot in place. Once the speed is set it continues until changed so the delay functions simply provide a little time for the robot to turn. Here’s the code:

void Program::run() {
	for (;;) {
		wheels.pivot(50);
		delay (delay_time);

		wheels.pivot(-100);
		delay(delay_time);

		checkSerialInput();
		if (serialEventRun) {
		}
	}
}

Wrap Up

The Redbot project is an interesting vehicle for demonstrating code techniques. The current test of the motor routines demonstrates how to override the existing Arduino main(). Even if you don’t like my approach with Program, the flexibility of using your own main() may come in handy for your own projects. The next article is going to revisit this program using templates.

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.


Filed under: Arduino Hacks, Hackaday Columns, Software Development, software hacks

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:

template code size

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.


Filed under: Arduino Hacks, Hackaday Columns, Software Development


  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook