Monday, May 22, 2017

Other insane hobbyists

Recently I've been shown that I'm not the only hobbyist with a touch of insanity.

I've already mentioned the folk behind 4004.com who have resurrected the 45-year-old Intel design for our education.

There's Robert C. Baruch, the self-named Half-Baked Maker, who is entertaining himself by reverse-engineering some old integrated circuits by stripping them layer by layer to develop a schematic diagram of their workings. This requires the use of nasty chemicals like hydrofluoric acid -- and people think I'm nuts for using tin/lead solder!

Personally, I think the person who most deserves the crazy inventor award is Sam Zeloof. He's creating working MOSFET transistors in his home laboratory. He recently acquired his own scanning electron microscope; can an unlicensed nuclear accelerator be far off?

My hat's off to you folk. You make me feel totally sane.

Monday, May 15, 2017

Packing worms into a can

Back a few years I threw the Verilog source code for the 4004 CPU at the Lattice toolchain and observed that it occupied "40% of the logic cells and one of the 16 block RAMs" of an iCE40-HX1K FPGA. From this I felt that using an iCE40-HX4K part, which is 2.75 times the size, would be plenty to implement the entire Busicom 141-PF calculator system. Of course it'd be even nicer if I could use the HX8K part, 6 times the size of the HX1K, but it's only available in a BGA.

While trying to get the comma positioning working in the VFD driver code I took a look at the resource utilizations for two potential implementations. What shocked me was not the difference, but the total size: 492 of the 1280 lookup tables (LUTs). That's 38%!

Once I caught my breath I asked myself how this compared with the Xilinx parts I've worked with. So I built the same Verilog code using Xilinx ISE 14.7, specifying a Spartan 6 chip; it used 331 LUTs. However, the Spartan 6 has 6-input LUTs, versus the 4-input LUTs of the iCE40. Trying to find a more apples-to-apples comparison I built it yet again, this time specifying the Spartan 3E chip which also has 4-input LUTs. The Spartan 3E used 320 LUTs. Advantage Xilinx, whether by better architecture, better synthesis, or both.

But what was using all these LUTs? I thought over my code and really couldn't see any real hogs. Most of the selectors in the case statements are 4-bit quantities, which should require only one LUT per output bit to implement. Looking at the Xilinx ISE Map report I noticed a section for "Utilization by Hierarchy." Excellent! I enabled the detailed Map report and reran the mapper. To my great surprise it is the Digilent Adept I/O Expansion interface that is taking up the majority of the LUTs: 205 of 331 in the LX9, and 157 of 320 in the S3E. (I don't know how to get the same statistics out of the Lattice version of Synplify Pro).

While it's certainly a relief to find my VFD driver isn't the hog I thought it was, it does point out the risk of underestimating resource utilization. The Adept interface doesn't look very complicated -- it's only about 100 lines of Verilog -- but it takes a lot of resources. For comparison, the entire 4004 CPU and one 4001 ROM, which I think of as complex, requires only 400 S3E LUTs.

So back to the choice of chips for the calculator. I found I was able to do more with ISE in a shorter time, though whether that's better integration or just greater familiarity I'm not sure. The Xilinx tools and chips seem be more efficient in their use of resources than the Lattice. Finally, I can get the Spartan 6 LX9 in a TQFP-144 package, while the iCE40-HX8K is only available in a 0.8mm-pitch BGA. Yes, mounting a BGA scares me, but more importantly it would be infeasible with this design unless I made the board with blind vias and that would really jack up the cost.

I think that settles the matter. The Lattice iCE40 series is quite reasonable to work with, if you're looking for something small, power efficient, or are willing to stick with commercial boards. The toolchain is quite acceptable, even if you do have to obtain a new (free) license every year. But for my specific needs, I think the Spartan 6 LX9 is the best fit.

Why not Altera? They make fine chips. The answer, simply put, is that I don't know Altera, I don't have any equipment to program them, and I just don't have time or interest in adding yet another variable. They do see to have quite a selection of chips in hobbyist-friendly (i.e. non-BGA) packages, though. Some other project, perhaps.

Saturday, May 13, 2017

Not too shabby

Here's the Vacuum Fluorescent Display salvaged from the Canon P170-DH calculator driven by a Lattice iCE40-HX1K FPGA through my driver test board.


