Earlier this year [Skyhawkson] got ahold of an Apollo-era printed circuit board which he believes was used in a NASA test stand. He took high quality photos of both sides of the board and superimposed them atop each other. After digging into a few obsolete parts from the 1960s, he was able to trace out the connections. I ran across the project just after making schematics for the Supercon badge and petal matrix. Being on a roll, I decided to take [Skyhawkson]’s work as a starting point and create KiCad schematics. Hopefully we can figure out what this circuit board does along the way.

The board is pretty simple:

• approximately 6.5 x 4.5 inches
• 22 circuit edge connector 0.156 in pitch
• 31 ea two-terminal parts ( resistors, diodes )
• 3 ea trimmer potentiometers
• 7 ea transistors
• parts arranged in 4 columns

The first thing I did was to create a “dumb” schematic, with no logical significance other than it matched the geometry of the board. The result should match [Skyhawkson]’s diagrams ( it did ).

The next step was to unwrap the parts and connections, with the goal of making recognizable circuits. It was easy to get circuits crossed up and lose track of the original connections. When making a PCB from schematics, if you delete connections and move parts around, you have the rats nest to guide you. But when going the other way, you’re on your own.

To mitigate this, I made a placeholder PCB whose only purpose is to hold the true netlist. Having a correct PCB design provides a way to check the schematic. Go to the PCB editor, update the PCB from schematics, and run a DRC. I little cumbersome, but better than nothing.

As I first studied the diagram, I realized there are really two independent circuits on the PCB, connected by only one signal. This made unfolding and rearranging the parts easier. Not having any clue what this board did, I just untangled each transistor circuit one by one. Knowing the basic function of a transistor, there are only so many ways to orient each one that makes any sense. Soon, familiar circuits began to appear from the jumble of parts.

Obviously this card belonged in a rack system with an interconnecting back plane. We have no idea what these signals do, and that made it more challenging. In addition, there are some signals that seem unnecessary. My speculation is that these are used in PCB testing, test equipment checkout, or perhaps to operate the board in different modes.

Parts

When researching the parts on the board, [Skyhawkson] found a few that were difficult to pin down. By coincidence, even the sketchy details of two such parts gives us clues to the board’s purpose.

Current Sense Resistor

R125 is an X.1 ohm, 3 W wirewound resistor. [Skyhawkson] had to peel back conformal coating to find even a partial part number. This resistor conforms to the MIL-R-26/C, RW59 specification. Many other RWxx resistors from this family are still used today, but RW59 seems to have been dropped a long time ago. It might have already been on the way out back in 1962.

Having such low resistance, perhaps 0.1 ohms, it seems likely to be a current sensing resistor. The high wattage reinforces that idea. But I later realized that almost all of the resistors on the board are 3 W, which I guess was the norm back then. This makes the 3 W power rating of R125 less special. Adding to the mystery, one leg of R125 leaves the board. But lacking a better explanation, I will stick to my initial guess that this is a current sense circuit.

Temperature Compensated Zener

There are several zener diodes on the board, but only one of them has an elusive datasheet — the 1N2625. After combing through old semiconductor data books from the 1960s, I found some interesting information on this Zener diode in Motorola’s Semiconductor Data Book from 1966. This diode comes from a family of temperature compensated Zener diodes 1N262x. Ignoring temperature grades, there are three basic ones: 22, 23, and 24, which differ only in their temperature coefficient. But there are two more special ones in the series: 25 and 26, which sport even better TC values and have a slightly lower zener voltage of 9.4 vs 9.7 V.

If you try to track this part over the decades, it seems to have become / been rolled into the 1N937 series that, though obsolete, is still available from Microchip. But this 60 year old zener has a TC that is an order of magnitude better than its modern equivalent. This suggests that the 9.4 V reference voltage on this PCB plays a key role.

Best Guess

I see a precision voltage reference, what looks like a differential amplifier, and also know that the board was used in NASA test equipment. I immediately think “sensor interface card” — most certainly designed to interface with a strain gauge. A strain gauge is wired into one leg ( or more ) of a Wheatstone bridge excited by a precision voltage. The bridge imbalance is proportional to the strain of the material being measured. The weak signal is usually boosted by a differential amplifier followed by other conditioning circuits. And if your sensor interface card is flexible, you can also configure it to read RTDs, thermocouples, and other kinds of sensors as well. Sensor interface circuitry would certainly be a common need throughout NASA ground test equipment back in the 1960s, and today as well.

Excitation Driver

If my analysis is correct, the supply takes about +80 VDC on the input before all three zener voltage references become active. That seems a bit high. But back in the 60s, maybe this was a common B+ voltage. But, if you only supply say 28 VDC, transistors Q101 and Q102 bypass the top and bottom zeners. Maybe all that circuitry is there just to allow a wide range of input voltages?

