Out of curiosity, I redrew the Supercon Vectorscope badge schematics in KiCad last year. As you might suspect, going from PCB to schematic is opposite to the normal design flow of KiCad and most other PCB design tools. As a result, the schematics and PCB of the Vectorscope project were not really linked. I decided to try it again this year, but with the added goal of making a complete KiCad project. As usual, [Voja] provided a well drawn schematic diagram in PDF and CorelDRAW formats, and a PCB design using Altium’s Circuit Maker format (CSPcbDoc file). And for reference, this year I’m using KiCad v8 versus v7 last year.

Importing into KiCad

This went smoothly. KiCad imports Altium files, as I discovered last year. Converting the graphic lines to traces was easier than before, since the graphical lines are deleted in the conversion process. There was a file organizational quirk, however. I made a new, empty project and imported the Circuit Maker PCB file. It wasn’t obvious at first, but the importing action didn’t make use the new project I had just made. Instead, it created a completely new project in the directory holding the imported Circuit Maker file. This caused a lot of head scratching when I was editing the symbol and footprint library table files, and couldn’t figure out why my edits weren’t being seen by KiCad.  I’m not sure what the logic of this is, was an easy fix once you know what’s going on. I simply copied everything from the imported project and pasted it in my new, empty project.

While hardly necessary for this design, you can also import graphics into a KiCad schematic in a similar manner to the PCB editor. First, convert the CorelDRAW file into DXF or SVG — I used InkScape to make an SVG. Next do Import -> Graphics in the Kicad schematic editor. However, you immediately realize that, unlike the PCB editor, the schematic editor doesn’t have any concept of drawing layers. As a work around, you can instead import graphics into a new symbol, and place this symbol on a blank page. I’m not sure how helpful this would be in tracing out schematics in a real world scenario, since I just drew mine from scratch. But it’s worth trying if you have complex schematics.

Note: this didn’t work perfectly, however. For some reason, the text doesn’t survive being imported into KiCad. I attribute this to my poor InkScape skills rather than a shortcoming in KiCad or CorelDRAW. Despite having no text, I put this symbol on its own page in sheet two of the schematic, just for reference to see how it can be done.

Just like last year, the footprints in the Circuit Maker PCB file were imported into KiCad in a seemingly random manner. Some footprints import as expected. Others are imported such that each individual pad is a standalone footprint. This didn’t cause me any problems, since I made all new footprints by modifying standard KiCad ones. But if you wanted to save such a footprint-per-pad part into a single KiCad footprint, it would take a bit more effort to get right.

Recreating Schematics and Parts

After redrawing the schematics, I focused on getting the part footprints sorted out. I did them methodically one by one. The process went as follows for each part:

• Start with the equivalent footprint from a KiCad library
• Duplicate it into a local project library
• Add the text SAO to the footprint name to avoid confusion.
• Position and align the part on the PCB atop the imported footprint
• Note and adjust for any differences — pad size and/or shape, etc.
• Update the part in the project library
• Attach it to the schematic symbols in the usual manner.
• Delete the imported original footprint (can be  tricky to select)

Some parts were more interesting than others. For example, the six SAO connectors are placed at various non-obvious angles around the perimeter. I see that [Voja] slipped up once — the angle between connectors 4 and 5 is at a definitely non-oddball angle of 60 degrees.

SAO Angle Difference
#1   326  102  6->1
#2     8   42  1->2
#3    61   53  2->3
#4   118   57  3->4
#5   178   60  4->5
#6   224   46  5->6

With all this complete, the PCB artwork consists of all new footprints but uses the original traces. I needed to tweak a few traces here and there, but hopefully without detracting too much from [Voja]’s style. Speaking of style, for those interested in giving that free-hand look to hand-routed tracks in KiCad, check the options in the Interactive Router Settings menu. Choose the Highlight collisions / Free angle mode and set the PCB grid to a very small value. Free sketch away.

Glitches

I used two photos of the actual board to check when something wasn’t clear. One such puzzle was the 3-pad SMT solder ball jumper. This was shown on the schematic and on the fully assembled PCB, but it was not in the Circuit Maker design files. I assumed that the schematics and photos were the truth, and the PCB artwork was a previous revision. There is a chance that I got it backwards, but it’s an easy to fix if so. Adding the missing jumper took a bit of guesswork regarding the new and adjusted traces, because they were hard to see and/or underneath parts in the photo. This redrawn design may differ slightly in appearance but not in functionality.