Tuesday, May 9, 2017

More data, but not more understanding

I continued poking around my VFD driver test board, looking for an explanation for why I need such strong pull-down resistors on the VFD grids. I know more than I did, but I still don't understand why.

Saturday, May 6, 2017

Who ya gonna call?

Grid Driver Configuration
I decided to dig deeper into the ghost segments appearing on the VFD.

The Toshiba RN4604 I used in the anode and grid drivers contain two pre-biased bipolar transistors, one PNP and one NPN; the bias resistors are all nominally 47K ohms. Driving the CTRL input to +3.3V turns on Q1B, which drives Q1A into saturation and pulls the grid to +30V. With the CTRL input at ground Q1B and Q1A are off, and R2 pulls the VFD grid to ground. The ends of the filament swing ±2V around a point +6.8V above ground, so an inactive grid should be at least -4.8V with respect to the nearest filament segment.

I connected my oscilloscope to the VFD grid leads for the active and ghosting digits. When the active digit's grid went to +30V with respect to ground I saw the ghosting digit's grid rise to about +10V. That's about +3V wrt to the average cathode voltage, which attracts enough electrons to cause the active anode in that digit to fluoresce too. Although this is not a truly stable state and tended to dissipate over time, it appeared the pull-down resistor R2 wasn't doing its job.

Just to be sure I looked for any indication that the ghosting digit's grid driver was turning on spuriously, but I couldn't find any. The circuit is sensitive enough to turn on momentarily if you touch an undriven CTRL input, but wiring CTRL to ground didn't change the behavior. Scoping the input to the PNP transistor showed nary a wiggle even as the grid lead voltage rose.

I expected some leakage current on an inactive grid, but the datasheets I saw for ICs that had built-in pull-downs used 125K ohm resistors so I wasn't expecting much current on an inactive grid. I tried placing a second 100K ohm resistor atop the existing 100K pull-down resistor, giving an effective 50K ohm pull-down, and although that reduced the brightness of the ghost segment it didn't eliminate it. Given 10V across 100K ohms, the leakage current on the ghosting digit's grid must be about 100 uA. Hanging a through-hole 10K resistor to ground on the lead killed the ghost. That's probably excessively low, but I haven't been able to find any information on this VFD that would give an expected inactive grid current.

My best guess at this point is that there is some capacitive coupling between the grids within the tube, and it causes the adjacent grid to rise. The condition isn't stable because the charge eventually bleeds off through the pull-down resistor. But I don't really understand the mechanism at work here.

I don't have a lot of 0603 SMD resistors laying around so I decided to replace the 100K pull-downs on the grids with 10K resistors. This will cost me an extra 3mA on the active grid, but there's only one grid active at any time. Active anodes draw less than 600uA each, while there are always 2 to 9 anodes lit per active digit, so I decided to leave their pull-downs as 100K resistors.

Next I'll work on getting the FPGA to drive this thing.

Friday, May 5, 2017

Some Assembly Required

After spending an exhausting day listening to multiple presenters talking non-stop about the project at work, I was ready to do something completely different: assemble my VFD driver test board!

Here's a bare board sitting on the connectors to the Lattice iCEblink40-HX1K demo board I'm using as a driver test driver.


Thursday, May 4, 2017

Well THAT's not quite right!

The USPS delivered my PCBs from Osh Park today. They look fantastic! Except for one thing...


Tuesday, May 2, 2017

Interfacing a VFD with the Busicom emulation

Hey! Something related to the Intel 4004 for a change!

The Busicom 141-PF calculator didn't have an electronic display; its only output mechanisms were the printer and three lamps that indicated an overflow condition, a negative result, and a value stored in memory. Here's a photo of the keyboard of the 141-PF; you can see the indicator lamps along the top edge to the left of the power switch:


The Canon P170-DH calculator I selected as my base for this reconstruction has a Vacuum Fluorescent Display tube that can display 12 numeric digits plus "E", "M", and a minus sign in place of a 13th digit. Aside from not being able to display all 14 digits the 141-PF supported, this is a pretty close match. But how to make use of the display?

Some good news re Lattice

After bad-mouthing Lattice for dropping support for the USB programming interface to their iCEblink40 demo card, I got down to the business of coding my VFD Driver test board test driver.

