Arr me hearties! Meet me ol’ Bus Pirate!

Those of you who are acquainted with my eccentric mannerisms must know that I rarely throw junk out, more so if it is electronic scrap. Old electronics are perfect places to find serial memory chips and audio amplifiers and digital logic gates and motor drivers. Sometimes (well, actually most times) the chips have vague numbers and markings, or even no numbers (so as to protect the manufacturer’s IP) and are therefore, quite unusable. You see, I be trawlin’ fo’ gold in the bogs, ya scallywags! And very often I pick up scum. Occasionally the chips are variants of common chips, and a bit of googling (funny how that term’s become a verb over the last few years, no?) turns up suitable datasheets. Other times the chip is just obscure enough to have a presence on china-ic-mart.com, but not have a datasheet. Even a Digikey search results in seeming useless information. However, if you’re willing to try to emulate Sherlock a bit then you can find similar devices with similar specs and similar pinouts.

The key word here is ‘similar’. If you’re *very* lucky you get the right pinout, but if Murphy is to be believed, its more likely that D₀ will actually be Q₁, and Xtal will really be Vin.

In the old days I would search for the closest matching chip for which a datasheet was readily available and have a go at the unknown chip. I would spend painfully long hours hunched over a chip with a multimeter in one hand, an oscilloscope probe in my mouth, and a finger on the chip-under-test, to ensure that it wasn’t overheating because of a reversed Vcc-Gnd.

A simple tool that allows you to sidestep this agony is the Bus Pirate. Developed by Dangerous Prototypes and marketed by Seeed Studio, this a fantastic tool that’s great for the intrepid hacker. It’s got several useful modes that allow you to bombard the device under test with different protocols until it finally burps out some info. Ordinarily, I would sit and program a microcontroller to ‘talk’ to the DUT. This would be a hit-or-miss kind of thing as I wouldn’t be aware of the DUT’s communication protocol. Since a lot of industrial protocols (like asynch serial, I2C, SPI and OneWire) as well ‘raw’ protocols are already built into the firmware of the Bus Pirate, you can save a lot of time and effort in your quest to unravel the chip’s mysteries.

So I’ve been wanting to get myself a Bus Pirate for quite a while, but its been out of stock at Seeed Studio for ages! DP has cool “Free PCB” days where they give out free PCBs (duh!), including Bus Pirate PCBs, but I’ve never been lucky enough to snag one. I got sick of waiting my turn and finally decided to build one myself.

My take on the Bus Pirate

And what better stuff to build the Bus Pirate from than the very junk that its going to be used to test! Most of my Bus Pirate’s components are salvaged from old computer motherboards, CD  ROM drives, and an old Motorola phone (thanks Eeshan – I got funky blue LEDs!). The board is an unhealthy mish-mash of through-hold and SMD components.

Changes
I’ve made a few tweaks to the original BP design, substituting the voltage regulators with what I had lying around – an LP2950-3.3v in an easy-to-solder TO92 package powers the BP, while SOT23 REG101s provide 3.3v and 5v to the external devices that the BP is capable of powering.

 
Left: The bottom of the board.
Right: A closer look at the regulators. I didn’t even bother adding filter capacitors on the outputs; maybe I will later.

Since I had a Sparkfun FT232RL  breakout board, I used that for comms (instead of having the FTDI onboard like the original).

Pin headers, the LP2950, a PIC24FJ64GA002, and a capacitor are on the top.

The top of the board. Visible are right angled pin headers (the top left one is for a PICKIT programmer, the bottom one is for the FTDI). Beside the

I also had a SOIC14 MC14066B from an old motherboard that I used in place of the CD4066.

    Left: Prepping the 4066 for soldering onto veroboard. Each pad was cut in half. 
Right: some SMD components – 10kΩ voltage dividers for the ADC in blue; 470Ω for LED current limiting in green, a 0.22uF ceramic in the yellow circle, and the blue LEDs in red.

A few cosmetic changes, like blue status LEDs, and juggling the BP header pins about, were also necessary; but the general idea remains unchanged.

The ‘Power’ and ‘Mode’ LEDs lit up. I forgot to name the LEDs on the paper decal.

The case is an artificial sweetener box swiped from mom’s kitchen and repurposed with my Dremel. Slots were cut into either end to hold the veroboard in place. An opening was cut in at the top, allowing the header to poke out. Two smaller openings were made for headers to the FTDI and a PICkit2.

 
Left:The original case, and Right: after being sanded and cleaned.

Once built, I programmed the PIC24FJ64GA002 with my trusty PICKit2. Firmware v5.10 was uploaded using ds30Loader. My BP passed the self tests without so much as a whimper.

To try out its features I decided to continue fooling around with the BU2090.

Driving the BU2090FS with a BP
Configuring the BP was simple enough. When I was greeted with HiZ> on the main prompt I changed mode to 2WIRE by pressing m and then 6. I pressed 4 to get the fastest available speed – 400kHz, and made the outputs ‘normal’ by entering 2.

Configuring the Bus Pirate

It was now a simple task entering special characters (_ – / \) to toggle the DATA and CLK lines the way I wanted.

The ‘2090 shifts one bit of data at a time.
To shift in a ‘0’ the keystrokes used by the BP are: _/_\.
To shift in a ‘1’ they are: –/_\.

Once data is shifted in it needs to be latched to the outputs.
To shift in a ‘0’ and latch all the data (including the recently shifted bit):_/-\.
To shift and latch a ‘1’: –/-\.

So if I wanted to get the following binary output from the 12-bit output of the ‘2090: 1 1 0 1 0 0 0 0 0 1 1 1, I’d use the following syntax:

