Posts with «arduino due» label

Smartwatch convenience ‘moves’ to the next level

To address the limitations of today’s fixed-face watches, researchers have come up with an actuated smartphone concept that physically moves itself using an Arduino Due, Bluetooth and several motors.

Receiving Internet notifications has gone from using a computer, to checking them on your smartphone, to now simply seeing them come in on your wearable device. On the other hand, you still have to rotate your wrist into the right position to see the screen. Worse yet, if you want to show others what is on your wrist, you may even have to twist your arm awkwardly.

Fortunately, there is a possible solution to this scourge in the form of Cito, which bills itself as “An Actuated Smartwatch for Extended Interactions.” This design can move in five different directions–rotates, hinges, translates, orbits and rises–potentially making viewing more convenient, or even providing haptic feedback. Prototype electronics are housed inside a control box on the upper arm, but presumably would become much smaller in a production version.

You can see the team’s entire paper here, or read this write-up for a more involved summary.

Photo: Jun Gong

M2 by Macchina joins At Heart!

We’re excited to announce the latest member of Arduino’s AtHeart program. M2 by Macchinanow live on Kickstarter–is an open-source, versatile development platform for hacking and customizing cars.

M2’s design is compact, modular, wirelessly connectable, and built on the popular Arduino Due. The device can be wired under the hood for a more permanent installation or plugged into the OBD2 port, enabling you to do virtually anything with your vehicle’s software. 

Macchina, a Minnesota-based company, has partnered with Arduino, Digi and Digi-Key to develop M2, and believes that its highly-adaptable hardware will most benefit hot rodders, mechanics, students, security researchers, and entrepreneurs by providing them access to the inner workings of their rides.

M2 accommodates a wide variety of wireless options thanks to its Digi XBee form-factor socket, allowing you to easily connect your car to the Internet, smartphone, satellites, or the cloud using BLE, WiFi, GSM, LTE, and other modules.

The platform can be programmed using the latest Arduino IDE, and is compatible with a number of software packages. Moreover, given its open-source nature, potential applications are bounded only by the collective imagination of the coding community.

Interested? Check out Macchina’s Kickstarter page to learn more or pre-order your M2 today!

Arduino Altair 8800 Simulator

Browse around eBay for an original Altair 8800 and you quickly find that the price range is in the thousands of dollars. If you are a collector and have some money in your pocket maybe that’s okay. But if you want the Altair 8800 experience on a budget, you can build yourself a clone with an Arduino. [David] kindly shared the build details on his Arduino Project Hub post. Using an Arduino Due (or a Mega for 25% of original speed), the clone can accurately reproduce the behavior of the Altair’s front panel elements. We covered a similar project in the past, using the Arduino Uno.

While not overly complicated to build one, you will need a fair amount of patience so you can solder all the 36 LEDs, switches, transistors, and resistors but in the end, you’ll end up with a brand new computer to play with.  In 1975, an assembled Altair 8800 Computer was selling for $621 and $439 for an unassembled version. Sourced right, your clone would be under 50 bucks. Not bad.

The simulator comes with a bunch of software for you to try out and even games like Kill-the-Bit and Pong. BASIC and Assembler example programs are included in the emulator software and can easily be loaded.

In addition, the simulator includes some extra functions and built-in software for the Altair which are accessible via the AUX1/AUX2 switches on the front panel (those were included but not used on the original Altair). From starting different games to mount disks in an emulated disk drive, there are just too many functions to describe here. You can take a look at the simulator documentation for more information.

In case you don’t know already, here’s how to play Kill-the-Bit:


Filed under: Arduino Hacks

Roast coffee to perfection with an Arduino and Android app

After winning the South African National Barista Championship in 2009, Neil Maree decided to actually start a company to make coffee roasting equipment. Genio was the result, and after some work, his machines can now roast coffee to perfection using recipe input via an Android app.

Once instructions are transferred, a heavily modified Arduino Due controls the roaster depending on user preferences. Maree first tried an analog solution, then used a PLC before deciding that the Arduino was what he needed.

All of Genio’s roasters have a control panel with a variety of traditional switches and knobs, and then a not-so-traditional tablet mount. The app sends a “roast profile” to the roaster over a Bluetooth connection.

Perk your interest? You can take an inside look at the roasting machine factory on htxt.africa here.