DRC checks took a little more iterating than usual, and at one point I did something to break the edge cuts layer. The irregular features on this PCB didn’t help matters, but I eventually got everything cleaned up.

I had some trouble sometimes assigning nets to the traces. If I was lucky, putting the KiCad footprint on top of the traces assigned them their net names. Other times, I had traces which I had to manually assign to a net. This operation seemed to work sporatically, and I couldn’t figure out why. I was missing a mode that I remember from another decade in a PCB tool, maybe PCAD?, where you would first click on a net. Then you just clicked on any number of other items to stitch them into the net. In KiCad it is not that simple, but understandable given the less-frequent need for this functionality.

You may notice the thru hole leads on the 3D render are way too long. Manufacturers provide 3D files describing the part as they are shipped, which reasonably includes the long leads. They are only trimmed at installation. The virtual technician inside KiCad’s 3D viewer works at inhuman speeds, but has had limited training. She can install or remove all through hold or SMT parts on the board, in the blink of an eye. She can reposition eight lamps and change the background color in mere seconds. These are tasks that would occupy a human technician for hours. But she doesn’t know how to trim the leads off of thru hole parts. Maybe that will come in future versions.

Project Libraries

I like to extract all symbols, part footprints, and 3D files into separate project libraries when the design wraps up. KiCad experts will point out that for several versions now this is not necessary. All (or most) of this information is now stored in the design files, alghouth with one exception — the 3D files. Even so, I still feel safer making these project libraries, probably because I understand the process.

KiCad can now do this with a built-in function. See the Export -> Symbols to New Library and Export -> Footprints to New Library in the schematic and PCB editors, respectively. These actions give you the option to additionally change all references in the design to use this new library. This didn’t work completely for me, for reasons unclear. Eventually I just manually edited the sch and pcb file and fixed the library names with a search and replace operation.

Hint: When configuring project libraries in KiCad, I always give them a nickname that begins with a dot. For example, .badge24 or .stumbler. This always puts project libraries at the top of the long list of libraries, and it makes it easier to do manual search and replaces in the design files if needed.

What about 3D files, you say? That isn’t built into KiCad, but have no fear. [Mitja Nemec] has you covered with the Archive 3D Models KiCad plugin. It was trivial to activate and use in KiCad’s Plugin and Content Manager.

All Done

In the end, the design passed all DRCs, and I could run Update PCB from Schematic... without errors. I went out on a limb and immediately placed an order for five PCBs, hoping I hadn’t overlooked something. But it’s only US$9.00 risk. They are on the way from China as I type this.

All the files can be found in this GitHub repo. If you find any errors, raise an issue there. I have not done this procedure for any of the SAO petals, but when I do, I will place a link in the repository.

I recently got one of the new RP2040-based Bus Pirate 5 (BP5), a multi-purpose interface debugging and testing tool. Scanning the various such tools in my toolbox already: an Analog Discovery 2, a new Glasgow Interface Explorer, and a couple of pyboards, I realized they all had a Python or MicroPython user interface. A few people on the BP5 forums had tossed around the idea of MicroPython, and it just so happened that I was experimenting with building beta versions of MicroPython for a RP2350 board at the time. Naturally, I started wondering, “just how hard can it be to get MicroPython running on the BP5?”

The Lazy Approach

Rather than duplicating the BP5 firmware functionality, I decided to ignore it completely and go with existing MicroPython capabilities. I planned to just make a simple set of board definition files — perhaps Board Support Package (BSP) is a better term? I’ve done this a dozen times before for development and custom boards. Then write a collection of MicroPython modules to conform to the unique aspects in the BP5 hardware. As user [torwag] over on the Bus Pirate forums said back in March:

Micropython comes already with some modules and enough functions to get some stuff out-of-the-box working. E.g. the infamous version of “hello world” for microcontrollers aka led-blinking.

The Tailoring

The main interfaces to the BP5’s RP2040 MCU were apparently done with the Pico reference design in mind. That is why  you can just load and run the latest RP2 MicroPython build without defining a custom board (note that this only worked with the current v1.24, and failed when I tried to load v1.23 using Thonny,  something I did not investigate further). But there are some things that can be done to tweak the build, so I did go ahead and make set of custom board definition files for the BP5.

