C++ wrappers

[helmut]

Hi,

being pretty new to ChibiOS I stumbled over the C++ wrapper, which seem rather incomplete
at the first glance. We are going to need support for C++ in our projects using ChibiOS so I was
looking into C++ support for the ChibiOS functions aswell.

Is there anyone working on the wrappers?
They look a bit abandoned, is there general interest in having ChibiOS C++ified?
If we were to take that task, how should we contribute? (Probably this is a FAQ, which I could not find an answer to!)

Helmut

[Giovanni]

Hi,

The wrapper is maintained but not actively extended, it is an area where contributions would be welcome.

What do you think is it missing?

Note that the wrapper is meant for RT, not HAL. An HAL wrapper would be another thing.

Giovanni

[helmut]

Hi,

one thing that hit me first was chThdCreateFromHeap(). And then there is no way to pass
arguments via start(), as in chThdCreateStatic(..., func, args). One reason being that chibi must
be up and running for these functions to work, so they should not be in the constructor and second
that start() is abusing the args for passing 'this'.

A virtual stop() method in ThreadReference does not make much sense to me, might be I'm missing
something (however it seems to be knowing that by itself and halts the system )

Additionally virtual destructors are missing in classes with virtual methods (which is a bad thing
to do), new() and delete() need some re-routing to the ChibiOS memory allocation functions, a makefile that
shows an optimal setup (--no-rtti, --no-exception) to reduce overhead.

We'll most probably need exceptions aswell, but that will be another issue.

Helmut
PS: how would we contribute?

[barthess]

Hi,
It is just my IMO.
I have used C++ with ChibiOS for about 2 years. C++ here gains more
problems than solves. Finally I am stuck with very limited subset
of C++ (namespaces, typed enums, virtual functions and single
level templates for functions).
Declaring new() delete() looks like bad idea too because there are
more than one memory allocator.

[Giovanni]

PS: how would we contribute?

Make your proposals here, there are several stakeholders so lets discuss first.

Then you can post code or I will give you write access to the repository if you want to maintain it directly.

Personally I think there are two ways:
1) Wrap the existing functionalities 1 to 1, following the C API closely, current approach.
2) Invent a C++ API and implement it on ChibiOS, there are already a couple of examples of API emulators: the CMSIS RTOS wrapper and the NASA OSAL wrapper. Those are located under ./os/common/abstractions. I am not aware of any C++ threading standard (for embedded) to follow.

Giovanni

[helmut]

Hi,

I think we can mostly stay with your 1:1 approach and see where it carries us.

For what barthess said:
1) we must use C++, because we'll have to integrate 50k+ lines of C++ library code.
2) we need reliable dynamic memory allocation in C++ for this
3) we need exceptions, which also needs dynamic memory.
4) we've done this before in an older version of ChibiOS (for testing) and will hopefully only migrate this kind of support.

If I understand Giovanni correctly, I'll simply post a patch here?
Against which version? Having ChibiOS on SVN won't simplify this process I fear...

Helmut
BTW: A side note about Documentation:
One could avoid the doxygen part of:
#if (CH_CFG_USE_next_super_feature == TRUE) || defined(__DOXYGEN__)
by simply using the PREDEFINED settings of doxygen, i.e. define all that is needed for documentation there ...
PREDEFINED = CH_CFG_USE_super_feature CH_CFG_USE_next_super_feature ...
This should reduce code complexity and you could even have several levels of documentation that way.
A side note for the side note: The documentation build should be done in a standard makefile, .bat files
won't work under Linux!

[Giovanni]

Just a requirement from my side: keep the wrapper free of exceptions-related code. We cannot enforce this on others because size concerns. Support for dynamic allocation is OK but should be optional and activated by the same flags already present in chconf.h.

Enhancing the current wrapper is fine for me, I don't dislike it.

Giovanni

[helmut]

Hi,

wrappers will be exception free, no problem. Dynamic allocation will be optional, but
will rely on new (which may be implemented using f.i. chHeapAlloc().)

Another questions:
Looking at class Timer and ThreadStayPoint which both have their inner references publicly
exposed and have no constructors, how are they intended to be initialized?
Has anyone ever used these?

In general all C++ wrapper classes expose their C-style underlying. Is this intentional?
I'd rather place them in the protected class section ...

Helmut

[helmut]

Ok,
just understood that virtual timers are initialized using setI(), but the trouble is, that calling
resetI() or isArmedI() with an uninitialized timer_ref potentially causes invalid memory accesses!
The same holds true for the ThreadStayPoint, resuming on uninitialized thread_ref will cause havoc.

Helmut

[Giovanni]

chVTSetI() is only a way to initialize them, there is also a normal initializer: chVTObjectInit(). You need to initialize if you are going to check the state.

There is also this ticket to consider: https://sourceforge.net/p/chibios/bugs/700/

Giovanni