Wildcat rides

I've just come across this amazing beast on Hackaday:

I suspect that there are some heavy-duty pneumatics buried in the body.

I wonder how close one could get using a much, much smaller body and conventional servos.

Arduino adds two more products to the range - Galileo and Tre

Yesterday's announcement of the Arduino Galileo at Make Faire Rome overshadowed a second significant announcement: The Arduino Tre.

Arduino Galileo

The Arduino Galileo is based on the Intel Quark SoC X1000, and should be in the store by the end of November, though the lucky attendees at Maker Faire were given one at the door yesterday. (If anyone has a spare...)

Intel plan to give away 50,000 to Universities over the next few months.

Arduino Tre

The Arduino Tre is based on the TI Sitara AM335x ARM Cortex-A8, built around a Leonardo core.  It has a 1GHz processor with 512M of RAM. It supports 1920x1020 HDMI video output and HDMI/Stereo Analogue audio.

It's expected to be available in Spring 2014.

Linux everywhere

Both boards run Linux, and both can be programmed using the Arduino IDE.

The Arduino family now spans a huge range of processing power while supporting a common development environment and compatible libraries across the whole range.

Text LCDs and the Raspberry Pi - continued

Over the weekend I spent some time on the LCD text display using the LiquidCrystalFast library. There's still work to do, but the core hardware is working. When I've finished the hardware and software I'll post the details but first I thought I'd document the mistakes I made and the processes I followed to troubleshoot the project and get it back on the rails.

My normal workflow for a new hardware design takes things in small steps, with lots of testing as I go. I start with a rough design, which may be on paper or in my head, and then I breadboard and test.

Once the breadboarded version is working I transfer the design to stripboard or to one of Adafruit's wonderful PermaProto boards, and test again.

If appropriate, I then design a board and send the files off to a PCB fab shop to make the first PCB version, which may need further testing and revision.

My First Mistake

This time I took a short cut.

I've built a dozen or so Arduino clones on stripboard, and several LCD display drivers, so I thought it was safe to go straight to a stripboard layout. I decided to use my old Veroduino design as a template, and checked it against a couple of reference sources.

I didn't know it, but I was already in trouble. I forgot that I had made a mistake in the original layout of the Verduino which I fixed in version 2. I'd corrected the schematic but forgot about that too. I did the new layout by carefully copying the (incorrect) connections on the Version 1 board.

I spotted a few other slips I made as I prepared the stripboard but managed to repair them, and after an hour or two had the board ready for testing.

Fist signs of trouble

I always start with a crude continuity check using a voltmeter. I made sure that I hadn't shorted out adjacent pins on the IC sockets and that the ground and Vcc connections were as I thought they should be.

The next step was to insert an ATMega328 chip  that I'd programmed with with a bootloader and check that I could download sketches from the Arduin IDE.

It didn't work.

I got an error message stating that the programmer was not responding, but that didn't tell me anything about what I'd done wrong.

Ouch!

Debugging  the board

I checked to see that the chip had a working bootloader by swapping it into the original Veroduino Mk 1. The IDE recognised the chip and I uploaded the basic blink program, which worked fine on the Veroduino version. So that told me that the chip was undamaged and had a valid bootloader.

I swapped the chip back to my new board and tried again.  Sill no success.

I did a visual check of the soldering, and re-did my continuity test, but could not see anything. That left two possibilities: a gross error in the layout, or a mistake in the links to the FTDI header.

To distinguish between them I soldered in a 5 volt LED to see if the blink program was running as expected.

No joy.

By now it was clear that the chip was just not starting up; that meant a problem with the reset line, the power supply or the oscillator components.  I looked and looked and could see nothing, so I decided to build a copy using a breadboard to verify that would work as expected.

I set up the breadboard design from the chip pinout diagram instead of blindly following the Veroduino layout. Within a couple of minutes I'd found the fault.

Version 1 of the Veroduino had AREF (pin 19) wrongly connected to the positive supply, along with a hard-to-see but correct link to pin 20. I spotted the connection to Pin 19, but not the link to pin 20, and assumed that the Vcc pin on that side of the chip was pin 19.

Progess...

I rewired the power lines on the stripboard, and applied power. The LED blinked as expected. Progress!

Next I tried to download the LiquidCrystalFast sketch which I'd modified to match the pin assignments used in my layout.

...and another problem

Once again I got an error.