First I tried to tell MicroPython about the larger QSPI flash. This is a standard thing in configuring MicroPython, but I found an issue with the RP2. The Pico C SDK has a 2 GiB hard-coded flash limit in a linker script. One can fix this by hand editing and rebuilding the SDK, something I decided to leave for later. So I did all my testing using just 2 GiB of the flash.

Several of the customizations that I would normally make, like the serial interface pins assignments, were not necessary. The customization I did make was for help files. Since the intended application of this project is a manual debugging, I wanted the modules and functions to have help text. By default, MicroPython builds on the RP2 do not enable __doc__ strings, but they can be re-enabled with a compiler directive. Unfortunately, while the __doc__ strings are now retained, the build-in help() function doesn’t print them like CPython. The workaround is to add a help() function to each class. So instead of help(adc) you’t type add.help().

Finally, I wanted to add a board top-level help screen, appending to the existing RP2 port help screen. That turned out to be much harder to do, and in the end, I just gave up doing that in the BP5 board definition folder. Instead, I kludged a couple of files in the RP2 port directory — ugly, but this is just an experiment after all.

The Interfaces

These are the basic interfaces of the BP5 hardware, and all of them are already or easily supported in MicroPython.

• Eight Buffered IO pins
• Programmable Power Supply
• NAND flash 1 Gbit
• IPS LCD screen, 320 x 240 pixels
• 18 RGB LEDs
• Push button

Going for some instant gratification, I decided to drive the chain of LEDs around the perimeter of the unit first. The RP2 port of MicroPython already has a NeoPixel class. Once I sorted out the chained shift register I/O expansion circuitry, I was blinking LEDs in no time. The eight main buffered I/O signals posed a bit more of a challenge, because there are bidirectional logic level translators on each pin. After writing a I/O pin wrapper class around the regular MP Pin class to handle that aspect of the hardware, I realized that wasn’t quite enough.

But the digital I/O signals on the BP5 aren’t useful until you also control the adjustable voltage reference rail. That led to the Power supply class next, which in turn led to the Analog to Digital class to handle ADC operations. To do this, you need to control the analog MUX. And you need to drive the 74HC595 output expander shift register to select the desired analog MUX channel. No more instant gratification.

The shift register was pretty easy, as I have done this before. The only thing I noted was that there is no feedback, so you can’t read the current state. This requires instead that you keep a shadow register of the current output expander state.

Ian Lesnet, former Hackaday writer and creator of the Bus Pirate, did a great job documenting all of these hardware sections of the design. The resulting power supply circuit is quite flexible. In brief, voltage and current control are done using PWM outputs, and actual voltage and current are sensed using the RP2040’s internal ADCs via the MUX. In addition, a programmable current limit threshold triggers a power supply shutdown, which can be overridden or reset as desired.

The Display

The BP5 uses a two inch IPS TFT LCD having 240 x 320 pixel resolution. It is controlled using a Sitronix ST7789 over SPI. Having driven similar setups before from MicroPython, this was pretty easy. At first. I used the ST7789 library by Russ Hughes. The display was up and displaying text and running a few demo examples in short order.

The NAND Flash

Turning attention to the Micron MT29F1G01A 1 Gib (128 MiB) NAND flash next, I ran into some difficulty. Peter Hinch’s memory chip driver library seemed like a good start. But this chip isn’t on the list of already tested chips. I changed the scan function to recognized the Micron ID manufacturer’s byte codes, but after configuring the correct chip size, sector size, and block size parameters, it still didn’t work. After finally asking for help, Mr Hinch explained that my problem was the large 138 KiB block size of this chip. His library buffers one entire block, and 138 KiB is just too big for most microprocessors.

He pointed me to a non-buffered SPI block device driver by Robert Hammelrath. I tried this briefly, but gave up after a few hours because I was spending too much time on this chip. This is a solvable problem, but not strictly needed for this goals of this experimental project.

The Images