There seems to be a lot of unused edge connector signals, or at least signals I don’t understand, associated with this section. I have a nagging feeling that some of these might be used by other parts of the system to check that the interface card is present and working, and that the cables to the sensor have not shorted nor broken.

Differential Input Amplifier

On the Hackaday.io project discussion section, hacker [Lauri Pirttiaho] pointed out that four of the transistors appeared to make up a differential amplifier. He is right I believe, and if he got that by just glancing at the PCB photos, I’m really impressed. The circuit appears to drive a load located off-board, presumably generating a voltage to be recorded, plotted, converted to digital data, and/or viewed on meters. The operating point is biased by a current set by the zener and transistor combination CR109 / Q107, but the return path for that current isn’t clear. I guessed it returns through the output power supply return, as drawn on the schematics, but am not 100% confident.

This CR109 / Q107 bias circuit can be turned off by grounding edge connector signal NET17, thus disabling the difference amplifier output transistors. This could be a useful feature for multiplexing a group of sensors boards onto a single using A2D converter. Instrumentation quality A2D converters were probably more expensive back in 1962, so this seems like a reasonably guess.

Edge Connector, Nets

I connected the external signals up to a 22-pin edge-card connector schematic symbol and labeled them according to my guesses. The hope was that their positions along the card edge connector would give me additional insight. They did not. Lacking any descriptive names for the nets, [Skyhawkson] numbered them. I retained that same scheme here. Note that nets 1 through 21 are go to the card edge, and nets 22 through 36 are internal to the board. He numbered the net names sequentially along the card edge connector. But because of the keying gap in the connector, the net numbers don’t match the connector pin number from pin 5 onwards. For example, connector pin 6 is NET05 and so on.

Mystery Trimming

The section with the R125 current sense resistor also has a bunch of trimmer potentiometers, and almost all of the connections go off board. It might be use to adjust the gain and offset of the output signal. I also wonder these could somehow comprise the fixed legs of the bridge. I’m at a loss here.

Lessons Learned and Next Steps?

This KiCad reverse engineering project has been both easier and more difficult than previous ones. The PCB is so simple by today’s standards, and [Skyhawkson] has already done the tedious task of tracing out the connections. He’s also identified all the parts on the board and prepared a bill of materials. This was a great starting point.

In previous projects, I knew the schematic ahead of time or else I had a reasonable idea of the PCB’s functionality and flow of signals. In the case of this Apollo-era board, I knew nothing. It was just a bunch of transistors and supporting discrete components. It made me appreciate modern IC packages, where knowing a part number gives big clues about its function.

Hints can be found in even the simplest parts. Figuring out that diode 1N2625 was a zener with 0.0002 % temperature coefficient was a big clue that a precision voltage reference was present. The low value R125 is probably a current sensing resistor, but what current is being sensed is still not clear.

The redrawn schematics are found in this GitHub repository. If you have any further ideas about how this circuit board might have been used, please let us know in the comments below. If we get enough additional information, maybe [Skyhawkson] can be convinced to power up the board and test it out.

Last week I completed the SAO flower badge redrawing task, making a complete KiCad project. Most of the SAO petals are already released as KiCad projects, except for the Petal Matrix. The design features 56 LEDs arranged in eight spiral arms radiating from the center. What it does not feature are straight lines, right angles, nor parts placed on a regular grid.

Importing into KiCad

Grep Those Positons

I first wanted to only read the data from the LEDs for analysis, and I didn’t need the full Kicad + Python scripting for that. Using grep on the PCB file, you get a text file that can be easily parsed to get the numbers. I confirmed that the LED placements were truly as irregular as they looked.

My biggest worry was how obtain and re-apply the positions and angles of the LEDs, given the irregular layout of the spiral arms. Just like the random angles of six SAO connector on the badge board, [Voja] doesn’t disappoint on this board, either. I fired up Python and used Matplotlib to get a visual perspective of the randomness of the placements, as one does. Due to the overall shape of the arms, there is a general trend to the numbers. But no obvious equation is discernable.

It was obvious that I needed a script of some sort to locate 56 new KiCad LED footprints onto the board. (Spoiler: I was wrong.) Theoretically I could have processed the PCB text file with bash or Python, creating a modified file. Since I only needed to change a few numbers, this wasn’t completely out of the question. But that is inelegant. It was time to get familiar with the KiCad + Python scripting capabilities. I dug in with gusto, but came away baffled.

KiCad’s Python Console to the Rescue — NOT

This being a one-time task for one specific PCB, writing a KiCad plugin didn’t seem appropriate. Instead, hacking around in the KiCad Python console looked like the way to go. But I didn’t work well for quick experimenting. You open the KiCad PCB console within the PCB editor. But when the console boots up, it doesn’t know anything about the currently loaded PCB. You need to import the Kicad Python interface library, and then open the PCB file. Also, the current state of the Python REPL and the command history are not maintained between restarts of KiCad. I don’t see any advantages of using the built-in Python console over just running a script in your usual Python environment.