For those who are insistent about using open-source code to the exclusion of all commercial products, there is an open-source toolchain for the iCE40 series of FPGA: Project IceStorm. That's really cool. If I was looking for an interesting hobby project this might be one, but I already have way too many irons in the fire as it is. Thus I'm using the Lattice-provided IceCube2 development environment.

IceCube2 is a fairly simple wrapper around your choice of two synthesis tools: the Lattice Synthesis Engine (LSE) and Synopsys Synplify Pro. LSE is part of the basic (free) license, while it appears that Synplify requires an extra-cost license. A "performance limited" version of Aldec Active-HDL is provided for simulation and debugging. Active-HDL is a major player in the Verilog/VHDL simulation market, and even the cripple-ware version appears to be on par with Xilinx Isim.

Normally I'd be saying "But Active-HDL won't run under Linux!" at this point, but I found a listing for it in the WineHQ database that gives it a Platinum rating. For non-geeks that means it appears to run very well under the Windows emulation environment in Linux.

I haven't tried to synthesize anything yet, but I may reconsider whether I want to put a Spartan-6 LX4 or an iCE40-HX4K in my calculator rebuild.

Friday, April 28, 2017

LatticeSemi Brokenness

While I'm ragging on vendors for their stupidity, let me turn my attention to Lattice Semiconductor and their broken support for their own demonstration boards.

I've previously written about the Lattice iCEblink40-HX1K demo board. This little board sells for $40 and has several Pmod compatible interface ports. When I designed my VFD Driver test board I decided to use this demo board (which I already own) to drive it. Now that the test boards are in fab I thought I'd load the latest iCEcube2 development environment and get started on some Verilog.

I'd forgotten that the last time I tried to program this board I struggled and faild to get their programming software to talk to the board, despite it having a USB programming interface on the board. This time I read the documentation more closely, and discovered that they dropped support for the on-board programming interface in 2014. Seriously? They expect you to buy one of their programming "cables" (pod) for $162.50 to program a $40 experimenter's board?

Searching the 'net I found two documented solutions. One is to load an older version of the development environment. The other is to use a set of completely open-source tools to synthesize, place-and-route, and program the chip. I'm going to use the former for simplicity.

A third possibility may be to use the Adept programming software from Digilent, as it seems Lattice used their tech for the programming interface on the iCEblink40 series of demo boards.

The newer iCEstick and iCE40-HX8K breakout board uses a non-proprietary FT-2232H for the USB interface, and doesn't suffer from this stupidity. If you want to play with a Lattice demo board, avoid the iCEblink40 series!

Wednesday, April 26, 2017

Osh Stencils solder stencil

It takes much less time to make a solder stencil than it does to fabricate a PCB. As proof (as if proof was needed), here's the solder stencil I ordered from Osh Stencils late Sunday evening:

Sunday, April 23, 2017

VFD Driver test board ordered

This evening I added a ground plane on the back of the board, which resolved the one unconnected airwire I'd left hanging. I then submitted the board for fabrication by Osh Park by sending them the KiCad PCB file, which avoided generating Gerber files. I've gotten used to submitting Eagle PCB layout files to PCB-Pool so I thought I'd give this a try. It seemed to work just fine.

Although the SOT-23-6 package of the RN4604 dual transistor I'm using as a driver is almost half again bigger than the SOT-363 of the RN4904, it's still a tiny thing with leads spaced only 0.95mm apart. Even building only one of these I wanted a solder stencil. Unlike PCB-Pool, who will provide stainless steel solder stencils for free, Osh Park only does PCB fabrication. So I ordered a polyamide solder stencil from Osh Stencils, which required me to generate Gerbers after all.

One of the options when ordering from Osh Stencils is how big a margin the allow around the board. The default is 1.75 inches, which increased the area from 7 square inches to over 18 sq in and nearly doubled the cost of the stencil. Reducing the margin to the minimum of 0.75 inches reduced the price significantly. Since all the SMDs are in the middle of the board I probably could have saved even more by lying about the dimensions of the board, but it wasn't worth the time.

Later this week I'll place an order from DigiKey for the parts needed to assemble the board. I won't receive the boards for a couple of weeks yet and DigiKey ships very quickly, so there's no rush to do that.

Saturday, April 22, 2017

VFD Driver test board

