Archive | Uncategorized

First look – Arduino Yún

Introduction

After being announced in May this year, the new Arduino Yún has arrived in the crowded marketplace – and I snapped up one of the first to arrive in Australia for an initial review. The purpose of which is to run through the out of box experience, and to see how easy it was to get the Yún working with the promised new features.

[Update – over time we’ll publish tutorials specifically for the Yún, which are listed here.]

The Yún introduces some interesting new combinations of hardware and connectivity, all within the familiar form-factor. Which gives us plenty to examine and write about, so let’s get started. First, a quick look around the Yún:

Arduino Yun Yún front

Notice the stickers on the header sockets, useful for beginners or the absent-minded…

Arduino Yún Yun right side

The usual TX/RX and D13 LEDs, plus notifiers for power, WiFi, LAN and USB use…

Arduino Yún Yun sockets

Ethernet, USB programming, USB host…

Arduino Yun Yún top side

Again with the stickers…

Arduino Yun Bottom Yún

The rear is quite busy. You can also see “Made in Taiwan” – a first for Arduino. I believe the reason for this was due to the new Atheros chipset requirements. Did you notice the multiple reset buttons? There are three – one for the Arduino, one for wifi and one to reboot Linino. As you can see there’s a lot of circuity on the bottom of the Yún, so it would be prudent to use some short standoffs to elevate the board and protect the bottom. Before moving on, you might like the following video where the Arduino team introduce the Yún:

Specifications

The Yún is based around the Arduino Leonardo-specification board – thus you have the ATmega32U4 microcontroller and the usual Leonardo functions. Note you cannot feed wild DC voltages into the Vin pin – it must be a regulated 5V. And the DC socket has gone, so for a solid connection you might want to make or buy your own power shield.

However there is so much more… underneath a small metal shield below the digital I/O pins is an Atheros AR9331 CPU running a Linux distribution based on OpenWRT named Linino. This Atheros part of the board is connected to a microSD socket, 10/100 Ethernet port, a USB 2.0 socket for host-mode functions and also has IEEE 802.11b/g/n WiFi, and Power-over-Ethernet support (with an optional adaptor).

And all of that is connected to the Arduino side of things via a simple serial “bridge” connection (with it’s own library) – which gives the Arduino side of the board very simple methods of controlling the other onboard hardware.

Getting started with the Yún WiFi

First thing is to download and install the new IDE, version 1.5.4. This is for Due and Yún, so keep your older installations as well. On the general Arduino side of things nothing has changed, so we’ll move on to the more interesting side of the board. The first of these is to setup and experiment with the onboard WiFi. After connecting your board to USB for power, you can connect to it with your PC’s WiFi:

Arduino Yun Yún office wifi

… at which point you connect to the Yún network. Then visit 192.168.240.1 from a web browser, and you’re presented with a page that asks for the default password, which is … “arduino”:

Arduino Yún Yun wifi setup

At which point you’re presented with the relevant details for your Yún:

Arduino Yún  Yun wifi details

… such as the IP address, MAC address, etc. Make note of your MAC address, you might need it later. From here you can configure the Yún WiFi details, for example the name and password, and also the details of your existing WiFi network which can be used to access the Yún. Once you save those, the Yún reboots and tells you to connect the PC back to the existing WiFi network:

Arduino Yun Yún WiFi setup complete

If for some reason it doesn’t work or you entered the wrong settings – hold down the “WLAN RST” button (next to the USB host socket) for five seconds. This sets the WiFi details in the Yun back to the default … and you can start all over again.

Note that the Yún’s preset IP of 192.168.240.1 may not be suitable for your own network. For example, if your home router is 10.1.1.1 you need to do some detective work to find out the IP address for the Yún. Head into your router’s administration pages and look for your DHCP Client Log. It will show a list of devices that are connected to the network, including their MAC and IP address – for example:

Arduino Yún Yun new IP address DHCPThen it’s a simple matter of finding the MAC address in the list and the matching IP. Once you have the IP address, enter that into a web browser and after being prompted for the Yún’s password, you’re back to the welcome page with the IP, MAC addresses etc.

WiFi Sketch Uploading