Back to the board layout. I'd felt a bit uneasy about the connections to the FTDI chip. These link the serial port  on the computer running the IDE to the serial pins (TX/RX) on the Arduino chip, so that the bootloader can work its magic. After a little checking I realised that I'd made a silly mistake, connecting the pin called RXD on the FTDI cable to the RX pin on the chip.

That's wrong: RXD should be connected to TX, and TXD should be connected to RX. It's confusing, but it makes sense if you think about it; the Receive pin on the FTDI cable is receiving data from the point of view of the computer it's connected to, and the pin it should be connected to is the one that is transmitting from the point of view of the chip.

To put it another way: your computer receives what the Arduino transmits, and the Arduino receives what your computer transmits.

Once I'd swapped over the RX and TX connections the Arduino IDE reported that it had downloaded my sketch successfully.

Time to plug in the LCD.

Nothing happened!

The final hurdle

I removed the LCD, downloaded the blink sketch, inserted the LCD and restored power. The LED didn't blink.

Inserting the LCD was somehow causing the chip to malfunction.

I inspected the soldering around the part of the board that supplies power to the LCD and found a hairline bridge of solder between the 5v supply and ground.

When I removed the solder bridge with a craft knife the LCD worked perfectly; it's run correctly for about a day, and I'm happy that the board is correct.

Lessons learnt

• Even old hands still make beginner's mistakes sometimes.
• It's a good idea to try circuits out on a breadboard even if you feel sure you know how they should work
• If possible,  start with a simple working version, adding one new feature at a time.
• If you've made a defective version of a design, throw it away or label is as defective!

I need to catch up with some admin over the next few days, but I'll publish the board design and code once I've had a chance to add the I2C connector and finish the controller code.

Text LCDs and the Raspberry Pi

One project I'm hoping to complete in the next day or so is an I2C-based Text LCD for use with the Raspberry Pi.

Why bother? After all, the Pi has an HDMI output, and it's easy to connect the Pi via Ethernet or wireless.

The problem is that there are situations where you really need a stand-alone display.

Stand-alone Pi Projects

If you're building a battery-powered  stand alone project you may need an output mechanism that's a bit more informative that a few flashing LEDs,  your power budget may not run to WiFi, and you may want to use what you're making in an environment where a network-based solution is not practical.

Another application: running a physical computing course

It may be hard to connect to the Pi because you don't know its IP address.

Earlier this year I helped to run a couple of workshops covering physical computing on the Pi. Practical considerations meant that we couldn't use monitors for each Pi, and we had to connect to the local network using DHCP.

It would have been really helpful if we'd had a text LCD for each Pi displaying its assigned IP address.

3 popular ways to link the Pi to a text LCD

There are plenty of articles on the web explaining how a Pi can drive a text LCD. I've listed a few at the end of this post.

They fall into three main groups.

1. Some drive the LCD via the Pi's GPIO pins
2. Some use I2C with a port expander like the PCF8547 or MCP23008
3. Some commercial products use I2C with a slave micro-controller which then drives the LCD

No-one is prefect

Each approach has some disadvantages.

1. The main problem with using the GPIO pins is that there are only eight of them (not counting the special-purpose pins which may already be in use). Driving the LCD display will use at least six of them. For many projects, that's not acceptable. It certainly wouldn't work for our courses where several of the labs involve driving things via GPIO.
2. I've used the port expander approach in past projects. It works, but it requires a lot of traffic on the I2C bus; you need to send multiple bytes over the bus in order to display a single character. For some applications this causes an unacceptable bottleneck on the I2C bus.
3. I like this approach, but it's not cheap. Most I2C-based LCD displays cost almost as much as a Raspberry Pi!

My preferred approach: hacking the veroduino

The approach I'm trying was suggested by my first experiment with the teensy 3.0. I'm going to build a simple veroduino (see below) which I will control over I2C. On the software side, I'm going to merge the standard Arduino I2C slave example with the LiquidCrystalFast library, adding some simple control code.

I'll publish diagrams and code when they are ready.

Web resources

There's a great article on driving Text LCDs via GPIO from Python on the Raspberry Pi Spy website.

Gordon Henderson has added C support for LCD displays to his super wiringPi library.

One good example of a port-expander based approach is the Adafruit LCD backpack, and there's a tutorial in the Adafruit learning system.

I described a DIY version using the PCF8574.

I did a very short write-up of a good commercial micro-controller based I2C LCD product.

