Updates from Pigweed Live - 29 January 2024

[Chad Norvell]

What is Pigweed? It's an open-source project that makes embedded software development efficient, robust, and heck, even delightful, for projects ranging from weekend Arduino experiments to commercial products selling in the millions.

How do I learn more? Visit pigweed.dev to find our documentation, join our Discord server to chat with the Pigweed team and contributors, and join us at Pigweed Live meeting on Mondays at 1 pm Pacific Time. Add yourself to the announcement email list to get this newsletter and calendar invitations to Pigweed Live.

// LGTM

Catch up on recent updates

It's been almost two months since the last session of Pigweed Live, but the Pigweed changelog has continued to be updated every two weeks. Check it out to see what we've been working on in the meantime!

Learn more ↗︎

Bazel support updates

Pigweed now supports Bazel 7.0 as well as the use of Python 3.11 in Bazel projects. We also have new documentation on using Pigweed modules in existing Bazel projects.

New async module

Learn pw_async2 is a successor to pw_async that moves beyond the original's callback-oriented model to an "informed poll"-oriented model, similar to Rust futures. It provides a much more natural thread-like API without the need for dynamic allocation, while maintaining interoperability with C++20 coroutines and Rust async fn. The SEED was accepted and now implementation has started.

Learn more ↗︎

New allocators module

pw_allocator has now been integrated into several downstream projects, and has already found bugs in some of those projects thanks to its memory allocation checks!

pw_allocator is more than just an allocator—it's actually a set of building blocks for creating allocators. See the discussion below for more context on how useful this flexibility can be.

Learn more ↗︎

IDE support improvements

The Pigweed Visual Studio Code extension is now useful for general Pigweed development after some months of incubation with specific downstream teams.

Useful features you should know about:

• You can launch activated terminals by running the Pigweed: Launch Activated Terminal command. There's a similar command to bootstrap your environment.

• You can submit bugs to the Pigweed bug tracker without missing a beat with Pigweed: File Bug.

• Downstream projects can define sets of extensions that developers need to have installed & activated, ensuring a consistent developer environment for their teams.

// TODO

Starting transfers at non-zero offsets in pw_transfer

This feature will enable several use cases, including resumable transfers. The same logic updates pw_blob_store to allow resumable writes.

Rust pw_log improvements

Work is in progress to support "untyped" and core::fmt style logs in the Rust implementation of pw_log.

clang on Windows

Initial groundwork is starting on supporting clang on Windows.

// SEEDs

What are SEEDs?

A SEED is Pigweed's version of an RFC. Learn more about the SEED process and check out the status of all SEEDs at the SEED index.

Active SEEDs

• 0116: Sockets - CL Doc

  • Still being drafted, will be ready for discussion in a few weeks

• 0117: pw_i3c - CL Doc

  • Actively soliciting feedback—are you using i3c? Provide your opinions!

// FYI

Using pw_allocator with a vendor-provided heap

• Suppose you get a heap from vendor code and would normally wrap it with new/delete/unique_ptr/etc. APIs – how can we leverage pw_allocator in this situation?

• pw_allocator is designed exactly for this, since it’s an interface first (that also includes some optional implementations). You can wrap your vendor provided heap/allocator with pw_allocator interfaces and get all the functionality that pw_allocator provides

• Functionality like what?

  • Use the metrics allocator wrapper to collect data and pass through to a vendor-provided allocator

  • Create separate pools for different purposes, instead of just one big global allocator – maybe some pools have stricter requirements

• If we're currently tracking the source code location of allocations in a custom wrapper, can we do that with pw_allocator instead?

  • We’ve thought about this in the Pigweed team but haven’t implemented it yet

  • There’s some benefit in connecting this with pw_tokenizer to get something better and more useful than just source code location

• You don’t need to introduce pw_allocator everywhere at once, just start in a few locations

When will Pigweed support C++20?

• C++20 provides more than just quality-of-life improvements – it makes it a much safer language, much better to develop with (e.g. concept, constraint)

• We’d love to move to C++20, but we would really need to drop support for C++17 to do that – otherwise we continue writing C++17 versions of things and not taking advantage of new features

• Maybe projects on stuck on old toolchains just stay on older versions of Pigweed?

  • Would formal releases help here? In practice no, fixed releases doesn't solve this problems, since projects can have many components that use different parts of Pigweed with different constraints

• A better approach could be feature flagging, e.g., you need C++20 to use certain new features

• Maybe Pigweed pushing on this can drive SoC vendors to move their toolchains forward (given the extent of Pigweed’s use in commercial products and open-source)

• Maybe certain modules keep alternate versions that continue to support C++17 – we already do this for C++14, which is only supported on a very small subset of modules

Archives