First Android App - Don't Eat Pete!

After a several months of developing my first Android app, I just published Don't Eat Pete! on the Android Market

Don't Eat Pete! - The Game

Perfect for young kids, Don't Eat Pete is a simple yet fun family activity. For those of you unfamiliar with the game, you draw a grid on a piece of paper. In each square of the grid, you place a piece of candy. Someone is selected to leave the room while the other players select a grid to be "Pete." After returning, the player begins eating candy until they begin to eat the candy on the grid selected as "Pete." All other players must yell "Don't Eat Pete" in order to prevent "Pete" from being eaten!

Don't Eat Pete! - The Android App

Don't Eat Pete! the app delivers all the fun of the regular game without the sugar. Simple game-play enables even young children can play and enjoy Don't Eat Pete. With the ability to control the playing grid size, the app randomly creates a grid with a hidden "Pete" square. As the player eats candy, people appear underneath until the player tries to eat Pete!

All about the LPC1343 USB Bootloader

So, you want to use the USB bootloader function built into the LPC1343? Personally, I think this is one of the coolest built in functions. Why? A lot of chips have serial bootloaders. In fact, all of the NXP LPC series chip have a built in bootloader. Why is the USB bootloader so cool?

Why is the USB bootloader so cool?

Who has a serial port?

Serial bootloaders are great if you don't want to buy an expensive JTAG or programmer. However, they have some shortcomings. First, you need a serial port. In the past 10 years, serial ports have slowly disappeared from computers. Often, you need a USB to Serial converter or level shifter, which defeats the purpose of not having a JTAG or programmer.

Speed is everything

Serial is slow. If you are lucky, you get 115200 baud to work on the LPC bootloader. Usually, I'm stuck at 57600. Regardless, USB is fast. 12Mbit. Programming the device happens in the blink of an eye.

Built in goodies

Guess what? That USB bootloader implements a lot of code. Code that you can use. The LPC1343 bootloader resides in ROM and contains all the code necessary for a USB Mass Storage Device. All you have to do is fill out the necessary USB device info, call an init function, and then a connect function. The ROM saves you around 8K memory space, and a lot of headaches (if you know some stuff about it).

Great! How do I use it?

If you want to implement the USB bootloader functionality into a new design using the LPC1343, you need to know the following.

Crystal/Oscillator selection

The USB bootloader code expects a 12Mhz external clock source. Why does this matter? The bootloader must set up the USB PLL in order to generate the 48MHz clock used in USB. The PLL settings are hard coded into the ROM. Any other frequency other than 12MHz will cause the the bootloader to crash and not function.

Soft Connect

It took some digging to figure out what 'Soft Connect' does. In short, the Soft Connect feature allows you to control when the host device detects that a new end device becomes available. It does this by connecting a 1.5K pull-up resistor to 3.3V. What does that mean for you? The device now can control when it must respond to host commands, allowing it to execute any initiation code without time constraints. Additionally, you can disconnect and reconnect the device without physically removing the device.

Most reference designs use a PNP BJT. A P-channel FET works just as well, reduces current consumption, and is available in ridiculously tiny packages.

Here is my reference design which is known to work

Getting Started with Android Development, Modifying the Snake Example for Touch Input

Google has done a good job with the Android SDK, especially including documentation. The only problem is, however, that the excess of documentation can be overwhelming. An inexperienced developer may find it difficult to pick out simple items in the wealth of information. Consider this the first of my 'Getting Started with Android Development' posts.
Recently I purchased a newer model Android device, only to find the example games used the keyboard exclusively. Wouldn't you know, my phone doesn't have a keyboard! Let's modify the Snake example to work with touch events.
Implementing touch events can be broken into three pieces,

1. Create an input listener
2. Register your listener
3. Implement your input handling function

The difficult thing is to pick a way to do this. Check here for an overview on the 3 ways to do this. I chose method 2, implementing the event listener in the View.

Creating an Input Listener

For this tutorial, I assume you are able to load the Snake example program. In the /src folder find the SnakeView.java file and open it. First, we must tell the the SnakeView that it will be handling the touch events. Change

...

/**
 * SnakeView: implementation of a simple game of Snake
 * 
 * 
 */