Once your Yún is on the same WiFi network as the PC running the IDE – you can upload a sketch over WiFi! This is possible due to the bridge between the Atheros section on the board and the Arduino hardware. Just select the board type as normal in the IDE, and the port (the IP address version):

Arduino Yun WiFi sketch upload  Yún

… then hit Upload as normal, enter the password:

Arduino Yun WiFi sketch upload  Yún

and you’re done. Awesome.

Console-based control of Arduino over WiFi

There’s a neat example that demonstrates how you can control the Arduino over the WiFi using a console terminal on the PC. Upload this sketch (from http://arduino.cc/en/Guide/ArduinoYun#toc13):

Then load your terminal software. We use PuTTY on Windows. Run the terminal software, then login as root, then telnet to “localhost 6571”:

Arduino Yún  Yun terminal console putty

You can then send characters to the Yún just as you would with a USB-connected Arduino via the serial monitor. With the example above you’re turning the D13 LED on and off, but you can get the idea.

The “Internet of Things”

Arduino has teamed up with a service called “Temboo” – which gives you over 100 APIs that your Yún can hook up with to do a myriad of things, such as send tweets, get weather data from Yahoo, interact with Dropbox, etc. This is done easily and explained quite well at the Temboo website. After signing up for Temboo (one account seems to be free at the moment) we tried the Yahoo weather API.

You enter the parameters using an online form in Temboo (in our example, the address of the area whose weather forecast we required), and the Temboo site gives you the required Arduno sketch and header file to upload. And you’re done. With this particular example, I wanted the weather in Sydney CBD – and once running the data is returned to the serial monitor, for example:

Temboo Arduino Yun yahoo weather Yún

It was great to see that work the very first time, and a credit to Temboo and Arduino for making it happen. But how?

There is a Temboo client in the Linino OS, which is the gateway to the API via WiFi, and also communicates with the Arduino via the serial bridge. The Arduino Temboo library can then interact with the Linino client without complex code. The weather data is then returned back from the Internet via the Temboo client and fed to the Arduino serial port, where you can parse it with your own code. This looks like a lot of fun, and also could be quite useful – for example capturing data and sending it to a Google Docs spreadsheet. For more information, check out the Temboo website.

However you can delve deeper and create your own APIs, matching code – and perhaps other services will develop their own APIs in the near future. But for now, it’s a good start.

Where to from here? And support?

This article has only scratched the surface (but not bad considering the board arrived a few hours ago). There’s plenty more examples on the getting started page, in the IDE (under “Bridge”) – plus a dedicated Arduino Yún forum. And check out this gmail notifier. In the near future we’ll create some of our own tutorials, so stay tuned.

Is the Yún a completely open-source product? 

Well it says “open source electronics prototyping platform” on the rear, but is this true? The Arduino Leonardo-side of the board is. However the Atheros AR9331 chip is not. Nevertheless, are you really going to reproduce your own AR9331? So it doesn’t really matter. Being a pragmatist I propose that the Yún solves the problem of Arduino and Internet connectivity quite well for the non-advanced user – so not being totally OSHW isn’t an issue.

Support

This board is very new to us here, so for questions or support please ask on the dedicated Arduino Yún forum.

Conclusion

Since the popularity of various single-board computers has increased exponentially over the last few months, some may say that the Yún is perhaps too little, too late. After only having the Yún for a few hours before writing this article, personally I disagree with this statement – the Yún is a device that still gives us the wide range of hardware control, and what looks to be a very simple method of connectivity that surely is cheaper and less prone to issues than the original Arduino WiFi shield.

What the Yún gives us is a simple, well-executed method of getting our Arduino connected to the outside world – and in a manner that won’t confuse or put off the beginner or intermediate user. So for now, it’s a win.

What do you think? Leave a comment below.

And for more detail, full-sized images from this article can be found on flickr. And if you’re interested in learning more about Arduino, or want to introduce someone else to the interesting world of Arduino – check out my book (now in a third printing!) “Arduino Workshop” from No Starch Press.

In the meanwhile have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

Posted in AR9331, Atheros, lesson, Linino, linux, review, temboo, tronixstuff, tutorial, Uncategorized, wifi, Yún8 Comments

Tutorial – Parallax Ping))) Ultrasonic Sensor

