Sparkfun at Microcenter!

After reading this post on Hack-a-day, I went to the local MicroCenter to see what all they had to offer in a brick-and-mortar store.  I remember when Parallax and RadioShack had joined together and while the new availability had made it easier to get started with microcontrollers, the most common expression recalled is one of sadness at the general disarray of the parts cabinets.  Thankfully Microcenter seems to have done Sparkfun right.  Read on for my initial impressions of Microcenter’s offerings and a full review of my first Arduino kit, the Sparkfun Inventor’s Kit.

If you are interested solely in the review, scroll down to the “Finally, the review!” section below.

 Online Only stores and Brick and Mortar stores intersect, a bit of history.

A lot of online-only stores have made offerings into brick and mortar retail stores  with varying amounts of success, unlike retail stores going into online offerings which anyone would say has been a huge success and convenience.  Unfortunately, the DIY/Hobbyist market hasn’t seen such a success and for the most part has remained largely an online-only affair.

Several years ago, Parallax announced that they would start offering some sensors and kits for sale at Radio Shack.  After hearing the news, I was tentatively excited however after seeing their initial offering, I don’t think Parallax was done right by Radioshack. They were given half of a disorganized “parts drawer”  and a couple of pegs to offer hanging merchandise.  Despite Parallax’s attempt, the move into retail ultimately floundered. It is my belief that if Radio Shack had given Parallax’s parts offering a bit more shelf space  and Parallax had made more of an initial offer in Parallax’s own packaging, they might have been able to make it more successful. Instead, Parallax’s limited offering (around 10 sensors and the “What’s A Microcontroller” kit) and Radio Shack’s shoddy mismanagement of the parts bins where the sensors were stored served to bury the Parallax name in the forgotten corners of the store.

Although there was a post several months ago with a shot of custom Parallax retail packaging, I can’t find the link now, nor did any searching reveal any information. Several other companies watched the Parallax and Radio Shack situation unfold and took notes, now it’s time to evaluate another initial transitional offering from online only to online/brick-and-mortar offerings.

Now, to Sparkfun and Microcenter…

Sparkfun Electronics has been well known in the Arduino community with their extensive offerings online. Chances are, if there’s a sensor out there, they have it either in kit form or as a complete pre-fab module.  When I heard that they are making an offering through Microcenter, I was thankful that I lived near Microcenter. Using Parallax and Radio Shack as an example of a failed attempt, I went to Microcenter to scope out their product  offerings.  I was very pleasantly surprised.  Sparkfun’s initial product offering outpaces Parallax’s offering by a significant margin as shown in the image below.  Not only do they offer a Getting Started kit (reviewed below), they also offer a wide variety of parts and shields for the Arduino platform.

Sparkfun Offering at Microcenter.

You can see in the above photo that they have a lot to offer. From my estimates, they had the Arduino platform as well as the Inventor’s kit and several other non-Arduino projects.  They also offered a wide array of sensors and components as well as several Arduino shields in kit form. Some of the shields they offer is the Arduino motor shield, Arduino Prototype Shield with microSD card reader and the Arduino Joystick Shield.  Their component offering is equally impressive with a multitude of sensors, both serial and parallel character LCD displays, breadboards and modules. Something I saw that I plan on getting later on is a dedicated 3.7V Lithium Polymer charging module with battery.  This module will charge off a USB port and will keep an Arduino running for 50 hours according to the box.  Having something like this is a big bonus when working on embedded hardware.

They also offer several kits like the X-Bee modules kit (which is probably my next purchase) which contain everything you need to get started.  You get a USB to Serial converter board, two X-Bee modules and an X-Bee to Arduino interface shield.  Their RFID kit also has the same level of thought put into it with the necessary adapter board, the RFID sensor and sample RFID cards to experiment with.

In addition to their parts and components, I found something I had been wanting personally. They had tool kits available in store. The kits were ranged according to skill level (easy, medium and complex) with the complex kit featuring a multimeter and soldering iron, while the medium kit only offered the soldering iron.  As the user’s skill level progresses, they can add to their kit as needed.

One thing that seemed to stand out about their Arduino offering is that they introduced three flavors of Arduino.  The Arduino Uno (which comes in the Inventor’s kit as well as individually), The Arduino Mini (and the related FTDI programming module) and the Breadboard Arduino (Arduino made on breadboard rather than the standard PCB board).

For those of you asking about cost, this was one of my concerns as well.  In my previous experience, anything in a brick-and-mortar store is usually more expensive.  I did a side-by-side comparison with my phone as I priced random components and kits and I found that the cost at the store was pretty much dead on, only varying by a few cents.

Final thoughts

I am thankful that Sparkfun and Microcenter teamed up and I am hoping that they continue to expand their product selection.  I have a feeling that there are a lot of people out there that are wanting to get into microcontrollers and embedded electronics however just aren’t convinced and need that one little push over from “Maybe” to “Definitely”.  I can’t wait to see what is “in store” next.  (That was a pun, laugh!)

And without more blathering about Sparkfun and Microcenter, finally we get to the review.

Finally, the Review!

The kit I picked up is the Retail version of the SparkFun Inventor’s Kit (SIK)which has everything one would need to get started with the Arduino and electronics. I won’t enumerate the full list of materials in the box, however I will present several pictures as shown below.

SIK Kit cover