public class SnakeView extends TileView {

...

XBee Enabled Joystick pIII

If you are arriving at part III first, check out the first two parts.

Xbee Enabled Joystick, part I
Xbee Enabled Joystick, part II

I finally got around to demonstrating this project. It has been a long time in the making. Throwing an Arduino with an XBee shield onto my homemade RC boat, Das Boot seemed like the simplest method to demonstrate the 'XBee Enabled Joystick'.

Setup

The setup is the same as before in the first two parts. I only changed the sample rate on the joystick XBee to 0x021, which translates to 33ms, or about 30Hz. Below you can find sample code I used to demonstrate this project. I'll admit, the code was quick and dirty, but demonstrates some principles of parsing the XBee sample packet.

Enjoy the video!

How to Neuter the Invincible Tornado (How to Remove the Speaker)

My mother-in-law decided to give my son an Invincible Tornado for his birthday.

Looks like a fun little R/C car. Unfortunately, there are 2 versions. One version (the version we got) plays annoying loud music when powered on. My mother-in-law warned me about this, and suggested I do what I know how and mute it with my electronics know-how. I'll be going through the steps for anyone else with aching ears.

Remove 3 screws on top

First, remove the 3 screws on the top of the vehicle. The screw on the front is covered by a sticker that can be peeled back.

Turnigy 9X Antenna Hack

I finally finished my Turnigy 9X Antenna Hack video! This moves the antenna to the wireless module, making it possible to completely remove the wireless module. The video is a little long, enjoy!

HowTo: Handbrake + Ubuntu + Encrypted DVDs

Every now and again I re-install Ubunutu and have to figure out how to re-install Handbrake and the DVD decryption.

Just a disclaimer, the legality of this is suspect, and this should only be used to make back-ups of DVDs you own. Blah blah blah. Be honest.

The following instructions come from Medibuntu documentation and Handbrake Ubuntu Installation instructions and work for me on Ubuntu 11.04.

The 5 steps to use Handbrake with Encrypted DVDs on Ubuntu

1. Install Handbrake. There is a handy Ubuntu PPA, which has the most recent Handbrake builds.
   $ sudo add-apt-repository ppa:stebbins/handbrake-releases
   
2. Add the Medibuntu repositories, which have the libraries for decrypting DVDs
   $ sudo wget --output-document=/etc/apt/sources.list.d/medibuntu.list http://www.medibuntu.org/sources.list.d/$(lsb_release -cs).list && sudo apt-get --quiet update && sudo apt-get --yes --quiet --allow-unauthenticated install medibuntu-keyring && sudo apt-get --quiet update
   
3. Install the libdvdcss2 library for decrypting DVDs
   $ sudo apt-get install libdvdcss2
   
4. Update everything and install Handbrake
   $ sudo apt-get update && apt-get upgrade -y && apt-get install handbrake-gtk -y
   
5. If everything went well, you can run handbrake with
   $ ghb
   and you can read encrypted DVDs! Hooray!
   

Turnigy 9X Wireless Module Resistor Fix

I recently posted how to do the Turnigy 9X resistor fix on rcgroups. Somebody pointed out that you could do the fix without opening the radio itself. You could apply the fix to the wireless module on the back of the 9X itself. I felt a little 'hackish' tonight, so I thought I'd give it a try and post a video HowTo.

How to generate .hex files from Code Red's LPCXpresso to use with FlashMagic

Recently I struggled to be able to use with the LPC serial bootloader and FlashMagic with the LPCXpresso software from Code Red. All I wanted was a .hex file to load onto an LPC1759. LPCXpresso generates a binary AXF file. FlashMagic requires an ihex file. The hex file actually is just the binary file converted to an ascii file. Unfortunately, due to the rich features of LPCXpresso, you have to dig to figure out how to automatically convert the .axf into a .hex. These steps should bring you a step closer to flashing code to your LPC chip over serial.

Official Code Red and LPCXpresso Documentation

Code Red provides two links with information on how to convert your program into a usable .hex for FlashMagic.

1. Generating srec (Motorola S format), binary, ihex (Intel Hex) files
2. Post-processing your linked application

Changing the project settings

In order to begin, you need to open your project settings. Once the project properties are open, choose 'C/C++ Build' -> 'Settings'. On the right, select the 'Build Steps' tab.

Now, edit the 'Post-build steps' command and add the steps to create a .hex that FlashMagic can use.

Steps to go from a ELF to a FlashMagic compatible HEX file

I got these steps from a thread on NXP's user forum. They agree with the knowledge base article.

Add the following steps to your Post-build Steps -> Commands

1. ELF=>BIN without CRC:
   