Sense distance with ultrasonic sensors in chapter forty-five of a series originally titled “Getting Started/Moving Forward with Arduino!” by John Boxall – a series of articles on the Arduino universe. The first chapter is here, the complete series is detailed here.

Updated 05/02/2013

Whilst being a passenger in a vehicle with a ‘reversing sensors’, I became somewhat curious as to how the sensors operated and how we can make use of them. So for this chapter we will investigate an ultrasonic sensor from Parallax called the Ping)))™ Ultrasonic Distance Sensor. It can measure distances between ~2cm and ~3m in length. Here is our example sensor:

(Memories of Number Five …)

Parallax have done a lot of work, the board contains not just the bare sensor hardware but controller circuitry as well:

Which is great as it leaves us with only three pins – 5V, GND and signal. More on those in a moment, but first…

How does it work?

Good question. The unit sends out an ultrasonic (a sound that has a frequency which is higher than can be heard by the human ear) burst of sound from one transducer (the round silver things) and waits for it bounce off an object and return – which is detected by the other transducer. The board will then return to us the period of time taken for this process to take, which we can interpret to determine the distance between the sensor and the object from which the ultrasonic sound bounced from.

The Ping))) only measures a distance when requested – to do this we send a very short HIGH pulse of five microseconds to the signal pin. After a brief moment a pulse will come from the board on the same signal pin. The period of this second pulse is the amount of time the sound took to travel out and back from the sensor – so we divide it by two to calculate the distance. Finally, as the the speed of sound is 340 metres per second, the Arduino sketch can calculate the distance to whatever units required.

It may sound complex, but it is not –  so let’s run through the theory of operation with an example. Using our digital storage oscillscope we have measured the waveforms on the signal pin during a typical measurement. Consider the following example of measuring a distance of 12cm:

fulltwelvecm

You can see the 5uS pulse in the centre and the pulse returned from the sensor board on the right. Now to zoom in on the returned pulse:

twelvecm

Without being too picky the pulse is roughly 720uS (microseconds) long – the duration of ultrasonic sound’s return trip from the sensor board. So we divide this by two to find the time to travel the distance – 360uS. Recall the speed of sound is 340 metres per second – which converts to 29.412 uS per centimetre. So, 360uS divided by 29.412 uS gives 12.239902081… centimetres. Rounded that gives us 12 centimetres. Easy!

Finally, there are some limitations to using the Ping))) sensor. Download the data sheet (pdf) and read pages three to five for information on how to effectively mount the sensor and the sensitivity results from factory resting.

How do we use it with Arduino?

As described previously we first need to send a 5uS pulse, then listen for the return pulse. The following sketch does just that, then converts the data to centimetres and displays the result on the serial monitor. The code has been commented to explain each step.

And the results of some hand-waving in the serial monitor:

So there you have it – you can now measure distance with a degree of accuracy. However that image above isn’t very exciting – instead let’s use a 7-segment display shield to get things up in lights. The shield uses the NXP SAA1064 LED display driver IC (explained quite well here). You can download the demonstration sketch from here. And now for the video:

So there you have it – now the use of the sensor is up to your imagination. Stay tuned using the methods below to see what we get up to with this sensor in the future.

LEDborder

Have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column, or join our Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

Posted in arduino, distance, learning electronics, lesson, microcontrollers, parallax, ping, sensor, tutorial, ultrasonic, Uncategorized25 Comments

Tutorial: Arduino and the SPI bus part II

This is chapter thirty-six of a series originally titled “Getting Started/Moving Forward with Arduino!” by John Boxall – A seemingly endless series of articles on the Arduino universe. The first chapter is here, the complete series is detailed here

[Updated 10/01/2013]

This is the second of several chapters in which we are investigating the SPI data bus, and how we can control devices using it with our Arduino systems. If you have not done so already, please read part one of the SPI articles. Again we will learn the necessary theory, and then apply it by controlling a variety of devices. As always things will be kept as simple as possible.