Most of the kits on the market have a hinge at one end however Sparkfun’s kit has a completely detached cover meant to be removed. This presents the bonus of not eating up twice the kit’s floor space on your desk.

Kit Contents

Inside the kit comes a nicely packaged assortment of parts in the right hand compartments and in the top compartment.  More on those in a bit.  The left hand compartment contains several pin jumpers for breadboarding and Arduino connections and the center large compartment holds the USB cable, the circuit flash cards, the Arduino in its own box and the mounting plate and breadboard.

Arduino Box

The Arduino Uno comes in its own little box, prepackaged and QC’ed from Italy where the Arduino was built and designed.

Unboxed Arduino

Along with the Arduino Uno comes a handful of stickers and a little pamphlet with more information about the Arduino.

Mounted Arduino and Breadboard

The mounted Arduino and breadboard on the included Sparkfun mounting plate.  This gives the user a good and stable place to work with the Arduino and the sample circuits in order to understand the Arduino’s capabilities.

Parts Pictures

The other parts of the SIK kit include:

•  74HC595 shift register (pictured)
• Rotary Potentiometer
• Photoresistor
• Two pushbuttons
• Piezo speaker
• Several LEDs
• Several Resistors in a few different values
• two Diodes
• Transistor (2N2222 variant)
• Subminiature Hobby Servo
• DC Motor
• Flex sensor (top center)
• Variable Flex resistor (under sensor)
• Additional headers and pins

The kit also includes a small booklet that has several circuits and sample code to get started.

Manual, flashcards and USB cable

The booklet (pictured) contains several circuits and is intended to be used with the flash cards together in order to guide the novice through building the circuits and becoming familiar with the Arduino.  The flash cards each contain a circuit diagram that correlates to how the components should be connected to the Arduino and the book contains sample code with a brief explanation of how the code works.

Thoughts on the booklet itself

The book is targeted at new users to the Arduino platform however I quickly came to the conclusion that this kit is not targeted at beginners to electronics.   Coming from the “What’s A Microcontroller” world that explained everything including the basic 101′s of electronics, this may be a bit off-putting for some however with an understanding of some of the basics, this may serve to bridge the gap between building basic passive electronics projects and more advanced digital electronics projects.

Unlike the “What’s A Microcontroller” kit, there is no complete guide to the command reference included in the kit however the Basic Stamp and the Arduino both have extensive community support.

Final Thoughts on the Kit

The Sparkfun Inventor’s Kit appears to be well stocked with a typical selection of components fit for a beginner’s kit and will make a good start in working with the Arduino, even if you have never had any microcontroller experience.  While I can’t recommend this kit as a complete beginner’s guide to electronics, any newbie should be able to perform additional research to locate the answers they seek.  This is not a completely offline course but I do not consider this to be enough of a deterrent to stop from recommending the kit.  I feel that this kit will be a great addition to any electronics bench and will help anyone with even the most basic electronics experience get started with the Arduino.

Verdict:  Buy!

Cost: $99

Found at: Microcenter and sparkfun.com (sku: RTL-10339)

The Parallax VGA GUI Demo is great for adding a pre-built GUI for your projects. The bonus is that the drivers for using a PS/2 keyboard and mouse and a VGA display are pre-built and ready to run.  With a little bit of configuration, you can add a well built UI to your application and make it easier to display output and receive input from the user.

In this article, I will demonstrate some of the basic options that are needed in order to get the GUI up and running.  While our application is going to be turning on a few LEDs, once you have these basics down you should be able to use this article and build whatever user elements are required for your application.

Prerequisites:

If you haven’t already, I would recommend the Parallax PS/2 and VGA Adapter board. This board provides two PS/2 ports (mouse and keyboard) and a 15 pin VGA port in an easy to use modular design that is breadboard compatible.  Here is a link to the VGA board on Parallax’s site and here is the link to my earlier article.

In addition to the Adapter Board, you will need
- A PS/2 mouse (Not a USB mouse with a PS/2 adapter)
- A PS/2 keyboard (Not a USB keyboard with a PS/2 adapter)
- A 15 pin VGA monitor
- six LEDs, any color
- six 100 ohm resistors (Brown-Black-Brown)
- Jumper Wires for the Adapter board
- A PC with USB port for the PropPlug USB programmer.
- 9V Battery or other 9VDC power source

Understanding the concept of a UI

Before we get started, let’s discuss the basic differences between a Prompt and a UI.

A Prompt:

• – asks for something direct like “Your Name”
• – Reads the response, Input halts until requirement satisfied, e.g. (Press any key to continue)
• – Treats the response as programmed, e.g. $YourName
• – is programmed in a linear fashion. e.g. You prompt for your name, then you prompt for your address, then you prompt for your date of birth, etc…

A GUI:

• Shows multiple items to interact with
• Reads a response when triggered with an event and does not wait.
• Performs actions based on event triggers.
• Can perform actions in a non-linear fashion. e.g. Clicking Button 1, Button 3, Button 2, Button 6, Button 1 again.

Remember, although a GUI can contain prompts (“Click OK to Continue”), it’s not often that a prompt becomes a GUI. Also remember that a GUI is Event driven, not prompted.

Events

It’s important to understand that performing any action with the mouse and keyboard triggers an event. It’s when the event (in most cases, a mouse click) occurs on a GUI element (a checkbox for example), we get something to happen.  By programming the Parallax GUI Demo, you will build GUI Elements (things to click on or type into) using Mouse and Keyboard Events in order to generate some kind of output (Lighting LEDs).

