Playing with Google Pigweed

After a seeing a few posts on show up on my LinkedIn, I decided to take a peek and see what the fuss was about. And since the whole ‘work-from-home’ thing is making my weekend indistinguishable from a normal wrkday, this was a happy medium.

Let me preface by saying, Pigweed isn’t a fancy new embedded target OS. Pulling straight from the Readme,

Pigweed is an open source collection of embedded-targeted libraries — or as we like to call them, modules. These modules are building blocks and infrastructure that enable faster and more reliable development on small-footprint MMU-less 32-bit microcontrollers like the STMicroelectronics STM32L452 or the Nordic nRF52832.

Ok then…

Running some basic builds and tests

There’s a getting started guide covers what you need, the brief steps are below

1. Getting the code is pretty easy, just grab the repo here.

git clone https://pigweed.googlesource.com/pigweed/pigweed

2) Run the bootstrap.bat(or .sh for our Mac/Linux friends out there) from the root folder and it takes a few minutes to set everything up.

3) For some reason the ‘activate.bat’ refused to play well with my VSCode powershell terminal(command worked but environment variables weren’t loaded correctly so, no GN). I had to switch over to standard windows command-line. Strange, but not a big deal.

4) Configuring targets using GN had windows command-line specific corrections, use the below command to take care of spaces and quotes

gn gen out/host
gn gen out/disco --args="pw_target_config =\"//targets/stm32f429i-disc1/target_config.gni""
gn gen --args="pw_target_config =\"//targets/docs/target_config.gni"" out/docs

5) After that just run the watcher to start automatic builds/tests.

I don’t have a STM32 board to try out the flashing/multiple board tests but they’re OpenOCD based which makes it pretty flexible for other targets.

So… what next?

My original hope was I would add a PSoC6 target to the repository just to see how I could adapt this for other targets. Sadly, there is little structured documentation to help there and I’m no expert on GN builds.

Digging through the ‘target_config.gni’ file does throw a few clues as to how the system is being built e.g., the pw_boot_armv7m is the module which sets up the vector tables, memory maps and deals with interrupt handling.

Defining target specific parameters

My other minor quibble is the fact that there’s are modules like pw_sys_io_baremetal_stm32f429 which sets up the UART by using bare-metal register writes which feels hacky. I would rather just see a way to include supporting HAL libraries similar to MbedOS/FreeRTOS by Amazon. Right now, the system seems to be consciously avoiding vendor support libraries, which makes it difficult to port.

Which is to say all of this still feels….hacky

In it’s current state, I can’t convince myself of going through the effort of porting this as the architecture is still in a nascent stage. Adhering to Google Test isn’t a requirement in the embedded space(yet?), so there’s no particular rush here if you’re not within Google.

Don’t get me wrong though, there’s definitely some promise here. I particularly like having a independent test system, virtualenv’s setup for cross-platform compilers and automatic code formatting ftw!

It’s a start, and I’m looking forward to see how it takes shape in the coming months.