Sunday, April 15, 2018

When is "Power Good" not good?

I've been putting together a couple of test PCBs to see how well my design for the power subsystems for the redesigned Canon P170-DH printing calculator. I figured it'd be smarter to build a couple of small (2" x 1.5") test PCBs at $15 each than to go all the way to the big (6.75" x 6.7") replacement board costing $150 and then discover that I'd made an error. In every case the circuit I started with is not the circuit I'm going to build.

Saturday, April 7, 2018

The resistance of a conductive pad keypad

I'm still relearning KiCad, so one of the first things I did while entering bits of schematic is the keypad. It's basically a 5 row, 8 column, matrix with a few contacts missing where there are larger keys.

A resilient rubber sheet formed with bumps covers the PCB, each of the bumps under a key on the keypad. On the inside of each bump is a flexible conductive pad. Pressing the key pushes the conductive pad against a pair of bare conductors in close proximity on the PCB. These conductors meander in a pattern intended to maximize the area of contact, which minimizes the chance of missing a keypress.

Since these conductors are exposed to air, they must be corrosion-resistant. This board appears to use a carbon rather than copper on the top of this board, which makes it quite resistant to corrosion. However, it also has a measurable amount of resistance to it. I believe the reason the traces visible in the photo here are so wide is to minimize that resistance.

This I knew from when I first disassembled and examined the board. I'd also measured the resistance of the conductive pad itself, which is quite low. What I'd never gotten around to measuring was how much resistance there was when the pad was pressed against the PCB, nor had I calculated acceptable values for the pull-up resistors on the rows and possibly columns. So tonight I made an attempt.

If you look closely at the photo (click on it to enlarge it) you'll find a key contact labeled "COST". Measuring from that to the via below the key contact area marked "GT" I see over 400 ohms. Measuring to the via above the "COST" key contact I see over 100 ohms. That's what I mean by "measurable resistance". Pressing the pad against the contact area gives a resistance of about 1.0K to 1.5K, depending on how hard the pad is pressed. If the carbon PCB traces account for 500 to 600 ohms I'd believe that the contact resistance accounts for the other 500 to 1K ohms.

I won't be making a PCB with a carbon layer on the top side, even if I knew where to get such a thing. On the other hand this is an experiment and I don't need that level of wear and corrosion resistance. My plan is to use normal copper with an ENIG (Electroless Nickel Immersion Gold) plating, which is easily available. This should give me reasonable corrosion protection while offering a flat surface. While I expect that will eliminate much of the contact resistance (and all but an insignificant amount of trace resistance), I'm still planning for 1K to 2K of resistance when a key is pressed.

Here's the schematic for the keypad as it stands now:

The 74LVC14 Schmitt trigger inverters I'm going to use to buffer these contacts wants to see a voltage below 0.7V before it considers an input to be low. The datasheet for the Spartan-6 family says the highest voltage on an output driven low is 0.4V, so the maximum voltage that I can allow to develop across the keypad contacts is 0.3V. If I hedge my bets and assume 2K through the keypad, Ohm's Law says 0.3V across a 2K resistor means there is 150µA flowing. Dropping the remaining 2.6V at 150µA requires my pull-up resistor to be 18K ohms or higher.

Looking at it the other way, an input of the 74LVC14 needs to reach as high as 2.0V before it sees the input as high. The datasheet says an input pin could leak as much as 5µA, so the upper limit on the pull-up resistor is 260K ohms.

There's also timing to consider. An input to the 74LVC14 presents a capacitance of only 5pF, but the contact patterns look a lot like tiny capacitors and the PCB traces are long. if I assume a bloated 50pF on each row, pulled up by a single 260K resistor, the RC time constant is 13µs. (In fact, it'll rise from 0.0V to 2.0V in 12.1µs, but who's counting?) This is far shorter than the 250µs I plan to assert the column output lines, so 260K would work.

As can be seen on the schematic, I'm planning to use 100K pull-up resistors on both rows and columns. This is the equivalent of one 50K ohm pull-up resistor when one switch contact is closed. There is also a 470 ohm resistor in series between the FPGA and the column of switch contacts.