I decided I didn't want to design, fabricate, and assemble a complete replacement PCB for the Canon P170-DH calculator without testing the various subsystems individually first.

I've already documented the work I did prototyping the printer interface. Although that test used a PIC instead of an FPGA, I have little doubt that I can make that simple bit work with an FPGA with the addition of a couple of Schmitt trigger buffers (the PIC inputs I used have ST inputs).

Next up is the Vacuum Fluorescent Display driver. I did some static testing on my breadboard, but the idea of wiring 12 anode drivers and 13 grid drivers doesn't sound like fun. I decided this would be a good project to develop my KiCad skills.

Here's a screenshot of the board editor window (click to view a larger image):

Monday, April 17, 2017

Size matters

I repaired my hot-air soldering station with some JB Weld PlasticWeld quick-setting epoxy. I didn't try to force the edges of the split together, but rather used the epoxy to fill in the crack so as to minimize the strain on the adhesive. I'm a bit concerned that it won't hold on the slippery plastic of the air reservoir, but after curing for a couple of days it seems to have bonded quite well.

To test it out I mounted a second of my SOT-363 packages on an adapter board. It worked well enough, but I'm having serious second thoughts about using this package, and here's a graphic display of why that is:


See the large black square package at the top? That's a standard 8-pin DIP with lead spacing of 0.1 inch. Now see the itsy-bitsy, teeny-weeny 6-lead black speck in front of it? That's an RN4904 in a SOT-363 package. Yeah.

My fine-point soldering iron looks like a frelling crowbar next to that thing. Hot air wants to blow the thing away. But my attempts at laying out an array of the larger RN4604 keep running into spacing issues.

Decisions, decisions...

Thursday, March 30, 2017

Adventures in cheap tools

Sometimes there's a reason something is cheap. And "cheap" isn't always just inexpensive.

Monday, March 27, 2017

Cracking open the second calculator

I decided there was too much uncertainty in the filament drive requirements, so I reluctantly cracked open my second P170-DH calculator to confirm exactly what voltages I should be putting out. The only thing I've done to this one is pop the bottom cover off to expose the bottom of the PCB.

Friday, March 24, 2017

New VFD Filament Driver

I gave some serious thought to using the original transformer and duplicating the original power supply circuit to power my redesign of the P170-DH calculator's guts, but I decided it involved too many compromises. I don't need a +5V supply; the FPGA needs +3.3V and +1.2V. Since the filament and VFD drive supplies are derived from taps on the same transformer, adjusting the output voltage down from 5V to 3.3V would also reduce those outputs proportionately, and I have no idea what current it could supply. I gave some thought to using it solely to power the VFD while implementing separate +3.3V and +1.2V supplies, but that just seemed silly.

Monday, March 20, 2017

More VFD characteristics

I've pretty much settled on using the 12-digit vacuum fluorescent display (VFD) that came with the P170-DH calculator. Trying to squeeze a 2-line, 20-character VFD in its place is more work than I want to undertake. Besides, I'm having too much fun figuring out how to drive the original tube.

Tuesday, March 14, 2017

Canon P170-DH Teardown, part 2

Continuing with the teardown of the Canon P170-DH printing calculator, I'll look in more detail at the power supply.


As I mentioned before, the AC mains go through a 60Hz power transformer that brings the voltage down to 8 VAC (RMS). This then goes through a full-wave bridge rectifier made up from four discrete diodes and filtered with a large electrolytic capacitor. This results in an output voltage of 7.85 VDC under load, as measured on an intact calculator. This much was obvious; to learn more I really had to dig in.

Monday, March 13, 2017

Blocking Oscillator operation basics

I've reverse-engineered enough of the calculator's power supply to identify it as a blocking oscillator. Any electrical engineer would recognize this from intoductory classes, but I'm not a EE and had to poke around the 'net a bit to learn about its operation.

I often start with Wikipedia, but in this case the wiki article is terrible. It goes into great detail without first giving a basic overview of the circuit operation. Looking elsewhere I found a pretty decent description on the Integrated Publishing website starting here. The good stuff start several pages in, but I'll summarize below.

Saturday, March 11, 2017

Floppy failure

I continued my analysis of the power section of my Canon P170-DH calculator today, and recorded a series of oscilloscope screen-shots on floppy disk to document it. But when I tried to read the floppy, my USB floppy reader said the disk was corrupt. Bummer.