First on our list today is the use of multiple SPI devices on the single bus. We briefly touched on this in part one, by showing how multiple devices are wired, for example:

Notice how the slave devices share the clock, MOSI and MISO lines – however they both have their own chip select line back to the master device. At this point a limitation of the SPI bus becomes prevalent – for each slave device we need another digital pin to control chip select for that device. If you were looking to control many devices, it would be better to consider finding I2C solutions to the problem. To implement multiple devices is very easy. Consider the example 34.1 from part one – we controlled a digital rheostat. Now we will repeat the example, but instead control four instead of one. For reference, here is the pinout diagram:

Doing so may sound complex, but it is not. We connect the SCK, MOSI and  MISO pins together, then to Arduino pins D13, D11, D12 respectively. Each CS pin is wired to a separate Arduino digital pin. In our example rheostats 1 to 4 connect to D10 through to D7 respectively. To show the resistance is changing on each rheostat, there is an LED between pin 5 and GND and a 470 ohm resistor between 5V and pin 6. Next, here is the sketch:

Although the example sketch may be longer than necessary, it is quite simple. We have four SPI devices each controlling one LED, so to keep things easy to track we have defined led1~led4 to match the chip select digital out pins used for each SPI device. Then see the first four lines in void setup(); these pins are set to output in order to function as required. Next – this is very important – we set the pins’ state to HIGH. You must do this to every chip select line! Otherwise more than one CS pins may be initially low in some instances and cause the first data sent from MOSI to travel along to two or more SPI devices. With LEDs this may not be an issue, but for motor controllers … well it could be.

The other point of interest is the function

We pass the value for the SPI device we want to control, and the value to send to the device. The value for l is the chip select value for the SPI device to control, and ranges from 10~7 – or as defined earlier, led1~4. The rest of the sketch is involved in controlling the LED’s brightness by varying the resistance of the rheostats. Now to see example 36.1 in action via the following video clip:


(If you are wondering what I have done to the Freetronics board in that video, it was to add a DS1307 real-time clock IC in the prototyping section).

Next on the agenda is a digital-to-analogue converter, to be referred to using the acronym DAC. What is a DAC? In simple terms, it accepts a numerical value between zero and a maximum value (digital) and outputs a voltage between the range of zero and a maximum relative to the input value (analogue). One could consider this to be the opposite of the what we use the function analogRead(); for. For our example we will use a Microchip MCP4921 (data sheet.pdf):

(Please note that this is a beginners’ tutorial and is somewhat simplified). This DAC has a 12-bit resolution. This means that it can accept a decimal number between 0 and 4095 – in binary this is 0 to 1111 1111 1111 (see why it is called 12-bit) – and the outpout voltage is divided into 4096 steps. The output voltage for this particular DAC can fall between 0 and just under the supply voltage (5V). So for each increase of 1 in the decimal input value, the DAC will output around 1.221 millivolts.

It is also possible to reduce the size of the voltage output steps by using a lower reference voltage. Then the DAC will consider the reference voltage to be the maximum output with a value of 4095. So (for example) if the reference voltage was 2.5V, each increase of 1 in the decimal input value, the DAC will output around 0.6105 millivolts. The minimum reference voltage possible is 0.8V, which offers a step of 200 microvolts (uV).

The output of a DAC can be used for many things, such as a function generator or the playback of audio recorded in a digital form. For now we will examine how to use the hardware, and monitoring output on an oscilloscope. First we need the pinouts:

By now these sorts of diagrams shouldn’t present any problems. In this example, we keep pin 5 permanently set to GND; pin 6 is where you feed in the reference voltage – we will set this to +5V; AVss is GND; and Vouta is the output signal pin – where the magic comes from 🙂 The next thing to investigate is the MCP4921’s write command register:

Bits 0 to 11 are the 12 bits of the output value; bit 15 is an output selector (unused on the MPC4921); bit 14 controls the input buffer; bit 13 controls an inbuilt output amplifier; and bit 12 can shutdown the DAC. Unlike previous devices, the input data is spread across two bytes (or a word of data). Therefore a small amount of work needs to be done to format the data ready for the DAC. Let’s explain this through looking at the sketch for example 36.2 that follows. The purpose of the sketch is to go through all possible DAC values, from 0 to 4095, then back to 0 and so on.

