Posts

Posted on

What is “Real-Time”, Anyway?

Recently, a colleague of mine was working on a project with an Arduino Yún that involved reading a lot of sensor data using the Yún’s Arduino processor and writing it to the microSD card via the board’s Linux processor to be served to other devices via HTTP. She found that it took anywhere from 20 milliseconds  to several seconds to get the data from the sensors written to the SD card. “Why is it not real-time?” she asked me.

Welcome to the world of embedded operating systems. They are not realtime. “Realtime” can mean many things. In automotive systems, for example, your car’s braking system had better react in “realtime” or you’re dead. That might mean only a couple of milliseconds. When measuring high-speed rotation, it might even mean microseconds.

My colleague was measuring her function’s response time in tens to hundreds of milliseconds. That function read one controller’s analog input pin, sent the result via asynchronous serial to another controller, and then stored the result on an SD card. I haven’t measured it, but I’d wager you’ll see the same response times on a BeagleBone or Raspberry Pi, or any embedded Linux board.  Here’s why:

All computers run programs. In a microcontroller like the Arduino, there’s only one program running. That program is made up of instructions stored in memory, in a particular order. The computer moves through those instructions one at a time. Sometimes it jumps around in the

At the electrical level, all computers are made up of transistors, so in computing, the fastest version of “realtime” means “how fast can you read and act on a changing voltage on a transistor?” Some of the input/output pins of a microcontroller are usually hardware interrupt pins, meaning that they can be programmed such that if there’s a change on that pin, the program running on the controller is immediately interrupted and a special function is run. This function, called an interrupt service routine or ISR, is typically very short. Normally an ISR simply stores the result of the interrupt in a variable. Then the processor returns to the main program.  

Operating systems, both on small boards like this and on servers and personal computers, do not guarantee a minimum response time to physical I/O. They are written to optimize processor sharing between programs, so the scheduler, a core part of the operating system, doles out processor time to each program. Even before the programs you run get time, there are OS tasks that take time.  Disk writing is one of the most time-intensive tasks. Perhaps the only longer task is a network transaction, because the data is going through many computers, each with its own operating system.

In systems that have to have real-time response, you typically use one of two options:

1) no operating system. Your processor runs one program only. Like Arduino

2) a “realtime operating system” or RTOS. RTOSes are stripped-down operating systems that leave many core functions out. As of yet, all RTOSes are custom packages, not very user friendly, though there has been some work lately on realtime linux. I haven’t seen one running on any of the hobbyist boards, but i wouldn’t be surprised if we don’t see one in the next year or so.

When we designed the Yun, we decided we’d give users the benefits of both real-time and an operating system. What you do on the 32U4 (the Arduino processor) is real-time because there is no operating system. What you do on the linino side is not, because it’s running linux, an operating system. The typical approach to a networked project (whether a Yun or other system) is to do all the real-time operations on a non-OS micro controller, then send the results to an operating system computer in non-real-time, after the action has happened.

Here’s a use case that illustrates the use of real-time and an operating system together:

Let’s say you’re using a rotary encoder to measure the speed of a wheel on a remote control vehicle. You want to display the speed on a dashboard screen that’s networked to the vehicle over Wifi.

Rotary encoders measure rotation by counting pulses generated by a rotating shaft. When the rotation is fast, the pulses happen VERY fast, and you need real-time to catch them. On a micro controller, this is typically sensed using hardware interrupts. These are sub-circuits of the micro controller that can interrupt the program flow when a change happens on a given I/O pin. They force the program to jump to a function to handle the interrupt. You usually want that function to be very short — typically all it does it to increment or decrement a variable counting the changes. The Arduino Uno has two hardware interrupts, and Paul Stoffregen’s encoder library allows you to use them for reading encoders.

The way you’d build this app is to have the rotary encoder attached to the hardware interrupts of a micro controller. This controller is your physical I/O controller. You’d write a program for the micro controller that calculates the speed based on the pulse rate and sends that serially to another controller connected to a display. One function counts the pulses. That’d be done by the function called by the interrupt (these are called Interrupt service routines, or ISRs). Another function calculates a running speed based on the changing count. A third function might control the movement of the vehicle’s steering based on the value. A fourth function sends the calculated value over a serial connection to the display computer.