So I slid a new, unused floppy into the 'scope. It said the floppy was unformatted. What the...? Ok, format it! Format failure. I then tried to format another new one in my USB floppy reader, which refused. I even tried installing a real floppy drive in my Windoze machine, and that refused. Suddenly none of my floppy drives will read or write ANY of my floppy disks.

Has there been a global floppy disk failure? Sheesh!

What to do... what to do...

Wednesday, March 8, 2017

Canon P170-DH Teardown, part 1

I decided to start really tearing down my Canon P170-DH calculator. Here's the main board with the vacuum fluorescent display detached:



Sunday, March 5, 2017

P170-DH Vacuum Fluorescent Display characteristics

I've been pondering how to handle the display on the Canon P170-DH calculator I'm cannibalizing to provide keyboard input and printer output for my replica Busicom 141-PF. The Busicom calculator didn't have a display, of course; when you pressed an operation key the appropriate value was printed. The easiest thing then would be to dispense with the VFD entirely.

On the other hand, it might be nice to have the display to show what you're entering as you enter it. In a previous post here I gave thought to replacing the 12-digit VFD with a 2-line, 20-character VFD module from Noritake-Itron, which would let me display a lot of status information. However, though the height and width of the active display areas are compatible, the VFD module is much thicker than the tube of the built-in display. It's also heavier than I expected, so it'd need some structural support to keep it in place. Now I'm thinking it's more trouble than it's worth.

Another option would be to keep the existing 12-digit VFD and drive it from the same Spartan-6 FPGA that will emulate all the logic other than the CPU. This would require characterizing the existing vacuum fluorescent display tube before I remove it from the Canon calculator's electronics board. It carries a Samsung SSVD part number of INB-13SM36T but my attempts to come up with any sort of datasheet came up empty.

Saturday, March 4, 2017

KiCad stupidity

As I work on the layout of my nRF24LE1 programmer board I'm discovering all sorts of stupidity in KiCad:
  • The X coordinates increase as you move left-to-right, but the Y coordinates increase as you move from top-to-bottom. Anyone who ever took a mechanical drafting class would know that no one creates drawings that way. Drawings always start with the (0,0) coordinate in the lower left, not the upper left.
  • The PCB is drawn inside a frame that is sized to the paper you may print on (A4, US Letter, etc.). If your board doesn't fit in a US Letter (8.5" x 11.0" frame you have to select a different paper size
  • The coordinates displayed at the bottom of the window are relative to the upper left corner of the paper you might print on. Although you can set a relative origin by tapping the space bar, when placing components using the edit dialog box you can only specify relative to the upper left corner of the paper page.
  • There is a "Move Footprint Exactly" dialog box. However, this moves it relative to its current position, not to an absolute position. There is a proposed patch for this, but it will no doubt be relative to the paper origin.
  • There is a "Set Grid Origin" option. It affects only the manufacturing output but has no effect on the layout display.
  • If you draw a "graphic line or polygon", to delineate the board outline for example, you can't edit it. You can move it only by doing a rectangular area select, but if you want to change its length you can't; you have to delete the line and re-draw it.
  • There is no way to create a via other than as part of switching layers while routing a signal.
Many of these issues could be because the KiCad developers are programmers and not engineers. I say that as someone who is a programmer by education, training, and profession. In the begining, raster graphics plotted from upper left to lower right because that's the way CRT-based TVs were scanned. But I had a mechanical drafting class in 8th or 9th grade (mid 1970s), and understand that computer programs are used mostly by non-programmers.

None of this is made better by the sycophants who bleat about how KiCad is the one true way and how everyone else in the world does things wrong and we all must adapt to their broken way of doing things.

Friday, March 3, 2017

Maximum M-32TL printer width

Over my lunch break I extended my printer test program to make it easier to specify the width of the printing. It prints a sequence of numbers that make it easy to tell how many characters have been printed:


Everything works fine through 17 numeric characters (20 characters total, including the three symbol characters on the far right edge). When it attempts to print 18 numeric characters the last (left-most) two characters over-print. Attempting 19 numeric characters causes the three left-most characters to over-print. This doesn't seem to cause any mechanical problems, but I'm not planning on stress-testing this.

