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

Touch Me Please!

Before I dive into this post I take a moment to profusely apologize for the title of the post – it is tragically horrendous.

OK, so now that I’ve got that out of the way, lemme begin. This post is a little out of ‘order’; it would have been more appropriate had I first blogged about how I procured some of the components mentioned in this post. But heck! Lazy as I am, I guess I’ll leave that for a later date.

A friend of mine (un)fortunately busted his laptop several months back. I managed to persuade him to let me scavenge parts from the laptop. What parts did I get? That’ll be the subject of a different post :-D I managed to rescue several components; a touchpad being one of them. And as usual, I went about trying to interface it.

Electronics being my love, and today being Valentine’s Day, it is most fitting that I have successfully managed to communicate with the touchpad. Now before you start making judgements about me, and why I fool about with electronics on this most awesome day, let me tell you how I went about the interfacing.

The touchpad is a mouse replacement ubiquitous on laptops. Synaptics is by far, the biggest touchpad manufacturer. Alps Electric, Cypress, and a few others are also into the touchpad market. Most touchpads today work on the principle of capacitive sensing.

The touchpad of my trusty IBM Thinkpad R51 

The touchpad I scavenged was from an HP Pavilion dv2000 series laptop. The touchpad used is probably manufactured by Alps Electric Corporation (there is a prominent “ALPS” silkscreened onto the back of the PCB). The touchpad is a capacitive sensing type and is controlled by a 48 pin QFP. The chip is marked 1CA026A. I googled high and I googled low but I couldn’t find anything useful; no datasheets, nothing. So it became necessary that I give experimentation a shot.

There is a four wire flat cable (FFC) heading off the PCB. Having fooled about with electronics for a while now, I knew that it was but obvious that the touchpad used some sort of serial protocol. I figured that there were a few possibilities – maybe USB, possibly I2C. Again, I googled to see if touchpads followed a standard protocol. Most sites on the net said that laptop touchpads invariably use the PS/2 protocol, however, none of them said it with ‘authority’. It was always “apparently, touchpads use the PS/2 protocol” or “the PS/2 protocol is used even on laptops”.

Anyway, I thought I’d give USB a try. I used a hacked-together USB dev board, pulled out V+, Gnd, D+, D-, and connected them to what seemed like the appropriate pins on the touchpad. When the error “USB device not recognized” popped up, I reversed D+ and D-. After I still got the same error, I guessed that it was the PS/2 protocol that the device used.

I don’t have a PS/2-to-USB converter so I had to use one of my trusty PICs (a ‘628A is this case) to emulate a PS/2 host. I wrote my own driver basing my ‘read data’ code on something written by Dheera Venkatraman (who has very kindly made his code available online).

I also referred to these sites for info about the timing specs of the PS/2 protocol:
http://www.computer-engineering.org/ps2protocol/
http://www.computer-engineering.org/ps2mouse/
http://documentation.renesas.com/eng/products/mpumcu/apn/reu05b0121_h8s2100ap.pdf

 

Below are a few pics that I took.

Right: The touchpad; left and right buttons are on the PCB
Left: Bottom view of the touchpad PCB

The test rig 

Initially, when the touchpad is powered up, it sends 0xAA (‘passed self-test’), followed by 0x00 (which is the mouse ID). The ‘628 then sends the byte 0xF4, which tells the touchpad to stream data, i.e. continuously send any activity on the touchpad or the buttons. Once all commands are received/issued the PIC asserts a pin connected to an LED.

The initialization sequence – 0xAA(self-test OK) followed by 0x00(Mouse ID)

Here is my code if you need it. While you are free to modify it in any way you wish without permission, it would be nice if you remember to give me credit. :-D

Video to come up shortly.

Of Scopes and SMDs

I've always loved electronics for its 'minuteness'. I'm fascinated, even today, by how small consumer electronics can get. Have you ever opened up your cell phone or iPod and seen the myriad tiny chips and resistors and capacitors and whatnot? And do you realize that what you see is actually not small; it is HUGE when compared to what is on the inside of those silicon chips.

With Intel, using the 45nm process to manufacture its current processors, now talking about switching to the 30nm, and progressing to the 10nm fab, everything is set to get very, very small. The SMD resistors on your Nokia motherboard seem gargantuan in comparison.

Anyway, I absolutely needed to get myself a piece of this deliciously small pie. So in the past few months I've stared working with surface mount devices. Naturally, if I've reached the level where I'm working with SMDs, I would also have reached the level where I would need the services of an oscilloscope. Problem is, an oscilloscope, even a government-office-used, second-hand, two channel, 100MHz scope - the minimum demanded by any respectable hobbyist - costs about 10 grand. 10 grand is something I would like to have, but sadly, I don't. A new plain-jane CRO-oscope is about 25-30K, while (drool) Agilent DSOs start at a prohibitive 70K. Even cheapo entry-level USB oscilloscopes are a minimum of 10K, and to make matters worse, they aren't available in India.

So, like any other respectable hobbyist (all respectable hobbyists have what is called 'electronics-ego' - some may call it a touch of madness, others, an obsession, and yet others, an incurable disease; to hell with you, you vile naysayers! May you all burn!). Umm, yes, where was I? Aah, as I was saying, like any other respectable hobbyist, I decided to go the DIY way, and build my own scope.

The advantages of building your own scope - it's dirt cheap, and you learn a ton of other stuff (analog layout design, ADC nitty-gritties, USB firmware coding, and host data-handling to name just a few).

The scope would follow this kind of layout:

(Analog front end) --> (Data packaging for USB, on the PIC) --> (Host data display)

AFE:

(Buffer) --> (PGA) --> (Hardware AA) --> (High speed dual-channel parallel-out ADC from MAXIM/TI)

PIC:
(PIC 18F4550)

-> (8Mbit memory from Cypress, for deep capture)
-> (External trigger sources)
-> (USB2.0 Full speed @ approx 1.2MBytes/sec bulk transfer)

Host:

(LabVIEW software frontend)

Upto now I've built, and tested various parts of the AFE - I still need to throw everything together, and see if I actually get the desired results (this, without a doubt, is the biggest thorn in any engineer's side; everything works perfect in the lab, it works well as individual modules, and then, when you try to put stuff together, it all just falls apart. You start swearing and tearing your hair out in frustration; that's the reason why I'm.....uuh, forget it).

Last night (in Sid's words, and CCS-C) I was on cloud [unsigned int8 cloud 0b00001001]. I got USB bulk transfers to work with LabVIEW, albeit, in a crude way. Nevertheless, it worked, pleasing me tremendously. LabVIEW makes development super-easy. Easy, in a way that makes you feel dumb. Amit Sabne, who I've been brain-storming with, puts it very concisely - "Yaar, feel hi nahi aati!" - which is kind of true. The chaps at NI have done a great job of making hardware interfacing a snap. Wait for your USB device to enumerate, enter its VID and PID (device/manufacturer specific 'serial numbers'), throw a few icons and VIs here and there, and voila! You have délicieux transferts de USB bulke, served hot! (yes, translate.google.com is most helpful). The NI engineers have robbed hardware-software hackers from the trials and tribulations of mind-messing driver-writing, back-breakingly long hours of prouring over hardware, and sleepless red-eye-rubbing nights. Damn! Where's the joy and satisfaction if you can do something in 10 minutes, what used to otherwise take hours?

Now that I've got a rough and dirty implementation of PIC to USB transfers to work, what remains is putting it all together. Gimme a few days, and I'll upload the PIC firmware in CCS-C, and the LabVIEW VI here for you to use, enjoy, redistribute!