   arm-none-eabi-objcopy -O binary "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin";
   
   
2. BIN=>BIN with CRC (this is useful for USB ISP mode with LPC13xx parts):
   
   checksum -v "${BuildArtifactFileBaseName}.bin";
   
   
3. BIN with CRC => HEX with CRC:
   
   arm-none-eabi-objcopy -I binary "${BuildArtifactFileBaseName}.bin" -O ihex "${BuildArtifactFileBaseName}.hex";
   
   
4. Save your project properties, and then repeat for your other Build Configurations (Debug/Release).

Now, when you rebuild your project, LPCXpresso should generate a .hex file that FlashMagic will be able to use.

Next, getting your code to actually run...

XBee Enabled Joystick, part II

This is a continuation of XBee Enabled Joystick, part I, that involved the physical hacking of the joystick. Part II consists of setting up the XBee to spit out sensor data from the joystick to another XBee.

Alright, it has been awhile, but I decided to finally finish off this project. Sort of. For today, I will just be doing something simple with the final result, eventually, I may even hook the XBee enabled joystick up to something that moves.

What is an XBee anyway?

Before I begin, I'm going to explain a little about what an XBee really is. Most people think of XBees as wireless modems, and not much more. XBees do much more, however, than just act as a modem, transporting bits from here to there.

First, XBees contain a processor, which takes care of the communication processing, taking care of packet routing, buffering data, power management, and more. Now, if you are putting a micro processor into something that has ADCs, PWMs, GPIOs and more, why not use them? For this reason, the XBee can do much more than just act as a method to communicate. Some of the later versions of XBees even allow you to load and execute your own code in the spare memory.

With all the extra functionality, Maxstream hoped that the XBee could function on its own without an additional processor to carry out simple tasks, such as reading sensor data.

First steps first, configuring the XBees to talk to each other. For this, I will simply be setting them up with short 16 bit addresses that point to each other. Perhaps in the future, I might do a post more in depth about configuring XBees with coordinators and such.

Turnigy 9X Resistor Fix

**Update Jul 2011** Created a new post and an instructional video on how to do this fix on the wireless module, which is much easier and does not require cracking open the main radio body

A couple months ago I received my Turnigy 9X radio. For the price, I couldn't be happier. When I purchased the transmitter, I expected to be taking it apart and tinkering with it. I happened to drop the radio, almost brand new, breaking off a switch and forcing me to crack it open. While open, I figured I could take care of the resistor fix while the thing was open.

The Resistor Fix

What people refer to as the 'resistor fix' solves the fairly annoying problem that in order to use the training port on the Turnigy 9X, you must unplug the 2.4GHz module. Not usually a problem to unplug a wireless module, but someone decided it would be nice to hardwire the antenna to radio on the 9X. Unplugging the 9X wireless module leaves the wireless module dangling on thin fragile coax.

Read the rest of this article at my other blog, RCShenanigans >>>

Installing and Compiling Ogre3d code with Ubuntu 11.04

I finally successfully compiled the Ogre3d example code. Hooray! It wasn't as straight forward as it should have been.

I installed the ogre libraries from the Ogre PPA. Should have been that simple, right? Not so much. I am running Ubuntu 11.04, 64bit. Most of the Ogre resources are configured for paths for Fedora/RedHat which installs everything in /usr/local/OGRE/. Ubuntu/Debian distros install ogre stuff in /usr/OGRE/. I outline below where you need to make some changes.

Here are the steps that I took

1. Follow the steps here to install all of the prerequisites. As a note, the boost packages might not install because the dependecies are for version 1.42 but you may already have version 1.46 of the boost libraries installed.
2. Follow the steps here and install the ogre libraries through the Ubuntu PPA. You should also be able to install the ogre-samples-media and ogre-samples-src packages
3. Follow the instructions here to compile the base example program with CMake. I had to also install the cmake-qt-gui. There are a couple modifications that need to be made to get the instructions to work.
   
