Roadmap to support AVR/8-bit chipset

[antonysigma]

(Summarizing the discussions at #105 ... Please feel free to revise the roadmap below.)

1. Wait for ISO C++26 standard to publish, which requires the standard library <stdexcept> to be part of the freestanding C++ toolchain;
2. Work with team behind the project avr-libstdcpp to include a subset of <stdexcept> features. https://github.com/modm-io/avr-libstdcpp?tab=readme-ov-file#notable-adaptions-and-limitations
3. If step 2 is blocked, convince the fmtlib team to remove the line #include <stdexcept> in the header-only library, or make it an optional #include similar to how #include <fmt/compile.h> is made optional.
4. If step 2 and 3 are blocked, convince the compile-time-init team to make #include <fmt/format.h> optional.
5. If step 2, 3, and 4 are all "no go", the feature is clearly stuck in a multi-team, multi-project stalemate. maybe we should give up on Microchip/Atmel AVR chipset support in the compile-time-init framework. (After all, the limited 16-bit address space, and the Harvard architecture may not justify cib's complexity.)
6. Or, use an outdated version without the latest features, e.g. RLE encoding of the command router, i.e. right before 🎨 Change format to use fmtlib compile-time formatting #338 .

[elbeno]

👍

IMO we are in the middle of a re-reckoning for the avr-libstdcpp claim "Some parts of the C++ standard library are not well suited for tiny bare-metal systems." It may still be true, but to a much lesser extent given the amount of stuff that is becoming usable purely at compile-time.

We don't really have to wait for C++26 for avr-libstdcpp to implement <string> (given std::string is usable constexpr in C++20) and once you have <string>, <stdexcept> needn't be far behind.

[bdeane-intel]

Update: https://wg21.link/p3295 is currently targeting C++29.

[elbeno]

Formatting with libfmt is now optional since intel/cpp-std-extensions@6f6cce7.

CIB and all its (Intel) dependencies compile with -ffreestanding on clang and GCC.

[antonysigma]

Thanks @elbeno for the update. I will test it on one of my pet projects, and will let you know if I run into issues.

Update: I am getting an internal compiler error for GCC 12.2.0. I will upgrade gcc-avr to v14 and try again.

../subprojects/compile-time-init-build/include/cib/detail/nexus_details.hpp:24:68:   required from 'constexpr const auto cib::initialized_builders<project>'
../subprojects/compile-time-init-build/include/cib/detail/nexus_details.hpp:43:9:   required from 'constexpr const auto cib::initialized<project, OnTimerInterrupt>::value'
../subprojects/compile-time-init-build/include/cib/detail/nexus_details.hpp:42:27:   required from 'struct cib::initialized<project, OnTimerInterrupt>'
../subprojects/compile-time-init-build/include/cib/nexus.hpp:26:31:   required from here
../subprojects/cpp-std-extensions/include/stdx/ct_format.hpp:270:66: internal compiler error: trying to capture 'args#0' in instantiation of generic lambda
  270 |         return (format1.template operator()<Is>(ct_format_as(FWD(args))) + ... +
      |                                                                  ^~~~
../subprojects/cpp-std-extensions/include/stdx/utility.hpp:267:42: note: in definition of macro 'FWD'
  267 | #define FWD(x) std::forward<decltype(x)>(x)

[antonysigma]

Update for @elbeno : The feature "optional fmtlib" works in principle for Atmel328p MCUs. I resolved the compiler error by upgrading to gcc16 toolchain.

I am currently stuck at enabling logging over serial port. Question: What is the new API for this line?

void log(FilenameStringType f, LineNumberType n, FmtResult const &fr)
{

    // !!! What do I call to retrieve the message ID? !!!
    //using Message = message<Level, MsgType>;
    //uint32_t const msg_id = catalog<Message>();
    const uint32_t msg_id = 0;

    // Assume number of messages < 256.
    Serial.write(static_cast<uint8_t>(msg_id & 0xff));

    fr.args.apply([](auto... args) { logArgs(args...); });
}

Source code: https://github.com/antonysigma/compile-time-init-build/blob/a2ba40b3fdd586751e42a886a05ab5f96154df74/examples/blinky/log_over_uart.hpp#L15

[elbeno]

Logging is pretty decoupled these days, basically in 3 parts:

• the builder which produces the binary format from the inputs (string ID, severity, etc)
• the string ID assignment
• the writer which takes a span over the binary data and writes it somewhere

The easiest thing to do is probably not customize (replace) the whole logger doing all of this, but customize the writer and (if you're using a custom format) the builder. That way you can just customize for your desired binary format and where the data goes; you don't have to wrangle the string IDs.

The writer is either passed as a template argument to logging::binary::config or customized on a per-log basis with the environment as at https://github.com/intel/compile-time-init-build/blob/main/include/log/catalog/encoder.hpp#L103) and it looks like this: https://github.com/intel/compile-time-init-build/blob/main/test/log/encoder.cpp#L409. The write function can be a template (over the size of span) or can take a dynamically-sized span, so one can make the tradeoff of runtime vs binary size.

A builder has a build function that produces a binary message format, like https://github.com/intel/compile-time-init-build/blob/main/include/log/catalog/mipi_builder.hpp#L119. If you're using a custom binary format you can describe it using the msg lib (like https://github.com/intel/compile-time-init-build/blob/main/include/log/catalog/mipi_messages.hpp), then the build function returns an owning message.

If you want to customize the whole logger, you still can; assuming you still want the string ID assignment & handling you'll want to do something like https://github.com/intel/compile-time-init-build/blob/main/include/log/catalog/encoder.hpp#L72.

[elbeno]

If it helps, I covered some explanation of this in my C++Now talk: https://youtu.be/DKLzboO2hwc?t=1521 (link is to the relevant timecode start)

[antonysigma]

Thanks @elbeno for the guidance. I probably will need to take a deep dive into the .query() design pattern, as well as get_string_id. I don't know enough to compile the example code examples/log/binary_custom/logger.hpp with avr-gcc.

So far, the concept valid_query_for always evaluate to false, which in turn triggers the following error:

../include/log/catalog/encoder.hpp:77:19: error: no class template named 'fn' in 'struct logging::binary::detail::to_message_t<decltype (fr.str), -1>'
   77 |             using Message = typename decltype(builder)::template convert_args<
      |                   ^~~~~~~

If you wish, I can file a separate ticket for the logging + avr-gcc integration issue. Complete log:
https://github.com/antonysigma/compile-time-init-build/actions/runs/19955616944/job/57224047455#step:12:68