Speaking of wasting time, I spent way too much time on this part of the project. Not because it was necessary, but just because it was just cool. My idea was a pong-like demo where an icon moves around the screen, rebounding off the screen edges. These LCD screen driver chips use a packed pixel format, RGB565. I found a tool on GitHub called rgb565-converter which converts PNG images to and from RGB565 format in C++ format. I forked and heavily modified this to generate Python code as well, in addition to 4-bit grayscale format as well. The animated GIF shows this in action.

The Wrap-up

I enjoyed making this project, and learned a few more things about MicroPython along the way. I knew that the STM32 and the ESP8266 / ESP32 families had been supported by MicroPython almost since the beginning, and that the Pico RP2040 was a relative newcomer to the ecosystem. But I was surprised when I stumbled on this talk by founder Damien George about the history of the project at the 2023 PyCon Australia conference. He shows some statistics collected over 8 years of downloads broken down by microprocessor family. The RP2040 has been extremely popular since its introduction, quickly surpassing all other families.

Which begs the question, does the idea of MicroPython on the Bus Pirate even make sense? The existing C-based Bus Pirate firmware is now well established and works well for its intended purpose — quick explorations of an interface from the command line. Would a alternate MicroPython build benefit the community or just waste people’s limited development hours?

There could be some way to create an MicroPython implementation without duplicating a lot of code. The existing BP5 firmware could be treated as a library, and compiled with various C to MicroPython shim functions to create an extensively customized build. That is beyond my MicroPython experience for now, but it might be worth consideration.

Another way would be just build a set of “big Python” classes to represent the BP5 on the desktop. This module would talk to the BP5 using the existing serial / USB port protocol, potentially requiring no firmware modifications at all. This seems like a good idea in general, since it allows users to easily script operations from the desktop using Python, and still retain the original capabilities of the BP5 in standalone operation.

The code for this project and associated documentation can be found here on GitHub. You can build your own binary if you want, but one is provided in the repository. And as [torwag] said back in March, you can just run the factory RP2040 MicroPython as well. In my testing, the only thing you’ll miss are the help messages.

If you want to learn more about MicroPython, visit their website and GitHub repository. Pre-built binaries are available for many standard development boards, and instructions on building it for a custom boards are quite clear and easy to follow. I’ve heard rumors that docker containers may be available soon, to make the building process even easier. Visit the Bus Pirate website and corresponding GitHub repository to learn more about the latest Bus Pirate 5 project.

Hackaday’s own Tom Nardi did an extensive hands-on review of BP5 upon its release the release of the Bus Pirate 5 back in February. Also Arya Voronova has written several articles on MicroPython, including this one on the eleventh anniversary of the project. Do you use MicroPython? What’s your take on the idea of using it with the Bus Pirate 5?

[Hunter Adams] has written a secondary bootloader for the RP2040 that uses an IR link and can be extended to behave like a polite worm virus. This allows the easy updating of a large cluster of co-located RP2040-based controllers. This could be handy in applications like swarm robotics or virtual cattle fencing. The project he demonstrates in the two videos ( below the break ) uses a pair of IR transmitters/receivers. But he purposely wrote the boot loader to be independent of the serial link, which could be infrared, radio, audio, or just wires.

Not only did [Hunter] make a boot loader, but he documented the entire boot process of the RP2040 chip. Whether or not you need a secondary bootloader, this is an excellent resource for understanding how the RP2040 responds to power cycling and resets. The boot loader code is available at his GitHub repository.

You may recall that [Hunter] is the lecturer of Cornell University’s Designing with Microcontroller classes, whom we’ve mentioned before. We’ve also covered some of his students’ projects as well, like these air drums and this CoreXY pen plotter.

As I walked into the huge high bay that was to be my part-time office for the next couple of years, I was greeted by all manner of abandoned equipment haphazardly scattered around the room. As I later learned, this place was a graveyard for old research projects, cast aside to be later gutted for parts or forgotten entirely. This was my first day on the job as a co-op student at the Georgia Tech Engineering Experiment Station (EES, since renamed to GTRI). The engineer who gave me the orientation tour that day pointed to a dusty electronic rack in one corner of the room. Steve said my job would be to bring that old minicomputer back to life. Once running, I would operate it as directed by the radar researchers and scientists in our group. Thus began a journey that resulted in an Arctic adventure two years later.

The Equipment