Arduino Blog 14 Nov 18:24

Smartwatch prototype turns your wrist into a joystick

Although smartwatches were designed to be an easy-to-use alternative for your smartphone, interacting with their touchscreens still requires your opposite hand to be free. So what do you do when you’re carrying a bag of groceries or holding onto a bus handle?

This is the problem a Dartmouth-led team set out to solve with WristWhirl, a smartwatch prototype that uses the wrist wearing the device as a joystick to perform common touchscreen gestures with one-handed continuous input, while freeing up the other hand for other tasks.

WristWhirl was built using a two-inch TFT display and a plastic watch strap equipped with a dozen infrared proximity sensors and a piezo vibration sensor, which is connected to an Arduino Due board. Commands are then made by moving the hand as if it were operating a joystick, while a finger pinch turns the sensors on/off to indicate the start or end of a gesture.

For starters, the team implemented four sample applications with off-the-shelf games and Google Maps to illustrate potential use cases.

Four usage scenarios for WristWhirl were tested: 1) a gesture shortcuts app was created, which allowed users to access shortcuts by drawing gestures; 2) a music player app was created, which allowed users to scroll through songs through wrist-swipes and play a selected song by double tapping the thumb and index fingers; 3) a map app was implemented for which 2D maps could be panned and zoomed depending on where the watch was held in relation to one’s body; and 4) game input, which often requires continuous input was tested, for which Tetris was played using a combination of wrist swipes, wrist extension and wrist flexion.

You can read more about the project on its page here, as well as see a demonstration of it below!

 

Scubo is an omnidirectional robot for underwater exploration

A team from ETH Zurich has created an incredible submersible robot called Scubo as a way to scan entire coral reefs. Equipped with six onboard webcams, the omnidirectional device is capable of exploring the deep sea from every angle. What’s more, users can take a virtual dive by throwing on a pair of VR glasses to make it feel as if they’re swimming with marine life.

Scubo consists of an Arduino Due for hard real-time tasks, an Intel NUC for high-performance calculation, an IMU, and a pressure sensor — all housed inside a carbon cuboid. Eight thrusters are symmetrically mounted to the outside, one at each corner, while a tube goes through the box to ensure proper water flow and to keep the electronics cool. The system is neutrally buoyed and weight in the form of screws can be added to the thruster arms to adjust buoyancy and the center of gravity.

One of its creators Johann Diep tell us, “We chose to work with Arduino because it offers the required interface (I2C, SPI, etc.), it is easy to program (none of us ever worked with Arduino at the beginning), and there is a large community on the web that is very supportive with our questions.”

A tether connects Scubo to a computer outside the water and the power source, which allows the camera pictures to be viewed live and the batteries to be recharged with a steady current. According to the team, this highly extends the operation time, though the batteries would last approximately 120 minutes under standard conditions without recharging.

Scubo is based on ROS, and with the rosserial_arduino package, they are able to send or receive commands on a laptop from the Arduino. This enables them to steer the bot with a SpaceMouse joystick while monitoring all the sensor messages (pressure, leakage, temperature, voltage, etc.) at the same time.

It should be noted that Scubo isn’t only restricted to coral research either. In fact, the underwater machine was built with modularity and entertainment in mind as well. Users can easily attach their own sensors, lights and HD cameras via one of five universal ports.

We are confident that Scubo has great potential for the future. Since every necessary sensor is already implemented, Scubo can be programmed to scan a coral reef or any other place fully autonomous. Telepresence could be used in many aquariums or in the sea for entertainment. Because of the module ports different kinds of sensors and devices can be connected and used, for example to generate a geographical map of the sea floor or to inspect boats.

Whether corals in the Caribbean, the shore of Lake Zurich or even a virtual dive in an aquarium — Scubo not only convinces with its captivating technology but also with its modern design. Innovation starts when science meets entertainment.

Intrigued? You can read more about the project on its website, and check out its trailer video below.

The Internet of Linux Things

The Linux Foundation is a non-profit organization that sponsors the work of Linus Torvalds. Supporting companies include HP, IBM, Intel, and a host of other large corporations. The foundation hosts several Linux-related projects. This month they announced Zephyr, an RTOS aimed at the Internet of Things.