Keep this in mind, as generating events and how to deal with them are the cornerstone of any GUI programming (not just Parallax!).

Elements

Mouse events are nothing without something to interact with, so that brings us to the point where we have to talk about the GUI. Each object in a GUI, checkboxes, menu items, windows, submit buttons, etc. are all considered elements of the GUI. We build the GUI using elements to satisfy our program’s needs.  For the “What is your name?” prompt, we would need a window element (with a Window Title element), a text element saying “What is your name?”, a text field element (so we can get the name back to the program) and a submit button element.  That’s Five elements! Thankfully, only two of them are interactive.  The text field needs to be clicked on (to tell the GUI that keyboard input goes here), and the Submit button needs to be clicked on to tell the program to continue.

Even though we started out with five elements, thankfully we only have to code for two events.

Below is a screenshot of various elements that the Parallax UI is able to generate.

Parallax VGA Demo Screenshot

In this screenshot, we can see the following interactive elements:
- Spin Boxes – A single element with up and down arrows that allow you to select from a list of predefined options. (like a Page Count field on a Print window)
- Checkboxes – A listed series of predefined options that allow for multiple options to be selected.
- Radio Buttons – A listed series of predefined options that allow only a single option be selected.
- Pushbuttons – A single element that is clickable (like a submit button).
- Menu Bar – A horizontal element containing multiple pushbuttons.
- A Text Input field – Another horizontal element that takes input from the keyboard.

We also see the following non-interactive but still needed elements:
- Windows – We need windows to keep these elements organized, otherwise it doesn’t work too well.
- Status Lamps – Think of these as the GUI equivalent to an LED and resistor. They can be toggled on or off.

Now that we know what all the elements are, let’s do something.

Getting the hardware ready

Connect the 15 pin VGA/PS2 breakout kit to the lower right hand corner of the breadboard as shown in the image below. The breadboard should be oriented as shown with the PropPlug mounted on the top, usb cable pointing right. You can then connect the 12 pins straight across (watch out for the crystal) to the 12 pins on the right hand side of the Propeller (P16-P27).  Attach the Vss lead to any of the Vss busses (black lines) on your breadboard.

VGA adapter hooked up

In order to get the required +5V for the PS/2 mouse and keyboard, look closely at the two voltage regulators at the top of the board. There is an LM2940 (back regulator on the picture below) that provides the 5V and a LM2937 (front regulator) which provides a 3.3V source for the Propeller. Be sure to attach to the OUTPUT of the LM2940 as shown in the picture below.  As a hint, my wire is in the third horizontal row from the top of the LM2940 which is its output lead.

+5V location

DO NOT CONNECT YOUR +5V LEAD TO THE +9V BATTERY OTHERWISE DAMAGE TO THE PROPELLER, MOUSE AND KEYBOARD MAY RESULT.

After you have the VGA adapter connected, hook up the LEDs so that the cathodes go to ground and the anodes run through the 100ohm resistors to P0-6 as shown below.

LED connection

Get the software

If you haven’t already done so, download the VGA Text GUI Demo from here:  http://obex.parallax.com/objects/413/

Unzip the archive, load it up in your Propeller Tool application and load it into RAM to save write cycles on your EEPROM.  If everything works properly, you should be able to move the mouse, click on things and be able to type text in to the “COMMAND” field at the bottom. Play around with it for a bit and get used to how the elements interact with each other.  If you want to ensure that your wiring is correct, read the GUIDEMO and GUIBASE section below.

Before proceeding, it’s recommended to make a backup of the unzipped Propeller VGA demo so that you will have something to refer to in case you accidentally delete part of the demo application. Load the copy of the code for the next step and leave the original copy untouched.

Hacking up the Code

Now that you’re up and running with the test code, let’s take a look at the existing code and start modifying it.  We’ll cover important aspects of the existing code along the way. In our application, we will be using the UI to draw a simple window containing six checkboxes that correspond to the six LEDs we have installed.  Once finished, when we check a box, it will light the corresponding LED. If we clear that checkbox, it will extinguish the LED.

So let’s get started.

GUIDEMO.spin

The GUIDemo.spin file is considered the “Top Level” or “root” (if you’re a Linux admin like I am) of the entire  application. This file references sub-codebases through  an OBJ (Object) declaration. Although Parallax called it Top Level, I have always referred to it as the “root” as in the root of the project much like the root of a filesystem.

Without getting into the syntax of Spin (the Propeller coding language, a topic that Parallax is much better suited for than I am) just know that this is the trunk of the tree as far as all other pieces of code in the VGA Demo are concerned.

Code Heirachy

Starting at the top of the GUIDemo.spin file, you see a secion labeled CON. This is for the constants that GUIBase uses to initialize the PS/2 mouse and keyboard and the 15pin VGA port.

The vga_base should point to the I/O pin that is connected to the “V” pin of the PS/2 VGA adapter. The GUIBase will assume that the rest are mapped accordingly.  If you are using something other than the Parallax adapter, you will want to ensure that your adapter is wired up as shown below:

I/O Pin        Function
P16        V – Vertical Scan
P17        H – Horizontal Scan
P18        B0 – Blue Positive?
P19        B1 – Blue Neutral?
P20        G0 – Green Positive?
P21        G1 – Green Neutral?
P22        R0 – Red Positive?
P23        R1 – Red Neutral?