First. note the variable outputvalue – it is a word, a 16-bit unsigned variable. This is perfect as we will be sending a word of data to the DAC. We put the increasing/decreasing value for a into outputValue. However as we can only send bytes of data at a time down the SPI bus, we will use the function highbyte() to separate the high side of the word (bits 15~8) into a byte variable called data.

We then use the bitwise AND and OR operators to set the parameter bits 15~12. Then this byte is sent to the SPI bus. Finally, the function lowbyte() is used to send the low side of the word (bits 7~0) into data and thence down the SPI bus as well.

Now for our demonstration sketch:

And a quick look at the DAC in action via an oscilloscope:

By now we have covered in detail how to send data to a device on the SPI bus. But how do we receive data from a device?

Doing so is quite simple, but some information is required about the particular device. For the rest of this chapter, we will use the Maxim DS3234 “extremely accurate” real-time clock. Please download the data sheet (.pdf) now, as it will be referred to many times.

The DS3234 is not available in through-hole packaging, so we will be using one that comes pre-soldered onto a very convenient breakout board:

It only takes a few moments to solder in some header pins for breadboard use. The battery type is CR1220 (12 x 2.0mm, 3V); if you don’t have a battery you will need to short out the battery holder with some wire otherwise the IC will not work. Readers have reported that the IC doesn’t keep time if the USB and external power are both applied to the Arduino at the same time.

A device will have one or more registers where information is read from and written to. Look at page twelve of the DS3234 data sheet, there are twenty-three registers, each containing eight bits (one byte) of data. Please take note that each register has a read and write address. An example – to retrieve the contents of the register at location 08h (alarm minutes) and place it into the byte data we need to do the following:

Don’t forget to take note of  the function SPI.setBitOrder(MSBFIRST); in your sketch, as this also determines the bit order of the data coming from the device. To write data to a specific address is also quite simple, for example:

Up to this point, we have not concerned ourselves with what is called the SPI data mode. The mode determines how the SPI device interprets the ‘pulses’ of data going in and out of the device. For a well-defined explanation, please read this article. With some devices (and in our forthcoming example) the data mode needs to be defined. So we use:

to set the data mode, within void(setup);. To determine a device’s data mode, as always – consult the data sheet. With our DS3234 example, the mode is mentioned on page 1 under Features List.

Finally, let’s delve a little deeper into SPI via the DS3234. The interesting people at Sparkfun have already written a good demonstration sketch for the DS3234, so let’s have a look at that and deconstruct it a little to see what is going on. You can download the sketch below from here, then change the file extension from .c to .pde.

Don’t let the use of custom functions and loops put you off, they are there to save time. Looking in the function SetTimeDate();, you can see that the data is written to the registers 80h through to 86h (skipping 83h – day of week) in the way as described earlier (set CS low, send out address to write to, send out data, set CS high). You will also notice some bitwise arithmetic going on as well. This is done to convert data between binary-coded decimal and decimal numbers.

Why? Go back to page twelve of the DS3234 data sheet and look at (e.g.) register 00h/80h – seconds. The bits 7~4 are used to represent the ‘tens’ column of the value, and bits 3~0 represent the ‘ones’ column of the value. So some bit shifting is necessary to isolate the digit for each column in order to convert the data to decimal. For other ways to convert between BCD and decimal, see the examples using the Maxim DS1307 in chapter seven.

Finally here is another example of reading the time data from the DS3234:

So there you have it – more about the world of the SPI bus and how to control the devices within.

LEDborder

In the meanwhile have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

Posted in arduino, BOB-10160, dac, DS3234, education, learning electronics, lesson, MCP4162, MCP4921, microcontrollers, SPI, tutorial, Uncategorized14 Comments


Subscribe via email

Receive notifications of new posts by email.

The Arduino Book

Arduino Workshop

Für unsere deutschen Freunde

Dla naszych polskich przyjaciół ...

Australian Electronics!

Buy and support Silicon Chip - Australia's only Electronics Magazine.

Use of our content…

%d bloggers like this: