AVR hacking

For the past couple of weeks I have finally had the chance to play with AVR microcontrollers.  A few months ago I bought an Atmel STK-500 evaluation board but it took me a while to get it fired up.  I started out using the AVR Studio integrated development environment, but being more of an old school programmer, those fancy-schmancy GUI tools with their point-and-click code editing drive me crazy.  I can edit code much faster with vi than by having to move a pointer around with a mouse.  Besides that, I try to limit the use of Windows at home, so I have successfully moved to developing code on my Mac using the GNU AVR tool chain.  Thanks to the OSX-AVR distro, the transition was pretty smooth.

Since I am just starting out, I needed to write a Hello World program.  Using the ATmega8515L processor that came installed on the STK-500, I wrote some routines to drive some DL1414 alphanumeric displays I had.  Some of my first 68HC11 microcontroller projects back in the late '80s used similar DL1416 displays, so it was sort of returning to familiar territory.  However, the AVR environment is much nicer than what I did on the the 'HC11, since writing code in C is a lot easier than hammering out assembly code one instruction at a time.

The circuit I came up with for the DL1414 was simply the external memory interface Atmel recommends for the '8515L.   It's remarkably similar to the 68HC11 <-> DL1416 interface I devised back in 1989.  (See below)  However, the Atmel processor has a mode to support it directly so I can write to the display as write-only memory, no fancy bit-banging required.  I had to bit bang the individual I/O lines with the 68HC11 because interfacing memory to the processor would use up all of the parallel I/O lines unless you used port replication expansion chip, which I didn't have.

The only snag is that the characters on the display are addressed right to left whereas strings are handled in C from left to right. Thus I needed a little extra code to reverse the order of the characters:


int dl1414str(sp)

char *sp;  /* pointer to a string to display */

{
    int length;
    int i;
    char *daddr;

    length = (int) strlen(sp);

    if (length > DL_SIZE) length = DL_SIZE;

    daddr = (char *)DL_ADDR;

    /* We have to reverse the order of the characters since the
           addressing of display characters is "backwards." */
    for (i=0;i<length;i++) daddr[(DL_SIZE-1)-i]=sp[i];       

    /* Blank out end of line if string being displayed is shorter than
       the display itself */
    if (length < DL_SIZE) for (i=0;i<(DL_SIZE-length);i++)
        daddr[i]=' ';

    return(0);
}



Cool Open Source Hardware Project

Last week I saw this article in EE Times on an open source hardware project called the Free Telephony Project.   The project is providing a reference design and open source hardware for an Asterisk PBX based on the Analog Devices Blackfin embedded DSP.  The device runs uClinux out of flash (no hard drives like a real telecom device.)  One incarnation, known as the IP04 is being made available for purchase for about $450, but you can also download the designs and build it from scratch yourself.  (When it's all said and done, you're probably better off buying one since it will pretty hard to compete with their volume pricing...)

Currently FXS (POTS station) and FXO (POTS central office) interfaces are available and T1/E1 ISDN-BRI interfaces are in the works.  It would be nice if they could develop a 4-wire E&M interface which would be useful for two-way radio projects.  One group of hams has already done some interesting linking work with Asterisk in a project called the Allstar Link Network.  They are using app_rpt with the Zapata Telephony Quad Radio PCI Card.  Thus, they've been able to build an IRLP or EchoLink-type network out of Asterisk boxes.   I find this approach attractive because it's totally open.   But while they seem to be off to a good start, by the look of their last updates things seem to be stagnating.  Perhaps some cheaper hardware would reinvigorate things.  If I only had more time on my hands....

Card Reader Project

A couple of weeks ago I ordered a magnetic stripe (credit card) reader from BG Micro along with a bunch of other miscellaneous electronic parts I was buying.  I intended to interface it with my PC and use it with Stripe Snoop.  While the description for item ACS1496 doesn't state the model number, the unit is a Panasonic ZU-1427ND.

It turns out that the reader is a bit different than the Magtek-based (and comptible) units that Stripe Snoop is written to talk to. Like the "standard" units, the ZU-1427ND reader has three signals, "card present" (CP), DATA, and Clock.  The CP and DATA signals are both active-low (i.e. 0V = "1", 5V = "0") like the standard reader, but the Clock signal is inverted and active-high, or in other words, strobes the data on a low-to-high transition.

No big deal I thought...  Since the signals needed to be buffered anyway, running the clock through an inverter before wiring it to the PC parallel port would be simple enough. However, I soon discovered that the ZU-1427ND card reader had another interesting quirk.   After hooking the card reader up to the PC, the Stripe Snoop software saw nothing but a string of zeros coming out of it.  So I broke out the logic anayzer to see what was coming out of the reader.  The picture below shows the output. (Don't bother trying to decode it...  It doesn't show the whole swipe and it's only my AAA card at that...)

Unlike the Magtek-based readers, the DATA line of this reader always returns to zero between each bit transmitted.   When multiple successive ones are transmitted a Magtek-type reader, the DATA line is held low until the next zero occurs. And when a zero occurs after a one, the return to zero happens much later, just microseconds before the clock line strobes the next bit.  When two or more successive ones occur on the Panasonic reader, the DATAline goes high shortly after the clock strobes the first one, and then returns low prior to the clock strobing the second one.   I think with all of the Windows overhead, Stripe Snoop is sampling the DATA line during this return to zero.

So I looked through my parts drawer and found a 74F373 latching buffer.  This was perfect... I ran the DATA line through one of these buffers and tied the latch gate to the inveretd clock.  The '373 is a tri-state device, but since I didn't need the High-Z state, I tied the output enable (OE) to ground.  This is the schematic of the complete intetrface circuit.

By latching the data line with the inverted CLOCK, the data state is held for the entire clock cycle and this gives Stripe Snoop a chance to read the DATA. In the timing diagram below, you can see the effect of the latching of the DATA signal and how the resulting output does not return to zero between successive ones by comparing the areas circled by two ovals.

Overall, while the reader works, the heads cannot be easily modified to read track 3 on the card. (You can still read track 1 by using the "shim method" though.)  I think I will continue to keep an eye out for a cheap Omron model or perhaps a reader that can read all three tracks natively.