–/_\–/_\_/_\–/_\_/_\_/_\_/_\_/_\_/_\–/_\–/_\–/-\
     1      1       0       1       0      0       0      0       0      1       1      1L
  MSB                                                                                           LSB

I’ve depicted alternate bits in different colours for clarity. Data is left-shifted MSB-first. The last ‘1’ to be shifted in latches data to the outputs. A quick video of data being shifted in is on it way, but you’ll have to make do with a still for the time being.

Data shifted in

Of course, this may not be the most efficient way to control the ‘2090 with the BP; there may be shorter command sequences, and better modes. Please post in the comments if you know of a better way.

Using the BU2090FS LED shift driver

I do a lot of scavenging for components. Whenever I get my hands on junk electronics I whip out my soldering iron, a desoldering pump, some pliers, and a pair of tweezers to see what I can extract from it. Scavenging is a long, tedious and sometimes painful process involving singed hair and burnt fingers, but every once in a while I come across a really nice component from an old TV or washing machine. I’ve learned a lot of desoldering (and some soldering) skills, and managed to save a few bucks by scavenging for components.

IIRC, I found the BU2090FS on a VCR board. I managed to desolder the SSOP16 chip by throwing the entire PCB into a toaster. I let the board cook for a few minutes and then started pulling off parts with my tweezers. The chip is quite solderable by hand, but I had no 0.8mm SSOP boards, so I superglued the chip onto veroboard and had a go at hand soldering the thing.

Now you’re probably thinking that hand soldering a 16 pin SSOP is a daunting job, but its not really that hard. All you need is a fine point soldering tip and a steady hand. A little bit of magnification and good lighting helps as well. All in all it took me less than 15 minutes to make the DIY SSOP-to-dip ‘adaptor’.

 
Left: the ‘adaptor’
Right: the chip can be seen below the wires

The ‘2090 is a 12-bit latched shift register, and is primarily used to drive LEDs. It runs off 5v and can sink upto 25mA per channel. Coding for the chip wasn’t difficult at all. Serial data can simply be clocked in and you’re ready to go.

Below is a ‘scope capture of the data to make output Q8 and Q0 low. Data is fed in MSB-first. Keep in mind that the outputs are active low since this is a sinking driver.

 Oscilloscope capture

Data and clock lines idle low. According to the datasheet data is sampled every rising clock. A shift occurs after every new bit of data is clocked in. Data is latched after all 12 bits are sampled by raising data high and then pulling clock low.

I used CCS-C on a PIC16F882 to test the chip. An excerpt of the driver is below:

#define clk pin_c5
#define data pin_c4

void writedata (int16 var)
{
    int8 loop;

    var<<=4;   

    for(loop=0;loop<11;loop++)
    {
        output_bit(data,var&0x8000);
        output_high(clk);
        output_low(data);
        output_low(clk);
        var<<=1;
    }
    output_bit(data,var&0x8000);
    output_high(clk);
    output_high(data);
    output_low(clk);
}

 

 
The BUF2090 mounted for prototyping

Cheap Graphics – Nokia 3310 LCD

It’s been aeons since I blogged last. I’ve kinda gotten rusty so I thought I’d begin small by blogging about something that’s been a work-in-progress for a quite a while.

I’m always looking for inexpensive ways to add ‘bling’ to my projects. A graphic LCD is a lovely way to add that extra bit of fun (and functionality) to an application. Granted, a graphical display may be total overkill in some situations, and may not even be required in others. But when it is necessary, the Nokia 3310 display is a cheap and easy way to display 48*84 pixels of graphics.

I’m not going to go into the specifics of driving the 3310 LCD – I simply followed the resource found online. Scroll to the end of this post to see what’s helped me out. In this post I’m going to condense the four years of dilly-dallying and playing around that was a ‘necessary’ prerequisite in learning to interface the 3310.

I bought my LCD from Lajpat Rai market in Old Delhi for Rs.120 (less than $3) from a mobile repair shop. If I had haggled I may have got it for 80 bucks. It took me two whole years to actually get down to interfacing it – the main thing that made me repeatedly postpone working on the LCD was the difficulty in interfacing. The pic below shows what I achieved in January of 2010. I used LCDInfo and connected the 3310 LCD to the parallel port of my IBM. The results were far from pretty, but I liked what I saw.

My first attempt: messy, to say the least.

Again, my reluctance to work on this seriously was due to the fiddly wires and temperamental connections. So I made the connections slightly more reliable by using the plastic chassis of the phone and soldering a ribbon cable to the connector (which, by the way, is not too difficult).

        

The LCD being tested. Read more about how I interfaced a touchpad here.

In May of 2010 I used a touch pad and interfaced the LCD to it with a PIC. Pretty fun stuff. Here’s the post and a video. The LCD, however, still had a mind of its own, and would abruptly stop working due to poor connections.

Finally, a year later (in June 2011) I got down to making something much more reliable; something that would allow me to easily prototype with the LCD. Here are the results.

  
The LCD board. Left: Top. Right: Bottom showing header.

  
The LCD spring connector. Hand soldered and compared to a pen.

  
Left: the veroboard marked for cutting with a Dremel.
Right: parts of the assembly.

It took me only a couple of hours with a Dremel, some cyanoacrylate glue, veroboard and some headers to make this. Now I can simply stick the board into a solderless breadboard. A backlight is missing, and is the order of business tomorrow. :-)

Resources:

• Michael Bavin’s driver (from the CCS forum): http://ccsinfo.com/forum/viewtopic.php?t=25571&start=0&postdays=0&postorder=asc&highlight=3310
• LCDInfo’s page: http://forum.lcdinfo.com/viewtopic.php?f=14&t=474&sid=09b25901128c924192ed04d6df6546d6