The computer in question was a Data General (DG) mini computer. DG was founded by former Digital Equipment Corporation (DEC) employees in the 1960s. They introduced the 16-bit Nova computer in 1969 to compete with DEC’s PDP-8. I was gawking at a fully-equipped Nova 2 system which had been introduced in 1975. This machine and its accessories occupied two full racks, with an adjacent printer and a table with a terminal and pen plotter. There was little to no documentation. Just to turn it on, I had to pester engineers until I found one who could teach me the necessary front-panel switch incantation to boot it up.

Not all Novas are the same, as they were avaialble in various configurations and could also be upgraded in the field. That said, the basic specifications of this machine were as follows:

• 16-bit CPU
• 64 Kb magnetic core memory
• Floating Point Arithmetic Unit
• Ten-slot chassis
• Two 9-track Tape Drives
  • Dual density
  • phase-encoded or NRZI
  • up to 10-1/2 in reels
• Two Diablo Systems Hard Disks, each with
  • one fixed 5 MB platter
  • one removeable 5 MB platter
  • Paper Tape puncher / reader
• GE Terminet Quasi-Line Printer
• Nicholet Zeta Pen Plotter
• ADM-3A Terminal

At twenty years old, this was a dream come true. I had programmed a TRS-80 in high school which is a very hands-on experience. I had also programmed in Fortran using the Georgia Tech central mainframe computer, which was the complete opposite of hands-on. Enshrined behind glass walls, you handed punched cards to the operator and waited around for your printouts. The notion of having a “big” computer all to myself was both exciting and a bit scary.

Who is Fred?

Everyone fondly called this computer “Fred Nova”. The story I heard was that the system was initially procured by a researcher named Fred Dyer. But when I recently tried to track this story down, it wasn’t so clear. Back in the 1970s, these Nova mini-computers were both popular and affordable. There were quite a number of them at EES, used all around in different laboratories on different projects. You could almost say they were the IBM PC or the Raspberry Pi of the era — cheap enough to own multiple systems, and veratile enough to pass around to new projects as old ones wrapped up. I’m pretty sure that this particular Nova originated from a project called Earth Resources Data Analysis System (ERDAS). This was a NASA-sponsored project to study the decline of peach tree orchards throughout the Southeastern United States.

Switches and Blinkin’ Lights

The first hurdle I overcame was how do you boot such a computer? The TRS-80 had a power switch and it magically came to life. The campus mainframe never turned off as far as I knew. The Nova minicomputer just sat there doing nothing when you turned it on. In modern computers, we have the BIOS which can be configured to boot from different devices, and there are tools like GRand Unified Bootloader (GRUB) to select between different OS partitions. Doing the same thing on the Nova was simpler but not at all obvious. There was a short program one had to key into the computer via the front panel. One of the values in the program selected the boot device. But I quickly discovered that this model had a special option for lazy operators. You only switched in the address of the device you wanted to boot from, and toggled the Program Load switch. This loaded a short boot program from the optional boot PROM, thus saving the painstaking process of toggling in a dozen or so words.

What’s with all the switch toggling and blinking lights? Well this is the most basic way to interact with the computer, speaking its own language. The Nova family of computers had 16-bit words, and the front panel had a row of 16 toggle switches. Using these switches, you could store any value you wanted into any address, first toggling in the address into a register (indicated by lamps) followed by toggling in the data and loading it. If you are entering a program, thankfully the address register auto-incremented with each data load. The lamps showed the current address and data. While this process is tedious to the extreme, I found it really helpful in learning the computer inner workings. I also gained an deep appreciation for keyboard-based memory monitors.

One quirk of the Nova, and other machines of the era, is that the the panel and all the supporting ecosystem of documents used octal notation. This seems a strange choice for 16-bit word sizes. Indeed, by the time I encountered the Nova, most of the industry was using hexadecimal. Jumping back and forth between hex and octal was annoying, and I’m glad octal eventially fell out of favor. Hexadecimal makes more sense, given that word sizes of modern machines are almost always an integer multiple of the 4-bit hex nibbles,

Base eight is just like base ten, really — if you’re missing two fingers!  – Tom Lehrer

Magnetic Core Memory

