I've been playing with this on a bare metal ARM target using the arm-none-eabi-gcc toolchain (in order to run rapidyml). I think rapidyml + c4core are a great combo for a small embedded system, being lightweight.

There is one issue, however, and that's regarding the use of <chrono>. This isn't well supported on bare-metal targets since getting the current time typically results in a call to the OS, or a SVC call. When compiling/linking rapidyml + c4core with -nostdlib, linking fails unless the user provides an implementation of std::chrono::high_resolution_clock::now() (ie std::chrono::_V2::system_clock::now()).

When compiling/linking with newlib (that is, omit the -nostdlib flag), it still doesn't work unless the user provides a custom implementation of `_gettimeofday'.

I'm not sure the best solution to this. Some ideas:

• Add an additional #if defined check in currtime() something like:

#elif defined(__ARM_EABI__)
	return time_type{0};

But I'm not sure what symbol to check for, because __arm__ and __ARM_EABI__ could both be set even with embedded Linux or an RTOS.

• Add a compilation flag such as "-DCOMPILE_BAREMETAL" which does the above (makes currtime() a stub returning 0 always)
• Add a compilation flag to omit compiling and including time.cpp/hpp. It seems that these functions aren't used by c4core itself, so this shouldn't interfere.
• Add compilations flags just for c4/time.cpp (or in-source __attribute__s to push flags for currtime()), so that currtime() will be optimized out before the linker sees it. Obviously, this fails if the user makes a call to currtime() or busy_wait() or exetime().

The other issue blocking usage on bare-metal systems was with fast-float, see this issue. It looks like will be addressed soon with #122 and #123

In any case, thanks for your hard work on this, and I've been enjoying using it on a small embedded system (with workarounds, which I'd love to get rid of).