Augmented reality has yet to find a foothold in widespread applications, but MIT has just released an AR app that allows you to control IoT devices.
The post MIT’s Reality Editor Controls IoT Devices via Augmented Reality appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.
It’s no secret that hackers like to measure things. Good numbers lead to good decisions, like when to kick your wastrel teenager out of a luxuriously lengthy shower. Hence the creation of this wireless Arduino-based water meter interface.
We’ll stipulate that “wireless” is a bit of a stretch. Creator [David Schneider] chose to split the system into two parts – a magnetometer and an Arduino to sense impulses from the water company meter, and a Raspberry Pi to serve the web interface. The water meter is at the street rather than in his house, so the sensor is wired to the Pi with some telephone cable. But from there the system is wireless.
[David] goes into some good detail on the sensing problem he faced, which relies on detecting the varying magnetic field due to the spinny-bits inside the flowmeter and cleaning up the signal with the Arduino; he also addresses aliasing errors that occur when flow rate approaches the sampling rate of the magnetometer.
We like the fact that there’s a lot of potential to leverage this technique to monitor other processes with rotating magnetic fields. And like this optically coupled gas-meter monitor, it’s not invasive of the utility’s equipment either, which is a plus.
[via reddit]
With so many amazing projects being done with both boards, it can be difficult to know which is right for you. Read on to make your decision.
The post Raspberry Pi or Arduino? One Simple Rule to Choose the Right Board appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.
Dear: LMR
Just to let you know guys it wasn't that long ago I asked my Dad if we could start a robot club at school. My dad brought it up to my princible and he did not have a problem with it. This robot club is probably going to teach people in highschool to build there first robot. I have no idea what robot I am going to teach highschoolers to build.
Hi, please, can you tell me difference between I2C and Serial communication and which is the best for communication Raspberry Pi 2 with Arduino (T'Rex Controller). Thanks
There’s a new documentary series on Al Jazeera called Rebel Geeks that looks at the people who make the stuff everyone uses. The latest 25-minute part of the series is with [Massimo], chief of the arduino.cc camp. Upcoming episodes include Twitter co-creator [Evan Henshaw-Plath] and people in the Madrid government who are trying to build a direct democracy for the city on the Internet.
Despite being a WiFi device, the ESP8266 is surprisingly great at being an Internet of Thing. The only problem is the range. No worries; you can use the ESP as a WiFi repeater that will get you about 0.5km further for each additional repeater node. Power is of course required, but you can stuff everything inside a cell phone charger.
I’ve said it before and I’ll say it again: the most common use for the Raspberry Pi is a vintage console emulator. Now there’s a Kickstarter for a dedicated tabletop Raspi emulation case that actually looks good.
Pogo pins are the go-to solution for putting firmware on hundreds of boards. These tiny spring-loaded pins give you a programming rig that’s easy to attach and detach without any soldering whatsoever. [Tom] needed to program a few dozen boards in a short amount of time, didn’t have any pogo pins, and didn’t want to solder a header to each board. The solution? Pull the pins out of a female header. It works in a pinch, but you probably want a better solution for a more permanent setup.
Half of building a PCB is getting parts and pinouts right. [Josef] is working on a tool to at least semi-automate the importing of pinout tables from datasheets into KiCad. This is a very, very hard problem, and if it’s half right half the time, that’s a tremendous accomplishment.
Last summer, [Voja] wrote something for the blog on building enclosures from FR4. Over on Hackaday.io he’s working on a project, and it’s time for that project to get an enclosure. The results are amazing and leave us wondering why we don’t see this technique more often.
What is an embedded system? The general definition is a computer system dedicated to a specific purpose, i.e. not a general purpose system usable for different tasks. That is a very broad definition. I was just skimming the C++ coding guidelines for the Joint Strike Fighter. That’s a pretty big embedded system and the first DOD project that allowed C++! When you use an ATM to get money you’re using an embedded system. Those are basically hardened PCs. Then at the small end we have all the Internet of Things (IoT) gadgets.
The previous articles about embedding C++ discussing classes, virtual functions, and macros garnered many comments. I find both the positive and critical comments rewarding. More importantly, the critical comments point me toward issues or questions that need to be addressed, which is what got me onto the topic for this article. So thank you, all.
Let’s take a look at when embedded systems should or should not use C++, taking a hard look at the claim that there may be hidden activities ripe to upset your carefully planned code execution.
Embedded systems are often thought of as having limited resources, e.g. memory, processing power. Having real-time constraints is another requirement frequently brought up. While those do occur in embedded systems they are not defining characteristics.
At some point a processor or memory limits preclude using C++, and often even C. Vendors might resort to a restricted version of C on some processors to provide a high-level language capability, an effort that would be silly for C++.
But we’ve not hit the limit on the boards used in these articles. We see with the Arduino Uno and its relatives that C++ is usable. The Uno is restricted to a subset of C++, in part because the developers did not have a C++ standard library available. (If you really want one, there are ports of the STL for the Uno.) The compiler in the Uno toolset supports C++11 and there is some support for C++14, but I haven’t explored the latter to know what is usable. There are capabilities in C++11, and C+14, that improve C++ use in embedded systems.
The Due, a larger Arduino board I’ve used to contrast with the Uno, does have the full standard library. Switch over to the Raspberry Pi, or equivalents, where you not only get the GCC toolset but can run Eclipse on the board, and it feels like the sky’s the limit.
While all the above is valid, it misses a critical point. The issue isn’t whether you can use C++ on the smaller systems but whether solving the problem needs C++’s capabilities. What I’m suggesting is changing the question from “Can you use C++?” to “Should you use C++?”
We’ve addressed some of the really basic objections to using C++. Code bloat is not the great explosion folks imagine. Virtual functions are not super slow. But the comments raise other issues. One comment advised against using C++ because of the hidden activities. Specifically mentioned were copy constructors, side effects, hidden allocation, and unexpected operations.
What is a copy constructor, and why do we need one? It’s a constructor that makes a copy of an existing instance. Any time a copy is made the copy constructor is called. Recall that all constructors initialize instances so they are ready to be used.
A copy constructor is required if you pass a parameter by value. That’s a copy. Returning a value from a function causes a copy, although a decent compiler will optimize it away. Assignment also involves making a copy.
With built in types the cost of a copy is low, except maybe if you are using long doubles at 16 bytes a value. For large data structures a copy can be expensive and can be tricky. Rather than bemoan that C++ does copies, we need to recognize they are a necessity. That recognition means we can work to avoid them and get them right when they are needed.
One way to avoid copies is to pass structures by reference. In C, passing by pointer is a pass by reference. C++ allows that and introduces the reference operator. The reference operator is not just syntactic sugar. For example, references eliminate the dangling pointer problem since you cannot have a null reference.
Which brings up the ownership problem with pointers and the questions they raise for data structure copies. Quite frequently, even in C++, a data structure contains a pointer to another data structure. When you make a copy who owns the structure at the end of the pointer? Do you copy the pointer or the data? If you just copy the pointer you are sharing data between the two copies. One copy can modify the data in the other copy. That is usually not a good thing. Copying the data might be expensive. Also, who ultimately decides when the target of a pointer is deleted, or even if it should be deleted?
C++ doesn’t introduce a problem with copy constructors; it highlights a requirement that needs to be addressed, sometimes by looking to the problem requirements. What is needed by the solution when a copy is made?
In my robotics work I use an inertial measurement unit (IMU) to help track position and bearing, the robot’s pose. Inside the IMU are an accelerometer, a gyroscope, and a compass. The accelerometer and gyroscope both provide data as a triple of data, i.e. measurements in x, y, and z axis. There are a number of operations that need to be done on that data to make it usable, many more than we want to look at here. But we can look at how to handle this triple of data and to add a triple of values together. This is done with the gyroscope since it reports the angular rate of change per unit of time. By accumulating those readings you can obtain, theoretically, the bearing of the robot.
Here’s the declaration of the class Triple and the overloaded addition operator:
class Triple {
public:
Triple() = default; // C++11 use default constructor despite other constructors being declared
Triple(const Triple& t); // copy constructor so we can track usage
Triple(const int x, const int y, const int z);
const 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 };
};
inline Triple operator+(const Triple& lhs, const Triple& rhs);
I’m using a number of C++11 features here. They’re marked, and the implications for most are obvious if you are familiar with earlier versions of C++. The line with Triple() = default; probably isn’t obvious. It requests that the compiler generate the default constructor. Without it we couldn’t create a variable with no arguments on the constructor: Triple t3;. Normally the default constructor is only created by the compiler when no other constructors are defined. Since Triple has two other constructors there would be no default constructor. I requested one using the notation so variables could be created without arguments.
The next constructor, Triple(const Triple& t), is the copy constructor. It is not needed for this class since C++ would have generated one by default that would have worked fine for this simple class. I created it to show how one works and illustrate where it is invoked. This uses a new C++11 feature where a constructor can invoke another constructor to handle the initialization. This came into being to avoid code duplication, which often led to errors, or the use of a class member to perform initialization.
The final constructor allows us to initialize a Triple with three values. Those three values are stored in the data members of the class.
The next function overloads the plus equals operator. It turns out that the most effective way to implement the actual addition operator, seen a few lines below, is to first implement this operator.
The remaining functions are getters because they allow us to get data from the class. Some classes also have setters that allow setting class values. We don’t want them in Triple.
Here are the implementations of the arithmetic operators:
inline const Triple& Triple::operator +=(const Triple& rhs) {
mX += rhs.mX;
mY += rhs.mY;
mZ += rhs.mZ;
return *this;
}
inline Triple operator+(const Triple& lhs, const Triple& rhs) {
Triple left { lhs };
left += rhs;
return left;
}
The first operator is straightforward; it simply applies the plus equal operator to each value in the class and returns the instance as a reference. This operator modifies the data in the calling object so the returned reference is valid.
The addition operator uses the plus equal operator in its implementation. Here is where the copy constructor comes into play. We have to create a new object to hold the result so one is created from the lhs value. That’s a copy.
The rhs is added to the new object using plus equal operator and the result returned by value, not by reference. The return is another copy. It cannot be returned by reference because the result object, left, was created inside the function.
There are two possible copies in any arithmetic operator. However, C++ in the standard specifically allows compilers to optimize away the copy for the return value. This is the return value optimization. You’re welcome to try adjusting the code, but there is no way you can avoid creating a copy or two somewhere during this operation.
This code will run on an Arduino, but I created it and ran it on Linux so I could step through the operations to verify where the copy constructor was called and where it wasn’t.
How do you use this? Pretty much the same as any arithmetic operation:
Triple t1 { 1, 2, 3 };
Triple t2 { 10, 20, 30 };
Triple t3 { t1 + t2 };
What would a similar implementation look like in C? How about this:
struct Triple {
int mX;
int mY;
int mZ;
};
void init(struct Triple* t, const int x, const int y, const int z) {
t->mX = x;
t->mY = y;
t->mZ = z;
}
struct Triple add(struct Triple* lhs, struct Triple* rhs) {
struct Triple result;
result.mX = lhs->mX + rhs->mX;
result.mY = lhs->mY + rhs->mY;
result.mZ = lhs->mZ + rhs->mZ;
return result;
}
Overall it looks shorter and neater. The struct Triple contains the three data items for the axis. The routine init sets them to user specified values. The add function adds two Triples and returns the result. The add routine avoids initializing result because we know its content will be overwritten by the addition operations. That’s a bit of a savings for C. There is still a copy when the function returns the value. You just don’t have any control of how that copy is done. In this simple situation it doesn’t matter but with a more complicated data structure, say, one with pointers, the copy might be more challenging. We’d probably need to resort to an output parameter using pass by reference with pointers instead of a return value.
Here is how it is used:
struct Triple t1; init(&t1, 1, 2, 3); struct Triple t2; init(&t2, 10, 20, 30); struct Triple t3 = add(&t1, &t2);
Two values are created and initialized and then added. Simple, but you’ve got to remember to take the addresses of the structures and to assure the init routine is only called once.
Consider how the two different versions would look if you implemented a complicated expression. I’ll just say I know which I would prefer.
I didn’t start this article intending to do a direct comparison between the two languages. I only wanted to illustrate that the copy constructor is, if you insist, a necessary evil. Copies occur in multiple places in both C++ and C. They become critical to understand in C++ when using user defined data types, i.e. classes. Copying in C is less obvious but still necessary.
Since I didn’t intend to make a comparison, I don’t have code size or timings for the two versions. As I pointed out and demonstrated in the article on virtual functions, comparing these simple examples on those parameters is often misleading. A C++ capability is used to solve a problem, not just as an exercise of the language features. Only if an equivalent solution in C is created is a comparison valid.
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.
A sharp-eyed Twitter user noticed that during a breaking news segment about the crash of the Russian Metrojet Flight 9268 in Egypt this week, CNN briefly displayed an Adafruit Industries component while discussing the possibility that an Isis bomb might have brought down the aircraft. Adafruit is an open-source hardware company that sells Arduino, […]
The post CNN Shows Adafruit Part During Bombing Segment appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.
Take advantage of these open source resources to set up voice control with Raspberry Pi and bark orders at your home appliances.
The post Roomba, I Command Thee: Use Raspberry Pi for Voice Control appeared first on Make: DIY Projects, How-Tos, Electronics, Crafts and Ideas for Makers.
An icon of Computer Science, [Edsger Dijkstra], published a letter in the Communications of the Association of Computer Machinery (ACM) which the editor gave the title “Go To Statement Considered Harmful“. A rousing debate ensued. A similar criticism of macros, i.e. #define, in C/C++ may not rise to that level but they have their own problems.
Macros are part of the preprocessor for the C/C++ languages which manipulates the source code before the actual translation to machine code. But there are risks when macros generate source code. [Bjarne Stroustrup] in creating C++ worked to reduce the need and usage of the preprocessor, especially the use of macros. In his book, The C++ Programming Language he writes,
Don’t use them if you don’t have to. Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer.
As C retrofitted capabilities of C++, it also reduced the need for macros, thus improving that language.
With the Arduino using the GNU GCC compilers for C and C++ I want to show new coders a couple of places where the preprocessor can cause trouble for the unwary. I’ll demonstrate how to use language features to achieve the same results more cleanly and safely. Of course, all of this applies equally when you use any of these languages on other systems.
We’re only going to be looking at macros in this article but if you want to read more the details about them or the preprocessor see the GNU GCC Manual section on the preprocessor.
The preprocessor is complex, but described in simplified terms, it reads each line in a compilation unit, i.e. file, scanning for lines where the first non-whitespace character is a hash character (#). There may be whitespace before and after the #. The next token, i.e. a set of characters bounded by whitespace, is the name of the macro. Everything following the name is the argument. A macro has the form:
#define <name> <rest of line>
The simplest macro usage is to create symbols that are used to control the preprocessor or as text substitution in lines of code. A symbol can be created with or without a value. For example:
#define LINUX #define VERSION 23
The first line defines the symbol LINUX but does not give it a value. The second line defines VERSION with the value 23. This is how constant values were defined pre-C++ and before the enhancements to C.
By convention, macro symbol names use all caps to distinguish them from variable and function names.
Symbols without values can only be used to control the preprocessor. With no value they would simply be a blank in a line of code. They are used in the various forms of the #if preprocessor directives to determine when lines of code are included or excluded.
When a symbol with a value appears in a line of code, the value is substituted in its place. Here is how using a macro with a value looks:
const int version_no = VERSION;
which results in the code
const int version_no = 23;
This type of macro usage doesn’t pose much of a threat that problems will arise. That said, there is little need to use macros to define constants. The language now provides the ability to declare named constants. One reason macros were used previously was to avoid allocating storage for a value that never changes. C++ changed this and constant declarations do not allocate storage. I’ve tested this on the Arduino IDE, and found that C does not appear to allocate storage but I’ve seen mention that C may do this on other systems.
Here is the current way to define constants:
const int version = 23;
enum {start=10, end=12, finish=24}; // an alternative for related integer consts
Another form of macro is the function macro which, when invoked looks like a function call, but it is not. Similar to the symbol macros, function macros were used to avoid the overhead of function calls for simple sequences of code. Another usage was to provide genericity, i.e. code that would work for all data types.
Function macros are used to pass parameters into the text replacement process. This is fraught with danger unless you pay close attention to the details. The use of inline functions is much safer as I’ll show below.
To illustrate here’s an example of a function macro to multiply two values.
#define MULT(lhs, rhs) lhs * rhs
This function macro is used in source code as:
int v_int = MULT(23, 25); float v_float = MULT(23.2, 23.3);
Consider this use of the macro, its expansion, and its evaluation, which definitely does not produce the expected result:
int s = MULT(a+b, c+d); // translates to: int s = a + b * c + d; // evaluates as: a + (b * c) + d
This can be addressed by adding parenthesis to force the proper evaluation order of the resulting code. Adding the parenthesis results in this code:
#define MULT(lhs, rhs) ((lhs) * (rhs)) int s = MULT(a+b, c+d); // now evaluates as: (a + b) * (c + d)
The parenthesis around lhs force (a + b) to be evaluated before the multiplication is performed.
Another ugly case is:
#define POWER(value) ((value) * (value)) int s = POWER(a++); // evaluates as: ((a++) * (a++))
Now there are two problems. First, a is incremented twice, and, second, the wrongly incremented version is used for the calculation. Here again it does not produce the desired result.
It’s really easy to make a mistake like this with function macro definitions. You’re better off using an inline function which is not prone to these errors. The inline equivalents are:
inline int mult(const int x, const int y) { return (x * y); }
inline int power(const int x) { return (x * x); }
Now the values of x and y are evaluated before the function is called. The increment or arithmetic operators are no longer evaluated inside the actual function. Remember, an inline function does not produce a function call since it is inserted directly into the surrounding code.
In C, there is a loss of generality using inline over the macro. The inline functions shown only support integers. You can add similar functions for different data types, which the standard libraries do, but the names must reflect the data type. A few cases would be covered by mult_i, mult_f, mult_l, and mult_d for integer, float, long and double, respectively.
This is less of a problem in C++ where there are two solutions. One is to implement separate functions, as in C, but the function names can all be mult relying on C++’s ability to overload function names.
A nicer C++ version is to use template functions. These really are straightforward for simple situations. Consider:
template <typename T>
inline T mult(const T x, const T y) { return (x * y); }
template <typename T>
inline T power(const T x) { return (x * x); }
You use these just like any other function call and the compiler figures out what to do. There is still one minor drawback. The mult cannot mix data types which MULT has no problem doing. You must use an explicit cast to make the types agree.
The code generated by the inline and template versions are going to be the same as the macro version, except they will be correct. You should restrict the use of macros to preprocessing of code, not code generation. It’s safer and once you are used to the techniques it’s easy.
If these problems aren’t enough, take a look at the GNU preprocessor manual section which provides more details and examples of problems.
The previous sections discussed the problems with macros and how to avoid them using C/C++ language constructs. There are a couple of valuable uses of macros that we’ll discuss in this section.
The first is stringification which converts a function macro argument into a C/C++ string. The second is concatenation which combines two arguments into a single string.
A string is created when a # appears before a token. The result is a string: #quit becomes “quit”.
Two arguments are concatenated when ## appears between them: quit ## _command becomes quit_command.
This is useful in building tables of data to use in a program. An illustration:
#define COMMAND(NAME) { #NAME, NAME ## _command }
struct command commands[] =
{
COMMAND (quit),
COMMAND (help),
...
};
expands to the code
struct command
{
char *name;
void (*function) (void);
};
struct command commands[] =
{
{ "quit", quit_command },
{ "help", help_command },
...
};
The C/C++ preprocessor is powerful and dangerous. The standards committees have followed Stroustrup’s lead in adding features that reduce the need to use the preprocessor. There is still a need for it and probably always will be since it is an inherent part of the languages. Be careful when and how you use #define, and use it sparingly.
