sys/irq: Add C++ wrapper using RAII

[jenswet]

Contribution description

This adds a C++ wrapper around the irq.h API. The wrapper uses RAII to accomplish a convenient and bug resistent use.

A little background: I'm currently writing my master thesis on using C++ for embedded development, at the working group that @maribu is part of. For that I will try to add better C++ support to several parts of RIOT and then do some benchmarking and metrics to compare it with the C implementation. For example, I also plan to add a wrapper around i2c, a std::cout drop-in replacement and probably some more about networks or threads.

Testing procedure

I've added a unit test to verify that the IRQ wrapper calls the original irq functions as expected. As C++ and wrapper testing isn't done much so far in this project, I've added two additional headers to ease testing:

1. #17076 - fake functions framework, already merged
2. As there is no framework for C++ unit tests yet, I've added something for this too. Unfortunately the existing frameworks like GoogleTest, CppUTest or CppUnit don't easily compile for embedded or are difficult to integrate in to the RIOT build process. That's why I wrote some (simple) helper functions and macros inspired by the above frameworks. That allows to create C++ tests based on a fixture class with set up and tear down methods. It also allows some simple assertions and is easily extendable for other use cases. It wraps some of the fff functionality too.

Both of this is obviously not required for the initial reason of this PR. But I'd like to provide unit tests for the features that I suggest to introduce where possible. So I'd appreciate some feedback on that too. If you'd prefer a PR without or different tests please let me know.

You can run the test irq_cpp locally or on the CI to test the implementation.

Please feel free to give feedback or suggest improvements!

[aabadie]

This PR also introduces the fff package. I'd like to also see a test application in C, just for it.

[jenswet]

This PR also introduces the fff package. I'd like to also see a test application in C, just for it.

@aabadie I've added a test fff_test that shows a basic test with an irq mock in C language. Is that enough or would you like to see more?

[aabadie]

I've added a test fff_test that shows a basic test with an irq mock in C language. Is that enough or would you like to see more?

Thanks! I think the addition of the fff package and the test application could into their own separate PR to simplify the review.

[aabadie]

Also make sure that you read our CONTRIBUTING guidelines and especially the section about commit conventions and about fixup commits.

[jenswet]

Thanks! I think the addition of the fff package and the test application could into their own separate PR to simplify the review.

That might be a good idea! Please check #17076. I will update this PR when the new one got feedbacked / merged.

Also make sure that you read our CONTRIBUTING guidelines and especially the section about commit conventions and about fixup commits.

Good hint, now I understood the concept of fixup commits that I often read in other PRs. Will do it correctly next time. Thanks!

[jenswet]

Rebased after #17076 got merged and added some other minor improvements.

[jenswet]

@aabadie @maribu @fjmolinas @miri64 It would be great to get some feedback on this so we can merge it. Thanks!!!

[kaspar030]

please don't put this in core/, if possible...

[miri64]

@aabadie @maribu @fjmolinas @miri64 It would be great to get some feedback on this so we can merge it. Thanks!!!

My knowledge on C++ is very limited (I looked at it last over 15 years ago) and I have no idea about RAII. So maybe the rest can have a look?

[OlegHahm]

@jenswet, @maribu, so I guess apart from the nitpicks we would be good to go here?

[jenswet]

@OlegHahm yes mostly. While working on some other C++ APIs I had some more ideas. Let's wait until I got the other parts of my thesis ready, maybe this PR can be further improved.

I will update it asap.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[benpicco]

This needs a squashing, right?

[maribu]

Yes. I fear that squashing done by anyone else except the author results in the PR being closes (likely a security feature to avoid sneaking in unrelated code while obfuscating the commit history / authorship). At least this was what happened the last two times a maintainer squashed a PR she/he didn't open.

But then again, I could just open a new PR if that happens and keep the correct authorship in the commit meta data.

[benpicco]

it worked for #12353 :innocent:

[jenswet]

Hey guys

I am sorry for the long delay in communication. I was a few months abroad without regular access to my computer. I will make the PR ready for merging asap in the next weeks.

[maribu]

@jenswet: Thx :) I the squashing (and the disabling of ESP8266) was the only thing missing. Let's see if we can get this in now.

bors merge

[bors[bot]]

:clock1: Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set.

[riot-ci]

Murdock results

:heavy_check_mark: PASSED

a9c5987fa3fc0410433d42244d0f5d36f1e4282a core/irq: Add C++ wrapper

Success	Failures	Total	Runtime
6779	0	6779	12m:36s

Artifacts

• Documentation preview

[maribu]

bors retry

[bors[bot]]

:clock1: Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set.

[maribu]

bors cancel bors merge

[bors[bot]]

:clock1: Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set.

[maribu]

bors cancel

[maribu]

bors merge

[maribu]

bors r+

[maribu]

bors retry

[maribu]

bors ping

[bors[bot]]

pong

[bors[bot]]

Already running a review