A few weeks ago, Raspberry Pi released the Pico W, an update to the Pico development board with the addition of a wifi chip and trace antenna. As I’ve been using the Pico for many of my projects, I’m excited by the possibility of adding wireless connectivity.

I program in Ada, so I want to add support for the Pico’s wireless controller, CYW43439 to my driver library.

First, a reality check; Raspberry Pi is going to continue producing new microcontrollers and development boards with new features. They’ve put an immense amount of effort into their C/C++ SDK and MicroPython libraries. Do I really want to continue reimplementing their drivers in Ada? Would I be better off just generating a wrapper around their SDK? The Pico SDK is pretty heavily dependent on the CMake build infrastructure right now, so I’d have to figure out how to make that work with Ada. The generated Ada bindings from C code are usually pretty awkward to work with, so I’d have to write a fair bit of code either way. For now I’m going to keep going with my native Ada libraries, but I’m going to keep asking myself if this is a worthwhile effort when good vendor libraries exist.

The wireless chip they’ve chosen, CYW43439, is a beast. Infineon (formerly Cypress, formerly Broadcom) have a public datasheet, which contains information useful to PCB designers and test engineers as well as some rather confusing timing diagrams that contain no actual timing information. The Pico W has an RP2040 connected to the CYW43439 with the "gSPI" interface with both the transmit and receive signals multiplexed onto a single microcontroller pin.

The RP2040’s PIO should be perfect for implementing this sort of odd serial protocol, but I found it to be quite frustrating in this case. The CS, CLK, and DAT signals are not accessible from any test pad or trace that I can find on the Pico W, so I can’t get a logic analyzer connected while the RP2040 is communicating with the CYW43439. I considered buying a standalone module that uses this chip so that I could connect it to some pins I can probe, but I figured I’d try working blind first. I configured the PIO to use some of the Pico’s exposed pins and connected a logic analyzer. At the very least, I can get the CS, CLK and DAT transmit timing to look correct before trying to talk to the wireless controller.

The datasheet says that the device needs up to 50ms after pulling REG_ON high before it’ll respond to gSPI commands. The host should poll the registers beginning at address 0x14 for the value 0xFEEDBEAD. Once that value is read correctly, a test write/readback at address 0x18 verifies that the gSPI bus is working and the CYW43439 is powered up and ready to accept commands.

That 0xFEEDBEAD value led to some interesting search results; this protocol has been used in Broadcom wireless chipsets as far back as the venerable WRT54G router. There are many open source drivers of varying quality for this family of chips and it seems that Broadcom/Cypress/Infineon kept the host interface mostly the same over the years, only adding new commands when necessary. I found a very detailed writeup about reverse engineering the firmware for these chips, which was quite interesting, if not immediately useful.

The Pico SDK has a PIO driver for gSPI, so I spent a lot of time reading that code and trying to understand it. They use a single PIO SM to control the DAT signal, with CLK configured as a side-set. To begin a transfer, the host CPU resets the SM and executes set pindirs, 1 to configure DAT as an output, then sets the x register to the number of bits to write and y to the number of bits to read. These instructions are not included in the main PIO program as they’re not timing critical and executing them from the CPU saves on PIO memory, which is only 32 instructions. The PIO program shifts one bit out on the DAT pin, toggles the CLK sideset, then decrements the x register. Once x reaches zero, DAT is reconfigured as an input and the SM starts shifting in bits, decrementing y as it goes.

This seems fairly reasonable. We can control the number of bits per word by changing the x and y registers before beginning a transaction. The host CPU needs to get involved after each TX/RX cycle to reset the pindirs, x, and y registers and pull CS high if the transaction has completed. The driver code uses DMA to send data to the PIO, which doesn’t seem like a huge benefit when the CPU is going to intervene after every word transferred. The DMA controller can do byte swapping, which may be useful for big endian network data, but I’m not sure if it’s worth the trouble in this case.

I decided that I’d rather use up a bit more PIO memory and have separate programs for read and write that do their own setting of pindirs and the x register. The CPU still needs to control CS though, which is inconvenient. I really wish the PIO had just a few more Delay/Side-Set bits so that we could have longer delays in PIO programs for timing the CS "back porch."

The CYW43439 datasheet also illustrates a "Read-Write" transaction, where CS stays low between the Write and Read commands. The datasheet says there should be a "fixed delay" in between read and write in this mode. The diagram shows four clock edges during this delay time and there is a bus configuration register for delay timing, but I wasn’t able to get this working. As far as I know, this is just an optimization, not a required bus mode.

Speaking of optimizations, the CYW43439 defaults to 16-bit words on the gSPI interface, but the command to switch to 32-bit mode is 2 16-bit words long, so we can send that as the first command and never have to deal with changing word sizes. As far as I can tell, this is what every driver does.

After spending far too long trying to make my program block until the SM finished clocking bits and wondering if the idle polarity of the clock really matters, I got a logic analyzer trace that looked reasonably close to what the datasheet specifies. I changed my pin config to connect the PIO to the wireless controller and got some signs of life! Polling the 0x14 register returned 0xED 0xFE, which was half of my expected 0xFEEDBEAD with swapped bytes. I played with the PIO SHIFTCTRL register a bit and got a successful read of 0xFEEDBEAD. Surprisingly, the test write/readback worked too! I guess that means I have a working gSPI implementation on PIO! I noticed that the Pico SDK runs the PIO at 33 MHz for this interface, but my test program fails at anything faster than 20 MHz. I guess I still need to get a probe on those DAT, CLK, and CS traces to get the timing right. The datasheet says this interface can run at 50 MHz, but we can worry about that later.

Now that I can communicate with the CYW43439, I started looking at cyw43-driver more seriously. The datasheet makes no mention of most of the CYW43439’s internal registers and this is not a trivial driver, so I’m going to try to interoperate with this C driver from Ada, rather than trying to rewrite it. It looks like this driver calls a bunch of symbols like cyw43_hal_pin_config that we need to provide. Luckily, exporting Ada procedures as symbols that conform to the C ABI is easy.

procedure HAL_Pin_Config
  (Pin, Mode, Pull, Alt : Interfaces.C.int)
with Export, Convention => C, External_Name => "cyw43_hal_pin_config";

On the more complex side of things, we need a TCP/IP stack. cyw43 only contains bindings for LwIP and that’s what Pico SDK uses, so I went searching for Ada bindings for LwIP. Surely someone else has tried to do embedded networking in Ada before, right?

Right! I found a directory called ipstack buried in the SPARK unit tests. If the README is to be believed, this is a formally verified rewrite of a large chunk of LwIP in SPARK. Excellent! This code predates the Alire package manager by many years, so I spent some time understanding the existing Makefiles and hierarchy of GPRbuild projects and got the whole mess built as an Alire crate I can use as a dependency. There’s a lot of room for improvement here, but I want to get some packets flowing before I start trying to improve the IP implementation. If this works at all, I’ll be impressed.

The ipstack library only has two hardware drivers: a minimal TUN/TAP implementation for testing on a Linux host and a driver for the ancient NE2000 ISA card. I spent many hours learning about firewalls with OpenBSD on a 486 with a couple of NE2K cards in my formative years, so this brings back fond memories. Back in the day, the NE2000 was not the fastest network card you could buy, but it was cheap, reliable, and rock solid under Linux, which was far from a guarantee for any peripheral back then.

So now I have three bits of code to string together: my Ada/PIO gSPI implementation, the SPARK ipstack, and cyw43-driver.

Stay tuned for my next post, where I might actually get something working.