+/*
+ * The remaining source code implements the PC library, which accepts
+ * sample data from API callers, and provides detector results as they
+ * become available after seeing input data.
+ *
+ * TODO items, known constraints
+ * - Counters in the IRMP core logic and the library wrapper are 32bit
+ * only. In the strictest sense they only need to cover the span of
+ * an IR frame. In the PC side library case they need to cover "a
+ * detection phase", which happens to be under calling applications'
+ * control. The library shall not mess with the core's internal state,
+ * and may even not be able to reliably tell whether detection of a
+ * frame started in the core. Fortunately the 32bit counters only roll
+ * over after some 2.5 days at the highest available sample rate. So
+ * this limitation is not a blocker.
+ * - The IRMP core keeps internal state in global variables. Which is
+ * appropriate for MCU configurations. For the PC library use case
+ * this constraint prevents concurrency, only a single data stream
+ * can get processed at any time. This limitation can get addressed
+ * later, making the flexible and featureful IRMP detection available
+ * in the first place is considered highly desirable, and is a great
+ * improvement in itself.
+ * - The detection of IR frames from buffered data is both limited and
+ * complicated at the same time. The routine re-uses the caller's
+ * buffer _and_ internal state across multiple calls. Thus windowed
+ * operation over a larger set of input data is not available. The
+ * API lacks a flag for failed detection, thus applications need to
+ * guess from always returned payload data.
+ * - Is it worth adding a "detection in progress" query to the API? Is
+ * the information available to the library wrapper, and reliable?
+ * Shall applications be able to "poll" the started, and completed
+ * state for streamed operation including periodic state resets which
+ * won't interfere with pending detection? (It's assumed that this
+ * is only required when feeding single values in individual calls is
+ * found to be rather expensive.
+ * - Some of the result data reflects the core's internal presentation
+ * while there is no declaration in the library's API. This violates
+ * API layers, and needs to get addressed properly.
+ * - The IRMP core logic (strictly speaking the specific details of
+ * preprocessor symbol arrangements in the current implementation)
+ * appears to assume either to run on an MCU and capture IR signals
+ * from hardware pins, falling back to AVR if no other platform got
+ * detected. Or assumes to run on a (desktop) PC, and automatically
+ * enables ANALYZE mode, which results in lots of stdio traffic that
+ * is undesirable for application code which uses the shared library
+ * for strict detection purposes but no further analysis or research.
+ * It's a pity that turning off ANALYZE switches to MCU mode, and that
+ * keeping ANALYZE enabled but silencing the output is rather messy
+ * and touches the innards of the core logic (the irmp.c source file
+ * and its dependency header files).
+ */