[Luis Cruz] is a Honduran High School student, and he built an amazing electrooculography system, and the writeup (PDF warning) of the project is one of the best we’ve seen.

[Luis] goes through the theory of the electrooculogram – the human eye is polarized from front to back because of a negative charge in the nerve endings in the retina. Because of this minute difference in charge, a user’s gaze can be tracked by electrodes attached to the skin around the eye. After connecting eye electrodes to opamps and a microcontroller, [Luis] imported the data with a Python script and wrote an “eyeboard” application to enable text input using only eye movement. The original goal of the project was to build an interface for severely disabled people, but [Luis] sees applications for sleep research and gathering marketing data.

We covered [Luis]‘ homebrew 8-bit console last year, and he’s now controlling his Pong clone with his eye-tracking device. We’re reminded of a similar system developed by Atari, but [Luis]‘ system uses a method that won’t give the user a headache after 15 minutes.

Check out [Luis] going through the capabilities of his interface after the break.

[Keba] not only asked Answeres.HackaDay.com, but also sent us an email as follows.

“Can you make a basic guide to designing a good Command Line User Interface?”

Wouldn’t you know the luck, I’m currently working on a Command Line type interface for a project of mine. While after the jump I’ll be walking through my explanation, it should be noted that the other replies to Answers.HackaDay.com are also great suggestions.

We have no real idea how [Keba] intends to implement a system for the ATmega16 (Serial display? Output to an LCD? etc?), but for my project it is as follows. Using C# along with DirectX (can you tell I’m making a game with a developer console?) I’ll display an input line, suggestions for inputs (intellisense), and outputs based only when a correct input is given.

To begin, and to stay focused on only the CLI, I’ll assume your project has all the necessary startup and load functions. In my case, loading of a DX device, and input handling. Also, we assume you know how to program in your respective language.

I’ll be using a pretty advanced technique (StringBuilder) for string handling, because traditional string + string concatenation is terrible on memory (and games need as much as they can get). If you don’t care for memory, you can simply use regular strings.

To start off we’ll need some global variables,

public bool bool_isConsoleOpen = false; //console, also known as CLI
public StringBuilder StringBuilder_Console = new StringBuilder(); //could be replaced with string
public InputDevice ID = new InputDevice();

Within the main function loop, make a call to a method named UpdateConsole();

Now, in my setup to prevent unwanted user input there is a small check to see if the console is ‘open’ or ‘closed’.

public void UpdateConsole()
{
 //opening console
 if (ID.isKeyDown(Keys.Oemtilde) && ID.isOldKeyUp(Keys.Oemtilde))
  if (bool_isConsoleOpen == false)
  {
   bool_isConsoleOpen = true; //user pressed magic key, open console
   StringBuilder_Console = new StringBuilder(); //clear string
  }
  else
   bool_isConsoleOpen = false; //user pressed magic key, close console
}

The next section of code handles all the inputs (keyboard presses) and builds our string that is about to be entered. It includes support for shift capitals, pasting from the clipboard, and also checks to make sure each key entered is allowed. Simply add this portion immediately after bool_isConsoleOpen = false;.