At the time, I was vaguely aware of magnetic core memory — just to the extent that it keeps its contents when power is removed. But I wondered if that property was helpful in the context of a mini-computer system, since that there were so many connected accessories. So one day I did a test. I fired up a large compilation that I knew would take a more than ten minutes. Once started, I went around to the back of the machine and yanked the big plug out of the wall. The front panel lights went out and all motors whirred down to a stop. Satisfied that it was really off, I went to lunch. Coming back an hour later, I plugged it back into the wall. To my surprise, it picked right up where it left off — comilation completed as if nothing had happened. Later, one of the engineers told me there was a small option board installed on this model which sensed power being removed, gaving the OS a few milliseconds to save a handful of CPU registers to scratchpad core memory.

Pseudo-line Printer

At the campus mainframe, the printer was a true line printer that struck one entire line of text with one whack. This Nova’s printer was similar, but unlike anything I’ve seen before or since. It was 120 columns wide with 120 tightly-packed, individually-controlled hammers. In front of these hammers ran a long belt holding type fingers. The fingers contained a complete set of the printable characters, repeated a few times along its length. This belt was in continuous motion during operation. When printing, the printer would buffer one line of text, and then fire all the necessary hammers in sequence with the rotating belt of type fingers, each hammer striking it’s assigned letter at the precise moment that letter passed by. This isn’t exactly a line printer, but it sounded almost like one. Instead of one whack per line, there was a very quick burst of sound each line — like a stuttering swarm of angry mechanical wasps. It was a fascinating mechanism to behold and hear.

Nicholet Zeta Pen Plotter

Many of the assignments that I received from the researchers involved producing plots, and I used the plotter like that in the advertisement above — notice one feature is a starting price of less than $6000. The researchers would give me a complicated formula and / or measured experimental data, and request various plots. Quite often these programs would run for hours just to generate one plot, sometimes requiring overnight shift work. One scientist was writing a book at the time, and I made dozens of graphs and charts for him. For the next couple of decades, I would find those same graphs in various radar reference books. One plotter program they asked me to write was actually the opposite of a plotter — it was to input already printed graphs. One of the “pens” you could get was in fact a clear “bomb sight”, complete with cross-hairs. You would manually steer the pen over a desired point on the paper, line it up exactly, enter the value in user units on the termina, and press OK to digitize the point. That program turned out to be surprisingly simple. You first digitize the origin and a point along each axis, then just enter all the desired points along each curve of interest.

Programming

Most of the programming I did on this computer was in Fortran, although the EES used a preprocessor called Fortran Language Extended Control Structures ( FLECS ). FLECS took away some of the annoying aspects of Fortran by providing structured programming features, like IF-THEN-ELSE structures, DO-WHILE-UNTIL loops, and internal procedures (kind of like an inline function). But the most interesting project, the subject of this article series, was using assembly language to control custom hardware in order to record radar measurement data — in the frozen Arctic. I will begin covering that in part two.

The team of [Michael] and [Chimdi] from Cornell’s Designing with Microcontrollers (ECE 4760) Fall 2023 session designed a version of Simon Says on an RP2040 which they call Pico Says. It uses UDP packets over WiFi to communicate between the players, and supports VGA graphics for output. Each player’s hardware consists of a Pico W module plus a control panel containing the four LEDs and buttons ( red, green, yellow, and blue ) plus send and reset buttons.

For purposes of this lab, the modules were build on a solderless breadboard and used perfboard for the control panels. They weren’t entirely happy with their choice of UDP because they experienced frequent datagram dropouts in the noisy environment of the microcontroller lab. They also planned to implement sound effects, but ran out of time after spending too much time on the WiFi implementation, and had to drop that feature. In the end, however, they wrapped up their project and demonstrated a working game. We can only speculate whether this bonus lesson in resource management was intended by [Dr. Hunter Adams] or not.

Two ECE 4760 course references are highlighted in the write-up that helped them jump-start the project: the UDP and VGA examples for the Pico. These are good links to put in your RP2020 toolbox for future projects, in addition to the ECE 4760 course home page itself. We’ve covered several of these projects recently, as well as the curriculum switch from the Microchip PIC32MX-based Microstick II to the RP2040 last Spring.

