Saturday, April 28, 2018

FPGA Power test board

Here's the second of my power subsystem test boards being probed:

This one will supply 1.2V for the Xilinx Spartan 6 FPGA's logic core, and 3.3V for the FPGA's I/O interfaces and the 74LVC2G14 Schmitt trigger inverters. The VFD filament transformer driver will also run off this 3.3V supply.

Friday, April 27, 2018

More iCEblink blues

I couldn't go to bed without trying the VFD power board with the actual vacuum fluorescent display. Which meant mating the iCEblink40 board with the VFD driver board. And once again I've run into problems.

VFD Power test board

Both the VFD power and FPGA power test boards showed up today. I decided to assemble one of them this evening, leaving the other for tomorrow.

Thursday, April 26, 2018

Understanding the V-t Product

I just realized I made an oopsie with my parts order from DigiKey. To understand why, we have to look at how transformers are characterized.

Wednesday, April 25, 2018

Gonna be a fun weekend

Why am I posting on a Wednesday afternoon? I got sent home from work because my allergies were making me sneeze so badly I really couldn't do much. Benadryl has calmed my sneezing, but writing this blog is about the most challenging thing I'm capable of at the moment. And that's questionable. :-)

On the bright side, this weekend is shaping up to be fun:
  • The parts I ordered from DigiKey early Monday morning arrives tomorrow via FedEx Ground.
  • The VFD power subsystem test boards I ordered last Friday from OSH Park came back from the fab yesterday (Tuesday) and delivery is promised by 8pm Friday.
  • The FPGA power subsystem test boards I ordered from OSH Park Monday just came back from the fab today (Wednesday). USPS says they'll arrive by 8pm Saturday.

Monday, April 23, 2018

Conductive Pad Keypad footprint

When you press a key on the Canon P170-DH keypad, it presses a conductive rubber "pill" against a pattern of exposed tracks on the PC board, shorting the tracks together. Here's a link to a good description of how this works. This is what that looks like on the original Canon PCB:

This happens to be the largest of the patterns, under the most used key: the Plus ("+") key. It's about 8mm in diameter, while the smaller pattern is about 6mm. What looks like a single gold track meandering through the hole in the solder mask is actually the bare board between two tan-colored conductive carbon patterns. I don't know why they chose this odd pattern; perhaps it's for reliability, or has something to do with the way carbon tracks are constructed. For the longest time I had no idea what purpose the two exposed pads at 10 and 4 o'clock served, but I've come to believe these are test pads to allow testing of the carbon tracks and have nothing to do with the operation of the keypad.

Friday, April 20, 2018

FPGA Power circuitry

Earlier this week I finished the schematic for the FPGA power circuit using the LTC3607 dual buck regulator rather than the pair of TPS62170s as had been my plan. This evening I finished up the test board for this circuit and sent it off to OSH Park for fabrication. I expect to get it back before the first weekend in May.

Here's an image of the PCB, measuring 2" wide by 1.5" high:

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 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.