The bottom line is no, but you might like to read on to find out what it is all about and see if you think I'm wrong.

I have to admit that I missed the initial announcement of Pigweed back in 2020. But if I had noticed it I would probably have dismissed it as yet another attempt to take over IoT development by creating a software system that cannot be refused - only it can. Back then, it would have looked really underdeveloped. After four years, it looks a little more convincing, but creating such a system is no small task.

This is Google's offering of "A modern embedded development suite". If you have done battle with any toolchain, you might be thinking that something simple might be better. Of course, after (mostly) winning the battle, the toolchain you know is the one to measure everything else against and there is a big cost in moving to anything else just because it's different. This is a big barrier to anything new, but this is Google and it claims:

"These components have shipped in millions of devices, including Google’s own Pixel suite of devices, Nest thermostats, DeepMind robots, as well as satellites and autonomous aerial drones."

If it's good enough for Google, it's worth a look and, with the introduction of the Pico 2, it is making a big thing about the help they have had from the Raspberry Pi team. It works with the original Pico as well, so it really isn't quite the revolution it is advertised as.

It is called Pigweed because:

"Pigweed, also known as amaranth, is a nutritious grain and leafy salad green that is also a rapidly growing weed. When developing the project that eventually became Pigweed, we wanted to find a name that was fun, playful, and reflective of how we saw Pigweed growing. Teams would start out using one module that catches their eye, and after that goes well, they’d quickly start using more."

Wikipedia says:

"Pigweed can mean any of a number of weedy plants which may be used as pig fodder"

No comment.

Whenever I encounter a new IoT development system my first question is always - what does it support. This always turns out to be a difficult question because of the desire not to have to admit how limited it is. The only time the information is easy to find is when support is so extensive that it is worth boasting about. Even when you do find the support list, you have to read the small print to discover what aspects of the device are actually fully supported. Usually the outcome is a disappointment. Pigweed isn't really an exception to this rule. It supports a few Nordic boards and the Pico. Of course, I like the Pico but there are so many other devices it could support - the ESP32, for example.

It also has to be said that Pigweed takes a very opinionated view of development. You shall use C++ and you will write tests, you will use the Bazel build system, the RTOS will be Zephyr and you will use as sophisticated a dialect of C++ as you can muster - even to understand the examples.

For example to flash an LED:

int main() {
  demo::system::Init();
  auto& rpc_server = pw::System().rpc_server();
  auto& monochrome_led = demo::system::MonochromeLed();
  static demo::BlinkyService blinky_service;
  blinky_service.Init(
      pw::System().dispatcher(), pw::System().
                 allocator(), monochrome_led);
  rpc_server.RegisterService(blinky_service);
  PW_LOG_INFO("Started blinky app; waiting for RPCs...");
  demo::system::Start();
  PW_UNREACHABLE;
}

The actual blinky_service is a bit more to the point, but still not simple. What I am getting at is that this might well be a system that is worth the steep learning curve involved in adopting all new tools and modern C++, but simple it isn't. I don't think that there is much point in even considering Pigweed unless you have the prospect of a very big project and possibly a large number of collaborators. All of its advantages seem to be at the "top" end of the project. I can find no support for a standard range of devices - no one-wire bus, no GPS, no temperature/ pressure/humidity support, no display driver, and so on. We seem to be working down at the level of basic buses - SPI, I2C and so on. This isn't good, primitive even...

Then we have the issue of trust. Having just watched Arm drop Mbed OS, choosing anything other than the basic toolchain for the hardware is looking increasingly dangerous. We all also know that Google has a reputation for dropping projects for reasons that are far from obvious. Would you trust your long-term project to Google unless what you were using was core to Google and had a number one following?

• Harry Fairhead, I-Programmer's hardware guru, is the author of Programming the Raspberry Pi Pico/W in C, Second Edition and Programming the Raspberry Pi Pico in MicroPython, Second Edition and the more advanced title, Master the Raspberry Pi Pico in C: WiFi with lwIP & mbedtls. 

More Information

Introducing the Pigweed SDK: A modern embedded development suite

Related Articles

Pico 2 Faster With More Memory And RISCier

Mbed Is Dead - Thanks Arm

Google Releases Home APIs

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info