//appending console if its open.
if (bool_isConsoleOpen == true)
{
 bool caps = false; //variable that helps determine if shift is pressed
 if (ID.isKeyDown(Keys.ShiftKey))
  caps = true;

 List pressedkeystemp = ID.PressedKeys; //I had to modify my ID a bit to make it get a list/array of the keys pressed.
 //go through each new key in list
 foreach (Keys currentkey in pressedkeystemp)
  {
   //make a string, this is for numbers
   string key;

   //if the key SPACE is pressed, make a space
   if (currentkey == Keys.Space)
   {
    StringBuilder_Console.Append(" ");
   }
   //if the key BACK is pressed, backspace
   else if (currentkey == Keys.Back)
   {
    if (StringBuilder_Console.Length > 0)
     StringBuilder_Console.Remove(StringBuilder_Console.Length - 1, 1);
   }
   //if enter is pressed
   else if (currentkey == Keys.Enter)
   {
    //send it off to apply our data
    ApplicationSettings(StringBuilder_Console.ToString());
    //clear our string
    StringBuilder_Console = new StringBuilder();
   }
   //if a number is pressed, make it show up
   else if (StringKeyINTCheck(currentkey, out key))
   {
    StringBuilder_Console.Append(key);
   }
   //if a-z is pressed, make it show up
   else if (StringKeyCheck(currentkey))
   {
    // if V was just pressed and either control key is down
    if (currentkey == Keys.V && (ID.isKeyDown(Keys.ControlKey)))
    {
     // paste time!
     string pastevalue = "";
     pastevalue = System.Windows.Forms.Clipboard.GetText(System.Windows.Forms.TextDataFormat.Text);
     StringBuilder_Console.Append(pastevalue);
    }
    // if not pasting, do a regular key
    else if (!caps)
     StringBuilder_Console.Append(currentkey.ToString().ToLower());
    else if (caps)
     StringBuilder_Console.Append(currentkey.ToString());
  }
}

In order to prevent some characters from being printed, such as alt characters, and to make sure the input key can actually be displayed (otherwise you could crash with error) I implement a few checks. You’ll notice I have two different types, Check(input, output) and Check(input). The former is necessary because often the input is the ASCII value, and needs to be converted to a char or string before being added to the builder. The latter simply returns true or false if the key is valid.

Example of the first, numerals

//numerals
private bool StringKeyINTCheck(Keys key, out string i)
{
 if (key == Keys.D1 || key == Keys.NumPad1)
 {
  i = "1";
  return true;
 }
 else if (key == Keys.D2 || key == Keys.NumPad2)
 {
  i = "2";
  return true;
 }
etc...
}

And the latter, a-z

private bool StringKeyCheck(Keys key)
{
 if (key == Keys.A ||
                key == Keys.B ||
                key == Keys.C ||
                etc...
                key == Keys.X ||
                key == Keys.Y ||
                key == Keys.Z)
  return true;
 else
  return false;
}

So now we have our string built, you’ll notice the new method ApplicationSettings(string) is called whenever enter is pressed. This is the sending off of the string the user just typed in/that we built, we must now break that string down and determine what the user typed, and what should happen.

Once again, I start off with a few checks, just to prevent crashes.

private void ApplicationSettings(string temp)
{
 if (temp != null) //make sure the user didn't type in "".
 {
  //make it all lower case
  temp = temp.ToLower();

  //split by spaces
  string[] words = temp.Split(' ');
 }
}

Now comes the fun part, We’ve assumed the user has entered things such as “quit” “fullscreen 1″ and “pos 100x100x100″. The first will quit the application, the second will determine if the application should be fullscreen or not. And the final sets the users XYZ position in space. These three are simply examples of multiple variable entry, and you could of course program whatever you need.

Immediately after string[] words = temp.Split(‘ ‘); add the following,

try
{
 //quit exit
 if (words[0] == "quit" || words[0] == "exit")
  this.Close();

 //check for users fullscreen preference
 else if (words[0] == "fullscreen")
 {
  if (words[1] == "0")
   WindowedMode = true; //arbitrary global named windowedMode
  else if (words[1] == "1")
   WindowedMode = false;
 }

 //set the camera position
 else if (words[0] == "pos")
 {
  if (words[1].Contains("x"))
  {
   string[] res = words[1].Split('x');
   int int_x = Convert.ToInt32(res[0]);
   int int_y = Convert.ToInt32(res[1]);
   int int_z = Convert.ToInt32(res[2]);

   Cam.Position = new Vector3(int_x, int_y, int_z);//arbitrary class camera Cam
  }
 }

}
catch (IndexOutOfRangeException e)
{
 //this occurs when the user types "fullscreen $". Where $ is a variable, and the user typed nothing.
 //do nothing we should tell the user this with an error message.
}
catch (FormatException e)
{
 //this occurs when the user types "resolution $x$", where $ is an int variable, and the user typed alpha.
 //do nothing we should tell the user this with an error message.
}

You probably could stop here if needed, you have input and output. However, I have something like 40 different commands in the current revision of my console, I couldn’t remember them all. So I made my own nifty intellisense.

This is going to require setting up another global–string list, filling it with commands, and then alphabetizing it.

List<string> ListString_Console = new List<string>();

private void LoadConsoleWordList()
{
 ListString_Console.Clear();

 //load in our console!
 ListString_Console.Add("fullscreen");
 ListString_Console.Add("resolution");
 ListString_Console.Add("showfps");
 //ListString_Console.Add("vertsync");
 ListString_Console.Add("maxfps");
 ListString_Console.Add("quit");
 ListString_Console.Add("exit");
 ListString_Console.Add("saveconsole");
 //ListString_Console.Add("bind");
 etc...

 //sort our list
 ListString_Console.Sort();
}

Now at the bottom of our UpdateConsole().

if (bool_isConsoleOpen == true)
{
 BMF_Arial.AddString(StringBuilder_Console.ToString() + "_", "console", new System.Drawing.RectangleF(5, 18, Resolution.Width, 20)); //how I draw things to the screen in DX. StringBuilder_Console is the string we built earlier, so the user can see what he is typing.

 //help our user search.
 int q = 35;

 //check every single string we know against what the user is typing in
 foreach (string stringy in ListString_Console)
 {
  //so long as the length is right, we continue
  if (stringy.Length >= StringBuilder_Console.Length) //this part could be eliminated, and we could simply go through every letter. But this speeds up operations a smidge.
  {
   //temporary bool
   bool hodling = false;

   //go through every letter
   for (int i = 0; i < StringBuilder_Console.Length; i++)
    if (stringy[i] == StringBuilder_Console[i])
     hodling = true;
    else
    {
     hodling = false;
     break;
    }

   //if it's a 100% match
   if (hodling)
   {
    //draw it, and update q relative.
    BMF_Arial.AddString(stringy, "console", new RectangleF(5, 2 + q, Resolution.Width, 20)); //these are all the matches to the currently types string.
    q += 18;
   }
  }
 }
}

So how does it finally look?

No console open,

Hitting the magical key opens up console, begin typing, see intellisense,

Continue typing, other words that don’t match get taken off display,

and hitting enter executes the command,

[Jack Toole] and his team [Aaron King] and [Libo He] sent in their computer interface dubbed the Chronos Flying Mouse. The video above explains the concept very thoroughly, but we’ll reiterate some of the highlights here. The project uses a Chronos EZ430 with its accelerometers to wirelessly transmit delta positions of the user’s wrist. Add a little open source software and you have a regular PC mouse, a video game joystick, a game wheel, and a few other different devices in one. We just love the suave feeling of snapping to click.

Considering how hackable the Nexus One is already, we can only imagine a whole new host of interesting things thanks to Ubuntu running on the device. [Max Lee] set his heart out on getting not just Ubuntu on the Nexus One, but also Debian, and he wrote a perfect install guide to help out those wanting to give it a shot.

He cheated a little bit by having Ubuntu run in the background while the X11 interface is simply VNCed, but he still did an awesome job with plenty of pictures and details to help you achieve Ubuntu on your Nexus One.

[Viktor], one of our favorite avid hackers, has been playing around with 1-wire systems all this month. What started out as a MicroLAN Fonera has turned into an iButton interface, to a 1-wire powered hub, and finally a 1-wire character driven LCD. Anyone looking at 1-wire systems or OWFS could surely benefit from his testing.

However, if you still haven’t gotten your fill of 1-wire goodness, let us remind you of the 1-wire HVAC and IPv6 to 1-wire protocol translator.

[Thanks Juan]

Sunday we saw robots playing pool and an augmented reality pool game. Today we’ll complete the pool trifecta: virtual pool using a real cue stick and ball in another vintage video from Hack a Day’s secret underground vault. The video is noteworthy for a couple of reasons:

First is the year it was made: 1990. There’s been much buzz lately over real-world gaming interfaces like the Nintendo Wii motion controller or Microsoft’s Project Natal. Here we’re seeing a much simpler but very effective physical interface nearly twenty years prior.

Second: the middle section of the video reveals the trick behind it all, and it turns out to be surprisingly simple. No complex sensors or computer vision algorithms; the ball’s speed and direction are calculated by an 8-bit processor and a clever arrangement of four infrared emitter/detector pairs.

The visuals may be dated, but the interface itself is ingenious and impressive even today, and the approach is easily within reach of the casual garage tinkerer. What could you make of this? Is it just a matter of time before we see a reader’s Mini-Golf Hero III game here?

[Tom Gerhardt] has made this very interesting mud interface for a computer.  Follow the link to see a video of it in action. It appears as though he’s using a laser grid of some kind to establish elevation. We might be way off on that though, there aren’t any details on the construction. He does mention that it is an open source hardware and software project, so maybe the details are available on request. In the video you can see it running as a projection surface where people are interacting with items directly on the mud. You can also see it being used as an external input device. People play Tetris using it in that example.

UPDATE: [Moon] reports from the ITP show that the tub has a 16×12 grid of generic pressurs sensors on the bottom. These feed into a MacBook Pro which is projecting on the surface. Despite the sparse grid, [Tom] says he gets good resolution by interpolating between sensors; it can detect a resting hand pivoting on the surface.

Microchip’s MCP6S21/2/6/8 are programmable gain amplifiers that multiply an input voltage by a factor of 1, 2, 4, 5, 8, 10, 16, and 32. The MCP6S22/6/8 also have selectable input channels for working with different signal sources. The multiplication factor and input channel are configured through an SPI interface. This chip is useful for multiplying a small input signal, and selecting among several analog input sources. We demonstrate the six channel MCP6S26 below.

MCP6S26 programmable gain amplifier (Mouser search, Octopart search, $2.56) Datasheet (PDF).

We tested the chip in the circuit shown above with a 3.3volt power supply. A resistor voltage divider (R1-4) outputs a fraction of the supply on channels 0, 2, and 4. We used 5K resistors, but the value isn’t critical. The divider outputs 2.4volts on channel 0, 1.6volts on channel 2, and 0.8volts on channel 4.

We used our Bus Pirate universal serial interface to demonstrate this chip, but the transaction sequence will be the same for any microcontroller implementation. We connected the Bus Pirate to the MCP6S26 as shown in the table above. We setup the Bus Pirate for raw3wire mode (M, 8) with normal outputs, and enabled the on-board power supply (capital ‘W’).

RAW3WIRE>[0b01000001 0] d
CS ENABLED <–begin SPI transaction
WRITE: 0×41 <–change input channel command
WRITE: 0×00 <–change to channel 0
CS DISABLED <–end SPI transaction
VOLTAGE PROBE: 2.4VOLTS <–Vout voltage measurement
RAW3WIRE>

Writing 0b01000001 (0×41) followed by a channel number changes the active MCP6S26 input. ‘[' lowers the chip select line to start an SPI transaction. We send the change channel command (0x41) followed by 0 to select input 0.  ']‘ raises the chip select line to end the SPI transaction. ‘d’ takes a voltage measurement and shows that input 0 with 0 gain is 2.4volts.

We can’t amplify the input voltage beyond the power supply (2.4volts * 2 = 4.8, 4.8volts > 3.3volts), so we need to change to a lower channel to play with the gain features.

RAW3WIRE>[0b01000001 4] d
CS ENABLED
WRITE: 0×41 <–change input channel command
WRITE: 0×04 <–change to channel 4
CS DISABLED
VOLTAGE PROBE: 0.8VOLTS <–Vout voltage measurement
RAW3WIRE>

A measurement on channel 4 shows an output of just 0.8volts, plenty of room to test the gain features of the chip.

RAW3WIRE>[0b01000000 0b00000001] d
CS ENABLED
WRITE: 0×40 <–change gain command
WRITE: 0×01 <–gain setting (x2)
CS DISABLED
VOLTAGE PROBE: 1.6VOLTS <–Vout is now 0.8volts * 2
RAW3WIRE>

A two-byte sequence sets the amount of gain. The command 0b01000000 (0×40) addresses the gain register, the second byte sets the multiplication factor (0×01= gain of 2). Setting the gain to 2 multiplies the output voltage by 2, 0.8volts * 2 = 1.6volts.

RAW3WIRE>[0b01000000 0b00000010] d
CS ENABLED
WRITE: 0×40 <–change gain command
WRITE: 0×02 <–gain setting (x4)
CS DISABLED
VOLTAGE PROBE: 3.2VOLTS <–Vout is now 0.8volts * 4
RAW3WIRE>

This time we set a gain of 4, 0.8volts * 4 = 3.2volts.

RAW3WIRE>[0b01000000 0b00000011] d
CS ENABLED
WRITE: 0×40 <–change gain command
WRITE: 0×03 <–gain setting (x5)
CS DISABLED
VOLTAGE PROBE: 3.3VOLTS <–not enough headroom to reach 0.8volts * 5
RAW3WIRE>

The maximum output voltage is the chip’s power supply voltage. If we set the gain to 5, the output voltage can’t exceed the power supply of 3.3volts  (0.8volts * 5 = 4volts, 4volts > 3.3volts).

RAW3WIRE>[0b00100000 0] d
CS ENABLED
WRITE: 0×20 <–sleep command
WRITE: 0×00 <–don’t care byte
CS DISABLED
VOLTAGE PROBE: 0.0VOLTS <–output is disabled
RAW3WIRE>

The MCP6S26 has a power-saving sleep mode. Shutdown the chip with the command 0×20, followed by any byte value. Leave sleep by sending any valid command.

Like this post? Check out the parts posts you may have missed. Want to request a part post? Please leave your suggestions in the comments.

We use the Bus Pirate to interface a new chip without writing code or designing a PCB. Based on your feedback, and our experience using the original Bus Pirate to demonstrate various parts, we updated the design with new features and cheaper components.

There’s also a firmware update for both Bus Pirate hardware versions, with bug fixes, and a PC AT keyboard decoder. Check out the new Hack a Day Bus Pirate page, and browse the Bus Pirate source code in our Google code SVN repository.

We cover the design updates and interface a digital to analog converter below.

Concept overview

The Bus Pirate started as a collection of code fragments we used to test new chips without endless compile-program-run development cycles. We released it in a how-to and used it to demonstrate a bunch of serial interface ICs in our parts posts. This article introduces an updated design with new features and a bunch of improvements.

• Surface mount design
• Pull-up resistors on all bus lines with external voltage source
• Software resettable 3.3volt and 5volt power supplies
• Voltage monitoring of all power supplies
• An external voltage measurement probe
• Cheaper parts

Hardware

Click for a full size schematic image (PNG). The circuit and PCB are designed using the freeware version of Cadsoft Eagle. All the files for this project are included in the project archive linked at the end of the article.

Microcontroller

We used a Microchip PIC24FJ64GA002 28pin SOIC microcontroller (IC1) in this project. The power pins have 0.1uF bypass capacitors to ground (C1,2). The 2.5volt internal regulator requires a 10uF tantalum capacitor (C20). The chip is programmed through a five pin header (ICSP). A 2K pull-up resistor (R1) is required for the MCLR function on pin 1. Read more about this chip in our PIC24F introduction.

RS-232 transceiver

An inexpensive MAX3232CSE RS232 transceiver (IC2) interfaces the PIC to a PC serial port. This chip replaces the expensive through-hole MAX3223EEPP+ used in the previous version of the Bus Pirate. The serial interface will work with a USB->serial adapter.

Bus pull-up resistors

The original Bus Pirate has 3.3volt pull-up resistors on 2 pins, but most of our tests required additional external resistors. The updated design has pull-up resistors (R20-23) on the three main bus signals (data in, data out, clock) and the chip select (CS) pin.

A row of jumpers (SV5) connects each resistor to an external voltage supplied through the Vext terminal (X4). Through-hole resistors are used like jumper-wires to make the PCB easier to etch at home.

We couldn’t find an elegant way to control an arbitrary voltage pull-up resistor array from a 3.3volt microcontroller. If you have any ideas, please share them in the comments.

Power supply

VR1 is a 3.3volt supply for the microcontroller and RS232 transceiver. VR2 is a 5volt supply. Both require two 0.1uF bypass capacitors (C3-C6). J1 is a power supply jack for a common 2.1mm DC barrel plug. 7-10volts DC is probably the ideal power supply range.

The original Bus Pirate had dual power supplies, 3.3volts and 5volts, so most ICs could be interfaced without an additional power supply. A major annoyance was the lack of a power reset for connected chips. If a misconfigured IC needed to be power-cycled, we had to disconnect a wire. We got so tired of this routine that we added a software controlled reset to the updated design.

VR3 (3.3volts) and VR4 (5volts) are TI TPS796XX voltage regulators with an enable switch. A high level on pin 1 enables the regulator. A pull-down resistor (R13,R12) ensures that the regulators are off when the PIC isn’t actively driving the line, such as during power-up initialization. The datasheet specifies a hefty capacitor on the input (C23, C21) and output (C24, C22) pins, we used the same 10uF tantalum we use everywhere. An additional, optional, 0.1uF capacitor (C12,C11) can improve regulation.

The switchable regulators are powered by VR2, a 5volt supply.  We did this because the maximum input for VR3 and VR4 is 6volts, leaving the device with a narrow 5.2-6volt power supply range. VR2 will work well above 10volts, and provides an adequate supply for the other regulators.

VR3 (3.3volts) has plenty of headroom to operate from a 5volt supply. VR4 (5volts) will lose about 0.2volts, but 4.8volts remains well within the acceptable range for most 5volt chips. In practice, and under light loads, we see less than 0.1volts drop-out from VR4.

Voltage monitoring

Voltage monitoring is a new feature we’re really excited about. Has your project ever mysteriously stopped responding because of an accidental short circuit? The Bus Pirate’s power supplies are equipped with voltage monitoring that can detect a change in power levels.

Each monitored signal is connected to an analog to digital converter (ADC) through a resistor voltage divider. Two 10K resistors (R10,R11 above) divide the input voltage in half, making it possible to measure up to 6.6volts with the 3.3volt PIC microcontroller.

The Bus Pirate has four voltage monitors. The 3.3volt and 5volt power supplies are monitored, as is the external voltage fed to the pull-up resistors. A fourth monitor is connected to pin 9 of the output header to make a voltage probe.

PCB

Click for a full size placement diagram (PNG). The board is a quasi single-sided design, we etched ours in the lab on a single-sided photo-resist PCB. At the top, near C13, two jumper wires meet at a single via; we soldered one jumper wire to the other on the back of the board.

Part list

Firmware

The firmware is written in C using the free demonstration version of the PIC C30 compiler. Learn all about working with this PIC in our introduction to the PIC 24F series.

The latest firmware is posted on the Hack a Day Bus Pirate page. The latest source is in our Google Code SVN repository.

Using it

The diagram above shows the Bus Pirate pinout.

We made a cable with alligator clips on the end, and added labels to each wire so we don’t have to refer to this table every time we interface a new chip.

If you know of any cool connectors or cables, please link to them in the comments.

LTC2640 SPI digital to analog voltage converter

The Linear Technology LTC2640-LZ8 is an 8bit digital to analog converter (DAC) programmed over SPI. A DAC is essentially a programmable voltage divider. They’re useful for recreating waveforms, such as audio signals. An 8bit DAC has 255 even intervals between 0 and the reference voltage, the L part we used has an internal 2.5volt reference.

The LTC2640 only comes in a small SOT223-8 package, so we made a breadboard adapter in the profile of a DIP-8 chip.  Our LTC2640 footprint is included in the project archive attached at the end of this article.

The schematic above shows our test circuit for the LTC2640. It requires a 2.7-5volt power supply, we used the Bus Pirate’s 3.3volt supply. C1 is a bypass capacitor between the power pin and ground. Pin 8 is an active-low reset pin, tie it high for normal operation. Pin 7 is the DAC output, connect the Bus Pirate voltage measurement probe (ADC) here.

We connected the Bus Pirate to the LTC2640 as shown in the table. The LTC2640 doesn’t have a data output pin, this SPI connection remains unused.

The Bus Pirate’s hardware SPI library and software RAW3WIRE library are compatible with the LTC2640′s SPI interface. We used the SPI library; if you use the RAW3WIRE library be sure to choose normal pin output.

HiZ>m<–select mode
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. JTAG
7. RAW2WIRE
8. RAW3WIRE
9. PC AT KEYBOARD
MODE>5<–SPI or RAW3WIRE
900 MODE SET
Set speed:
1. 30KHz
2. 125KHz
3. 250KHz
4. 1MHz
SPEED>1 <–test at low speed
…
102 SPI READY
SPI>

Press M for the Bus Pirate mode menu, choose 5 for SPI mode. There are a bunch of configuration options for the SPI module, use the default options for all of them. After SPI mode is ready we need to configure the power supply.

SPI>p<–power supply setup
W/w toggles 3.3volt supply?
1. NO
2. YES
MODE>2<–use 3.3volt supply
W/w toggles 5volt supply?
1. NO
2. YES
MODE>1<–don’t use 5volt supply
9xx SUPPLY CONFIGURED, USE W/w TO TOGGLE
9xx VOLTAGE MONITOR: 5V: 0.0 | 3.3V: 0.0 | VPULLUP: 0.0 |
SPI>

p opens the Bus Pirate power supply menu. We use the 3.3volt supply but not the 5volt supply. The voltage monitor verifies that the power supplies are off.

SPI>W<–capital W (silly CSS) enables power supply
9xx 3.3VOLT SUPPLY ON
SPI>v<–voltage monitor
9xx VOLTAGE MONITOR: 5V: 0.0 | 3.3V: 3.3 | VPULLUP: 0.0 |
SPI>

Capital ‘W’ enables any power supplies selected in the previous menu, a small ‘w’ disables them. V displays the supply voltage monitor, which now shows 3.3volts output from the 3.3volt supply.

Now that configuration is finished, we can send commands to the LTC2640 over the SPI bus. The LTC2640 has a 24bit (3byte) interface protocol. The first byte is a command, followed by two data bytes. The LTC2640 is available in 8,10, and 12bit versions; the 8bit version uses the first byte to set the DAC value, and ignores the second byte.

SPI>[0b00110000 255 0]<–set DAC to full
110 SPI CS ENABLED
120 SPI WRITE: 0×30<–write DAC command
120 SPI WRITE: 0xFF<–DAC value
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
SPI>

Every SPI command begins by enabling the chip select pin ([). The first byte is the command to update the DAC (0b00110000), followed by the value to output (255), and a third byte that's ignored (0). The command ends by disabling chip select (]).

We used an 8bit DAC with 255 even voltage steps, output set to 255 is 100%. We can use the Bus Pirate voltage probe to measure the output.

SPI>d<–measure voltage
9xx VOLTAGE PROBE: 2.5VOLTS<–DAC output
SPI>

D triggers a voltage measurement. The DAC output voltage is 100% (255/255) of the internal reference, 2.5volts.

SPI>[0b00110000 0 0] d
110 SPI CS ENABLED
120 SPI WRITE: 0×30<–write DAC command
120 SPI WRITE: 0×00<–DAC value
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
9xx VOLTAGE PROBE: 0.0VOLTS<–DAC output
SPI>

The same command with a DAC value of 0 outputs 0% (0/255) of 2.5volts; 0volts.

SPI>[0b00110000 128 0] d
110 SPI CS ENABLED
120 SPI WRITE: 0×30<–write DAC command
120 SPI WRITE: 0×80<–DAC value
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
9xx VOLTAGE PROBE: 1.2VOLTS<–DAC output
SPI>

A DAC value of 128 is about 50% (128/255) of the reference voltage, 1.2volts.

SPI>[0b01000000 0 0] d
110 SPI CS ENABLED
120 SPI WRITE: 0×40<–power down command
120 SPI WRITE: 0×00<–don’t care
120 SPI WRITE: 0×00<–don’t care
140 CS DISABLED
9xx VOLTAGE PROBE: 0.0VOLTS<–DAC off
SPI>

The LTC2640 has a low power mode, triggered by the command 0b01000000 and two bytes that are ignored. After the power down command we can verify that there’s output from the DAC. Write any DAC value to exit low power mode.

Taking it further

What’s the next step for the Bus Pirate? We’ll eventually make a final update to the design that includes USB on a professionally made, double-sided PCB. Power supply indicator LEDs were slated for this version, but didn’t get included. It would also be handy to have an AT  keyboard connector for debugging without a PC. Check out the roadmap and wishlists on the Hack a Day Bus Pirate page.

Download: buspirate.v1a.zip

Download: buspirate.v0c.zip

A few weeks ago we wrote about our Bus Pirate universal serial interface tool. We used the recent holiday to add some new features, like a JTAG programmer, macros, frequency measurement, and more. A major code reorganization makes everything easier to read and update.

Check out the a demonstration of the new features below. We’re compiling a roadmap and wish list, so share your ideas in the comments. You can also see how we used the Bus Pirate to read a smart card and test-drive an I2C crystal oscillator.

New protocols

I2C>m <–setup mode
1. HiZ <– high impedance pins (safe mode)
2. 1-WIRE <– not ready for this release
3. UART
4. I2C
5. SPI
6. JTAG <– interface and programmer
7. RAW2WIRE
8. RAW3WIRE
MODE>1
900 MODE SET
HiZ>

This firmware release lists three new protocols.

Hi-Z makes all pins high impedance/input, a safe state that won’t damage an attached circuit. To be safe, the Bus Pirate now starts in this mode.

1-Wire is listed, but we couldn’t include it in this release because we still don’t have any parts to test with our library. This is just a placeholder for now, but it will be added as soon as we get a 1-Wire part to test.

We wrote a simplified JTAG interface that includes a XSVF player for programming JTAG device chains.

**We included a hardware I2C library, but according to the device errata there’s a bug in the 24FJ64GA002 rev3 I2C module. This will work with a different chip (e.g. a 28pin dsPIC33).

Connection table

*also raw 2 wire. **also raw 3 wire.

The new modes connect to the Bus Pirate as outlined in the table.

New features and settings

Frequency measurement

HiZ>F <– do a frequency count
9xx FREQ COUNT ON AUX: 22199552Hz (22MHz)
HiZ>

As seen in the DS1077 demonstration, we added a frequency counter to the Bus Pirate’s AUX pin.  ‘F’ measures frequency, maximum of about 50MHz.

Assign axillary control

HiZ>c <– menu c
AUX PIN
1. AUX (DEFAULT)
2. CS/TMS
MODE>1 <– set AUX control mode
9xx AUX: DEFAULT SETTING (AUX PIN)
HiZ>

Sometimes we need to control the chip select (CS) /JTAG state machine (TMS) pins manually. ‘c’ toggles the pin control between the axillary pin and the chip select pin.

Set terminal speed

HiZ>b <– menu b
Set serial port speed: (bps)
1. 300
…
9. 115200
SPEED>9 <– set speed
Adjust your terminal and press space to continue
HiZ>

‘b’ adjusts the PC-side serial port speed.

Macros

A new syntax addition, ‘(#)’, triggers protocol dependent macros.

JTAG>(0) <–macro 0
0.Macro menu
1.Reset chain
2.Probe chain
3.XSVF player
JTAG>

In any mode, use the macro (0) to display a menu of available macros.

I2C address search

I2C>(1) <–scan I2C addresses macro
xxx Searching 7bit I2C address space.
Found devices at:
0xB0 0xB1 <–DS1077 responds to write and read address
I2C>

The I2C library includes a macro to automatically search the I2C address range for devices. Helpful when you work with an unknown chip.

Raw2wire smart card ISO 7813-3 ATR

RAW2WIRE>(1)<–ATR and decode macro
ISO 7813-3 ATR
950 AUX LOW
951 AUX HIGH
4xx RAW2WIRE 0×01 CLOCK TICKS
950 AUX LOW
ISO 7813-3 reply: 0xA2 0×13 0×10 0×91<–ATR bytes
Protocol: 2 wire <–decoded ATR data
Read type: to end<–
Data units: 256 <–
Data unit length: 8 bits <–
RAW2WIRE>

Macro 1 resets and identifies a smart card. For more about the ISO7813-3 ATR, see how we used the Bus Pirate to read a smart card.

JTAG

JTAG is a debugging and programming interface for all kinds of electronics. The raw hardware interface can be accessed with the Bus Pirate’s raw 3 wire library, but we added a few features to make it much easier.

JTAG has different modes where data entry does different things. Modes are navigated with the JTAG TMS signal; there are a bunch of JTAG modes, called states.The Bus Pirate’s JTAG library is just the raw 3 wire library, enhanced to help with JTAG state changes.

We only implemented the JTAG states we need to get data in and out of a JTAG device chain: reset, idle, data register, and instruction register. Macro (1) issues a JTAG chain reset, and initializes the chain to the idle state. { puts the JTAG chain in data register mode. [ puts the chain in instruction register mode. ] or } return the chain to the idle state. The Bus Pirate has an internal state machine tracker that is smart enough to manage the chain without explicitly returning the chain to idle; in other words, you don’t have to close your tags. The state machine tracker reports every state change to help debug problems.

JTAG>[0xfe {rrrr} <-- same as [0xfe]{rrrr}
xxx JTAGSM: ALREADY IDLE
xxx JTAGSM: IDLE->Instruction Register (DELAYED ONE BIT FOR TMS)
610 JTAG READY TO WRITE IR <– JTAG chain instruction register
620 JTAG WRITE: 0xFE <– request ID
xxx JTAGSM: (WROTE DELAYED BIT) IR->IDLE <–back to IDLE
xxx JTAGSM: IDLE->Data Register <–IDLE to data register
611 JTAG READY TO READ/WRITE DR
630 JTAG READ: 0×93 <–device ID
630 JTAG READ: 0×40
630 JTAG READ: 0×60
630 JTAG READ: 0×59
xxx JTAGSM: DR->IDLE <–back to idle
640 JTAG IDLE
JTAG>

Here is a short interaction with a Xilinx XC9572 CPLD. We go to the instruction register ( [ ), and send the device ID request command (0xfe). Then, we go the the data register( { ), read four bytes (rrrr, or r:4 shorthand), and return to idle ( } ).

What are delayed bit writes?

JTAG requires that the last data bit written to the instruction register be entered at the same time as the state change. Since the Bus Pirate has no way of predicting when we'll actually change states, it delays the last bit of each byte write until one of three things happens:

• Exit the instruction register with a }, ], or { command
• Write another byte value
• A read command

Pending bits are not cleared by bitwise operations (like ! or ^). Do these before writing your last byte, or change the code. We haven’t implemented pending writes to the data register, but it’s probably needed. You might need to implement this if you’re writing the data register, rather just reading, like we did.

JTAG Macros

JTAG>(1) <–macro 1
xxx JTAGSM: RESET
xxx JTAGSM: RESET->IDLE
JTAG>

JTAG macro (1) resets the JTAG chain and then advances it to the idle state.

JTAG>(2) <–macro 2
xxx JTAG INIT CHAIN
xxx JTAGSM: RESET
xxx JTAGSM: RESET->IDLE
xxx JTAGSM: IDLE->Instruction Register (DELAYED ONE BIT FOR TMS)
xxx JTAGSM: IR->IDLE
xxx JTAGSM: IDLE->Data Register
xxx JTAGSM: DR->IDLE
xxx JTAGSM: RESET
xxx JTAGSM: RESET->IDLE
xxx JTAGSM: IDLE->Data Register
xxx JTAG CHAIN REPORT: <–start of report
0×01 DEVICE(S)
#0×01 : 0×93 0×40 0×60 0×59 <–device IDs
xxx JTAGSM: DR->IDLE
JTAG>

Macro (2) resets the chain, counts the devices, and reports all the device IDs.

JTAG>(3) <–macro 3
6xx JTAG XSVF PLAYER
xxx XON/XOFF FLOW CONTROL REQUIRED <–required!
xxx PRESS z TO CONTINUE <– press z
xxx BEGIN XSVF UPLOAD <– upload the file
6×0 XSVF OK <– result or error
YOUR PC DRIBBLED MAX 0×05 BYTES AFTER XOFF (THAT’S OK)
6xx PRESS z 5 TIMES TO CONTINUE <– continue
JTAG>

Macro 3 is an XSVF player/programmer using code from Xilinx. XSVF is byte format SVF, as described by Xilinx (pdf). XSVF files can be compiled for any chain with the correct generic JTAG definition files, even non-Xilinx devices. We successfully used the binary transfer features in Hercules and Tera Term to send XSVF files to the programmer.

JTAG sometimes pauses longer than it takes the PC to transfer a byte of data, so we implemented XON/XOFF software flow control for the XSVF player. Your terminal must be in XON/XOFF flow control mode before you upload the XSVF file, or the programmer will fail. Even with software flow control, a modern PC has already send several bytes through the layers of operating system before it receives the flow control signals. We deal with this by catching these bytes before moving on, this is reported as the maximum number of bytes “dribbled”.

If there’s an error in the upload, the PC will probably continue to spit bytes at the Bus Pirate. To keep error messages visible, and prevent garbage in the terminal, the XSVF player waits for five lower case z’s before it returns to the prompt. We chose this sequence because it will never occur in an XSVF file.

*Note that the XSVF player does not respect the JTAG Hi-Z pin setting. Went it does, it fails. Be careful mixing voltages without a buffer.

Better code structure

The biggest difference between the version 0b and 0c firmware is a massive improvement in code structure. The Bus Pirate existed in many incarnations before we packaged it for the initial article. v.0c harmonizes the code libraries and makes it easier to add new protocols.

How to add a custom protocol

The Bus Pirate code handles the user interface, and passes two variables to the active protocol library. The first variable is a command, such as CMD_READ, CMD_READBULK, or CMD_WRITE. The entire command set is defined in base.h. The second variable is an optional value. A simple CMD_READ command passes no value, a bulk read command passes the number of bytes to read, a write command passes the value to write to the bus, etc. At minimum, a custom protocol needs a function to receive these variables and translate them to bus actions.

We used three different techniques to link commands to bus actions. Simple code can go directly in a giant switch statement, like SPI.c. External libraries use an single linking function, like I2C.c, and m_i2c_1.c. More complicated protocols use the switch statement to call functions included in the library (raw2wire.c, raw3wire.c, jtag.c UART.c). Helpful functions for terminal IO are included in base.h/c.

Due to massive code improvements, it’s now only mildly confusing to register a new protocol with the Bus Pirate:

base.h – Create a definition for the protocol. The last entry is currently “#define RAW3WIRE 7″, so the next entry could be “#define MYCUSTOMWIRE 8″.

busPirate.c – Include a header file with that gives access to the processing function.  Add a menu entry in the char* mode[]  = variable list. The menu entry must be in the same position on the list as the number assigned in the base.h define. If MYCUSTOMWIRE is number 8, it must be the eight entry in the mode variable. Finally, add an additional switch to the bpProcess() function that calls the custom library processing routine when the mode is set to “MYCUSTOMWIRE”.

Taking it further: a Hack a Day wish list

We compiled the feedback we’ve gotten into three wish lists: protocols, features, and macros.

Protocols

• 1-Wire, with enumeration (*ready as soon as we have parts to test it)
• OBD-II (thanks [Shadyman])
• CAN
• MIDI (Wikipedia)
• DMX512-A
• IRDA, RC5x, etc.

Some protocols will require an external transceiver.

Features

• Pulse-width modulator, frequency generator
• “Wait until interrupt” command
• Convert frequency measurement to input capture peripheral
• Allow frequency measurement on any pin
• Show a report of the current configuration settings and pin states.
• Integer repeat values for bulk read, clock ticks, delays, etc.
• A CRC generator

Macros

• Transparent UART bridge
• SD card initialization, meta data extract, and dump
• EEPROM program/dump (I2C/SPI)
• Nokia 6100 LCD initialization, control
• NMEA GPS data decoder

Do you have anything to add to the list?

Firmware download: buspirate.v0c.zip

[floe] wrote in to tell us about his multitouch based thesis work. While many projects have focused on the hardware side of multitouch, TISCH is designed to promote the software side. TISCH is a multiplatform library that features hardware abstraction and gesture recognition. This takes a lot of weight off of widget developers since they can specify known library gestures instead of writing the exact motions from scratch. Using TISCH also means a standard set of gestures across multiple widgets, so the learning curve will be much easier when a user tries out a new app. If you’re researching multitouch, check out this project and help improve the codebase.

Our fascination with multitouch is fairly well known, but it expands even further to cover all sorts of man machine interaction. Embedded above is a tech demo of g-speak, a spatial operating environment. The user combines gestures and spatial location to interact with on screen objects. If it seems familiar, it’s because one of the company’s founders advised on Minority Report. We doubt all this hand waving is going to catch on very quickly though. Our bet is on someone developing a multitouch Cintiq style device for people to use as a secondary monitor. It would bridge the gap between between our standard 2D interactions and gestures without making a full leap to 3D metaphors.

[via Create Digital Motion]

Yesterday we linked to an OCZ Neural Acutator Interface teardown. Several in the comments wanted to know more about the sensor electrodes. Check out the OpenEEG project and OpenEEG mailing list for information on sensing, amplifying, and recording brain activity (EEG). The OpenEEG project maintains an open source Simple ModularEEG design. Two other open source variants of the ModularEEG are the MonolithEEG and [Joshua Wojnas'] Programmable Chip EEG BCI. All three projects use Atmel microcontrollers, with designs in Cadsoft Eagle.

Brain activity is measured using passive or active electrodes. Passive electrodes require a conductive paste to make proper contact with the skin (examples: 1, 2). Active EEG sensors don’t need conductive goop because they have an amplifier directly on the electrode (examples: 1, 2, 3).

[via anonymous reader, comments]

The Siftables are quite interesting. They are an information interface that is supposed to be more physical and natural. The analogy they use is a container of nuts and bolts can be sifted through quite easily using your hands. They envision us being able to sift through data similarly. They also mention that it could be used as a gestural interface as well.

Each unit is a small device with a screen, wireless communication, and IR sensors. There are some pictures of the units in action as well as a video on their site.

[via Make Flickr Pool]

Currently, they support software enviroments like: Processing, Max/MSP, VVVV, and Adobe Flash. That list will undoubtedly grow as the community plays with it. They envision the hardware connecting via MIDI, OSC, RS232, TCP/UDP, DMX, or USB.

They encourage others to design their own inputs. Community members can share modifications and designs, though there isn’t a forum or store yet. If you design a setup that you really like, they can even fabricate a single unit for you. Keep your eyes on this one, it could be a real hit.

A similar idea for general gadgetry can be seen over at Bug Labs. Starting with a base unit, you can add different input and output modules to create various useful functions. They currently offer GPS, a camera, a display, and motion sensing. Mix and match to make your dream gadget.