* Please note, the ?’s mean I’m not certain on polarity, but I am sure on the grouping. The reason is that I only have the Parallax VGA adapter so I haven’t tried to fabricate my own adapter.

The mouse and keyboard each require two pins, “dat” and “clk”.  The Parallax Adapter has each pin’s function silkscreened onto the adapter’s PCB for easy connection and are mapped as shown below:

I/O Pin        Function
P24        Mouse Data
P25        Mouse Clock
P26        Keyboard Data
P27        Keyboard Clock

If you’re using Parallax’s VGA adapter, then make sure that your values match what is shown above.  If you are using another adapter, make sure that the values match your respective device’s pins.

The OBJ section is where we declare any additional code that needs to be included. In the original code, you can see there are three objects declared (GUI, TMRS and NUMS) however for our program, we only need the first one (GUI).  Delete the two lines starting with TMRS and NUMS highlighted in the green square in the image below.

External Objects

When it comes time for you to add your own routines, you can include them here by defining them as objects. For now, just scroll down to the next section.

The VAR section is important because the code shows that all of the interactive elements in the GUI require a byte be assigned to them. This is important as this is how the GUI keeps track of what element is called when an event is triggered. It is critical to remember when you are designing your own GUI, that each interactive element has it’s own unique ID. This will be important later when we tie the elements into events. For now, remove all the declared bytes and add the below in it’s place:

Variable Bytes

In the above image, we are declaring six CHKB elements numbers 1 through 6.  The naming convention is important as there is code later on where these get defined.

