
Pigweed: A Collection of Embedded Libraries - proppy
https://opensource.googleblog.com/2020/03/pigweed-collection-of-embedded-libraries.html
======
LennyWhiteJr
> This is a huge disparity from web development workflows where file watchers
> are prevalent—you save a file and instantly see the results of the change.

> Pigweed’s pw_watch module solves this inefficiency directly, providing a
> watcher that automatically invokes a build when a file is saved, and also
> runs the specific tests affected by the code changes. This drastically
> reduces the edit-compile-flash-test cycle for changes.

Eh, no thanks. Web dev environments can get away with this because the
turnaround time is so quick, but even a medium sized embedded C++ project can
easily take minutes to build, plus 30+ seconds to download, even with a
debugger.

Please don't try to bring webdev workflows into the embedded space. This isn't
javascript.

~~~
Espressosaurus
Yeah, I'm trying to reconcile their objectives against a several minute build
time (for just the deepest embedded target) up to a 15 minute build time (for
the driver at the next level up) or even (god forbid) the top level target,
which is a multi-hour build. And you want to kick that off every time I save
one file? Are you nuts?

And then pushing it to a target and testing it. Again, are you nuts? I work in
the real world, with physical devices that can and will break if I misuse
them. Blindly flashing my latest unfinished change is a great way to wreck
equipment, even if it happens to compile.

Maybe it makes sense for something like the MCU on a network switch. But it
doesn't sound like something I want anywhere near any codebase I'm committing
to.

Handling the dependency management and environment _is_ nice though. That part
is absolutely a low-grade irritation that would be nice to get rid of.

------
jschwartzi
Correct me if I'm wrong, but this seems to run unit tests on the embedded
target. Why?

In the embedded space I've found unit tests to mostly be useful for testing
logic and algorithms but not terribly useful for testing hardware integration,
which is where all the really painful and tedious problems happen. If the unit
test passes on the board but fails on your host it's likely due to a compiler
bug or a bug in the MCU, and you usually just work around those.

What would be more interesting is creating an environment to support manual
and automated integration and system-level testing. I haven't seen such a
system in practice because such systems require a very lengthy and painful
characterization of the system under test. They also require hardware support,
meaning a tool needs to be integrated with the software to interface with and
measure the output of the system under test. These can range from simple
I2c-based GPIO expanders for monitoring and controlling IO lines to pressure
and flow meters for pneumatic measurements, or current probes for
instantaneous and aggregate power draw measurements. This is more like
laboratory automation so I think a lot of software people try to avoid doing
these things.

Do you have any plans to implement APIs that might enable development of such
a system in the future?

~~~
sgtnoodle
I've found a lot of value in running unit tests on target hardware. For one
thing, it means you can actually include peripheral drivers in the test. Also,
as you said, embedded compilers tend to be more buggy than host compilers.
I've actually found compiler bugs through embedded unit testing.

~~~
ctz
Peripheral unit tests are best run off-target in my experience. We mock out
all register accesses for host builds, then can write unit tests that validate
we write registers in the right order, handle states that are in-spec but hard
to get the real peripheral in to, etc. Things that may work a million times in
a row on real hardware, but then regularly fail in the field on a few million
devices.

Running them on-target is more of an integration test -- useful too,
obviously, but gives a quite low level of assurance.

~~~
jschwartzi
Yes, exactly. Once you're testing integration with hardware you're integration
testing, not unit testing as it's not pure software dictating the outcome of
the test.

------
kettro
Been following Pigweed for a while now internally. Great testing
infrastructure!

------
leggomylibro
When I saw this, I thought Google was making a vendor-independent HAL and I
got excited.

But it looks like it's just a set of small plug-ins like statically-allocated
strings and easy tests.

I guess that's cool too, but...eh. I agree with others who say that it seems
counterproductive to try to run embedded integration tests every time a file
is saved. This sort of looks like a solution in search of a problem.

Also, when has Google ever supported a novel project like this over the long
term? I'm not too eager to buy into something that'll get discontinued a few
years down the line.

------
elo3210
I'm just starting to wrap my head around embedded development but what kind of
audience is this aimed at?

Is it bare-metal embedded developers? Can it work with yocto or buildroot for
those who rely on deploying linux on embedded?

~~~
fbkr
It's for bare metal microcontroller development. It _can_ work for those, but
you probably already have relatively better alternatives for those
environments.