The serial connection of the physical controller be connected to a networked modem like the Wifi shield or a Bluetooth radio, but that modem is just another single-function controller. That transmission takes time, and you don’t want to take processor time away from counting the pulses, so your physical I/O controller doesn’t handle this transmission, it only counts pulses and sends the value on. The radio controller handles the network connection. It transmits the data on to a display computer or a server. That server is typically running an operating system, and not working in real time, but that’s okay, because humans aren’t going to react in more than a half-second or so most of the time.   What you see onscreen is typically a report of the sensor readings, but it’s an average or aggregated reading, not the raw, realtime reading.  The delay depends on the transmission time of the data. Perhaps you have a virtual steering wheel onscreen that then directs the card, but this is not real-time either. The user gets to steer the car, but what she’s really doing is affecting the gross movement of the steering, not the fine control over the axle. She’s changing the overall balance, but the physical I/o controller is the only part acting in real-time to the sensors.

It is possible for a controller that’s running an operating system to have hardware interrupts, and for it to have interrupt service routines. But those are typically part of the operating system kernel, not part of the user programs. You have to write custom kernel routines and restart the OS in order to use them. So unless you’re a kernel programmer, you typically won’t use these on BeagleBone, Raspberry Pi, or Arduino Yun. This is why there are many projects that combine the Pi or the Bone with an Arduino or other non-OS controller to do real-time sensing, and it’s why the Yun has a separate processor for that as well.

A typical personal computer is made up of several controllers, in fact. There’s normally a CPU, a network controller, a controller inside any disk drive (if it’s a drive with a motor), a graphics processor, a hardware bus controller, and more. These are usually tied together with synchronous serial communication like SPI or I2C or some other means of communication. The dedicated controllers handle their subsystems in realtime, and report back to the CPU, which reports in user time (not real time).

Posted on

BlinkyTape using NeoPixel Library

Blinkinlabs is shipping their product now after their successful KickStarter campaign, and I got mine in the mail a couple days ago. I had a few minutes and thought I’d get a basic example up and running. The Blinkinlabs documentation was confusing to me, however. The “Simplest BlinkyTape Sketch” wasn’t. The code was more complex than I had hoped, and I couldn’t find documentation of the API, but I noticed there were some examples that used the Adafruit NeoPixel library. Those examples didn’t run for me, but I figured if there were NeoPixel examples in the BlinkyTape repository, it should be possible to run the thing with that library.

A quick look at the schematics for BlinkyTape confirmed that it was indeed running the Atmega32U4, same as the Arduino Leonardo (their documentation’s good on setting the tape up as a Leonardo). Furthermore, the data in of the lights is connected to pin 13.  From there, it was simply a matter of modifying the Adafruit NeoPixels to work on pin 13.

Like the BlinkyTape examples, most of the Adafruit NeoPixel library examples were all about color scrolling. I dislike color scrolling. Call me old and cranky, but I remember a time when lighting designers made color choices and stood by them; when the designers of lighting tools gave us controls that let us choose those colors easily. I’m hoping that someday we’ll look back on this era  see color scrolling as a lighting design choice the same way as we see the mullet in hairstyle choice: a bad idea we had to go through to get to something more pleasant. Now you kids, get outta my yard! </cranky old man rant>

My sketch works like this: you send a serial string to the Arduino starting with a capital C, followed by the pixel number, the red level (0-255), the green level (0-255) and the blue level (0-255). The NeoPixel library then sets the color of the pixel you chose. That’s it.

Now that I know this thing’s so simple to use, I can see a lot of projects with it. Love the built-in processor too, makes it even more convenient. Makes me want to order a whole lot more NeoPixels from Adafruit too.

Here’s the code. You can also get it from gitHub.


[github_cv url='https://github.com/tigoe/NeoPixel_examples/blob/master/BlinkyTape/BlinkyTape.ino']
Posted on

Sending Data Serially To Arduino

One question I get all the time is this:

I know how to send data from Arduino to (Processing, OpenFrameworks, etc). But how to I send data from (Processing, OpenFrameworks, etc) to Arduino?

Many people don’t seem to know that Arduino has built-in functions for parsing streams of data. Back with version 1.0.1 Michael Margolis’ excellent TextFinder library was merged into the core Stream library. So you can send an ASCII string like this:

123, 456, 789

And Arduino can read it and convert the numeric characters back into numeric values.

For example, let’s say you want to send a string to set the values of two LEDs that you’re going to fade using the analogWrite() command. Your data might look like this:

P1, 255\n
P2, 127\n

(the \n represents a newline character, ASCII 10)