When I saw this year’s Supercon Vectorscope badge, I decided that I had to build one for myself. Since I couldn’t attend in-person, I immediately got the PCBs and parts on order. Noting that the GitHub repository only had the KiCad PCB file and not the associated schematics and project file, I assumed this was because everyone was in a rush during the days leading up to Supercon weekend. I later learned, however, that there really wasn’t a KiCad project — the original design was done in Circuit Maker and the PCB was converted into KiCad. I thought, “how hard can this be?” and decided to try my hand at completing the KiCad project.

Fortunately I didn’t have to start from scratch. The PCB schematics were provided, although only as image files. They are nicely laid out and fortunately don’t suffer the scourge of many schematics these days — “visual net lists” that are neither good schematics nor useful net lists. To the contrary, these schematics, while having a slightly unorthodox top to bottom flow, are an example of good schematic design.

Graphical Lines to PCB Traces

The first thing I took a look at was the features on the PCB file, since I was hoping to extract the net names from the traces. Unfortunately, when I looked at the traces, they were just graphical lines. I knew from previous digging on the KiCad user forums that going backwards from a PCB to a schematic is an unnatural workflow. But I was surprised that there in recent versions of KiCad (I am using v7) there is a feature to convert graphical lines into traces.

One non-obvious quirk to be aware of — this operation duplicates the selected the graphical lines before converting them into traces, resulting overlapping elements. This can be confusing, because the newly-created trace is presented by PCBNEW as being underneath the original graphical line, making it appear that the conversion failed. The solution is to immediately delete the selected items, and the converted tracks will remain. You can do this on an entire board at once by disabling everything except graphical items in the selection filter and just select an entire layer for conversion.

Part Footprints

When designing a PCB, the task of mapping the schematic symbols into their corresponding physical footprints can be tedious. Most modern CAD tools with their corresponding parts management schemes make this process easier than ever, but it can still be a headache when you are using parts not in the libraries. We’re going backwards in this design, so I wasn’t quite sure what problems might exist. But a quick glance at the PCB file shows that the parts on the board are really footprints. This seems promising, so let’s move on to making schematics.

Automatic Schematic Generation?

The usual design flow is from schematics to PCB, whether you’re using a CAD tool or doing everything by hand. Changes to a schematic are reflected on the PCB layout. Modern PCB CAD tools can update a PCB design automatically from the schematics, updating the net list and adding and/or removing parts as needed. These tools even take a stab at placing any new parts for you. Even if this is only a jumbled cluster of footprints, it’s easier than adding each part manually. But can you go the other direction?

There are also long-established processes for going the other direction, from PCB to the schematics, which have been around longer than computerized CAD tools. Perhaps the most common of these is called back annotation. Once the layout is substantially complete, the designer will re-sequence the reference designators on the board so that they appear in some order and are easy to find by people working on the PCB. We often skip this step for the kinds of small boards people make today, but if you’re making a 9U Eurocard design that is some 350 mm square, you really need to re-sequence the reference designators and back annotate the schematic.

Another example of this backwards flow is gate swapping, so-named because it was very common in old designs using 74-series TTL logic chips. These chips have multiple gates per chip, single logic gates with multiple inputs, or both. Fortunately, CAD tools such as KiCad have provisions for these as well.

But we have the complete opposite of the normal “have a schematic and want to populate a new blank PCB” situation. Can I get KiCad to similarly populate a schematic from an existing PCB, no matter how ugly and disorganized it would be? Conceptually it doesn’t seem far fetched, given the existing KiCad capabilities. But in practice, the answer is no.

Make Schematics

Not unexpectedly, I needed to re-draw these schematics from scratch. Fortunately, this project doesn’t have a lot of parts and many of those parts are standard and found in KiCad or my own libraries. Equipped with the original documentation, I proceeded to draw the schematics in KiCad. Rather than making an exact duplicate of the existing schematics, I decided to rearrange the flow of the circuit into the more familiar left-to-right direction.

I started with just the main chips and components, ignoring connections and discrete components at first. Some of the parts weren’t in my libraries and had to be constructed in the KiCad symbol editor. I normally start with a large schematic sheet, realizing the page can always be resized later if needed ( I guessed A3, which turned out to be correct ). With all the chips on the page, you have to move things around until the visual flow on the page describes the actual logical flow of the design. Similar to placing components on a new PCB layout, there is no clear-cut process to place schematic symbols on a blank page. But here are some general concepts that I’ve learned over the years that I find helpful:

