amp-embedded-infra-lib VS Ceedling

Have a look here: https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/cmake/emil_test_helpers.cmake where we use the EMIL_ENABLE_COVERAGE flag.

I can recommend having a look at: - https://github.com/philips-software/amp-embedded-infra-lib (stl-like replacement and utility library including a HAL definition - https://github.com/philips-software/amp-hal-st (HAL implementation for STs based on EMiL HAL) - https://github.com/philips-software/amp-preview (a GUI library for STs based on above mentioned repo's)

Not to downplay your work. But, we are in the process, almost finalised, tests and all of adding this kind of support as well. But then to allow freertos to work with c++'s native threading API. https://github.com/philips-software/amp-embedded-infra-lib/tree/feature/add-osal We have a thin wrapper, and during configuration you choose: None, native, freertos or zephyr.

Everything that needs to do something is scheduled using a simple EventDispatcher.schedule(lambda) construction; adding the lambda to the event queue. If you want an example of such a system: https://github.com/philips-software/amp-embedded-infra-lib/blob/modern-cmake/infra/event/EventDispatcher.hpp

You can have a look at https://github.com/philips-software/amp-embedded-infra-lib it is a library project. So not an actual embedded teacher. Although the library is aimed at embedded usage.

If you want a good example of a full library then take a look at https://github.com/philips-software/amp-embedded-infra-lib

https://github.com/philips-software/amp-embedded-infra-lib had support for RPC over protobuf.

Unfortunately, our codebase (at work) isn't on a public github account. But I can really recommend throwtheswitch.org.

throwtheswitch.org tools are pretty interesting. They focus on C, but support C++ as well.

This is very situational, but I have recently been part of a project that does a lot of C server-side development and we have found that static linking our non-glibc dependencies has really improved our developer experience. Using ceedling's dependency plugin[1] and producing a single "statically" linked library has made our C development much closer to using a language with a more modern package manager. Don't get me wrong, if I was trying to distribute binaries to machines I didn't control I'd definitely be willing to invest in the Linux packaging "fun", but for a server-side application it's been a good choice for our team overall.

[1] https://github.com/ThrowTheSwitch/Ceedling/tree/master/plugi...