Using the parsing functions, you can look for the initial P character, then parse the numeric string that follows it until a non-numeric character (like the comma) comes along. Then you can do another parse until the next non-numeric character (like the newline at the end of the line) comes along. It’s as simple as this:

if (Serial.find("P")) {
    // read and parse characters before the comma:
    int ledNumber = Serial.parseInt(); 
    // read and parse characters after the comma:
    int brightness = Serial.parseInt();
}

Here’s a full example.

So the next time you’re trying to figure out how to read data in Arduino, first decide what your data looks like, then get to know the Stream functions. In addition to find() and parseInt(), there’s also readBytes(), readBytesUntil(), parseInt(), parsefloat(), and a few other goodies.

The really nice thing about these functions is that they work on any library based on Stream. So, for example, you can also use them on the Ethernet and WiFi and GSM Client and Server classes.  This makes parsing network data much simpler.

 

Posted on

Arduino Ethernet (and WiFi) and Your Favorite Band

Let’s say you’re a fan of one of the bands in The Deli magazine’s new bands poll. There are so many good bands there, like Teen Girl Scientist Monthly, and others. And let’s say you were looking for a project for an Arduino WiFi shield or Ethernet shield.  Why not make your Arduino vote for your favorite band? It’s not hard to do.

First you need to know how to scrape the webpage for the URL of the vote. If you view source on the page, you’ll see it nice and clear:

/poll/poll.php?category=6&answer=6560&adZone=7

So the whole URL is

http://nyc.thedelimagazine.com/poll/poll.php?category=6&answer=6560&adZone=7

Great! Now, take the WiFi WebClient example, or the Ethernet WebClient example, and change a few lines:

Change  this:

client.println("GET /search?q=arduino HTTP/1.1");
client.println("Host:www.google.com");

to this:

client.println("GET /poll/poll.php?category=6&answer=6560&adZone= HTTP/1.1");
 client.println("Host:nyc.thedelimagazine.com");

And change this:

char server[] = "nyc.thedelimagazine.com";

to this:

char server[] = "www.google.com";

And give it a go! Remember, no cheating. You can only vote once per IP address.  But if you know a friend with several WiFi shields or Ethernet shields, well, that’s only one IP address per shield, right?

 

(Good luck, Matt and the band!)

Posted on

Sending Tweets from Arduino through Pachube.com

I get a lot of people asking me how to send tweets from an Arduino through an Ethernet or WiFi shield. It turns out to be a bit tricky, because Twitter uses OAuth to manage authentication, which is difficult to program on an Arduino due to its limited program memory size.  Most libraries that send tweets from an Arduino do so by handling the authentication through another site. There are a couple of libraries that attempt to do it directly from the Arduino, but I haven’t seen one I like yet that sticks to the Arduino API style and/or doesn’t take up a lot of memory (though I am ever hopeful someone will write one). Since not everyone knows how to write a server-side middleware program to handle the authentication, I decided to see if I could get an existing service to take care of it for me.

My first thought was to use If This Then That, but I don’t know the details of their API well enough, so I went with something I already knew: Pachube. Yes I know they have a newer name, but due to some complications I’m not sure are resolved, I’m using the old name. Here’s how to do it:

Continue reading “Sending Tweets from Arduino through Pachube.com”

Posted on

Using REST as a command protocol for web-to-serial applications

Updated 19 Jan 2014

The address you type into your browser’s address bar is often the location of a particular document on a server. For example, http://tigoe.net/index.html refers to an HTML document living in the main directory of my server, tigoe.net. But URLs can be used to represent more than a file address. They can also be used to set or get the state of web-based application. For example, http://www.mystore.com/item/3045/price could be used to tell the application you want the price of item 3045. If you want the set the price, you could use http://www.mystore.com/item/3045/price/4.99. Web frameworks like Sinatra (for Ruby), Flask (for Python) and Express (for JavaScript through node.js) make it possible for you to build a web server that uses Representational State Transfer, or REST, as the control protocol for your application.