Scroll down to the PUB statement below. This section is the actual code of the program and where we will be doing most of the editing.  First off, make sure that you can see between the CreateUI statement and the PUB statement (top of the blue section of code as pictured below. We will be removing the code there as it was used with the timers code object (that we removed) was initialized at start.  Just like before, delete all the code within the green box. It’s not needed and will generate errors if you attempt to compile it.

PUBlic function to delete

We will replace the deleted code with our own code. This  is the initialization code for our application and occurs prior to the GUI being set up. All our code does is ensure that the first six I/O pins (P0-P5) are set as outputs and are set low so that the LEDs are off.

When you are developing your own program, be sure that the initialization code occurs before the CreateUI statement for best results.

PUBlic INIT code to add

At this point, we have removed excess objects from our code and declared six variables for our checkbox elements and we have initialized the LEDs. Now we will tell the application what to do when an event has been triggered in order to get the LEDs to light up.

If you look at the code, you will notice that it is a very large repeat loop that contains a case loop inside it. The way it works is that the Propeller will constantly evaluate GUI.ProcessUI. When evaluated, it will check gx against the list of elements and if gx matches a defined element ID, it will then perform the appropriate action.

For now, start at the line that reads “case gx” and highlight the text down until you get to the “START OF UI HELPER FUNCTIONS”. Since we are not using the demo code in our application, we can safely remove it.

Once removed, add the code in the below image to tie in the events with our custom function. (We’ll write it next).

Public Events to add

In the above code, we are calling LEDFunction with a different parameter corresponding to each of the six LEDs. Now we need to write the function LEDFunction so it actually does something.

In your application, you may end up writing all of your code in another .spin file and then using an OBJ to declare it.  If you do that, then you can reference your OBJ functions instead of using a basic function here.

Start off by copying that CON statement and inserting it into the empty space. This will create a line we can use when reading the code to make it easier.  Change it from “UI HELPER FUNCTIONS” to “UI APPLICATION FUNCTIONS” and add the below code as shown.

PRIvate Function to add

In this section of code, we will write our function for the events.  All we are doing is taking the function’s parameter and inverting it’s existing value. If it’s 1 (on) it is then set 0 (off) and vice versa.  Although we return the value of the I/O pin, it is not used elsewhere and will get overwritten elsewhere.

Scroll further down and we finally get to the CreateUI function.  This is where the UI gets built and the bytes for the elements earlier get defined.

We can see that there are a lot of commands listed here. Don’t let that intimidate you as we are going to remove most of them. Find the line that starts off with “vga_cols” and highlight all the way down to the MIT License.  Remove the code and add the code in the picture.

GUI Code to add

This code draws out the Text box for our project and gives it a text label. Don’t worry about the syntax, we’ll cover that in the GUI CODE section later.

Basically what happens here is that a Simple Box (SBOX) gets drawn with the title of “LEDs”.  Inside that box, six checkboxes are drawn, each with their own text description. Pretty straightforward on the UI, right?

We’re almost done and ready to test our new GUI.

GUIBASE

Now, there’s one more thing we need to do before we go loading this project into RAM and seeing if it works. We need to make an edit to GUIBase.
At the very top of GUIBase, in the CON section, you can see that there is a note describing the GUI Element Inventory that must be present.  We need to edit the code and tell GUIBase that we’re only using six checkboxes.  However, as the note describes, we can’t just go set GZ_CHKB to 6 and all others to 0, as this would throw a compiler error.

Go ahead and set all of the GZ_ variables to 1 except for GZ_CHKB which will get a value of 6 since we have six LEDs as shown below.

GUIBase changes

Once modified, be sure to save your work and then go to “Run”, Compile Top, Load RAM.  You should get something like the below image on your display.

Our GUI LED demo

If all went well and you didn’t get a compiler error, you should get this GUI.  The little green square is the mouse cursor.  Go ahead and try it out. Make sure that checking each checkbox lights up an LED and that clearing the checkbox turns it off.

Now that we’ve got a working GUI up and running, let’s review what all we did aside from removing a lot of extra stuff.

• We declared a byte for each GUI element.
• We added initialization code.
• We added a declaration in the main loop to handle events from the UI to point to our function
• We wrote a function that did something based on the events we had given it.
• We updated GUIBase with the element count so that the GUI code knew how much it had to work with.

These are the fundamental steps for creating a UI with the propeller using the GUIBase code. Now that you understand the basics as far as what is required, let’s take a look at some other stuff you can do too.

Looking further into the GUI Code

In the GUIBase.spin file, you can find the code required to draw the various elements of your GUI.  Reading through the code,  most of the options required are in terms of position.  For example, the code for the simple box (window) shown earlier, required an X and Y coordinates (in rows/cols) to place the upper left hand corner of the UI, then the width and length of the box and a title.  The Checkboxes each required an X and Y coordinate, then a text length and finally a label.

If we were to use a Radio Button group, we would need to provide an X and Y coordinates, a text length, a text label and a Group ID.  The Group ID is used to associate the radio buttons together.  Below is a screenshot of my implementation along with an Apply button:

Radio Buttons and Pushbutton code

In the above code, you can see that I have established five radio buttons (RADIO1 to RADIO5) in addition to PUSHBTN1 pushbutton. These are set up in the main loop below:

Push Button UI Code and Functions

In the above code, you can see that the SetLEDStorage passes a number which gets stored in LEDState. When the Apply button is pressed, CommitLEDs takes LEDState and sets the six LEDs to the binary value of whatever was in it.  Below is what the UI looks like:

Radio Button GUI

Just like adding the checkboxes, I followed those same steps here:

• – I declared my additional UI elements’ GUID bytes (RADIO1 to RADIO5), my Radio Button group (RBGID1), my  pushbutton (PUSHBTN1) and my LEDState variable.
• – I added my init code (setting LEDState to 0, not pictured)
• – I added routines for my elements to call user functions. (SetLEDStorage and CommitLEDs)
• – I declared the routines so that they did something (stored the LED value, applied the value to the first six I/O pins)
• – I updated GUIBase.spin with the new list of items ( added five radiobuttons and one pushbutton.)

Give the code a try and you will see that while the checkboxes set the LED state instantly, the radio buttons do nothing until they are applied with clicking on the Apply button. This is important because as you design your GUI, you will need to decide if something must happen when the mouse is clicked right then (immediate action) or if the action will get applied later on via an “Apply” button. This is entirely up to you and there is no need to do things only one way.  Either method works but whether or not it works properly for your application will be your choosing.

Tips and Tricks, and things to watch out for

While developing this article, there were a couple of things I came across that you may want to watch out for. Don’t worry, you won’t blow up your Prop if you make a mistake in coding, however there are a few things you may want to keep an eye on:

• - Load to RAM, load to RAM, load to RAM and check your battery.
  In my writing this article, I found out real quick that driving a display, mouse and full size keyboard will drain a 9V transistor battery very quick.  A symptom of this drain is the Green LED that is present on the Propeller Education Kit. If it starts to pulse and your monitor loses sync, it’s time for a new 9V or consider a 5V USB power cord. Also, to save write cycles on the EEPROM, load to RAM whenever possible. Your computer’s hard  drive is more suited to incremental saves, EEPROMs are not.  Only save to EEPROM when you are ready to test your application in real life.
• - There is no boundary checking.  If you overlap your windows, then there is no going back. When in doubt, you can use the Mouse code to print the mouse coordinates on your project to help you identify and troubleshoot positioning.  Remember that all GUI elements start by defining the upper left hand corner of the element. You will need to include the NUMS object (SimpleNumbers.spin) and the code from the original GUIDEMO.spin (lines 314 to 316) in order to have it show up.  You can see an example of the boundary overlap in the below image.

Button overlaps window

• - There is no off-edge boundary checking either.  If you are setting a text field too far right of the video display or too far down, it will get cut off and your entire GUI will not work right.  In this case, I set the Predefines window to X40,Y75 and 25 columns wide which was out of the limits of the current VGA resolution.  The below image was the result and my UI only partially worked.  Resetting and reloading RAM fixed it.

Window moved out of range

• - Also as demonstrated in the image above, UI elements are not bound to the window you create them under. Assuming that both windows were same size and I mis-typed the coordinates, the Apply button could very easily show up under the checkboxes instead of the radio buttons leading to a confusing display.  You will want to make sure that your UI elements do not overlap at all as this could affect how the UI interprets your mouse actions.

Last Thoughts

There is so much you can do with the Propeller UI to make your applications more interactive.  With little work, you could build something like a serial terminal and embed your project in an LCD monitor or you could make a basic home automation system with a touchscreen LCD and a wireless transceiver. The possibilities are endless and with the Propeller, you can now use full GUI capability with keyboard and mouse support.

As always, Happy Hacking!

FIRESTORM_v1

A little background on the TI MSP430 first.

This is TI’s approach to the microcontroller market that is not targeted at the industrial segment, but rather at us the hardware DIY crowd.  I have to admit that they did it right with the $4.30 price point and I can’t wait to get started.  The kit includes two of the MSP430 chips:

• MSP430G2211IPN14  -2kB of on-die flash, 128 bytes of RAM, 10 GPIO pins, One 16-bit timer, a Watchdog timer, a BOR and a comparator.  You can download the datasheet from here.
• MSP430G2231IPN14 – 2kB of on-die flash, 128 bytes of RAM, 10 GPIO pins, One 16-bit timer, a Watchdog timer, a BOR, a Serial Interface (for I2C or SPI), an internal temperature sensor and an 8 channel 10bit ADC.  This chip’s datasheet can be found here.

The 2231 chip comes preinstalled and pre-programmed with a basic temperature demo which shows off the internal temperature sensor.  It’s definitely more than the blinking LED demo that comes with most sample programs.

So, let’s take a look at the thing.

Launchpad Box

The box comes in a very nice black cardboard box with TI’s launchpad Wiki printed on the front.  On the back of the box is TI’s other site URL straight to the chip specs, http://www.ti.com/430value.

The Development board with an MSP430G2231 mounted and ready to fire up.

The board itself is in a small anti-static bag, and when you open it up, you get a red development board like above.  There is a chip pre-programmed and ready to go.  Just like the Arduino, this board is USB powered and USB programmed.  There is a socket in the middle that you can plug a chip into, program, and then remove for use in your own projects or breadboard.  For the Arduino crowd, there is even a couple of headers included to populate the left and right solder pads for an easy method of attaching jumpers to the board for prototyping.

Accessories

In addition to the development board, you also get the above accessories.  Left is the two single row headers for the board (both female connector and male pins are included).  At the top is the second chip, (the chip without SPI/I2C and the Serial interface) and in the foreground is a 32.768kHz crystal that you can solder onto the development board for a more accurate clock.  The MSP430′s do include their own internal clock source however for those time sensitive projects, the external crystal is preferred and this board gives you you ready access to it should you find you need one.  Also included is a USB A to Mini-B cable.

A

Plugged in and ready for action!

Here is a picture of the board plugged in and ready to rock.  Although the LED’s brightness blurs the camera, there is a red LED and a green LED located next to the switch in the foreground.  When you first apply power to the board, the back LED (near the USB header) lights indicating power is applied, and the two LEDs near the left switch blink alternating, indicating that the chip is ready to be programmed.  In this image, I was using the chip that was already inserted, so all I had to do to run the simple test application was to hit the left pushbutton and start the program.

According to the wiki page, there are nine variants of the MSP430, some offering more flash (code) storage, some offering additional features however they are all pretty consistent at the 128-byte RAM.  Many people on the Hack-a-day article expressed concern at the windows only compiler however Hack-a-day released another article later on about how to code it in our favorite OS.

Generally speaking, cost has been the #1 thing that has distracted me from getting started with the Arduino ($35 for a board) and the PIC microcontroller suffers the same fate.  While the chips for each are quite inexpensive, it’s the programmers that usually ends up costing you in the end.  TI definitely has my attention with a $5 price point and extra chips.  I look forward to playing around with it very soon!

If you’ve gotten ahold of one of these, please let me know what you’ve done in the comments.  I’ve read several articles on Hack-a-day which have been appealing to me, especially the low power article here.

Happy Hacking!

FIRESTORM_v1

Image courtesy of Parallax.com

Hello Everyone!   If you’ve been in a Radio Shack sometime in the last year or so, you’ll know that Radio Shack and Parallax have teamed up to bring some variety to the parts drawers.  This once $50 serial RFID reader kit is now $10 at Radio shack although it only comes with two tags.  Read more for additional details about the Serial RFID reader now on sale!

The Parallax Serial RFID reader is 5 volt TTL compatible signalling and requires two I/O pins.  One is output for the “enable” pin which when brought low, turns on the RFID reader.  The tag data comes in on another pin to be read by your 5V TTL compatible microcontroller.   If you are using the 5V Basic Stamp or the 3.3V (5V tolerant) Propeller, then this is just a snap-in add on, no additional hardware is required.  Other controllers may require additional voltage converters to drop the TTL signal down to a voltage compatible for your controller.

Also take note that this is a 125kHz tag reader, so reading your company’s HID RFID tag will more than likely not work unless you have a 125kHz tag.

You can find the full datasheet, sample code and schematics from Parallax’s product web page here.

If two tags just aren’t going to cut it, you can take a look at all of Parallax’s tags here.

In this post, we’ll be going over the basics of using an old regular PC-gameport joystick with Parallax’s Basic Stamp powered Boe-Bot.  This howto will have all the information you need to get started including code, schematics and a parts list.  We will be covering how the joystick is wired and how to go about interfacing it with the Boe-Bot for an easy to use and easy to expand analog control method for your Boe-Bot.  Next step, world domination!

Foreword

The joystick is something that has been around quite a long time, even longer than computers.  The idea of being to control something on-screen by using a joystick is one that takes almost no learning curve,  is easy to start and you only end up getting better.  Even today in modern gaming, it is easy to find controllers with at least one analog joystick on it.  My Xbox 360 controllers feature two sticks per controller which give the gamer a very precise method for movement and aiming accuracy, something that buttons can’t quite provide.  As long as I’ve been working on computers, I always remember using PC analog joysticks in my games.

Nowadays, the modern PC joystick has all but gone the way of the dodo, however those few that are around now are USB and have a ton of buttons.  The legacy joystick (or “gameport” joystick) still has a bit of usefulness in it and today we will be covering how to get it to work with a Basic Stamp microcontroller.

Of course someone’s going to ask, “Why use a PC joystick?, Why not (insert control method here)?”.  My answers are:

1:  Cost – The PC joystick used in this tutorial was bought at a Goodwill for $3.

2: Ease of use – Once you have programmed your application, you just grab it and go. There’s no need to go over complex control methods or trying to remember what does what now.

3: Low Parts Count – In this tutorial, I used two capacitors and six resistors to get the joystick working.  Most other control schemes require a lot more parts.

Basic Theory of Operations

The way an analog PC joystick works is not very complex at all.  You have a stick which is capable of moving any position along two axes (X and Y) and with two switches or “buttons” for interaction.  The position of the stick is detected via two variable resistors usually around 10Kohm, one running horizontal (left/right) and one running vertical (towards you/away from you).  The computer would send a pulse out to the joystick and get return values from the variable resistors.  Using the returned pulse it could then decide on what action to take, how far/fast to move your character, etc..

The two buttons (or more) are detected through simple momentary contact switches. If the switch pin was high, then the button was depressed otherwise, the button was released.  These button switches are normally open and while the gameport pinout supports up to four buttons, additional buttons were made by figuring out how to multiplex them as shown in the chart below:

When using the PC gameport joystick, you would need to go through calibration which taught the computer the limits of your axes and the button layout.  Because variable resistors are not terribly accurate across manufacturers this calibration was a requirement as no two joysticks, not even those made by the same manufacturer,  would behave exactly alike. There would always be minute differences between the joystick’s behaviors so the calibration was a way to standardize the measurements and clean up the inaccuracy of the joystick.

In our tutorial, we will be using a two-button model.  This joystick is a very standard stick and has a trigger button and a thumb switch button.  It connects to the computer via a 15 pin D-sub connector usually to the sound card which has a Gameport connector on it.  This connector is usually orange on newer motherboards, if it exists at all.

On the bottom of this joystick, there are two sliders.  These two sliders can be used to “tune” the position of the VRs in order to be able to get the best range of motion for the stick.  You may need to use these during the next step for calibration.  Here is a picture of the bottom of my joystick.  The large circular things are suction cups which help keep the base down on the table while you move the joystick around:

After taking the bottom off, we can  see the setup of the two variable resistors (VRs).  Unlike most joysticks this one uses linear VRs and not the rotary VRs (sometimes called pots) that are commonly found for volume controls. We have oneVR on the left for the Y axis, and the other one along the bottom for the X axis, some support hardware and a small PCB:

The little circuit board at the top of the stick doesn’t conceal any electronics, It’s only a bypass as shown in these next two images:

This picture is of the bottom of the circuit board, As stated before, this only acts as a pass through to make wiring the joystick easier during production.

Here is a picture of one of the two linear variable resistors.  These are 100Kohm but yours might be different:

Now that the joystick has been opened up and we know all it’s secrets, it’s time to start on the interface for the BOE-BOT.

The interface circuit

The interface for your joystick is actually quite simple.  You will need the following items:

• A 15 pin female D-sub connector with ribbon cable – I used the one from an old PC that I had many years ago.  The long ribbon was perfect for this job.
• 4x 220ohm resistors
• 2x 10K resistors
• 2x .1uF capacitors – Note: I used ceramic capacitors in my project as they are easier to work with however in theory electrolytic capacitors should work as well. If you use electrolytics, please pay careful attention to the polarity as electrolytics can explode if hooked in backwards and may risk hurting you and/or damaging your microcontroller.
• Jumper wire as needed

This will provide the basic parts needed to perform our calibration test.  You will need to hook up the parts as shown in this schematic below.  Click on the image for a full size one if you need it.

Here is a full pinout of the PC gameport connector that shows all of the various things that the pins are used for: (Pinouts obtained from pinouts.ru – a good site to have handy)

In my D-Sub connector, pin 4 and pin 5 are shorted together however this may be done either at the joystick end or in your D-sub cable as well. When in doubt, test it with a multimeter.  If you find that during your calibration test, your buttons do not respond at all try examing those two pins to make sure that they are both shorted together.  WARNING! Although the pinouts.ru pinout provided above has some things labeled “Ground” and “+5VDC” use my schematic as the final verdict.   The reason for this is the pinouts.ru site describes the joystick’s gameport connector on a computer.  Since we are not using a computer and this is not a digital joystick, I have changed some of the meanings of the pins as shown in my schematic.  If you hook it up differently, you might damage your microcontroller.

Calibration Software

Now that the interface is built, we need to write the code needed for making the BOE-BOT “read” the joystick and to make it do stuff.  We will be using the RCTIME function of the Basic Stamp to charge and time the two .1uF capacitors.  By timing their discharge rates, we can then mathematically calculate the position of the joystick.

As far as the buttons go, they are just as easy as any other two buttons for your microcontroller.  The BOE-BOT will monitor pin2 and 3 and if they are brought high (by pushing a button) the BS2 will sense it and perform whatever action you have programmed.  For now, we are just getting the calibration information and to make sure everything works properly.  The tags for “Lights” and “Horn” will come in the next section.

You can download the source code called “BS2_joystick_diagnostics.bs2″ from my downloads page, or here is the direct link You might need to right click on the link and go to “Save As”.

After loading it into your BOE-BOT, be sure to leave a debug window open, as this is where you can see the RCTIME counts and the buttons.  You may  notice that the values will be all over the place and will constantly be changing but this is normal.  Play around with it a bit and get a general feel for how your joystick works.

If for some reason, your RCTIME is stuck at 0, this indicates that the Basic Stamp is not seeing the capacitor or is not sensing the capacitor’s discharge.  You will need to check your wiring to make sure everything’s lined up. If need be, you can use a 100Kohm resistor between pins 1 and 3 or between pins 1 and 6  on your 15 pin D-sub connector to test.  If RCTIME shows up there, then use the multimeter on your joystick’s D-sub cable and make sure that you can see the resistance changing on those two sets of pins.  If you get no connection on the joystick, you could have a bad joystick on your hands.

Here are the images of my RCTIME output along with a picture showing the position of my joystick.  You will have different numbers, but the format is still the same.

Center or "zero" position

X (horizontal) axis left

X (horizontal) axis right

Y (vertical) axis up

Y (vertical) axis down

Button 0 pressed

Button 1 pressed

Once you have a “feel” for how the joystick responds, let’s actually do something with this. You will need to figure out the zones on where to apply the speed settings.   The BS2_Rover application contains routines that can filter out and adjust pulses sent to the servos however this requires a bit of calibration (hence the calibration application).  All you need to do is to figure out where your joystick should switch between off and low, low and medium and lastly medium and high.    The reason for this is that for precise movements, we don’t want the BOE-BOT to lurch out of control, and while high speed all the time might not be a bad idea, it can be cumbersome trying to get into a small space with it.

Getting it to work

Go ahead and download the file “BS2_joystick_rover.bs2″ from my Downloads page or via this direct link. Load it up in your Basic Stamp Editor  as now we need to make some adjustments to it.  I’m pretty sure that your joystick will behave differently than mine will which is why my code won’t work out of the box.  Well let me rephrase that, the CODE will work, but the joystick calibration will be off.   Using the calibration application above, you can get the RCTIME values needed to make the servo speeds and the directions work properly.  Look at my speed chart below and you will get a better understanding how the BS2 rover works:

With this chart you can see at which points the BOE-BOT will change speeds.  You will need to make a similar chart for your joystick using the calibration program and then you can edit the BS2 Rover file and add those settings in the two GOSUB statements.  The DEADZONE is important as this is the point where your stick’s RCTIMEs will fall when no one is touching the joystick.  It is important to have a deadzone that matches your joystick to prevent your BOE-BOT from running away from you.

Something of note is that my chart starts at “1″ and not “0″.  This is because if the VR is at minimum resistance RCTIME will still return a “1″.   The only time RCTIME will return a 0 is if there is no load for the capacitor to discharge to, for instance when the joystick is disconnected.  In the event that RCTIME does return a 0, then we will send out the same pulses as what we send out in our deadzone so that way our BOE-BOT does not move once the joystick is unplugged.

Here’s how the two subroutines work in a nutshell.  You start off with a pulse value of 200 and depending on where your RCTIME is, you will either add to it which makes the servo rotates one direction at one of three speeds or you will subtract from it which will make the servo rotate the other direction at one of three speeds.  Once the comparisons are done,  you add a constant value of 550 to the pulse value.  This pulse value will then get pulsed out to the servos and the wheel turns.

The reason 550 was selected was because 550+200 = 750 which is the point at which your servos do nothing. In the speed chart below, we can see how the offset affects the servo pulses and how each of the two items correspond with the speed levels:

So now that you understand the two subroutines, go ahead and edit them to match your joystick’s behavior and desired positions.

Extra fun stuff

Now that we have the complex part out of the way, we can also instruct the BOE-BOT to do something when we press the buttons on the joystick.  I have added a buzzer, a 220 ohm resistor and an LED to the last schematic so that now when we press the trigger button, the piezo buzzer will make a beep-beep sound and when you hit the thumb button, you will see the LED turn on and off.   Here is the updated schematic with our new parts. (Click on it for a full size image)

Once you have made the needed changes to your code, there’s one last thing that needs to be done before you upload it to your BOE-BOT.  Check one last time and make sure everything is set properly, otherwise you might have unexpected results.  If all looks well, go ahead and upload then try it out.

Here is a video I made of my BOE-BOT in action.  For this test, I used a white ultrabright LED which produced a lot more light than the standard LEDs that came with the BOE-BOT.

The “chugging” motion is normal.  This is the BOE-BOT, checking the RCTIME of X, pulsing out the X servo, checking RCTIME of Y, pulsing out the Y servo, checking the buttons then repeating itself.  Since the BOE-BOT is a single-process chip, it can only do one thing at a time otherwise the motion would be a lot smoother than it is.   If you are using the Propeller, you will get smoother action out of it by dedicating a COG to monitoring the joystick’s X and Y axes, and another COG to controlling the servos.

Last words

Using an analog joystick for your robotics projects can be an excellent way to bring an easy and intuitive interface for robot control into your project and I hope that this article shows you how easy it is to use.  It doesn’t take any fancy coding, expensive hardware or overkill designs, just some basic knowledge of how RCTIME works and a few bucks for the joystick. With a minimal part count, you can increase the flexibility of your robot’s design quite easily and you might even save yourself some programming headaches later on.

As always, thank you for reading.

FIRESTORM_v1