1. Take a step back from circuitry, and consider the inputs, outputs, and functionality of the overall design as if it were a black box.
2. Flow goes from left to right, inputs on left, outputs on right.
3. Connectors go on the sheet edges, or for large designs, put all connectors on page 1.
4. Group circuits together by function on the page, or for large designs, into hierarchical sheets.
5. Avoid signal-name-only hidden connections (those without a wire) when possible — try to arrange the parts so all pins can be connected by wires.
6. Use signal buses when applicable and when it helps the visual flow of the circuit.

There are many exceptions and contradictions within these guidelines. And the quality of the results can be subjective — give the same circuit, two different engineers could both prepare two different but good schematics.

Know Your Tools, Tweak Your Symbols

If you’ve ever sketched a circuit on paper, you usually make chips starting from an empty rectangle and then add signals where they are needed to make things flow. For many chips, like an 8-bit latch, the logical arrangement for your circuit matches up with the standard symbol diagrams provided by the manufacturer and/or your CAD tool libraries. But this is far from universal, especially when it comes to complex chips like microprocessors or FPGAs.

Don’t be afraid to tweak the schematic symbols to match your needs if necessary (being sure to use a local project-specific copy of the symbol). Remember the multiple-gates-per-IC feature of your EDA tool, like a hex inverter or a quad comparator package. This can be used to break up large chips into smaller manageable chunks. This is often used to separate the power supply pins of large chips into a separate symbols. But you can be further subdivide the chip into smaller symbols as needed by the overall signal flow of your design.

But probably the most helpful tweak is to simply rearrange the location of pins on the symbol and its size to better match your circuit. Consider the schematic symbol of a Raspberry Pi Pico module, which is arranged in a familiar pattern by GPIO number. Following that is the same Pico module after being tweaked to fit into the redrawn Vectorscope schematics.

Wrapup

There were a few issues between the original schematics and the PCB layout, but those have been sorted out. Some of the part footprints on the PCB are not footprints after all. Instead, they appear as a bunch of independent pads. And some parts have a discrepancy between the PCB pattern and the parts purchased from the BOM.

Just a few of the nets on the original schematic have names, and the rest are just blank. In the schematics, I tried to pick reasonable net names for the nets. I think this will be helpful when I eventually make the connection between the schematics the PCB.

At this point, I’ve completed what I wanted to in the beginning — make a KiCad schematic for the Vectorscope project. The KiCad project is not 100% consistent, but I have dug into the few missing pieces and solving those issues is not going to be a huge effort. These issues are explained in the readme of the project’s GitHub repository.

If you like Nixie tubes and/or DIY calculators, checkout this interesting talk from the HP Handheld Conference in Orlando last month by [Eric Smith] from Brouhaha and [John Doran] from Time Fracture. For 20-some years, [Eric] and the late [Richard Ottosen] have been incrementally developing various DIY calculators — this paper from the 2005 HHC conference is an excellent overview of the early project. [John] got one of those early DIY calculators and set about modifying it to use Nixie tubes. However, he got distracted by other things and set it aside — until reviving it earlier this year and enlisting [Eric]’s aid.

This presentation goes over the hardware aspects of the design. Unlike the earlier PIC-based DIY calculators, they decided to use a WCH RISC-V processor this time around. The calculator’s architecture is intentionally modular, with the display and keyboard housed in completely separate enclosures communicating by a serial interface. If the bulkiness alone doesn’t exclude it from being pocket-sized, the 170 VDC power supply and 1/2 W per digit power consumption certainly does. This modularity does lend itself to DIYers replacing the display, or the keyboard, with something different. [Eric] wants to build a mechanical flip-digit display for his unit. As for the software, [Eric] reviews the firmware approach and some future upgrades, such as making it programmable and emulating other flavors of HP calculators.

If you’re embarking on a similar project yourself, check out this talk and take notes — there are a lot of interesting tidbits on using Nixie tubes in the 21st century. If [Eric]’s name sounds familiar, you may know him from the Nonpareil calculator software used on many emulators and DIY calculator projects, one of which we covered some years ago. [John] is also a long-time tinkerer, and we wrote about his gorgeous D16/M HCMOS computer system back in 2012. Thanks to [Stephen Walters] for sending in the tip.