REST is a style of formatting URLs such that the URL itself describes the state of the thing it’s addressing. In the store example above, the URL is a representation of the item in the store (http://www.mystore.com/item/3045/price).  To change the state of the item, you use another URL to represent that change (http://www.mystore.com/item/3045/price/4.99).  At its simplest, REST means organizing your web application so that the URLs provide clear, sensible meaning as to what’s going on. For a more detailed explanation, see Understanding REST or Building Web Services the REST way. In this post, you’ll learn how to use a RESTian scheme as a communications protocol between a microcontroller and a web page using node.js and a little client-side JavaScript in the middle.

Continue reading “Using REST as a command protocol for web-to-serial applications”

Posted on

Serial to JSON in Node.js and Arduino

Node.js is great for making web services, and node-serialport makes it very easy to connect to serial devices on your computer. In my last post, I showed how to connect an Arduino microcontroller application to a web page using Node.  This post expands on that, introducing how to use JavaScript Object Notation (JSON) from Arduino all the way through to your HTML page.

The beauty of node is that it’s JavaScript, so you get to use everything Javacript gives you, including its wonderful lightweight data format, JSON, or JavaScript Object Notation. JSON describes data objects using arrays of key-value pairs separated by colons. If you want to add more properties to an object, just add another array element. the value of an element can be a JSON object itself. When you’ve got an application that uses JavaScript on the server side and on the client side, it makes sense to use JSON to describe your data all the way through, so you can just pass it around without a lot of conversion.

Arduino doesn’t speak JSON natively. There are a couple JSON parser libraries out there for Arduino, but I haven’t seen one that I like yet. All of the ones I’ve seen expect more pointer knowledge from the user than I’d like.  So for this example you’ll assemble your own JSON string using Arduino’s String class, and letting node.js turn it into a JSON object.

To make this happen you’ll need:

This post assumes you understand:

  • How to use Arduino, including how to send serial data
  • How to write a web page, and what a server is
  • A little about JavaScript
  • A little about the command line
  • Beginning experience with node.js.  For my brief intro, see this post.

Continue reading “Serial to JSON in Node.js and Arduino”

Posted on

Serial to Browser using node.js

Updated 28 July 2015

This is a brief introduction to using node.js and websockets to connect a serial device, like an Arduino microcontroller, to a browser.

To make this happen you’ll need:

This post assumes you understand:
Posted on

Datalogging with Arduino

There are several ways to save data from a sensor attached to an Arduino. If you’re connected to a personal computer, you can simply send the data from the Arduino to the personal computer serially, and save it to a file. If you’ve got an SD card attached to the microcontroller, you can save the data to the card. Or, if you have access to the internet and a device that can connect to a server, you can save the data to a server. In the tutorial below, you’ll read a DHT11 temperature and humidity sensor and log data in three ways:

  • Serial transmission to a personal computer, and serial capture to a file.
  • Saving data to an SD card mounted on the Arduino
  • HTTP upload to xively.com (formerly pachube.com) via an Ethernet shield or Ethernet Arduino.

Hardware you need:

  • personal computer
  • Ethernet Arduino and USB-to-serial connector, or Arduino Uno and Ethernet shield (or equivalents)
  • SD Micro card
  • DHT11 temperature and humidity sensor
  • 10-kilohm resistor

Software you need:

Concepts you should know:

  • Basic understanding of Arduino code
  • Basic electrical concepts
  • Serial communication concepts
  • How to install libraries in Arduino
  • HTTP request concepts

For more on the DHT sensors, see Adafruit’s tutorial.

To get started, install the Arduino IDE and download the DHT library. Unzip the library and change the directory name to DHT, then copy it to the libraries/ directory of your Arduino sketch directory. If this is your first time using Arduino, the default location is in your user directory, called Arduino/ . You might have to create the libraries directory inside the sketch directory. Then download the example sketches from my gitHub repository, unzip them and save them to your sketch directory as well. Then start the Arduino IDE.

Connecting the sensor

Connect the DHT11 sensor to the Arduino as follows:

  • Vcc (pin 1) – Digital pin 8
  • Output (pin 2) – Digital pin 7
  • Ground (pin 4) – Digital pin 5

Since the DHT11 sensor uses very little current, you can use the output pins of the microcontoller to power the sensor, using pins 5 and 8. Then attach the output pin of the sensor to pin 7. The output pin will also need a pullup resistor so that it goes high when no data is transmitted. To do this, connect the 10-kilohm resistor from pin 8 to pin 7, or to the +5V pin.

Serial Data Capture to a Graph

The simplest way to get data off the sensor is to print the results out serially and capture them directly on your computer. To make this happen, you’ll need your Arduino attached via a USB-to-serial connection. The sketch SerialTempHumidityReader uses the Adafruit DHT library to read the sensor and sends the results back to the computer serially. Download it and copy it into a new window in the Arduino IDE.

To upload the sketch to your board, connect the board to the computer via USB-to-serial, and look for the board type in the Tools > Board menu. Assuming you’re using an Arduino Ethernet, choose that:

To find your serial port, check the Tools >Serial Port menu with the USB-to-serial adapter NOT connected. Then plug the adapter into your computer again and check the menu again.  The new port that shows up is your USB-to-serial adapter’s port.

Once you’ve selected the board type and the port, upload the sketch by clicking the upload button in the toolbar, or ctrl-U:

When you’ve got the sketch loaded, open the serial monitor by clicking the Serial Monitor button on the right hand side of the toolbar.

You should see readings like this:

The sketch is outputting tab-separated data, and prints out column headers at the beginning.

When you’ve got several readings, click in the serial monitor window, select all (ctrl-A), and copy (ctrl-C). Then open a blank spreadsheet in OpenOffice and paste the results into the sheet. When the Text Import dialog comes up, make sure you click Separated by Tab in the Separator options:

Select the two columns of numbers, and click the graph icon. In the Graph dialog box, choose Line type, the Lines Only option, then click Finish. Your graph will be inserted in your spreadsheet. Voila, graphing made simple!

Serial Data Capture to a File

If you have a serial terminal program like CoolTerm on your computer, you can also capture to a file. To do so, open CoolTerm, and choose your serial port in the Options menu. Click the Connect icon, then from the Connection Menu, choose Capture to TextFile… and Start. Give your file a name and save.

Note: if you want the file to start from the beginning of your sketch, hold down the reset until you’ve started capture.

To stop capture, choose Connect > Capture to TextFile… > Stop. Then you can use your file in any application you want. Change the file extension to .csv and you can open it in a spreadsheet and graph as above.

Saving Data to an SD Card

Sometimes you want to save data when you’re not connected to a personal computer. Attaching an SD card to an Arduino is fairly straightforward. There are several different shields that have SD cards on board, and the Arduino Ethernet has an SD card right on the main board. The SD card library makes it simple to save files to your SD card.

Format a microSD card as FAT16 or FAT32 on your personal computer, and load it onto your Arduino. Then upload the SDCardDataLogger sketch. This sketch reads the sensor using the Adafuit DHT library, and if there is an SD card present and initialized, it saves the results to a file called “DATALOG.CSV”. Transfer this file to your computer and use it as you wish. You can open it in a spreadsheet and graph it as you did above, or anything else you wish.

Posting data to Xively.com

If your Arduino is connected to the internet via Ethernet, you can connect to pachube.com and program it to post data there. Then you can use Pachube’s data storage and graphing tools to save and visualize your data.

Set up a xively.com account. Click Create a Feed. Give it a name, add any descriptive tags you want, and add a location if you wish. Add two datastreams called rH (relative humidity) and temp (temperature) as follows:

Write down the feed number and fill it into the feed variable in the sketch (PachubeDataLogger). You’ll also need your API key, which is a long string that identifies you to pachube.com. Click My Keys from the pachube menu to get your key. Copy it into the apiKey variable in the sketch below.

Upload this sketch to your Arduino, and connect the board to the net via Ethernet. Open the serial monitor. When the sketch starts, it will look for an IP address using DHCP. Then every ten seconds, it will read the sensor and try to upload to Pachube. A successful upload will print out something like this:

192.168.2.6
rH,26.00
temp,30.00
connecting...
data uploaded
HTTP/1.1 200 OK
Date: Sat, 16 Feb 2012 10:03:14 GMT
Content-Type: text/plain; charset=utf-8
Connection: close
X-Pachube-Logging-Key: logging.G5DkQtnxEdwyKbk0KSKI
X-PachubeRequestId: 0b4efe30282b715276cf1f849f7123ed3eaba234
Cache-Control: max-age=0
Content-Length: 1
Age: 0
Vary: Accept-Encoding

When you look at your feed, you’ll see a graph of your temperature and humidity.

Now you’ve got several methods to log data from an Arduino. You can change the sensor to any sensor you wish, and revise the sketches shown here to read that sensor instead of the DHT11. Enjoy!

Update

I’ve added code to the repository for this tutorial that shows how to use the Pachube code with a BMP085 barometric pressure sensor. Thanks to Adafruit for the excellent library for this sensor.  I’ve also added an example showing how to use the BMP085 with the SD card, and with a Realtime Clock. Again, Adafruit’s library for the RTC makes this easy.

Update 2

Pachube became xively.com, and then they became part of the Google IoT Cloud platform, so I can’t vouch for the validity of any of the pachube examples on this page now. They may work, if xively/Google didn’t change the API.