Clearly there is a use case for this console. By all appearances, a lot of effort has gone into building up this capability. It appears to be full of features that must be valuable to some users and/or developers. Perhaps I should have stuck with it longer and figured it out.

KiCad Python Script Outside KiCad

This seemed like the perfect solution. The buzz in the community is that modern KiCad versions interface very well with Python. I’ve also been impressed with the improved KiCad project documentation on recent years. “This is going to be easy”, I thought.

First thing to note, the KiCad v8 interface library works only with Python 3.9. I run pyenv on my computers and already have 3.9 installed — check. However, you cannot just do a pip install kicad-something-or-other... to get the KiCad python interface library. These libraries come bundled within the KiCad distribution. Furthermore, they only work with a custom built version of Python 3.9 that is also included in the bundle. While I haven’t encountered this situation before, I figured out you can make pyenv point to a Python that has been installed outside of pyenv. But before I got that working, I made another discovery.

The Python API is not “officially” supported. KiCad has announced that the current Simplified Wrapper and Interface Generator-based Python interface bindings are slated to be deprecated. They are to be replaced by Inter-Process Communication-based bindings in Feb 2026. This tidbit of news coincided with learning of a similar 3rd party library.

Introducing KiUtils

Many people were asking questions about including external pip-installed modules from within the KiCad Python console. This confounded my search results, until I hit upon someone using the KiUtils package to solve the same problem I was having. Armed with this tool, I was up and running in no time. To be fair, I susepct KiUtils may also break when KiCad switched from SWIG to IPC interface, but KiUtils was so much easier to get up and running, I stuck with it.

I wrote a Python script to extract all the information I needed for the LEDs. The next step was to apply those values to the 56 new KiCad LED footprints to place each one in the correct position and orientation. As I searched for an example of writing a PCB file from KiUtils, I saw issue #113, “Broken as of KiCAD 8?”, on the KiUtils GitHub repository. Looks like KiUtils is already broken for v8 files. While I was able to read data from my v8 PCB file, it is reported that KiCad v8 cannot read files written by KiUtils.

Scripting Not Needed — DOH

At a dead end, I was about to hand place all the LEDs manually when I realized I could do it from inside KiCad. My excursions into KiCad and Python scripting were all for naught. The LED footprints had been imported from Altium Circuit Maker as one single footprint per LED (as opposed to some parts which convert as one footprint per pad). This single realization made the problem trivial. I just needed to update footprints from the library. While this did require a few attempts to get the cathode and anodes sorted out, it was basically solved with a single mouse click.

Those Freehand Traces

The imported traces on this PCB were harder to cleanup than those on the badge board. There were a lot of disconinuities in track segments. These artifacts would work fine if you made a real PCB, but because some segment endpoints don’t precisely line up, KiCad doesn’t know they belong to the same net. Here is how these were fixed:

• Curved segments endpoints can’t be dragged like a straight line segment can. Solutions:
  • If the next track is a straight line, drag the line to connect to the curved segment.
  • If the next track is also a curve, manually route a very short track between the two endpoints.
• If you route a track broadside into a curved track, it will usually not connect as far as KiCad is concerned. The solution is to break the curved track at the desired intersection, and those endpoints will accept a connection.
• Some end segments were not connected to a pad. These were fixed by either dragging or routing a short trace.

Applying these rules over and over again, I finaly cleared all the discontinuities. Frustratingly, the algorithm to do this task already exists in a KiCad function: Tools -> Cleanup Graphics... -> Fix Discontinuities in Board Outline, and an accompanying tolerance field specified as a length in millimeters. But this operation, as noted in the its name, is restricted to lines on the Edge.Cuts layer.

PCB vs Picture

When I was all done, I noticed a detail in the photo of the Petal Matrix PCB assembly from the Hackaday reveal article. That board (sitting on a rock) has six debugging / expansion test points connected to the six pins of the SAO connector. But in the Altium Circuit Maker PCB design, there are only two pads, A and B. These connect to the two auxiliary input pins of the AS1115 chip. I don’t know which is correct. (Editor’s note: they were just there for debugging.) If you use this project to build one of these boards, edit it according to your needs.

Conclusion

The SAO Petal Matrix redrawn KiCad project can be found over at this GitHub repository. It isn’t easy to work backwards using KiCad from the PCB to the schematic. I certainly wouldn’t want to reverse engineer a 9U VME board this way. But for many smaller projects, it isn’t an unreasonable task, either. You can also use much simpler tools to get the job done. Earlier this year over on Hackaday.io, user [Skyhawkson] did a gread job backing out schematics from an Apollo-era PCB with Microsoft Paint 3D — a tool released in 2017 and just discontinued last week.

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.