A couple of years ago I described an I2C Arduino-based approach for the BeagleBoard, and I wrote about the venerable veroduino back in 2010.

The Arduino Yún just keeps on going

The Arduino Yún has been running for a couple of days now.

Nothing earth-shattering about that, you might think:  one of my Linux boxes got rebooted  just four times in a decade, twice for house moves, once for a power cut, and once for a kernel upgrade.

However,  my Arduino Ethernet board crashes repeatedly after a few hours of air-time. I don't know whether that is due to software problems with the Ethernet stack or a hardware issue, but the Yún seems much more reliable.

Driving text LCDs with the teensy 3.0

A few days ago I started exploring the teensy 3.0. I'm keen to see if we should consider using the teensy for C3Pi, so I want to get more familiar with the teensy hardware and the development environment.

When you install teensy's extensions to the Arduino IDE you are given a chance to install a number of additional libraries that have been tested on the teensy family. One of them - LiquidCrystalFast - caught my eye and I decided to explore it in more detail.

The LiquidCrystalFast library

LiquidCrystalFast is yet another library for driving text LCDs based on the ubiquitous Hitachi HD44780. I love these displays, and so do many hobbyists; a old post about an Arduino DVM with LCD display is one of the most visited pages on this blog.

The standard Arduino LiquidCrystal library works pretty well, but suffers from two minor issues.

The first is that it doesn't work as it should for 4-row 16-column displays. (It's fine for 2 row displays and for the 4-row 20-column variety).

The other issue is that it relies on precise timing of the signals it sends to the LCD.

Two LCD Driver designs

Displays based on the HD44780 can be driven uni-directionally or bi-directionally. The standard Arduino library uses them uni-directionally, which means that the code contains delays to make sure that the display has time to process each command.

The LiquidCrystalFast library uses the data lines bi-directionally, and as a result it runs significantly faster. Display speed is not usually a problem, but using up too much of the Arduino's processing power can be. If you're trying to do lots of other work on the 8-bit micro, a slow LCD driver isn't ideal.

The library also fixes the bug with 4-row 16-column displays.

Don't fry your teensy!

The LiquidCrystalFast library is a little harder to use on the teensy 3.0 because of voltage incompatibility. Like most ARM-based systems, the teensy accepts inputs between 0 and 3.3 volts; most LCDs use 5 volt signals. If you're using the data lines uni-directionally, that's not a problem, as most displays work fine with 3.3 volt inputs. If you use it bi-directionally the display's 5 volt outputs could damage the teensy.

All this is clearly explained on the teensy website, along with a simple solution. You just insert four 1k ohm resistors between the data pins on the LCD and the GPIO pins on the teensy.

Don't get spaghetti on the Breadboard

The only downside of the hardware layout on the teeny website is that the wiring is a bit spaghetti-like. Neater layouts are easier to check.

Fortunately the library allows you to change the pin assignments on the teensy, and it's possible to do so in a way that lets you create really neat connections.

Here's a Fritzing diagram of the layout I ended up with. It was really easy to wire it up, and it worked right away.

The only thing you need to change in the provided LiquidCrystalFast sketch example is the statement that creates the lcd object, which should read

LiquidCrystalFast lcd(2, 3, 4, 9, 10, 11, 12);
        // LCD pins:  RS RW EN D4 D5  D6  D7

My next task is to modify the breadboarding and the sketch to use a stripboard-based arduino clone which I can drive via I2C; it's an enhanced version of an old project and I plan to use it with the Raspberry Pi and the Quick2Wire interface board.

Arduino Yún - first impressions

The Arduino Yún is the latest addition to the Arduino range, and it looks very exciting.

In this post I'm assuming that you are familiar with the Arduino and with Linux; I may write a beginner's introduction later.

The Yún combines the features of a traditional Arduino with a tightly-coupled Linux System-on-a-chip (SoC). The two are seamlessly connected via SPI using a Bridge class on the Arduino and some Python code on the Soc.

Easy internet connectivity

The Yún's Linux SoC makes it easy to integrate physical computing projects with the Internet. Previously you'd have needed an Ethernet shield or an Ethernet Arduino, using a fairly limited API which was not  always reliable. The Yún gives you many different ways to connect you applications to the internet. Some are useful but very simple; some will take longer to master but look extremely flexible.

Shield Compatibility