   1. Modify CMakeLists.txt by changing all references pointing to /usr/local/ to just /usr/. This corrects the following cmake errors
      CMAKE_BUILD_TYPE RelWithDebinfo
CMAKE_INSTALL_PREFIX /usr/local
OGRE_DIR OGRE_DIR-NOTFOUND
OID_DIR OID_DIR-NOTFOUND
   2. Before running make install in the tutorial, you also must modify plugins.cfg and change all references from /usr/local/ to just /usr/. There should be 2 if I remember correctly.

If all goes well, you should get this

Hooray! Now, why was this so difficult?

Arduino High Current Motor Shield from Sparkfun

Now there is a source for something like this!

Looks like Sparkfun decided to make their own high current motor shield for the Arduino. Beware, the page says 41V and 30A right now, but it uses the same chips that my shield uses, which shutoff somewhere between 16V and 22V.

However, I am still planning to make an even more powerful, higher voltage motor controller (version 2) that can handle brushless motors as well.

DorkbotPDX Delivers

Exciting news today. In February I just missed DorkbotPDX's 4 layer panel, but I ordered some 4 layer boards anyway. The boards arrived today, and on first glance they look great.

I thought I'd add some scale, but the only coin I had on me was an obscure coin that doesn't add much scale.  I expected HASL finish, but happily discovered that the batch had been upgraded to ENIG.  On first inspection, the alignment looks great, holes are centered, contour routing doesn't touch the inner planes.  I'll be racing to populate one to test the boards out and put them through the paces.  The silkscreen is slightly better than average in resolution and clarity.  All told, 3 of these for $16, not bad at all! Can't wait to throw some parts on and fire them up.

I think I will be using this service even more in the future!

High Current Motor Controller Shield Schematic

Good news, folks! I've decided to post the schematics for the high current motor controller shield with some knowledge on how to use the VN2SP30 IC. The schematic is taken almost directly from the datasheet from ST. I left out the reverse voltage diode because I have a polarized connector, but I still managed to accidentally reverse voltage and fry it. The next rev will include reverse voltage protection.

Here is some sample code to run the motor controller. Disclaimer: This code was written in minutes and may not be the best code in the world

Example Sketch for the Motor Controller Shield

/*
    High current motor controller shield example sketch
    ilektron-x.blogspot.com
*/
const int pwm1Pin = 5;   // the pin that the pwm1 is attached to
const int pwm2Pin = 6;   // the pin that the pwm2 is attached to
const int ina1Pin = 7;   // the pin that the ina1 is attached to
const int inb1Pin = 8;   // the pin that the inb1 is attached to
const int ina2Pin = 9;   // the pin that the ina2 is attached to
const int inb2Pin = 10;  // the pin that the inb2 is attached to

#define timestep 20
#define kscale 11370     // Calculated from datasheet, used to convert ADC reading to current
#define res 1500         // Current sense resistor value

void setup()
{
  // initialize the serial communication:
  Serial.begin(57600);
  
  // initialize the motor controller pins as an output:
  pinMode(pwm1Pin, OUTPUT);
  pinMode(pwm2Pin, OUTPUT);
  pinMode(ina1Pin, OUTPUT);
  pinMode(inb1Pin, OUTPUT);
  pinMode(ina2Pin, OUTPUT);
  pinMode(inb2Pin, OUTPUT);
  
  // Make sure everything is low, set up the motors to spin in opposite directions
  digitalWrite(pwm1Pin, LOW);
  digitalWrite(pwm2Pin, LOW);
  digitalWrite(ina1Pin, HIGH);
  digitalWrite(inb1Pin, LOW);
  digitalWrite(ina2Pin, HIGH);
  digitalWrite(inb2Pin, LOW);
}

void loop() {
  static byte speed1 = 0;
  byte rxdata = 0;
  byte cs1 = 0;
  static int countdown = timestep;
  
  static long current1 = 0;
  static long current2 = 0;
  float cval1 = 0;
  float cval2 = 0;

  // check if data has been sent from the computer:
  if (Serial.available()) {
    // read the most recent byte (which will be from 0 to 255):
    rxdata = Serial.read();
    
    // 'u' key press ups speed, 'd' decreases it. 0-9 set the speed to 0-90% of speed
    switch (rxdata)
    {
        case 'u':
          speed1 = (speed1 < 250) ? speed1 + 5: 255;
          break;
        case 'd':
          speed1 = (speed1 > 5) ? speed1 - 5: 0;
          break;
        case '0':
        case '1':
        case '2':
        case '3':
        case '4':
        case '5':
        case '6':
        case '7':
        case '8':
        case '9':
        case ':':
          speed1 = (255*(rxdata-'0')/10);
          break;
        default:
          speed1 = 0;
          break;
    }
    
    // Display what the new speed setting is
    Serial.print('\n');
    Serial.print('s');
    Serial.print(speed1, DEC);
    
    // set the motor speed:
    analogWrite(pwm1Pin, speed1);
    analogWrite(pwm2Pin, speed1);
    
  }
  
  current1 += analogRead(0);
  current2 += analogRead(1);

  delay(1);
  if (!countdown) // Simple countdown timer to space out frequency of current reading output 
  {
    // Calculate current for motor 1
    Serial.print("M1:\0");
    cval1 = current1;
    cval1 = (cval1*kscale/timestep)/res*5/1024;
    Serial.print(cval1, 3);
    // Calculate current for motor 2
    Serial.print("\tM2:\0");
    cval2 = current2;
    cval2 = (cval2*kscale/timestep)/res*5/1024;
    Serial.print(cval2, 3);
    Serial.print('\n');
    countdown = timestep;
    current1 = 0;
    current2 = 0;
  } else {
    countdown--;
  }
}

Arduino - Perspective from someone with embedded experience

Recently there have been some articles about why the Arduino is here to stay and how to kill it.

It concerns me that people want to kill the Arduino. Why kill a project that meets a definite need? Time to rant a little bit.

In order to give a little background, I have experience with PICs, AVRs, LPCs, DSPs, and more. I've put these microcontrollers into all sorts of applications. I've used all sorts of development tools. Guess what? As you can gather from my blog, I own an Arduino. And I play around with it.

Recently, I recommended Arduino platforms to two of my Mechanical Engineer friends. Both projects they were working on needed a microcontroller. Both projects contain components more complicated than blinking LEDs. One project hopes to assist a sibling with automating a home business, the other project is a complicated hobbyist robotics project. Why did I steer them towards the Arduino?

Have I betrayed my hacking roots by steering them to the Arduino when I could have pointed them in any direction? Let us look at the options.

PICs

The Good

PICs are the original hobbyist microcontroller. PICs come in many forms, from motorcontrollers to RF transceivers. A friend of mine opened his car's key fob only to see an pic inside. Used in major industry, PICs definitely have a lot to offer. To add to PIC's credit, they are robust well designed chips that can take a lot of abuse.

The Bad

As great as PICs are, even for an experienced engineer, it can take a couple of days before you get code running on one. Like a lot of microcontrollers, it requires the user to pour through datasheets looking for registers and bit values.
Almost all PIC projects require a programmer. The programmer is PICs Achilles's heel. They don't work 100% of the time. I've fried a couple of them. The simplest one, the PICkit, my favorite of the programmers, cost more than I'd like to spend on a programmer. One last gripe, Microchip's IDE for the PIC, MPLAB, doesn't exude love or freedom.

AVRs

The Good

I am not sure why, perhaps because I love linux, I have a crush on AVRs. You can develop and program AVRs from any platform with a multitude of IDEs thanks to gcc-avr. Even Atmel's development suite provides a multitude of features. AVRs have some unique features, one in particular makes it easy to implement bootloaders on the AVR. AVRs, like PICs are difficult to damage, and come in many varieties and flavors.

The Bad

Although you can pick up an AVR programmer for $20, they still require one to get started. You still have to pour through 300 page datasheets looking for registers to modify to set up PWM or UARTs. Users coming from little or no programming background face the same large learning curve like with the other microcontrollers.

LPC

The Good

One of my personal favorites, the LPC series chips provide a large selection of peripherals, and power. They include ARM cores, allowing a user to utilize several of the open tool chains, or even proprietary ones if they choose. LPCs ship with a serial bootloader, eliminating the need for a JTAG or programmer. A simple TTL serial cable is enough. The LPC1343 comes with a USB bootloader that shows up as another drive containing firmware.bin!

The Bad

Setting up the tool chain can be frustrating. Getting the serial bootloader working may not be as easy as it sounds, and often doesn't work for some reason or another the first time. No different than the others, long datasheets threaten to slow you down as you look for the right register bit value.

Arduino

The Good

$30 complete package. Incredibly simple IDE that just works. Figuring out which serial port to use is the most difficult part of setup. Arduino includes simple libraries for otherwise overly complicated tasks. Huge community support and very open user base.

The Bad

The Arduino is not hardcore because anyone can do it. Arduino specific functions suffer performance hits due to overhead. Pin functions are somewhat locked in to specific functions, for example, analog pins. Arduino stackups can become quite bulky compared to a custom solution.

The Ugly Comparison

What does Arduino offer that the others do not? Watered down programming and a dumbed down development environment? TI offers a development board for $4.30 while the Arduino cost $30. Other chips offer boot loaders, more power, more control, and raw C goodness?
Back to my friends to whom I recommended the Aruduino to. Both of them set up the IDE and had code running within half an hour. By themselves. One of them had text up on an LCD within the night. The other was reading sensor values the same night. One had worked with LabView, the other Matlab, but neither had any embedded experience. Guess what? Neither would have tasted such quick success using another platform. I doubt they wanted to set up a compiler or figure out a programmer. I imagine they will never care about the finer points of a UART, peripheral clocks, ADC timing, or power options. Do you have to understand calculus to calculate interest or know control theory to use cruise control? Sure, it would be nice if everyone knew calculus, but it will never happen. The Arduino provides a platform that provides the power of C without a lot of challenges of getting things to work. Arduino is the personal computer of the embedded world. Somebody else already got everything to work. If people using the Arduino want eventually 'upgrade' to something more barebones, great! If not, great! Not everyone enjoys the embedded aspect of their projects.

Look at Sparkfun. The whole company works by wrapping raw products into nice friendly functional packages. Sure, I could design my own widget that they sell, but purchasing widget X gets me to my goal faster and easier and helps me avoid design aspects I don't care about if my goal is simply a completed project.
I will continue recommending Arduino even though I, myself, may not use it for more than just prototyping. I hope to see the Arduino continue to grow and continue to meet the demand that it fills.

Time to work build a new motor controller

I finally got around to testing out the repaired motor controller after the reverse voltage fiasco.  No dice.  The thing ist kaput.  I threw a quick tutorial on removing SMT components from PCBs to show how easy it can be to quickly do some hot air rework with a $25 heat gun.  Here is the video, enjoy!

(PS, while it uploads I will be updating the high current motor controller shield and working on V2)

Evalbot has arrived!

Despite doubting that TI would honor the $125 off coupon, guess what arrived at my door last week?

Amazing!  I promptly put it together and let it wander around the living room while my 2 year old chased it, stepping on it repeatedly while trying to trigger the bump sensors with his foot.

Hopefully I'll find some time to play with it and try to write some code for it in linux, thanks to this post, Evalbot: Hello World!, linked from Hackaday.

Although wheels and motors are great, what I would really like to swap the motors for some LEDs, plugging this into my home network, and using this as a home automation server.  Or sell it for a profit.  Either way...

Dorkbot PDX

I just found a new PCB batch order source that beats the pants off of BatchPCB.com.  $5 per square inch for 2 layer boards and $10 per square inch for 4 layer boards.  The best part?   The price is for sets of 3.  That is right!  In reality, that is $1.66 per square inch for 2 layers, and $3.22 for 4 layers.  Amazing!


I'm sending off my first boards to be made now.  No more breadboarding/perfboard for me.  Not worth my time at those prices.