Why the 470 ohm series resistors on the column drivers? My Verilog test code drives all the columns high, except for the one I want to probe which is driven low. If two switches on the same row are pressed at the same time, the low output of the column being probed and the high output of the other column are connected through the switches. That could damage the FPGA's driver circuitry. Digilent addressed this on their PmodKYPD keypad by placing 470 ohm resistors in series with the columns. If all seven keys in a row were pressed simultaneously, there would be seven 470 ohm resistors in parallel (equivalent to one 67 ohm resistor) in series with one 470 ohm resistor, for a total resistance of 537 ohms. With 3.3V across 537 ohms there would be a current of about 6mA. That's not ideal but it's insufficient to damage the FPGA.

Why the 100K ohm pull-ups on the columns? To avoid the issue of connecting two opposing drivers together, and thus avoiding the need for the series resistors, I could set the column drivers for the inactive columns to a high-impedance state. After all, the pull-up resistor on the row would pull the column high when a switch is pressed. However, digital logic really doesn't like inputs that float, and the columns that aren't being driven are essentially floating inputs. The column pull-ups keep these inactive columns in a known (high) state, as well as avoiding glitches on the rows when switches are pressed.

Laying out the PCB for both series resistors and pull-ups allows me to defer the decision on how to drive the columns until long after the board is fabricated. It's easy to leave the pull-up resistors off if I drive the columns high, and almost as easy to install 0-ohm "resistors" if I use the pull-ups. Or install both sets of resistors, which would permit either mode of scanning.

Isn't this fun?

Friday, April 6, 2018

KiCad display update rate fix

I've been working with KiCad to start the schematic and layout for the printed circuit board I'm going build to replace the factory PCB in the Canon P170-DH calculator.

The stable release of KiCad is 4.0.7, but I'm using bleeding-edge 5.0.0-rc2-dev built from sources — literally last night's vintage. I don't recommend this for everyone (or anyone who isn't prepared for random failures and corruptions), but it seems to have reached a level of stability I'm willing to tolerate. I'm doing this largely because I have some modifications I'm developing, and I don't want to have to re-implement them when the 5.0 release comes out in a couple months.

Wednesday, April 4, 2018

The Need for Speed (and stability)

Monday I ordered some 10K 0.5% resistors in the 0402 package. As I ordered them I had the horrible thought that maybe, just maybe, they'd used 0201 packages instead, so I ordered a strip of those too.

Tuesday, April 3, 2018

M-32TL Printer contact debouncing

I got to thinking about the interface to the M-32TL printer from my Canon P170-DH calculator. Now that I have an async serial interface I thought I'd plumb it into the printer.

Sunday, April 1, 2018

More issues with the iCEblink40-HX1K

I decided it might be worth implementing a simple UART to allow the use of a PC serial port when testing the I/O peripheral interface. And it sounded like fun.

I looked on OpenCores to see if there was one I wanted to grab instead of writing my own, but most were complex clones of the 16550 UART chip, complete with a bus interface to control registers; far too complex for what I wanted. After all, the receiver is a simple state machine, and the transmitter almost trivial.

I coded up the transmitter in one evening. The receiver took a bit longer, about two evenings. Another evening was spent running it through the Xilinx iSIM simulator working out the kinks. I wrote a top module that took the output of the receiver and looped it back into the transmitter; something of a very complex loopback plug. I connected a PmodRS232 module to the board and connected that to one of my computer's serial ports. All that was left was loading it into the iCEblink40 board and giving it a test. I tapped a key... and got back garbage.

Sunday, March 25, 2018

Matrix keypad experiments, part 2

Ever heard the saying, "The cobbler's children go barefoot"?

One of problems with being everybody's go-to guy for home tech problems is that there isn't anyone to call when your own tech develops problems. This morning I woke up to find my main computer and home network was  completely locked up. Several frustrating hours later I finally got back to working on the keypad scanner.

The pic shows the iCEblink board with the PmodKYPD keypad plugged in, and my scope probes attached to the column 3 and 4 outputs.