The project stresses modularity, security, and the smallest possible footprint. Initial support includes:

  • Arduino 101
  • Arduino Due
  • Intel Galileo Gen 2
  • NXP FRDM-K64F Freedom

The project (hosted on its own Website) has downloads for the kernel and documentation. Unlike a “normal” Linux kernel, Zephyr builds the kernel with your code to create a monolithic image that runs in a single shared address space. The build system allows you to select what features you want and exclude those you don’t. You can also customize resource utilization of what you do include, and you define resources at compile time.

By default, there is minimal run-time error checking to keep the executable lean. However, there is an optional error-checking infrastructure you can include for debugging.

The API contains the things you expect from an RTOS like fibers (lightweight non-preemptive threads), tasks (preemptively scheduled), semaphores, mutexes, and plenty of messaging primitives. Also, there are common I/O calls for PWM, UARTs, general I/O, and more. The API is consistent across all platforms.

You can find out more about Zephyr in the video below. We’ve seen RTOS systems before, of course. There’s even some for robots. However, having a Linux-heritage RTOS that can target small boards like an Arduino Due and a Freedom board could be a real game changer for sophisticated projects that need an RTOS.


Filed under: Arduino Hacks, ARM, linux hacks, news
Hack a Day 25 Feb 16:30

How to turn data into cocktails!

Data Cocktail is a device which translates in a tasty way the Twitter activity and running on Arduino Due and Arduino Pro Mini. When you want a cocktail, the machine will look for the five latest messages around the world quoting one of the available ingredients. These messages define the drink composition and Data Cocktail not only provides a unique kind of drink, but it also prints the cocktail’s recipe along with the corresponding tweets.
Once the cocktail mix is done, Data Cocktail thanks the tweeters who have helped at making the recipe, without knowing it. Check the video below to see how it works:

Data Cocktail was created in a workshop held at Stereolux in Nantes by a theme composed by Bertille Masse, Manon Le Moal-Joubel, Sébastien Maury, Clément Gault & Thibaut Métivier.

They made it using Processing and Arduino:

A first application, developed in Processing, pilots the device. The requests are performed using the Twitter4J library, then the application processes the data and controls the device, i.e. the robot, the solenoid valves and the light. The robot itself is based on a modified Zumo frame, an Arduino Pro, a Motor Shield and a Bluetooth module. The solenoid valves and the LEDs are controlled by an Arduino Due connected via USB. The impression is realized by Automator.

To prepare a cocktail, the machine can take up to a minute and may provide up to 6 different ingredients!

Code Craft – Embedding C++: Templates

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.


Filed under: Arduino Hacks, Hackaday Columns, Software Development

High Speed SSD1306 Library

[Lewin] wrote in to tell us about a high speed library for Arduino Due that he helped develop which allows interfacing OLED displays that use the SSD1306 display controller, using DMA routines for faster display refresh time.

Typically, displays such as the Monochrome 1.3″ 128×64 OLED graphic display , are interfaced with an Arduino board via the SPI or I2C bus. The Adafruit_SSD1306 library written by [Limor Fried] makes it simple to use these displays with a variety of Arduinos, using either software or hardware SPI. With standard settings using hardware SPI, calls to display() take about 2ms on the Due.

[Lewin] wanted to make it faster, and the SAM3X8E on the Due seemed like it could deliver. He first did a search to find out if this was already done, but came up blank. He did find [Marek Buriak]’s library for ILI9341-based TFT screens. [Marek] used code from [William Greiman], who developed SD card libraries for the Arduino. [William] had taken advantage of the SAM3X8E’s DMA capabilities to enable faster SD card transfers, and [Marek] then adapted this code to allow faster writes to ILI9341-based screens. All [Lewin] had to do was to find the code that sent a buffer out over SPI using DMA in Marek’s code, and adapt that to the Adafruit library for the SSD1306.

There is a caveat though: using this library will likely cause trouble if you are also using SPI to interface to other hardware, since the regular SPI.h library will no longer work in tandem with [Lewin]’s library. He offers some tips on how to overcome these issues, and would welcome any feedback or testing to help improve the code. The speed improvement is substantial. Up to 4 times quicker using standard SPI clock, or 8 times if you increase SPI clock speed. The code is available on his Github repo.


Filed under: Arduino Hacks