The Yún follows the form factor of its predecessors, so you can use it with many existing shields, or breadboard it as you would a traditional Arduino prototype. To develop software for the Yún you'll need a compatible version of the Arduino development environment. At the time of writing that's version 1.5.4, described as a beta though it's worked well so far in my limited experiments.

Connecting to the on-board Linux SoC

There's quite a bit of information about using the Yún on the Arduino website, including a getting started guide. I leapt in without following its process; I connected the Yún to its micro-USB cable, plugged in an Ethernet cable, and fired up the Arduino IDE. When I looked at the ports menu of the IDE, I could see an entry for an Arduino Yún at IP address 192.168.1.69. I connected to it as root using ssh and was rewarded with the logon screen of the embedded Linux processor:

Connecting to the network Console

Next I tried a quick code example from the Arduino website which uses the bridge to connect to the network-based console. It worked perfectly. The example lets you turn a LED on or off via a remote connection, and suggests a whole range of potential applications.

Connecting to Temboo

Encouraged by that, I tried the new temboo interface. Temboo offers a simple RESTful API that can access hundreds of different services from different vendors. Among them is an API that can access Google's geocoding service, which converts a Postcode into Latitude and Longitude.

It takes under a minute to sign up for a free account with temboo; once you have done so, you can use their API from a browser, from a program on your desktop computer, from a phone or tablet, or from your Arduino Yún.

When I tried the example I got confused by the fact that the Yún has two serial consoles available. One is USB-based, the other is telnet-based, and the temboo sample code uses the USB version. Once I'd got that sorted out, I could see my Yún connecting via temboo to Gooogle's geocoding API and correctly displaying my geocoded postcode.

Much more to explore

There's a huge amount of functionality available for the Yún, and it's going to take a while to explore it all. I have two other projects on the go at the moment, but I suspect I won't be able to resist the lure of the Yún for long!

Three reasons why I like teensy 3.0

I've just been experimenting with the Teensy 3.0, and it's fantastic.

The teensy 3.0 is the latest member of Paul Stoffregen's teensy family. The teensy boards are USB-based micro-controller development environments, like the Arduino but teensy :)

Three reasons why I like teensy 3.0

• ARM Hardware
• Arduino Software
• It's breadboard-friendly

ARM Hardware with lots of extra functionality

Early versions of the teensy used Atmel AVR chips, like the Arduino, but the teensy 3.0 uses an ARM processor.

The  teensy 3.0's CPU is a 32-bit MK20DX128 Cortex-M4 from Freescale. You can run it at up to 96 MHz. That's six times faster than the clock on a typical Arduino, and the speed is matched by plenty of memory for program and data. There's space for 128K bytes of program in flash and 16K bytes of data in RAM. As an added bonus, teensy 3.0 has plenty of pins, both general-purpose and specialised: 34 general-purpose GPIO pins, of which 12 can be used as analogue inputs.

The teensy 3.0 has too many pins to connect to its headers; the extras are brought out to solder pads on the underside of the board.

Arduino Software

These days it's easy to find inexpensive ARM-based development boards with their own development environments, but the teensy 3.0 is different: you develop software for it using the Arduino IDE. Almost  all the Arduino libraries are supported, as are many third-party libraries. I've had a quick play with the LiquidCrystalFast library, which is an improved version of the standard Arduino Text LCD driver; it works really well, and I'll write up the experiment next week.

Teensy Tips

I've found the teensy easy to work with, but I did hit a couple of minor snags which you'll want to avoid.

The first was entirely my fault. By default the teensy comes without header pins. I soldered mine in at an angle, and when I tried to repair my mistake I managed to make a solder bridge between the pins of the processor which was fiddly to remove.  The small form factor of the teensy means that you need to be very careful when soldering the headers.

The second problem was easy to fix. I'm running the Arduino software on a workstation with Linux Mint 15. I'd installed the Arduino environment from the appropriate repository, and had difficulty  in installing the teensy enhancements.

I might have been OK if I had run the installer as root, but instead I decided to remove the sightly outdated version of the Arduino environment and install an up-to-date zip file downloaded form the Arduino website. Once I'd done that, the teensy software installer worked perfectly and I had no trouble programming the device.

Overall the teensy 3.0, like its predecessors, is a well-thought-out product that's great value.

If you're looking for a product that combines the processing power of an ARM CPU with Arduino's ease of use, the teensy 3.0 is a great buy.

You can get it for $19 from Paul Stoffregen's PJRC store; UK customers can buy it for around £19.80 including VAT from a range of local sources, including SK Pang.