Clearly the limit for the Epson M-32TL printer is a total of 20 characters, composed of up to 17 numeric characters and three symbols on the right edge.


A few more printer tests

I hate leaving questions dangling, so I ran just a few more tests.


The M-32TL printer works!

It took a couple evenings of work, but I have the M-32TL printer working!


I've only done some basic testing, but as you can see from the photo above it prints the intended test output (from right-to-left: delta, multiply, black space, decimal, zero).

Wednesday, March 1, 2017

New M-32TL printer testbed

I decided I'd learned enough about the M-32TL printer in my Canon P-170DH calculator, and it was time for surgery.

There are no screws holding the printer in the calculator shell, just careful design of the shell itself. So all that remained was disconnecting the wiring. For ease of assembly these wires are glued to a small piece of plastic which holds the wires at the proper (0.1" or 2.54mm) spacing. Unfortunately this had come loose during my handling. To make it easier to connect these wires to my solderless breadboard I assembled a plug of sorts from a small piece of pad-per-hole perf-board and an 8-position pin header.

Monday, February 27, 2017

KiCad schematic and board

Over the weekend I finished up the schematic for the nRF24LE1 programmer. Here's a screenshot:

Thursday, February 23, 2017

First KiCad project

A couple of years ago I built a set of boards using the Nordic Semiconductor nRF24LE1 radio chip. These boards are designed to fit snugly into a Compact Flash card case. For programming and debugging it plugs into a standard PCB edge connector. Here's a photo of an incomplete board (this one was damaged during assembly).

When I started prototyping this project I used a nRF24LE1 breakout board plugged into a solderless breadboard. To program it I used an FTDI FT232R breakout board plugged into the same breadboard and a custom Linux program. Later, when I had completed radio boards, I used a commercially-available cable that has a 2x13 PCB edge connector on one end and a pin header socket on the other to connect the radio board to the solderless breadboard. The photo below shows both the breakout board and the radio board plugged in at the same time, which of course I wouldn't do in real life.


This worked well during initial development and testing, but the breadboard jumper wires tend to come loose with use (two loose wires are visible in this pic). It's also occupying one of my breadboards for which I have other uses. Since there is actually very little circuitry required to support the FT232R I decided a dedicated programmer board would make an excellent first KiCad project.

Thursday, February 2, 2017

I'm expanding!

By this I mean I'm expanding the scope of this blog, not my waistline.

Rather than being solely about my exploration of the Intel 4004 CPU and peripherals, I'm going to include some of my other electronic tinkerings. I'll be tagging the i4004 stuff with an appropriate label, my work with KiCad with another, etc.

I expect this will mean more frequent updating, though as a hobby it will still be dependent on what I find time to work on.

Wednesday, February 1, 2017

A very tight fit

I spent a few hours hunting around for a socket that would accept a row of pins on 2.0 mm centers. There are quite a few of them, but most are designed to accept small square pins, perhaps as wide as 0.66 mm. The pins on the Vacuum Fluorescent Display are 0.7 ±0.12 mm wide and only 0.18 mm thick. This would be trivial if I wanted to solder it directly to a PCB, but I'm not in a position to know what I need in the way of a final PCB yet, and I don't want to risk damaging the VFD by trying to removing it from a PCB.

I think I finally found one possibility: the Mill-Max 8114 series. This is a single-contact pin receptacle able to accept a pin up to 0.86 mm wide, while only being 1.65 mm wide itself. That would leave a 0.35 mm gap between pins. Not terribly wide, but wide enough to fit some sort of insulator between, if need be, to maintain spacing. Maybe a bit of heat-shrink tubing over each one? I'd hope that the centering action of the VFD's pins would make this unnecessary.

A second option is to simply solder some wires to the pins and plug them into the solderless breadboard for testing. The only bit that seems critical is the pin is connected to an on-display oscillator, which requires an RC circuit that needs to be connected close to the pin. For this I'd simply solder the resistor and capacitor directly to the oscillator pin.

Sunday, January 29, 2017

Memory is the second thing to go

It's said that as we age, your memory is the second thing to go. And I don't remember what the first one was...

Since I have new incentive to learn to use the KiCad electronic design suite, I thought I should start with a small project. Something worth doing, but small enough that I can focus on the tool rather than the project. Also something that wouldn't cost much to re-spin if I screwed it up.

One of the first that came to mind is a test board to drive the Noritake-Itron DS2029H Vacuum Fluorescent Display (VFD). The connections to this display are a row of flat fingers along the top edge, kinda like an integrated circuit, as you can see in this photo:


I'd just plug this thing into my solderless breadboard except for one thing: the fingers have a 2.00mm pitch, not the 2.54mm pitch of my breadboard. Bummer.

I'm weighing two options for PCBs. I could make a board that mates with these fingers and connects them to pins on 2.54mm (0.1 inch) centers. Then I could wire test circuits on a solderless breadboard. The other is a complete VFD test board supporting a PIC, a USB serial interface, and the 5V-to-36V boost regulator needed to drive the VFD anode. Right now I'm leaning toward the latter.

How does the title of this posting figure into this? Keep reading...

Thursday, January 26, 2017

Major changes in Eagle licensing

When I started to do PCB layout back in 2000, I looked at a number of CAD packages. As a hobbyist I tend to favor open-source products. First I looked at the gEDA suite but it looked like a collection of un-related tools that could be forced to work together. Then I looked at KiCad, but at the time it was lacking many essential functions. Eventually I found CadSoft's Eagle.

Like several other commercial PCB CAD packages, Eagle offered a "freeware" version intended for hobbyists. All of these are crippled in some way to prevent them being used for commercial purposes, but while most limited the number of holes or devices, Eagle limited only the size of the board to 100mm x 80mm and the number of layers to two. The project I wanted to do at the time was a very small 2-layer board but had a lot of holes, so this was a good fit. When that project appeared to be destined for commercial production I spent $50 to obtain the smallest commercial license for V4. I continued to use the freeware V4 and V5 for hobby projects for several years.

When I started the 4004 replica I immediately realized that making 2-layer 100mm x 80mm boards wouldn't work. Again I looked around at other products, but discovered that Eagle V6 offered a non-commercial hobbyist license that would give me 6 layers, 100mm x 160mm dimensions, and multiple schematic sheets of a size large enough for the 4004 schematic. That seemed to work well, so I spent the $160 to get it.

A few years back Farnell bought CadSoft. The initial V7.0 release had a wacko licensing scheme that had all the Eagle users upset. Eventually the outcry forced Farnell to return to the previous licensing scheme. I was content with my perpetual V6 hobbyist license, but decided to buy the V7 upgrade to get the bugfixes. All was good until this summer, when AutoDesk bought Eagle from Farnell. AutoDesk promised expanded investment that would bring all sorts of enhancements, and even promised a better pricing structure.

Beware of people who promise to "make things great", because it means they think what exists is bad. AutoDesk's "better pricing structure" changes the perpetual license to a subscription license, meaning that you have to keep paying or the product stops working. It's "better" because if you only need the product for a month you only have to pay for a month. But then if you want to go back to a project after the end of that month, you have to pay for another month. Of course you can pay for longer-term subscriptions and get better pricing, but when the subscription runs out, poof!

As anyone who has followed this blog knows, I'll work on a project for a weekend and then it may be weeks or months before I work on it again. A subscription license is a non-starter for me and folks like me. Further, the hobbyist license I have seems to have disappeared. For me to use Eagle V8 on my 4- or 6-layer boards I'd need to buy the "Professional" package at $65/mo or $500/yr. I have seen discussions where AutoDesk has talked about expanding the "Standard" package to 4 layers, but that wouldn't help with my 6-layer ID and ALU boards, and it'd still be $15/mo or $100/yr. That's not going to happen.

Thus my involvement with Eagle has nearly reached its end. My license for Eagle V7 has no termination date, and AutoDesk can't change that retroactively. I will continue to use Eagle for the 4004 boards, as most of them have already been started and there's no reason to change horses in mid-stream. But I won't be upgrading to V8, which means no bugfixes and no support for new OS releases.

What will I use in the future? KiCad has come a long way in the last 17 years, and it continues to improve. The PCB I'll need to make to fit into the shell of the P170-DH calculator is larger than the 100mm x 160mm limits of my Eagle hobbyist license, so I'd long planned to use KiCad for that. The changes in Eagle licensing simply means that instead of that being a one-off use I won't be going back to Eagle for future projects. Instead I'll focus on learning to use KiCad as well as I have Eagle.